La traducción del artículo fue preparada específicamente para estudiantes del curso. .
es un desarrollador de software, fanático de Go y solucionador de problemas. También es mantenedor de Prometheus y cofundador de la instrumentación SIG de Kubernetes. En el pasado, fue ingeniero de producción en SoundCloud y dirigió el equipo de monitoreo en CoreOS. Actualmente trabaja en Google.
- Ingeniero de Infraestructura en Improbable. Está interesado en las nuevas tecnologías y los problemas de los sistemas distribuidos. Tiene experiencia en programación de bajo nivel en Intel, experiencia como colaborador en Mesos y experiencia en producción SRE de clase mundial en Improbable. Dedicados a mejorar el mundo de los microservicios. Sus tres amores: Golang, código abierto y voleibol.
Si observa nuestro producto estrella, SpatialOS, puede adivinar que Improbable requiere una infraestructura de nube altamente dinámica y de escala global con docenas de clústeres de Kubernetes. Fuimos de los primeros en utilizar un sistema de seguimiento. . Prometheus es capaz de rastrear millones de métricas en tiempo real y viene con un poderoso lenguaje de consulta que le permite extraer la información que necesita.
La sencillez y fiabilidad de Prometheus es una de sus principales ventajas. Sin embargo, una vez superada cierta escala, nos encontramos con varios inconvenientes. Para resolver estos problemas hemos desarrollado es un proyecto de código abierto creado por Improbable para transformar sin problemas los clústeres de Prometheus existentes en un único sistema de monitoreo con almacenamiento ilimitado de datos históricos. Thanos está disponible en Github .
Nuestros objetivos con Thanos
A cierta escala, surgen problemas que están más allá de las capacidades de Vanilla Prometheus. ¿Cómo almacenar petabytes de datos históricos de forma fiable y económica? ¿Se puede hacer esto sin comprometer el tiempo de respuesta? ¿Es posible acceder a todas las métricas ubicadas en diferentes servidores de Prometheus con una única solicitud de API? ¿Existe alguna forma de combinar datos replicados recopilados con Prometheus HA?
Para abordar estos problemas, creamos Thanos. Las siguientes secciones describen cómo abordamos estos temas y explicamos nuestros objetivos.
Consultar datos de múltiples instancias de Prometheus (consulta global)
Prometheus ofrece un enfoque funcional para la fragmentación. Incluso un único servidor Prometheus proporciona suficiente escalabilidad para liberar a los usuarios de las complejidades de la fragmentación horizontal en casi todos los casos de uso.
Si bien este es un excelente modelo de implementación, a menudo es necesario acceder a datos en diferentes servidores Prometheus a través de una única API o UI: una vista global. Por supuesto, es posible mostrar varias consultas en un panel de Grafana, pero cada consulta solo se puede ejecutar en un servidor Prometheus. Por otro lado, con Thanos puedes consultar y agregar datos de múltiples servidores Prometheus, ya que se puede acceder a todos ellos desde un único punto final.
Anteriormente, para obtener una vista global en Improbable, organizamos nuestras instancias de Prometheus en varios niveles. . Esto significó crear un metaservidor Prometheus que recopile algunas de las métricas de cada servidor hoja.
Este enfoque resultó problemático. Esto ha resultado en configuraciones más complejas, la adición de un posible punto de falla adicional y la aplicación de reglas complejas para garantizar que el punto final federado solo reciba los datos que necesita. Además, este tipo de federación no permite obtener una visión global real, ya que no todos los datos están disponibles a partir de una única solicitud de API.
Estrechamente relacionada con esto está una vista unificada de los datos recopilados en servidores Prometheus de alta disponibilidad (HA). El modelo HA de Prometheus recopila datos dos veces de forma independiente, lo cual es tan simple que no podría ser más simple. Sin embargo, sería mucho más conveniente utilizar una vista combinada y deduplicada de ambas transmisiones.
Por supuesto, existe la necesidad de servidores Prometheus de alta disponibilidad. En Improbable, nos tomamos muy en serio el monitoreo de datos minuto a minuto, pero tener una instancia de Prometheus por clúster es un punto único de falla. Cualquier error de configuración o falla de hardware puede provocar la pérdida de datos importantes. Incluso una implementación simple puede causar interrupciones menores en la recopilación de métricas porque los reinicios pueden ser significativamente más largos que el intervalo de extracción.
Almacenamiento confiable de datos históricos
Nuestro sueño es el almacenamiento de métricas barato, rápido y a largo plazo (compartido por la mayoría de los usuarios de Prometheus). En Improbable, nos vimos obligados a configurar el período de retención de métricas en nueve días (para Prometheus 1.8). Esto añade límites obvios a lo lejos que podemos mirar hacia atrás.
Prometheus 2.0 ha mejorado en este sentido, ya que el número de series temporales ya no afecta al rendimiento general del servidor (ver. ). Sin embargo, Prometheus almacena datos en el disco local. Aunque la compresión de datos de alta eficiencia puede reducir significativamente el uso de SSD local, en última instancia, todavía existe un límite en la cantidad de datos históricos que se pueden almacenar.
Además, en Improbable nos preocupamos por la confiabilidad, la simplicidad y el costo. Los discos locales grandes son más difíciles de operar y realizar copias de seguridad. Cuestan más y requieren más herramientas de respaldo, lo que genera una complejidad innecesaria.
Reducción de resolución
Una vez que comenzamos a trabajar con datos históricos, nos dimos cuenta de que existen dificultades fundamentales con big-O que hacen que las consultas sean cada vez más lentas a medida que trabajamos con semanas, meses y años de datos.
La solución estándar a este problema sería (reducción de resolución): reducción de la frecuencia de muestreo de la señal. Con la reducción de resolución, podemos "reducir la escala" a un rango de tiempo más amplio y mantener la misma cantidad de muestras, manteniendo la capacidad de respuesta de las consultas.
La reducción de la resolución de datos antiguos es un requisito inevitable de cualquier solución de almacenamiento a largo plazo y está más allá del alcance de Prometheus básico.
Metas adicionales
Uno de los objetivos originales del proyecto Thanos era integrarse perfectamente con cualquier instalación de Prometheus existente. El segundo objetivo era la facilidad de operación con barreras de entrada mínimas. Cualquier dependencia debería satisfacerse fácilmente tanto para usuarios pequeños como grandes, lo que también significa un costo base bajo.
Arquitectura de Thanos
Después de enumerar nuestros objetivos en la sección anterior, analicémoslos y veamos cómo Thanos resuelve estos problemas.
Vista global
Para obtener una vista global de las instancias de Prometheus existentes, necesitamos vincular un único punto de entrada de solicitudes a todos los servidores. Esto es exactamente lo que hace el componente Thanos. . Se implementa junto a cada servidor Prometheus y actúa como un proxy, entregando datos locales de Prometheus a través de la API gRPC Store, lo que permite recuperar datos de series temporales por etiqueta y rango de tiempo.
En el otro lado está el componente Querier escalable y sin estado, que hace poco más que responder consultas PromQL a través de la API HTTP estándar de Prometheus. Querier, Sidecar y otros componentes de Thanos se comunican a través de .
- Querier, al recibir una solicitud, se conecta al servidor Store API correspondiente, es decir, a nuestros Sidecars y recibe datos de series temporales de los servidores Prometheus correspondientes.
- Después de eso, combina las respuestas y ejecuta una consulta PromQL sobre ellas. Querier puede fusionar datos separados y duplicados de los servidores Prometheus HA.
Esto resuelve una pieza importante de nuestro rompecabezas: combinar datos de servidores Prometheus aislados en una sola vista. De hecho, Thanos sólo se puede utilizar para esta función. ¡No es necesario realizar cambios en los servidores Prometheus existentes!
¡Vida útil ilimitada!
Sin embargo, tarde o temprano querremos almacenar datos más allá del tiempo de retención normal de Prometheus. Elegimos el almacenamiento de objetos para almacenar datos históricos. Está ampliamente disponible en cualquier nube, así como en centros de datos locales, y es muy rentable. Además, casi cualquier almacenamiento de objetos está disponible a través de la conocida API S3.
Prometheus escribe datos de la RAM al disco aproximadamente cada dos horas. El bloque de datos almacenado contiene todos los datos durante un período de tiempo fijo y es inmutable. Esto es muy conveniente porque Thanos Sidecar puede simplemente mirar el directorio de datos de Prometheus y, a medida que haya nuevos bloques disponibles, cargarlos en depósitos de almacenamiento de objetos.
Cargar en el almacenamiento de objetos inmediatamente después de escribir en el disco también le permite mantener la simplicidad del raspador (Prometheus y Thanos Sidecar). Lo que simplifica el soporte, el costo y el diseño del sistema.
Como puede ver, la copia de seguridad de datos es muy sencilla. Pero ¿qué pasa con la consulta de datos en el almacenamiento de objetos?
El componente Thanos Store actúa como un proxy para recuperar datos del almacenamiento de objetos. Al igual que Thanos Sidecar, participa en el grupo de chismes e implementa la Store API. De esta manera, el Querier existente puede tratarlo como un Sidecar, como otra fuente de datos de series temporales, sin necesidad de configuración especial.
Los bloques de datos de series temporales constan de varios archivos grandes. Cargarlos bajo demanda sería bastante ineficiente y almacenarlos en caché localmente requeriría una enorme cantidad de memoria y espacio en disco.
En cambio, Store Gateway sabe cómo manejar el formato de almacenamiento Prometheus. Gracias a un programador de consultas inteligente y al almacenamiento en caché solo las partes de índice necesarias de los bloques, es posible reducir consultas complejas a un número mínimo de solicitudes HTTP a archivos de almacenamiento de objetos. De esta manera, puede reducir la cantidad de solicitudes de cuatro a seis órdenes de magnitud y lograr tiempos de respuesta que generalmente son difíciles de distinguir de las solicitudes de datos en un SSD local.
Como se muestra en el diagrama anterior, Thanos Querier reduce significativamente el costo por consulta de datos de almacenamiento de objetos al aprovechar el formato de almacenamiento de Prometheus y colocar los datos relacionados uno al lado del otro. Con este enfoque, podemos combinar muchas solicitudes individuales en una cantidad mínima de operaciones masivas.
Compactación y reducción de resolución
Una vez que un nuevo bloque de datos de series temporales se carga con éxito en el almacenamiento de objetos, lo tratamos como datos "históricos", que están disponibles inmediatamente a través de Store Gateway.
Sin embargo, después de un tiempo, los bloques de una fuente (Prometheus con Sidecar) se acumulan y ya no utilizan todo el potencial de indexación. Para resolver este problema, introdujimos otro componente llamado Compactor. Simplemente aplica el motor de compactación local de Prometheus a los datos históricos en el almacenamiento de objetos y puede ejecutarse como un simple trabajo por lotes periódico.
Gracias a una compresión eficiente, consultar el almacenamiento durante un largo período de tiempo no supone un problema en términos de tamaño de los datos. Sin embargo, el costo potencial de descomprimir mil millones de valores y ejecutarlos a través de un procesador de consultas resultará inevitablemente en un aumento dramático en el tiempo de ejecución de las consultas. Por otro lado, dado que hay cientos de puntos de datos por píxel en la pantalla, resulta imposible incluso visualizar los datos en resolución completa. Por lo tanto, la reducción de resolución no sólo es posible, sino que tampoco provocará una pérdida notable de precisión.
Para reducir la muestra de datos, Compactor agrega datos continuamente con una resolución de cinco minutos y una hora. Para cada fragmento sin procesar codificado mediante la compresión TSDB XOR, se almacenan diferentes tipos de datos agregados, como mínimo, máximo o suma para un bloque. Esto permite a Querier seleccionar automáticamente un agregado que sea apropiado para una consulta PromQL determinada.
No se requiere ninguna configuración especial para que el usuario utilice datos de precisión reducida. Querier cambia automáticamente entre diferentes resoluciones y datos sin procesar a medida que el usuario acerca y aleja el zoom. Si lo desea, el usuario puede controlar esto directamente a través del parámetro "paso" en la solicitud.
Dado que el costo de almacenar un GB es bajo, Thanos almacena de forma predeterminada datos sin procesar, datos con resolución de cinco minutos y una hora. No es necesario eliminar los datos originales.
Reglas de grabación
Incluso con Thanos, las reglas de grabación son una parte esencial del sistema de monitoreo. Reducen la complejidad, la latencia y el costo de las consultas. También resultan convenientes para que los usuarios obtengan datos agregados por métricas. Thanos se basa en instancias estándar de Prometheus, por lo que es perfectamente aceptable almacenar reglas de grabación y reglas de alerta en un servidor Prometheus existente. Sin embargo, en algunos casos esto puede no ser suficiente:
- Alerta y regla globales (por ejemplo, una alerta cuando un servicio no funciona en más de dos de tres clústeres).
- Regla para datos fuera del almacenamiento local.
- El deseo de almacenar todas las reglas y alertas en un solo lugar.
Para todos estos casos, Thanos incluye un componente separado llamado Ruler, que calcula reglas y alertas a través de Thanos Queries. Al proporcionar una StoreAPI conocida, el nodo Query puede acceder a métricas recién calculadas. Posteriormente, también se almacenan en el almacenamiento de objetos y están disponibles a través de Store Gateway.
El poder de Thanos
Thanos es lo suficientemente flexible como para personalizarlo según sus necesidades. Esto es especialmente útil cuando se migra desde Prometheus simple. Recapitulemos rápidamente lo que hemos aprendido sobre los componentes de Thanos con un ejemplo breve. A continuación se explica cómo llevar su Prometheus básico al mundo del “almacenamiento ilimitado de métricas”:
- Agregue Thanos Sidecar a sus servidores Prometheus; por ejemplo, un contenedor sidecar en un pod de Kubernetes.
- Implemente múltiples réplicas de Thanos Querier para poder ver datos. En esta etapa es fácil iniciar chismes entre Scraper y Querier. Para comprobar la interacción de los componentes, utilice la métrica 'thanos_cluster_members'.
¡Solo estos dos pasos son suficientes para proporcionar una vista global y una deduplicación de datos perfecta desde posibles réplicas de Prometheus HA! Simplemente conecte sus paneles al punto final HTTP de Querier o use la interfaz de usuario de Thanos directamente.
Sin embargo, si necesita una copia de seguridad de las métricas y un almacenamiento a largo plazo, deberá completar tres pasos más:
- Cree un depósito de AWS S3 o GCS. Configure Sidecar para copiar datos a estos depósitos. Ahora se puede minimizar el almacenamiento de datos local.
- Implemente Store Gateway y conéctelo a su grupo de chismes existente. ¡Ahora puedes consultar los datos respaldados!
- Implemente Compactor para mejorar la eficiencia de las consultas durante largos períodos de tiempo mediante la compactación y la reducción de resolución.
Si quieres saber más, no dudes en echar un vistazo a nuestra и !
En solo cinco pasos, convertimos a Prometheus en un sistema de monitoreo confiable con vista global, tiempo de almacenamiento ilimitado y alta disponibilidad potencial de métricas.
Solicitud de extracción: ¡te necesitamos!
Ha sido un proyecto de código abierto desde el principio. La integración perfecta con Prometheus y la capacidad de usar solo una parte de Thanos lo convierten en una excelente opción para escalar su sistema de monitoreo sin esfuerzo.
Siempre damos la bienvenida a las solicitudes de extracción y los problemas de GitHub. Mientras tanto, no dudes en contactarnos a través de Github Issues o slack.Si tiene preguntas o comentarios, o desea compartir su experiencia al usarlo. Si te gusta lo que hacemos en Improbable, no dudes en contactarnos - !
Fuente: habr.com