Thanos - Prometeo escalable

La traducción del artículo fue preparada específicamente para estudiantes del curso "Prácticas y herramientas de DevOps" .




(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .


Al observar nuestro producto insignia SpatialOS, puede adivinar que Improbable necesita una infraestructura de nube global altamente dinámica con docenas de clústeres de Kubernetes. Fuimos uno de los primeros en usar el sistema de monitoreo Prometheus . Prometheus es capaz de rastrear millones de métricas en tiempo real y viene con un poderoso lenguaje de consulta para recuperar la información necesaria.

Simplicidad y confiabilidad Prometheus es una de sus principales ventajas. Sin embargo, después de pasar una cierta escala, encontramos varios inconvenientes. Para resolver estos problemas, desarrollamos Thanos- Un proyecto de código abierto creado por Improbable para transformar sin problemas los clústeres Prometheus existentes en un único sistema de monitoreo con un depósito ilimitado de datos históricos. Thanos está disponible en github aquí .

Manténgase al día con las últimas noticias de Improbable.

Nuestros objetivos con Thanos


En cierta escala, surgen problemas que van más allá de las capacidades del Prometheus de vainilla. ¿Cómo almacenar de forma confiable y económica petabytes de datos históricos? ¿Se puede hacer esto sin perjuicio del tiempo de respuesta a la solicitud? ¿Es posible acceder a todas las métricas ubicadas en diferentes servidores Prometheus con una sola solicitud de API? ¿Es posible combinar de alguna manera los datos replicados recopilados con Prometheus HA?

Para abordar estos problemas, creamos Thanos. Las siguientes secciones describen cómo abordamos estos problemas y explicamos los objetivos que perseguimos.

Consulta de datos de múltiples instancias de Prometheus (consulta global)


Prometheus ofrece un enfoque funcional para fragmentar. Incluso un servidor Prometheus proporciona escalabilidad suficiente para liberar a los usuarios de las dificultades de fragmentación horizontal en casi todos los casos de uso.

Aunque este es un excelente modelo de implementación, a menudo se requiere para acceder a datos en diferentes servidores Prometheus a través de una única API o UI: vista global. Por supuesto, es posible mostrar varias solicitudes en un panel de Grafana, pero cada solicitud solo se puede ejecutar en un servidor Prometheus. Con Thanos, por otro lado, puede consultar y agregar datos de múltiples servidores Prometheus, ya que todos son accesibles desde un punto final.

Anteriormente, para obtener una visión global de Improbable, organizamos nuestras instancias de Prometheus en un nivel múltipleFederación jerárquica . Esto significó crear un meta servidor Prometheus que recolecta parte de las métricas de cada servidor hoja, lo



que resultó ser problemático, complicando la configuración, agregando un punto potencial de falla adicional y aplicando reglas complejas para proporcionar al punto final federado los datos correctos. Además, la federación de este tipo no le permite obtener una vista global real, ya que no se puede acceder a todos los datos desde una solicitud de API.

Estrechamente relacionado con esto está la presentación única de los datos recopilados en los servidores de alta disponibilidad (HA) de Prometheus. El modelo Prometheus HA recolecta datos de forma independiente dos veces, lo cual es tan simple que no podría ser más simple. Sin embargo, usar una representación combinada y deduplicada de ambos hilos sería mucho más conveniente.

Por supuesto, existe la necesidad de servidores Prometheus de alta disponibilidad. En Improbable, nos tomamos muy en serio el monitoreo de datos cada 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 resultar en la pérdida de datos importantes. Incluso las implementaciones simples pueden provocar fallas menores en la recopilación de métricas, ya que el reinicio puede ser significativamente más largo que el intervalo de raspado.

Almacenamiento confiable de datos históricos


El almacenamiento de métricas barato, rápido y a largo plazo es nuestro sueño (compartido por la mayoría de los usuarios de Prometheus). En Improbable, nos vimos obligados a establecer el período de almacenamiento para las métricas en nueve días (para Prometheus 1.8). Esto agrega limitaciones obvias a lo lejos que podemos mirar hacia atrás.

Prometheus 2.0 es mejor en este aspecto, ya que el número de series de tiempo ya no afecta el rendimiento general del servidor (vea la nota clave de KubeCon sobre Prometheus 2 ). Sin embargo, Prometheus almacena datos en un disco local. Aunque la compresión de datos altamente eficiente puede reducir significativamente el uso de un SSD local, todavía hay una limitación en la cantidad de datos históricos que se guardan.

En Improbable, también nos preocupamos por la fiabilidad, la simplicidad y el costo. Las unidades locales grandes son más difíciles de operar y realizar copias de seguridad. Son más caros y requieren más herramientas de respaldo, lo que conduce a una complejidad innecesaria.

Desmuestreo


Tan pronto como comenzamos a trabajar con datos históricos, nos dimos cuenta de que existen dificultades fundamentales con O-big que hacen que las consultas sean cada vez más lentas si trabajamos con datos durante semanas, meses y años.

La solución estándar a este problema será la disminución de muestreo, la disminución de la señal. Al reducir el muestreo, podemos "reducir" a un rango de tiempo mayor y mantener el mismo número de muestras, lo que nos permite mantener la capacidad de respuesta de las solicitudes.

La disminución de datos antiguos es un requisito inevitable de cualquier solución de almacenamiento a largo plazo y va más allá de Prometheus.

Objetivos adicionales


Uno de los objetivos iniciales del proyecto Thanos era integrarse perfectamente con cualquier instalación Prometheus existente. El segundo objetivo era una operación simple con una barrera de entrada mínima. Cualquier dependencia debe satisfacerse fácilmente para usuarios pequeños y grandes, lo que también implica un bajo costo base.

Arquitectura Thanos


Después de que nuestros objetivos se enumeraron en la sección anterior, trabajemos en ellos y veamos cómo Thanos resuelve estos problemas.

Vista global


Para obtener una vista global sobre las instancias existentes de Prometheus, necesitamos asociar un único punto de entrada de solicitud con todos los servidores. Esto es exactamente lo que hace el componente Thanos Sidecar . Se implementa junto a cada servidor Prometheus y actúa como un proxy, y sirve datos locales de Prometheus a través de la interfaz gRPC de la Tienda, lo que le permite seleccionar datos de series de tiempo por etiqueta y rango de tiempo.

Por otro lado, hay un componente Querier escalable horizontalmente sin estado que hace un poco más que responder a las solicitudes de PromQL a través de la API HTTP Prometheus estándar. Los componentes Querier, Sidecar y otros Thanos se comunican a través del protocolo de chismes .



  1. Al recibir una solicitud, Querier se conecta al servidor API de la tienda correspondiente, es decir, a nuestro Sidecar, y recibe datos de series temporales de los servidores Prometheus correspondientes.
  2. Después de eso, combina las respuestas y realiza una consulta PromQL sobre ellas. Querier puede combinar tanto datos disjuntos como datos duplicados de servidores Prometheus HA.

Esto resuelve la mayor parte de nuestro rompecabezas, combinando datos de servidores Prometheus aislados en una sola vista. De hecho, Thanos solo puede usarse para esta oportunidad. ¡Los servidores Prometheus existentes no necesitan hacer ningún cambio!

¡Vida útil ilimitada!


Sin embargo, tarde o temprano querremos guardar datos que vayan más allá del tiempo de almacenamiento normal de Prometheus. Para almacenar datos históricos, hemos elegido el almacenamiento de objetos. Está ampliamente disponible en cualquier nube, así como en centros de datos locales y es muy económico. Además, se puede acceder a casi cualquier almacenamiento de objetos a través de la conocida API S3.

Prometheus escribe datos desde la RAM en el disco aproximadamente cada dos horas. El bloque de datos almacenados contiene todos los datos durante un período fijo de tiempo y es inmutable. Esto es muy conveniente, porque Thanos Sidecar puede simplemente mirar el catálogo de datos de Prometheus y, a medida que aparecen nuevos bloques, cargarlos en los depósitos de almacenamiento de objetos.



La descarga al almacenamiento de objetos inmediatamente después de escribir en un disco también le permite mantener la simplicidad de un "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 los datos es muy simple. ¿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 clúster de chismes e implementa la API de la tienda. Por lo tanto, el Querier existente puede considerarlo como Sidecar, como otra fuente de datos de series temporales: no se requiere una configuración especial.



Los bloques de datos de series temporales están formados por varios archivos grandes. Descargarlos a pedido sería bastante ineficiente, y el almacenamiento en caché local requería una gran memoria y espacio en disco.

En cambio, Store Gateway sabe cómo manejar el formato de almacenamiento Prometheus. Gracias al ingenioso planificador de consultas y al almacenamiento en caché de solo las partes de índice necesarias de los bloques, fue posible reducir las consultas complejas al mínimo número de solicitudes HTTP para objetar archivos de almacenamiento. Por lo tanto, es posible reducir el número 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 de una sola solicitud de datos en el almacenamiento de objetos mediante el uso del formato de almacenamiento Prometheus y colocando los datos relacionados uno al lado del otro. Con este enfoque, podemos combinar muchas consultas individuales en un número mínimo de operaciones masivas.

Compactación y disminución de resolución


Después de que el nuevo bloque de datos de series temporales se haya cargado con éxito en el almacenamiento de objetos, lo consideramos como datos "históricos" que estarán disponibles de inmediato 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 usan todo el potencial de indexación. Para resolver este problema, presentamos otro componente llamado Compactor. Simplemente aplica el mecanismo de compactación Prometheus local a los datos históricos en el almacén de objetos y puede ejecutarse como un simple trabajo por lotes periódico.



Gracias a la compresión eficiente, una consulta en el repositorio durante un largo período de tiempo no presenta problemas en términos de tamaño de datos. Sin embargo, el costo potencial de desempaquetar mil millones de valores y ejecutarlos a través de un procesador de consultas conducirá inevitablemente a un fuerte aumento en el tiempo de ejecución de consultas. Por otro lado, dado que hay cientos de puntos de datos por píxel de la pantalla, resulta imposible incluso visualizar los datos en resolución completa. Por lo tanto, la disminución de la resolución no solo es posible, sino que no conducirá a una pérdida notable de precisión.



Para datos de disminución de muestreo, Compactor agrega datos continuamente con una resolución de cinco minutos y una hora. Para cada fragmento sin procesar codificado utilizando la compresión TSDB XOR, se almacenan varios tipos de datos agregados, como min, max o sum para un bloque. Esto permite a Querier seleccionar automáticamente el agregado adecuado para esta consulta de PromQL.

Para usar datos con precisión reducida, el usuario no necesita ninguna configuración especial. Querier cambia automáticamente entre diferentes resoluciones y datos sin procesar a medida que el usuario se acerca y aleja. 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 pequeño, por defecto Thanos guarda los datos originales, datos con una resolución de cinco minutos y una hora. No es necesario eliminar los datos originales.

Reglas de registro


Incluso con las reglas de grabación de Thanos son una parte esencial de la pila de monitoreo. Reducen la complejidad, la latencia y el costo de las solicitudes. También son convenientes para que los usuarios obtengan datos métricos agregados. Thanos se basa en instancias de vainilla 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:

  • Alertas y reglas globales (por ejemplo, alertas cuando un servicio está inactivo en más de dos de los tres grupos).
  • Regla para datos fuera del almacenamiento local.
  • El deseo de mantener todas las reglas y alertas en un solo lugar.



Para todos estos casos, Thanos incluye un componente separado llamado Regla, que calcula la regla y la alerta a través de las consultas de Thanos. Al proporcionar el conocido StoreAPI, el nodo Consulta puede acceder a métricas recién calculadas. Más tarde, también se almacenan en el almacenamiento de objetos y se ponen a disposición 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. Echemos un vistazo rápido a lo que aprendimos sobre los componentes de Thanos. Aquí le mostramos cómo transferir su Prometheus de vainilla al mundo del "almacenamiento de métricas ilimitado":



  1. Agregue Thanos Sidecar a sus servidores Prometheus, por ejemplo, el contenedor adyacente en el pod Kubernetes.
  2. Expanda múltiples réplicas de Thanos Querier para ver los datos. En este punto, es fácil configurar chismes entre Scraper y Querier. Use la métrica 'thanos_cluster_members' para probar las interacciones de los componentes.

¡Solo estos dos pasos son suficientes para proporcionar una visión global y una deduplicación de datos sin problemas de posibles réplicas de Prometheus HA! Simplemente conecte sus paneles al punto final HTTP de Querier o use la interfaz de UI de Thanos directamente.

Sin embargo, si necesita hacer una copia de seguridad de las métricas y el almacenamiento a largo plazo, deberá realizar tres pasos más:

  1. Construye un AWS S3 o GCS Bucket. Configure Sidecar para copiar datos a estos depósitos. Ahora puede minimizar el almacenamiento local de datos.
  2. Expanda Store Gateway y conéctelo a un clúster de chismes existente. ¡Ahora puede enviar solicitudes de datos en copias de seguridad!
  3. Implemente Compactor para mejorar el rendimiento de las consultas durante largos períodos de tiempo utilizando compactación y disminución de resolución.

Si desea saber más, ¡no dude en mirar nuestros ejemplos de los kubernetes manifiestos y comenzar !

En solo cinco pasos, hemos convertido 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!


Thanos fue 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 un sistema de monitoreo sin ningún esfuerzo adicional.

Siempre damos la bienvenida a la solicitud y los problemas de GitHub Pull. Al mismo tiempo, no dude en contactarnos a través de Github Issues o slack Improbable-eng #thanos si tiene preguntas o comentarios, o si desea compartir su experiencia. Si te gusta lo que hacemos en Improbable, no dudes en contactarnos, ¡siempre tenemos vacantes !



Aprende más sobre el curso.



All Articles