Hola a todos. A continuación se presenta la transcripción .
– un sistema de monitoreo de diversos sistemas y servicios, que permite a los administradores de sistemas recopilar información sobre los parámetros actuales de los sistemas y configurar alertas para recibir notificaciones sobre desviaciones en el funcionamiento de los sistemas.
En la charla se realizará una comparación y – proyectos para el almacenamiento a largo plazo de métricas de Prometheus.
Primero hablaré sobre Prometheus. Es un sistema de monitoreo que recopila métricas de objetivos específicos y las guarda en un almacenamiento local. Prometheus puede grabar métricas en almacenamiento remoto, genera alertas y reglas de grabación.
Limitaciones de Prometheus:
- No tiene vista de consulta global. Esto ocurre cuando tienes varias instancias independientes de Prometheus. Recopilan métricas y deseas realizar una consulta sobre todas estas métricas, recopiladas de diferentes instancias de Prometheus. Prometheus no permite esto.
- La capacidad de Prometheus está limitada a un solo servidor. Prometheus no puede escalar automáticamente sobre varios servidores. Solo puedes dividir manualmente tus objetivos entre varios Prometheus.
- El volumen de métricas en Prometheus también está limitado a un solo servidor por la misma razón por la cual no puede escalar automáticamente sobre varios servidores.
- No es tan fácil organizar la persistencia de datos en Prometheus.
¿Soluciones para estos problemas/tareas?
Las soluciones son las siguientes:
Todas estas soluciones son para almacenamiento remoto de datos recopilados por Prometheus. Abordan el problema del almacenamiento remoto del anterior diapositiva de diferentes maneras. En esta presentación solo hablaré sobre las dos primeras soluciones: y .
Por primera vez, la información sobre apareció en . Ahí se describe la arquitectura y cómo funciona.
Thanos toma los datos que Prometheus ha guardado en el disco local y los copia en S3, en o en otro almacenamiento de objetos.
Así, Thanos proporciona una vista global de la consulta. Puedes solicitar los datos almacenados en el almacenamiento de objetos desde varias instancias de Prometheus.
Thanos es compatible con PromQL y .
Thanos utiliza el código de Prometheus para almacenar datos.
Thanos es desarrollado por los mismos desarrolladores que Prometheus.
Sobre . Aquí es , donde hablamos por primera vez sobre .
VictoriaMetrics recopila datos de varios Prometheus a través del protocolo soportado por Prometheus.
VictoriaMetrics proporciona una vista de consulta global, ya que múltiples instancias de Prometheus pueden escribir datos en una única VictoriaMetrics. Por lo tanto, puede realizar consultas sobre todos esos datos.
VictoriaMetrics también soporta, al igual que Thanos, PromQL y la API de consulta de Prometheus.
A diferencia de Thanos, el código fuente de VictoriaMetrics se escribió desde cero y está optimizado para rapidez y consumo de recursos.
VictoriaMetrics, a diferencia de Thanos, se escala tanto vertical como horizontalmente. Hay , que se escala verticalmente. Puede comenzar con un procesador y 1 GB de RAM y crecer gradualmente hasta cientos de procesadores y 1 TB de RAM. VictoriaMetrics puede utilizar todos esos recursos. Su rendimiento aumentará aproximadamente 100 veces en comparación con un sistema de un solo núcleo.
La historia de Thanos comenzó en noviembre de 2017, cuando se realizó el primer commit público. Antes de eso, Thanos se desarrolló internamente en la empresa .
En junio de 2019, se lanzó una versión emblemática 0.5.0, en la que gossip. Se eliminó de Thanos porque mostró un rendimiento deficiente. A menudo, el clúster de Thanos no funcionaba correctamente y los nodos se conectaban incorrectamente debido al protocolo gossip. Por lo tanto, decidieron eliminarlo. Creo que fue la decisión correcta.
En junio de 2019, también enviaron la solicitud número en .
Y a los pocos meses, Thanos fue aceptado en , que incluye Prometheus, Kubernetes y otros proyectos populares.
En enero de 2018 comenzó el desarrollo de VictoriaMetrics.
En septiembre de 2018 mencioné públicamente por primera vez a VictoriaMetrics.
En diciembre de 2018, publicamos la versión de nodo único.
En mayo de 2019 los códigos fuente tanto de la versión de nodo único como de la versión de clúster.
En junio de 2019, al igual que Thanos, enviamos una solicitud a la fundación CNCF bajo el número . Enviamos la solicitud un día antes que Thanos.
Pero, lamentablemente, aún no nos han aceptado. Necesitamos la ayuda de la comunidad.
Veamos las diapositivas más importantes que muestran la arquitectura de Thanos y VictoriaMetrics.
Empecemos con Thanos. Los componentes amarillos son los componentes de Prometheus. Todo lo demás son componentes de Thanos. Comencemos con el componente más importante. Thanos Sidecar es un componente que se instala junto a cada Prometheus. Se encarga de cargar los datos de Prometheus desde el almacenamiento local a S3 o a otro objeto de almacenamiento.
Hay un componente llamado Thanos Store Gateway, que puede leer estos datos desde Object Storage al recibir consultas de Thanos Query. Thanos Query implementa PromQL y la API de Prometheus. Es decir, desde afuera se presenta como Prometheus. Recibe consultas PromQL, las envía a Thanos Store Gateway, y este extrae los datos necesarios de Object Storage y los devuelve.
Sin embargo, en nuestro Object Storage se almacenan los datos sin las últimas dos horas debido a las características de implementación de Thanos Sidecar, que no puede cargar las últimas dos horas en el Object Storage S3, ya que Prometheus no ha creado archivos en el almacenamiento local para esas dos horas.
¿Cómo se logró solucionar esto? Thanos Query, además de las consultas en Thanos Store Gateway, envía consultas paralelas a cada Thanos Sidecar que se encuentra cerca de Prometheus.
Y Thanos Sidecar, a su vez, reenvía las consultas a Prometheus, y extrae los datos de las últimas dos horas.
Además de estos componentes, hay otro componente opcional, sin el cual Thanos funcionará de manera ineficiente. Este es Thanos Compact, que se encarga de fusionar pequeños archivos en Object Storage en archivos más grandes que han sido cargados por Thanos Sidecar. Thanos Sidecar carga archivos con datos de las últimas dos horas. Si estos archivos no se fusionan en archivos más grandes, su número puede crecer significativamente. Cuantos más archivos existan, más memoria necesita Thanos Store Gateway, y más recursos se requieren para la transmisión de datos por la red, así como para los metadatos. El funcionamiento de Thanos Store Gateway se vuelve ineficiente. Por eso, es imprescindible ejecutar Thanos Compact, que fusiona pequeños archivos en archivos más grandes, para reducir su cantidad y así minimizar la sobrecarga en Thanos Store Gateway.
También hay un componente llamado Thanos Ruler. Este ejecuta las reglas de alerta de Prometheus y puede calcular las reglas de grabación de Prometheus para registrar datos nuevamente en Object Storage. Pero se recomienda no usar este componente, ya que .
Así es el esquema simple de Thanos.
Ahora comparemos con el esquema de VictoriaMetrics.
VictoriaMetrics tiene 2 versiones: Single-node y versión en clúster. Single-node funciona en una sola computadora. En Single-node no hay estos componentes, solo un binario. Este binario en la diapositiva se presenta como un cuadrado. Todo lo que está dentro del cuadrado es el contenido del archivo binario para la versión Single-node. No es necesario que lo conozcas. Simplemente ejecutas el binario y todo funciona.
La versión en clúster es más compleja. Dentro de ella hay tres componentes diferentes: vmselect, vminsert y vmstorage. Por su nombre, debería ser evidente cuál es la función de cada uno. El componente Insert acepta datos en diferentes formatos: desde la API remote write de Prometheus, el protocolo en línea de Influx, el protocolo de Graphite y desde el protocolo de OpenTSDB. El componente Insert los recibe, los analiza y los distribuye entre los componentes de almacenamiento disponibles, donde los datos se guardan. , así como la API de consulta de Prometheus, y puede ser usado como reemplazo de Prometheus en Grafana u otros clientes de API de Prometheus. Select acepta consultas PromQL, las analiza, lee los datos necesarios para ejecutar dicha consulta desde los nodos de almacenamiento, procesa estos datos y devuelve la respuesta.
Compararemos la complejidad de instalación de Thanos y VictoriaMetrics.
Comencemos con Thanos. Antes de comenzar a trabajar con Thanos, es necesario crear un bucket en un almacenamiento de objetos, como S3 o GCS, para que el Thanos Sidecar pueda escribir datos allí.
Luego, para cada Prometheus, se debe instalar Thanos Sidecar. Antes de eso, no olvide desactivar la compactación de datos en Prometheus. La compactación de datos comprime periódicamente los datos en el almacenamiento local de Prometheus para reducir el consumo de recursos.
Cuando instalas Thanos Sidecar en tus Prometheus, debes desactivar esta compactación de datos, porque Thanos Sidecar no funciona correctamente cuando la compactación de datos está activada. Esto significa que tu Prometheus comienza a guardar datos en bloques de dos horas y deja de fusionar esos bloques en bloques más grandes. Por lo tanto, si realizas consultas que exceden la duración de las últimas dos horas, no funcionarán tan eficientemente en comparación con cómo podrían hacerlo si la compactación de datos estuviera activada.
Por eso, Thanos recomienda reducir el tiempo de retención de datos en el almacenamiento local a entre 6 y 8 horas, para disminuir la sobrecarga causada por una gran cantidad de pequeños bloques.
Después de haber instalado Thanos Sidecar, debes instalar dos componentes para cada bucket de almacenamiento de objetos. Estos son Thanos Compactor y Thanos Store Gateway.
Después de eso, necesitas instalar Thanos Query y configurarlo para que pueda conectarse a todos los Thanos Store Gateway que tienes, así como a todos los Thanos Sidecar.
Aquí puede haber un pequeño problema.
Necesitas configurar una conexión segura y confiable de Thanos Query a estos componentes. Y si tienes Prometheus en diferentes centros de datos o en diferentes VPC, las conexiones externas están prohibidas. Pero para que Thanos Query funcione, necesitas establecer alguna forma de conexión, y debes encontrar una solución.
Si tienes muchos de estos centros de datos, la confiabilidad de todo el sistema disminuye. Ya que Thanos Query debe mantener constantemente conexiones con todos los Thanos Sidecar ubicados en diferentes centros de datos. En cada solicitud entrante, enviará peticiones a todos los Thanos Sidecar. Si la conexión se interrumpe, obtendrás un conjunto de datos incompleto o recibirás una respuesta de 'el clúster no está funcionando'.
En VictoriaMetrics todo es un poco más sencillo. Para la versión de nodo único, simplemente necesitas ejecutar un binario y todo funcionará.
En la versión en clúster, solo necesitas ejecutar los tres tipos de componentes mencionados anteriormente en cualquier cantidad que necesites, o utilizar para automatizar el lanzamiento de los componentes en Kubernetes. También planeamos crear un operador de Kubernetes. El helm chart no cubre algunos casos y puede permitirte dispararte en el pie. Por ejemplo, permite reducir la cantidad de nodos de almacenamiento, lo que provocará la pérdida de datos.
Después de que hayas lanzado un binario o la versión en clúster, solo necesitas agregar a la configuración de Prometheus , para que comience a registrar datos de forma paralela en el almacenamiento local y en el almacenamiento remoto. Como habrás notado, esta configuración debería funcionar mucho más confiablemente en comparación con la configuración de Thanos. No necesitamos mantener una conexión de VictoriaMetrics a todos los Prometheus, porque los Prometheus se conectan a VictoriaMetrics y transmiten datos.
Consideremos el soporte de Thanos y VictoriaMetrics.
Thanos necesita monitorear el Sidecar para asegurarse de que no detenga la carga de datos en el Object Storage. Ellos pueden interrumpir esta carga de datos debido a errores de carga, por ejemplo, si su conexión a la red con el Object Storage se interrumpe temporalmente o si el Object Storage no está disponible temporalmente. En ese momento, el Thanos Sidecar notará esto, reportará un error, puede fallar y después dejar de funcionar. Si no lo monitorea, dejará de transferir datos al Object Storage. Si se supera el tiempo de retención (6-8 horas recomendado), perderá datos que no llegaron al Object Storage.
Los compactores de Thanos pueden dejar de funcionar debido a . Los compactores toman datos del Object Storage y los consolidan en bloques de datos más grandes. Como los compactores no están sincronizados con los Sidecars, puede ocurrir lo siguiente: el Sidecar aún no ha terminado de escribir un bloque, el Compactor decide que este bloque está completamente escrito. El Compactor comienza a leerlo. Lee el bloque de manera incompleta y deja de funcionar. Vea los detalles .
El Store Gateway puede devolver datos inconsistentes debido a competencias entre el Compactor y los Sidecars. Aquí sucede lo mismo, porque el Store Gateway no está sincronizado con los Compactores y los Sidecars. Por lo tanto, pueden surgir condiciones de carrera, donde el Store Gateway no ve parte de los datos o ve datos adicionales.
El componente de consulta en Thanos por defecto devuelve resultados parciales si algunos Sidecars o el Store Gateway no están disponibles en ese momento. Obtendrá parte de los datos y ni siquiera sabrá que no recibió todos los datos. Así es como funciona por defecto. En una situación similar, VictoriaMetrics devuelve los datos marcados como parciales.
A diferencia de Thanos, VictoriaMetrics rara vez pierde datos. Incluso si se interrumpe la conexión de Prometheus con VictoriaMetrics, no es un problema, ya que Prometheus sigue escribiendo los nuevos datos entrantes en el Write Ahead Log, que tiene un tamaño de 2 horas. Si recupera la conexión con VictoriaMetrics dentro de dos horas, los datos no se perderán. Prometheus .
A diferencia de Thanos, que registra datos en el almacenamiento de objetos solo después de dos horas, Prometheus replica automáticamente los datos a través del protocolo remote write en el almacenamiento remoto, como VictoriaMetrics. No tienes que preocuparte por la pérdida del almacenamiento local en Prometheus. Si de repente pierde el almacenamiento local, en el peor de los casos, solo perderás los últimos segundos de datos que no se han registrado en el almacenamiento remoto.
Kubernetes gestiona automáticamente el clúster a diferencia de Thanos. Todos los componentes de Thanos son difíciles de encajar en un solo clúster de Kubernetes, a diferencia de los componentes en clúster de VictoriaMetrics.
Actualizar VictoriaMetrics a una nueva versión es muy sencillo. Simplemente detienes VictoriaMetrics, actualizas los binarios y vuelves a iniciar. Al detenerlo mediante la señal SIGINT, todos los binarios de VictoriaMetrics realizan un cierre limpio. Guardan correctamente los datos necesarios y cierran adecuadamente las conexiones entrantes para no perder nada. Por lo tanto, no perderás nada durante la actualización.
Es muy fácil expandir el clúster de VictoriaMetrics. Simplemente agregas los componentes necesarios y continúas trabajando.
Sobre las trampas de Thanos y VictoriaMetrics.
Thanos tiene las siguientes trampas. Prometheus debe almacenar datos de las últimas dos horas. Si se pierden, los perderás por completo, ya que aún no se han registrado en el almacenamiento de objetos, como S3.
El componente Store Gateway y el componente compactor pueden requerir mucha memoria para trabajar con grandes almacenes de objetos, si allí se almacenan muchos archivos pequeños. Cuanto mayor sea la cantidad y el tamaño de los archivos, más memoria RAM necesitarán el Store Gateway y el compactor para almacenar la metainformación. Thanos tiene muchos problemas relacionados con que .
Thanos se publicita como si pudiera escalar indefinidamente en la cantidad de tus Prometheus. En realidad, esto no es cierto. Dado que todas las consultas pasan a través del componente Query, que debe consultar en paralelo todos los componentes Store Gateway y todos los componentes Sidecar, extraer los datos de allí y luego preprocesarlos. Es evidente que la velocidad de las consultas está limitada por el eslabón más lento, ya sea el Store Gateway más lento o el Sidecar más lento.
Estos componentes pueden estar cargados de manera desigual. Por ejemplo, tienes un Prometheus que recolecta millones de métricas por segundo. Y hay otro Prometheus en el que se recolectan miles de métricas por segundo. El Prometheus que recolecta millones de métricas por segundo carga mucho más el servidor en el que opera. Por lo tanto, el Sidecar allí funciona más lentamente. En general, todo funciona más lento allí. Y el componente Query extraerá datos de allí muy lentamente. Como resultado, el rendimiento de todo tu clúster estará limitado por este Sidecar lento.
Por defecto, Thanos devuelve datos parciales si algunos Sidecar o el Store Gateway están no disponibles. Por ejemplo, si tienes Sidecar distribuidos por todo el mundo en diferentes centros de datos, la probabilidad de pérdida de conexión y la falta de disponibilidad de componentes aumentan significativamente. Por lo tanto, en la mayoría de los casos, recibirás datos parciales sin saberlo.
VictoriaMetrics también tiene sus trampas. La primera trampa es una opción que limita la cantidad de memoria RAM utilizada para la caché de VictoriaMetrics. Por defecto, es del 60% de la memoria RAM en la máquina donde está ejecutado VictoriaMetrics, o el 60% de la RAM del pod de VictoriaMetrics en Kubernetes.
Si se cambia incorrectamente este valor, se puede perjudicar el rendimiento de VictoriaMetrics. Por ejemplo, si se establece un valor demasiado bajo, los datos podrían dejar de caber en la caché de VictoriaMetrics. Esto implicaría que tendría que realizar trabajo adicional y cargar el procesador con el disco. Si configuras esta opción demasiado alta, aumentará, en primer lugar, la probabilidad de que VictoriaMetrics se cierre con un error de falta de memoria, y, en segundo lugar, dejará muy poca memoria RAM en el sistema operativo para la caché de archivos. Y VictoriaMetrics depende de la caché de archivos para su rendimiento. Si no hay suficiente, la carga en el disco puede aumentar significativamente. Por eso, el consejo es: no cambies este parámetro sin necesidad extrema.
La segunda opción es retentionPeriod, que por defecto está configurado en 1 mes. Este es el tiempo durante el cual VictoriaMetrics almacena los datos. Una vez transcurrido este plazo, VictoriaMetrics elimina los datos.
Muchos inician VictoriaMetrics sin este parámetro, registran datos durante un mes. Y luego preguntan: ¿por qué se perdieron los datos del mes anterior? Porque el retentionPeriod por defecto es de 1 mes. Por eso es necesario conocer y establecer el retentionPeriod correcto.
Repasemos las características únicas.
Thanos tiene una función llamada downsampling: intervalos de 5 minutos y de una hora, que a menudo . Si buscas en Google y miras sus problemas en GitHub, hay muchos problemas relacionados con este downsampling, que a veces no funciona correctamente, o no lo hace como esperan los usuarios.
Thanos tiene deduplicación de datos para pares de Prometheus HA. Cuando dos Prometheus recopilan las mismas métricas de los mismos targets y Thanos las combina en Object Storage. Thanos sabe cómo deduplicar correctamente estos datos, a diferencia de VictoriaMetrics.
Thanos tiene un componente de alertas, que estaba en el esquema de Thanos. Pero no .
Thanos tiene la ventaja de que el código de Thanos y de Prometheus es común. Thanos y Prometheus fueron desarrollados por los mismos desarrolladores. Al mejorar en Thanos o Prometheus, la otra parte se beneficia.
La principal característica de VictoriaMetrics es MetricsQL. Esta es la extensión de VictoriaMetrics para PromQL, sobre la que hablé en el último gran encuentro de monitoreo.
VictoriaMetrics admite la carga de datos a través de muchos protocolos diferentes. VictoriaMetrics no solo puede recibir datos de Prometheus, sino también a través de los protocolos Influx, OpenTSDB y Graphite.
Los datos de VictoriaMetrics ocupan normalmente mucho menos espacio en comparación con Thanos y Prometheus.
Si se registran datos reales, los usuarios mencionan una reducción de 2 a 5 veces en el tamaño de los datos en disco en comparación con Prometheus y Thanos.
Otra ventaja de VictoriaMetrics es que está optimizada para la velocidad.
Hablemos sobre el costo de la infraestructura.
Una de las ventajas de Thanos es que guarda los datos en object storage, que es relativamente barato.
Al guardar datos en object storage, debes pagar por las operaciones de escritura y lectura de datos ($10 por millón de operaciones). Cuando escribes datos en object storage, pagas los costos de tu hosting por cargar datos a Internet, si tu clúster no está en AWS, donde es gratuito. Al leer datos, pagas entre $10 y $230 por 1TB. Esto puede ser significativo si solicitas frecuentemente datos históricos del clúster de Thanos.
Para el clúster de Thanos, se deben pagar servidores para los componentes Compact, Store Gateway y Query, que requieren mucha memoria y CPU para grandes volúmenes de datos.
Los gastos para VictoriaMetrics son los siguientes. Si se almacenan los datos en discos HDD de GCE, el costo es de $40 por 1TB. Para VictoriaMetrics, son suficientes discos HDD comunes, no se necesitan SSD, que son cinco veces más caros. VictoriaMetrics está optimizada para HDD.
Para VictoriaMetrics se necesitan servidores para componentes: ya sea Single-node o para componentes de clúster, que, a diferencia de los componentes de Thanos, requieren mucho menos CPU y RAM, lo que resultará en un costo menor.
Ejemplos de implementación.
Un ejemplo de implementación de Thanos es Gitlab. Gitlab funciona completamente con Thanos. Sin embargo, no todo es tan simple. Si se revisan sus , se puede ver que constantemente enfrentan algunos : les falta memoria para los componentes Store Gateway o Query. Constantemente tienen que aumentar la capacidad de memoria.
Debido a esto, aumentan los gastos para resolver estos problemas.
Una segunda implementación, que puede ser más exitosa, es la empresa Improbable, que comenzó el desarrollo de Thanos. Publicaron el código fuente de Thanos. Improbable es una empresa que se dedica al desarrollo de motores de juego.
Los ejemplos públicos de implementación de VictoriaMetrics son:
- wix.com, un constructor de sitios web
- Adidas implementa VictoriaMetrics e incluso dio una presentación en el último PromCon 2019
- TrafficStars, una red publicitaria
- Seznam.cz, un popular buscador checo.
Y luego están las empresas sin nombre que no puedo mencionar ahora. No dieron su consentimiento.
- Un gran desarrollador de videojuegos. Más grande que Improbable.
- Un gran desarrollador de software gráfico.
- Un gran banco ruso.
- Un fabricante europeo de turbinas eólicas que ha probado con éxito VictoriaMetrics. Este fabricante implementa VictoriaMetrics para monitorear los datos obtenidos de las turbinas eólicas a una tasa de 50 muestras por segundo por cada sensor. En cada turbina eólica hay varios cientos de sensores. Tienen varias centenas de turbinas eólicas.
- Aerolíneas rusas que quieren implementar VictoriaMetrics, pero no pueden hacerlo aún. Estamos en la etapa del contrato con ellos.
Conclusiones.
VictoriaMetrics y Thanos abordan problemas similares, pero de diferentes maneras:
- Vista global de consulta
- escalado horizontal
- retención arbitraria
Gracias.
Los esperamos en nuestro .
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Qué utilizas como almacenamiento a largo plazo para Prometheus?
35,3%Thanos
0,0%Cortex
0,0%M3DB
41,2%VictoriaMetrics
23,5%otro
17 usuarios votaron. 16 usuarios se abstuvieron.
Fuente: habr.com
