{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 un Prometheus escalable","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traducci\u00f3n del art\u00edculo ha sido preparada especialmente para los estudiantes del curso \u00abPr\u00e1cticas y herramientas de DevOps\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 desarrollador de software, aficionado a Go y amante de resolver problemas complejos. Tambi\u00e9n es mantenedor de Prometheus y cofundador de Kubernetes SIG instrumentation. Anteriormente fue ingeniero de producci\u00f3n en SoundCloud y lider\u00f3 el equipo de monitoreo en CoreOS. Actualmente trabaja en Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 ingeniero de infraestructura en Improbable. Est\u00e1 interesado en nuevas tecnolog\u00edas y en los problemas de sistemas distribuidos. Tiene experiencia en programaci\u00f3n de bajo nivel en Intel, experiencia como contribuyente en Mesos y experiencia en SRE a nivel mundial en Improbable. Se dedica a mejorar el mundo de los microservicios. Sus tres pasiones: Golang, c\u00f3digo abierto y voleibol.<\/i><\/p>\n

Al observar nuestro producto insignia SpatialOS, puedes deducir que Improbable necesita una infraestructura de nube de alta din\u00e1mica a escala global con docenas de cl\u00fasteres de Kubernetes. Fuimos uno de los primeros en comenzar a usar el sistema de monitoreo Prometheus<\/a><\/noindex>. Prometheus es capaz de rastrear millones de m\u00e9tricas en tiempo real y viene con un poderoso lenguaje de consultas que permite extraer la informaci\u00f3n necesaria.<\/p>\n

La simplicidad y confiabilidad de Prometheus es una de sus principales ventajas. Sin embargo, al alcanzar cierta escala, nos encontramos con varias desventajas. Para abordar estos problemas, desarrollamos Thanos<\/a><\/noindex> \u2014 un proyecto de c\u00f3digo abierto creado por Improbable, para la transformaci\u00f3n fluida de los cl\u00fasteres existentes de Prometheus en un \u00fanico sistema de monitoreo con almacenamiento ilimitado de datos hist\u00f3ricos. Thanos est\u00e1 disponible en Github aqu\u00ed<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Mantente al tanto de las \u00faltimas noticias de Improbable.<\/a><\/noindex><\/p>\n

Nuestros objetivos con Thanos<\/h2>\n

\nA cierta escala, surgen problemas que superan las capacidades de un Prometheus vanilla. \u00bfC\u00f3mo almacenar de manera confiable y econ\u00f3mica petabytes de datos hist\u00f3ricos? \u00bfEs posible hacerlo sin comprometer los tiempos de respuesta de las consultas? \u00bfSe puede acceder a todas las m\u00e9tricas ubicadas en diferentes servidores de Prometheus mediante una sola solicitud API? \u00bfEs posible combinar de alguna manera los datos replicados recopilados con Prometheus HA?<\/p>\n

Para abordar estas preguntas, creamos Thanos. En las siguientes secciones describimos c\u00f3mo abordamos estas cuestiones y explicamos los objetivos que perseguimos.<\/p>\n

Solicitar datos de m\u00faltiples instancias de Prometheus (consulta global)<\/h4>\n

\nPrometheus ofrece un enfoque funcional para el sharding. Incluso un solo servidor de Prometheus proporciona suficiente escalabilidad para liberar a los usuarios de las complejidades del sharding horizontal en pr\u00e1cticamente todos los casos de uso.<\/p>\n

Aunque este es un excelente modelo de implementaci\u00f3n, a menudo se requiere acceder a los datos de diferentes servidores de Prometheus a trav\u00e9s de una \u00fanica API o interfaz de usuario \u2014 vista global. Por supuesto, es posible mostrar m\u00faltiples consultas en un \u00fanico panel de Grafana, pero cada consulta solo puede ejecutarse en un servidor de Prometheus. Por otro lado, con Thanos puedes consultar y agregar datos de varios servidores de Prometheus, ya que todos son accesibles desde un \u00fanico punto final.<\/p>\n

Anteriormente, para obtener una vista global en Improbable, organizamos nuestras instancias de Prometheus en una jerarqu\u00eda de Federaci\u00f3n Jer\u00e1rquica<\/a><\/noindex>. Esto signific\u00f3 crear un meta-servidor Prometheus que recolecta parte de las m\u00e9tricas de cada servidor \"leaf\".<\/p>\n

\"Thanos
\n
\nEste enfoque result\u00f3 problem\u00e1tico. Condujo a una configuraci\u00f3n m\u00e1s complicada, a la adici\u00f3n de un posible punto de falla adicional y a la aplicaci\u00f3n de reglas complejas para proporcionar al punto final federado solo los datos necesarios. Adem\u00e1s, la federaci\u00f3n de este tipo no permite obtener una verdadera vista global, ya que no todos los datos est\u00e1n disponibles desde una \u00fanica solicitud API.<\/p>\n

Esto est\u00e1 estrechamente relacionado con una \u00fanica representaci\u00f3n de los datos recopilados en servidores Prometheus de alta disponibilidad (high-availability, HA). El modelo HA de Prometheus recopila datos de manera independiente dos veces, lo cual es tan sencillo que no podr\u00eda ser m\u00e1s f\u00e1cil. Sin embargo, utilizar una representaci\u00f3n combinada y desduplicada de ambos flujos ser\u00eda mucho m\u00e1s conveniente.<\/p>\n

Por supuesto, existe la necesidad de servidores Prometheus de alta disponibilidad. En Improbable, tomamos muy en serio la monitorizaci\u00f3n de datos cada minuto, pero tener una \u00fanica instancia de Prometheus en el cl\u00faster representa un \u00fanico punto de falla. Cualquier error de configuraci\u00f3n o fallo de hardware puede potencialmente llevar a la p\u00e9rdida de datos importantes. Incluso una implementaci\u00f3n simple puede causar peque\u00f1os fallos en la recolecci\u00f3n de m\u00e9tricas, ya que el reinicio puede tardar significativamente m\u00e1s que el intervalo de scraping.<\/p>\n

Almacenamiento confiable de datos hist\u00f3ricos<\/h4>\n

\nUn almacenamiento econ\u00f3mico, r\u00e1pido y a largo plazo para m\u00e9tricas es nuestro sue\u00f1o (compartido por la mayor\u00eda de los usuarios de Prometheus). En Improbable, nos vimos obligados a configurar el tiempo de retenci\u00f3n de m\u00e9tricas en nueve d\u00edas (para Prometheus 1.8). Esto impone limitaciones evidentes sobre cu\u00e1n lejos podemos mirar hacia atr\u00e1s.<\/p>\n

Prometheus 2.0 ha mejorado en este aspecto, ya que la cantidad de series temporales ya no afecta al rendimiento general del servidor (ver la presentaci\u00f3n principal de KubeCon sobre Prometheus 2<\/a><\/noindex>). Sin embargo, Prometheus almacena datos en disco local. Aunque una compresi\u00f3n de datos de alta eficiencia puede reducir significativamente el uso del SSD local, todav\u00eda existe un l\u00edmite en la cantidad de datos hist\u00f3ricos que se pueden almacenar.<\/p>\n

Adem\u00e1s, en Improbable nos preocupamos por la confiabilidad, la simplicidad y el costo. Los discos locales grandes son m\u00e1s dif\u00edciles de operar y respaldar. Cuestan m\u00e1s y requieren m\u00e1s herramientas de respaldo, lo que lleva a una complejidad innecesaria.<\/p>\n

Submuestreo<\/h4>\n

\nUna vez que comenzamos a trabajar con datos hist\u00f3ricos, nos dimos cuenta de que hay complicaciones fundamentales con O-grande, que hacen que las consultas sean cada vez m\u00e1s lentas si estamos trabajando con datos de semanas, meses y a\u00f1os.<\/p>\n

La soluci\u00f3n est\u00e1ndar a este problema es el submuestreo<\/a><\/noindex> (downsampling) \u2014 reducir la frecuencia de muestreo de la se\u00f1al. Con la reducci\u00f3n de la frecuencia de muestreo, podemos 'escalar hacia abajo' a un rango de tiempo mayor y mantener la misma cantidad de muestras, lo que permitir\u00e1 mantener la capacidad de respuesta de las consultas.<\/p>\n

El submuestreo de datos antiguos es un requisito inevitable para cualquier soluci\u00f3n de almacenamiento a largo plazo y va m\u00e1s all\u00e1 del Prometheus est\u00e1ndar.<\/p>\n

Objetivos adicionales<\/h4>\n

\nUno de los objetivos iniciales del proyecto Thanos era la integraci\u00f3n sin problemas con cualquier instalaci\u00f3n existente de Prometheus. El segundo objetivo era la f\u00e1cil operaci\u00f3n con una barrera de entrada m\u00ednima. Cualquier dependencia debe ser f\u00e1cil de satisfacer tanto para usuarios peque\u00f1os como grandes, lo que tambi\u00e9n implica un costo base insignificante.<\/p>\n

Arquitectura de Thanos<\/h2>\n

\nDespu\u00e9s de que enumeramos nuestros objetivos en la secci\u00f3n anterior, trabajemos en ellos y veamos c\u00f3mo Thanos aborda estos problemas.<\/p>\n

Vista global<\/h4>\n

\nPara obtener una vista global sobre las instancias existentes de Prometheus, necesitamos vincular un \u00fanico punto de entrada de solicitudes con todos los servidores. Esto es precisamente lo que hace el componente Thanos. Sidecar<\/a><\/noindex>. Se implementa junto a cada servidor de Prometheus y funciona como un proxy, sirviendo datos locales de Prometheus a trav\u00e9s de la interfaz gRPC del Store API, lo que permite seleccionar datos de series temporales por etiquetas y rango de tiempo.<\/p>\n

Por otro lado, est\u00e1 el componente Querier, escalable horizontalmente y sin estado, que hace un poco m\u00e1s que simplemente responder a las solicitudes PromQL a trav\u00e9s del est\u00e1ndar API HTTP de Prometheus. Los componentes Querier, Sidecar y otros de Thanos interact\u00faan a trav\u00e9s del protocolo gossip.<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. El Querier, al recibir una solicitud, se conecta al servidor correspondiente del Store API, es decir, a nuestros Sidecars, y obtiene los datos de series temporales de los servidores de Prometheus correspondientes.<\/li>\n
  2. Despu\u00e9s de esto, combina las respuestas y ejecuta la consulta PromQL sobre ellas. El Querier puede combinar tanto datos no superpuestos como datos duplicados de servidores HA de Prometheus.<\/li>\n<\/ol>\n

    \nEsto resuelve gran parte de nuestro rompecabezas: combinar datos de servidores de Prometheus aislados en una \u00fanica vista. De hecho, Thanos se puede utilizar solo por esta capacidad. \u00a1No se requieren cambios en los servidores Prometheus existentes!<\/p>\n

    \u00a1Almacenamiento ilimitado!<\/h4>\n

    \nSin embargo, tarde o temprano querramos conservar datos que excedan el tiempo de almacenamiento normal de Prometheus. Para almacenar datos hist\u00f3ricos hemos elegido un almacenamiento de objetos. Est\u00e1 ampliamente disponible en cualquier nube, as\u00ed como en centros de datos locales y es muy econ\u00f3mico. Adem\u00e1s, pr\u00e1cticamente cualquier almacenamiento de objetos es accesible a trav\u00e9s de la API S3 bien conocida.<\/p>\n

    Prometheus escribe datos de la memoria a disco aproximadamente cada dos horas. Un bloque de datos guardados contiene todos los datos para un intervalo de tiempo fijo y es inmutable. Esto es muy conveniente, ya que Thanos Sidecar puede simplemente observar el cat\u00e1logo de datos de Prometheus y, a medida que se generan nuevos bloques, cargarlos en los buckets del almacenamiento de objetos.<\/p>\n

    \"Thanos
    \n
    \nLa carga en el almacenamiento de objetos inmediatamente despu\u00e9s de escribir en disco tambi\u00e9n permite mantener la simplicidad del \u201cscraper\u201d (Prometheus y Thanos Sidecar). Esto simplifica el mantenimiento, el costo y el dise\u00f1o del sistema.<\/p>\n

    Como pueden ver, la copia de seguridad de datos se realiza de manera muy sencilla. Pero, \u00bfqu\u00e9 pasa con las consultas de datos en el almacenamiento de objetos?<\/p>\n

    El componente Thanos Store act\u00faa como un proxy para acceder a los datos del almacenamiento de objetos. Al igual que Thanos Sidecar, participa en el cl\u00faster de gossip y implementa la API Store. De este modo, los Querier existentes pueden tratarlo como un Sidecar, como otra fuente de datos de series temporales, sin necesidad de configuraci\u00f3n especial.<\/p>\n

    \"Thanos
    \n
    \nLos bloques de datos de series temporales consisten en varios archivos grandes. Cargarlos a demanda ser\u00eda bastante ineficiente, y el almacenamiento en cach\u00e9 local requerir\u00eda una enorme memoria y espacio en disco.<\/p>\n

    En su lugar, el Store Gateway sabe c\u00f3mo manejar el formato de almacenamiento de Prometheus. Gracias a un planificador de consultas inteligente y al almacenamiento en cach\u00e9 de solo las partes indexadas necesarias de los bloques, se ha vuelto posible reducir consultas complejas a un n\u00famero m\u00ednimo de solicitudes HTTP a los archivos del almacenamiento de objetos. De esta forma, se puede reducir el n\u00famero de solicitudes en cuatro a seis \u00f3rdenes de magnitud y alcanzar tiempos de respuesta que son, en general, dif\u00edciles de distinguir de las consultas de datos en un SSD local.<\/p>\n

    \"Thanos
    \n
    \nComo se muestra en el diagrama anterior, Thanos Querier reduce significativamente el costo de una solicitud de datos en el almacenamiento de objetos al utilizar el formato de almacenamiento de Prometheus y alinear los datos relacionados. Usando este enfoque, podemos combinar muchas solicitudes individuales en un n\u00famero m\u00ednimo de operaciones en bloque.<\/p>\n

    Compactaci\u00f3n y downsampling<\/h4>\n

    \nUna vez que un nuevo bloque de datos de series temporales se ha cargado con \u00e9xito en el almacenamiento de objetos, lo consideramos como datos \"hist\u00f3ricos\", que est\u00e1n disponibles de inmediato a trav\u00e9s del Store Gateway.<\/p>\n

    Sin embargo, despu\u00e9s de un tiempo, los bloques de una misma fuente (Prometheus con Sidecar) se acumulan y ya no utilizan todo el potencial de indexaci\u00f3n. Para abordar este problema, introdujimos otro componente llamado Compactor. Simplemente aplica el mecanismo de compactaci\u00f3n local de Prometheus a los datos hist\u00f3ricos en el almacenamiento de objetos y puede ejecutarse como una simple tarea por lotes peri\u00f3dica.<\/p>\n

    \"Thanos
    \n
    \nGracias a la compresi\u00f3n eficiente, realizar una consulta al almacenamiento durante un per\u00edodo prolongado no presenta problemas en t\u00e9rminos de tama\u00f1o de los datos. Sin embargo, el costo potencial de descomprimir mil millones de valores y procesarlos a trav\u00e9s del controlador de consultas inevitablemente llevar\u00e1 a un aumento dr\u00e1stico en el tiempo de ejecuci\u00f3n de la consulta. Por otro lado, dado que cada p\u00edxel de la pantalla corresponde a cientos de puntos de datos, se vuelve imposible incluso visualizar los datos en resoluci\u00f3n completa. Por lo tanto, el downsamping no solo es posible, sino que tampoco dar\u00e1 lugar a una p\u00e9rdida de precisi\u00f3n notable. <\/p>\n

    \"Thanos
    \n
    \nPara el downsamping de datos, Compactor agrega continuamente los datos con una resoluci\u00f3n de cinco minutos y una hora. Para cada fragmento sin procesar, codificado con la compresi\u00f3n TSDB XOR, se almacenan diversos tipos de datos agregados, como min, max o sum para un bloque. Esto permite que Querier seleccione autom\u00e1ticamente el agregado que sea adecuado para la consulta PromQL dada. <\/p>\n

    Para utilizar datos con menor precisi\u00f3n, el usuario no necesita ninguna configuraci\u00f3n especial. Querier cambia autom\u00e1ticamente entre diferentes resoluciones y datos sin procesar a medida que el usuario acerca o aleja. Si lo desea, el usuario puede controlar esto directamente a trav\u00e9s del par\u00e1metro \"step\" en la consulta. <\/p>\n

    Dado que el costo de almacenamiento de un GB es bajo, por defecto Thanos conserva los datos originales, los datos con resoluci\u00f3n de cinco minutos y de una hora. No es necesario eliminar los datos originales.<\/p>\n

    Reglas de grabaci\u00f3n<\/h2>\n

    \nIncluso con Thanos, las reglas de grabaci\u00f3n son una parte esencial de la pila de monitoreo. Reducen la complejidad, la latencia y el costo de las consultas. Tambi\u00e9n son convenientes para los usuarios para obtener datos agregados por m\u00e9tricas. Thanos se basa en instancias de Prometheus de vanilla, por lo que es completamente aceptable almacenar las reglas de grabaci\u00f3n y las reglas de alerta en el servidor Prometheus existente. Sin embargo, en algunos casos, esto puede no ser suficiente:<\/p>\n