Invitado | Organizado por Huo Bingjie | Producido por Xijing Swordsman | CSDN Yunyuan
Prometheus, como proyecto simbólico que surge en la era nativa de la nube, se ha convertido en el estándar de facto en el campo observable. Prometheus no es escalable para una sola instancia, por lo que si los usuarios necesitan recopilar más datos y guardarlos durante un período de tiempo más largo, ¿qué solución de almacenamiento a largo plazo deberían elegir?
El 9 de agosto de 2022, en la 15.ª "Cumbre Prometheus" de la Cumbre en línea de la serie nativa de la nube de CSDN, Huo Bingjie, jefe de Observabilidad y Computación de funciones en Qingyun Technology, compartió "Almacenamiento a largo plazo de Prometheus: todos los ríos son inclusivos y la tolerancia es genial".
Introducción a Prometeo y sus limitaciones
Prometheus, que surgió en la era nativa de la nube, se ha utilizado ampliamente en el campo observable y su influencia va mucho más allá del alcance de la nube nativa, con dos características notables.
Instancia única, no escalable
El autor de Prometheus y los principales desarrolladores de la comunidad se adhieren a un concepto: Prometheus solo se enfoca en las funciones principales, y las funciones extensibles se dejan a la comunidad para que las resuelva, por lo que Prometheus ha sido una instancia única no escalable desde su nacimiento. .
Esto es increíble para muchos ingenieros que han venido de la era de los grandes datos Muchos proyectos de código abierto en el campo de los grandes datos, como Elasticsearch, HBase, Cassandra, etc., son diseños de múltiples nodos y múltiples funciones.
El desarrollador central de Prometheus explicó una vez que Prometheus combina las características y ventajas del lenguaje Go, lo que le permite capturar y almacenar más datos a un costo menor, mientras que los proyectos de big data implementados en Java, como Elasticsearch o Cassandra, procesan la misma cantidad de datos. Consumirá más recursos. En otras palabras, Prometheus, de instancia única y no escalable, es lo suficientemente potente como para satisfacer las necesidades de la mayoría de los usuarios.
Modo pull para obtener datos
Prometheus aboga por el uso del modo Pull para obtener datos, es decir, Prometheus va activamente a la fuente de datos para extraer datos. Para fuentes de datos que no son convenientes para Pull, Prometheus proporciona PushGateway para procesamiento, pero PushGateway tiene limitaciones en algunos escenarios de aplicación.
Aunque una sola instancia de Prometheus es lo suficientemente poderosa, todavía hay algunos requisitos que no puede cumplir, como la agregación entre clústeres, almacenamiento más prolongado, etc. Para expandir Prometheus, la comunidad ha brindado una variedad de soluciones.
Antes de la aparición del almacenamiento a largo plazo de Prometheus, si los usuarios necesitaban agregar datos informáticos entre clústeres, la comunidad proporcionaba un método de federación.
Hay un Prometheus global en la capa superior de múltiples instancias de Prometheus, que es responsable de obtener datos y computar en cada instancia, para resolver el problema de la computación agregada entre clústeres. Sin embargo, si el volumen de datos de cada clúster es grande, GlobalPrometheus de instancia única también encontrará cuellos de botella.
El auge de la solución de almacenamiento a largo plazo de Promretheus
Prometheus agregó la API de lectura/escritura remota en 2017. Desde entonces, ha surgido una gran cantidad de soluciones de almacenamiento a largo plazo en la comunidad, como Thanos, Grafana Cortex/Mimir, VictoriaMetrics, Wavefront, Splunk, Sysdig, SignalFx, InfluxDB , Grafito, etc
A continuación, seleccionaremos varias soluciones principales de almacenamiento a largo plazo de Prometheus para un análisis comparativo.
M3
M3 es una solución de almacenamiento a largo plazo de Prometheus de código abierto de Uber. Sus componentes incluyen principalmente M3 Coordinate, M3 Queries, M3 Aggregator y M3DB.
El principio de funcionamiento de M3 es que Prometheus escribe datos en M3DB a través de M3 Coordinate Remote, y M3 Queries puede conectarse directamente a M3DB para realizar consultas. M3Aggregator agrega los datos recibidos en tiempo real, reduce la muestra y los almacena en M3DB.
M3 es una solución de almacenamiento a largo plazo de Prometheus desarrollada por Uber para satisfacer sus propias necesidades de datos masivos. Sus desventajas son que es difícil de implementar, la comunidad no está activa y la documentación no es buena.
VictoriaMetrics
VictoriaMetrics es un proyecto de almacenamiento a largo plazo Prometheus de código abierto, además de los proyectos de código abierto, hay productos y servicios comerciales. Los adoptantes de VictoriaMetrics incluyen Zhihu, Grammarly, fly.io, CERN, etc.
VictoriaMetrics se compone principalmente de tres componentes: vminsert para acceder a los datos, vmstorage para almacenar datos y vmselect para consultar datos.
Tanto vminsert como vmselect no tienen estado y se pueden ampliar agregando réplicas.
Aunque vmstorage tiene estado, también se puede expandir.Cuando la cantidad de datos excede la capacidad de almacenamiento de una copia, se puede expandir agregando otra copia.
La función de Agente de VictoriaMetrics es relativamente potente, lo que se refleja principalmente en los siguientes aspectos:
- Puede reemplazar a Prometheus para obtener datos y también puede recibir datos enviados por fuentes de datos distintas de Prometheus, como Graphite, InfluxDB, OpenTSDB, etc.;
- Los datos capturados pueden escribirse remotamente en varios almacenamientos a largo plazo;
- Se puede distribuir una gran cantidad de objetivos de rastreo entre las instancias de vmagent.
VictoriaMetrics también tiene un componente separado para alertas: VictoriaMetrics Alert, que tiene dos funciones:
- Determine si se requiere una alarma consultando vmselect y envíe la alarma al administrador de alertas si es necesario;
- Calcule la regla de grabación consultando vmselect y escriba el resultado del cálculo en el almacenamiento a través de vminsert.
Otro componente es VictoriaMetrics Gateway, que tiene dos funciones principales:
- Límite de velocidad, cuando el inquilino lee y escribe, se escribirán algunos datos en otra instancia de VictoriaMetrics para registrar el uso, y se harán ciertas restricciones cuando se exceda la cantidad;
- Control de acceso, control de acceso significa que antes de leer o escribir, primero se debe obtener un Token.
VictoriaMetrics también tiene otros componentes como vmauth, vmbackup/vmrestore, vmbackupmanager, vmanomaly, etc.
Vale la pena mencionar que no todas las funciones de VictoriaMetrics son de código abierto, y las funciones de la versión empresarial que no son de código abierto incluyen:
- Reducción de muestreo reducción de muestreo;
- vmgateway 的 SSO, LDAP, autenticación de token JWT y control de acceso;
- Límites de velocidad de lectura y escritura a nivel de arrendatario;
- vmagent lee y escribe Kafka;
- Alarma y estadísticas de múltiples inquilinos;
- Administrador de copia de seguridad;
- Supervisión de anomalías basada en aprendizaje automático para vmanomaly.
Thanos
Thanos, de código abierto de Improbable, es la primera solución de almacenamiento a largo plazo de Prometheus en la comunidad, y sus usuarios incluyen a Adobe, Byte, eBay y Tencent.
Thanos es relativamente innovador en arquitectura y tiene muchas funciones únicas:
- Puede proporcionar una vista de consulta global de las instancias de Prometheus y puede consultar y agregar datos en varias instancias de Prometheus;
- Los datos se pueden cargar en el almacenamiento de objetos a través de Sidecar para el almacenamiento a largo plazo;
- Se proporcionan funciones de compresión y reducción de muestreo. A través de la compresión, se puede reducir el tamaño de los bloques guardados en el almacenamiento de objetos y, a través de la reducción de muestreo, se puede acelerar la velocidad de consulta y agregación de datos a largo plazo.
Thanos tiene dos modos, el modo Sidecar y el modo Recibir.
Modo sidecar de Thanos
El modo ThanosSidecar es el modo más antiguo admitido por Thanos. Su principio es:
- Hay un Sidecar en cada Prometheus Pod, que interactúa con el mundo exterior a través de la Store API;
- Thanos Query interactúa con Thanos Sidecar a través de Store API, consulta los datos en cada instancia de Prometheus a través de Thanos Sidecar, los agrega y brinda a los usuarios una vista global de varias instancias de Prometheus después de la deduplicación;
- Shipper en Thanos Sidecar cargará el bloque colocado en la instancia local de Prometheus en el almacenamiento de objetos, y luego Thanos Compact comprimirá, reducirá la muestra y expirará el bloque cargado en el almacenamiento de objetos;
- Store Gateway to Thanos Query puede proporcionar el bloque almacenado en el almacenamiento de objetos a través de Store API, y Store Gateway almacenará en caché el índice del bloque en el almacenamiento de objetos para acelerar la consulta;
- Además, hay Thanos Query Frontend frente a Thanos Query para almacenar en caché los resultados de las consultas para acelerar las consultas;
- Thanos Ruler se usa para calcular las reglas de grabación o alerta consultando Thanos Query.
Modo de recepción de Thanos
El modo de recepción de Thanos es un nuevo modo agregado por Thanos en respuesta a las necesidades de los usuarios de la comunidad de escritura remota. El principio es:
- Prometheus o Prometheus Agent envía datos de monitoreo al enrutador de recepción de Thanos a través de escritura remota;
- El enrutador de recepción de Thanos envía datos al Ingestor de recepción de Thanos correspondiente de acuerdo con la información del arrendatario, donde el enrutador no tiene estado y el Ingestor tiene estado;
- Thanos Receive Ingestor es equivalente a agregar compatibilidad con Store API para interactuar con Thanos Query/Thanos Ruler sobre un Prometheus sin captura de datos ni capacidades de alarma, y agregar un componente Shipper para cargar objetos en bloques de almacenamiento;
- Thanos Query puede consultar uniformemente a Thanos Ingestor y Thanos Store Gateway;
- Las funciones de otros componentes son similares al modo Thanos Sidecar.
Corteza
Cortex es de código abierto de Grafana, y los productos o proyectos como Loki, Tempo y Grafana Cloud utilizan la tecnología de Cortex. Los adoptantes incluyen AWS, Digital Ocean, Grafana Labs, MayaData, Weaveworks y más.
Cortex se basó originalmente en la versión Chunk Storage. Debido a la complejidad de la implementación y el funcionamiento y su dependencia de Cassandra o DynamoDB para almacenar metadatos, se ha determinado que está obsoleta y reemplazada por una versión basada en Block Storage.
Inspirada en Thanos, la nueva arquitectura de Cortex utiliza Block Storage. Podemos ver que el distribuidor, el ingerido, el buscador, el gobernante, la puerta de enlace de la tienda y el compactador de la nueva arquitectura de Cortex son todos similares a Thanos, y la regla, la puerta de enlace de la tienda y el compactador se tomaron prestados de Thanos.
Grafana Mimir
Grafana Mimir es un proyecto de código abierto recientemente lanzado por Grafana Lab bajo el acuerdo AGPL v3 a fines de marzo de 2022.
En el Blog que anuncia Grafana Mimir publicado por Mimir, se puede ver que Grafana Mimir ha agregado muchas funciones de nivel empresarial después del proyecto Fork the Cortex, que se utiliza en Grafana Cloud y Grafana Enterprise Customers' Grafana Enterprise Metrics (GEM). La razón principal de esto es que Grafana Lab cree que Cortex es utilizado por algunos ISV o proveedores de la nube para brindar servicios a sus clientes, pero no contribuyen con código como Grafana Lab, por lo que colocan más y más funciones en Fork Mimir de Cortex.
Como una versión mejorada de Cortex, Mimir no ha sido de código abierto durante mucho tiempo, pero esto es contrario a la cultura de código abierto de Grafana Lab, por lo que para tener en cuenta tanto el código abierto como sus propios intereses comerciales, Grafana Lab hizo que Mimir fuera abierto. fuente bajo AGPL v3.
Desde Grafana Mimir Fork Cortex, su arquitectura es muy similar a Cortex y Thanos.
Aunque Grafana Mimir también se basa en la puerta de enlace de la tienda, el compactador y la regla de Thanos, la diferencia con Cortex es que se agrega un programador de consultas de componentes adicionales entre el queryer y la interfaz de consultas, lo que satisface mejor la escalabilidad del componente de consultas.
La escalabilidad horizontal de los componentes de Mimir (incluido el compactador, la puerta de enlace de la tienda, la consulta, la regla, etc.) es buena. Vale la pena mencionar que Mimir admite la expansión horizontal y multiusuario de Alertmanage.
Comparación de soluciones de almacenamiento a largo plazo de Prometheus
Podemos hacer una comparación horizontal de las soluciones de almacenamiento a largo plazo de Prometheus presentadas anteriormente en función de múltiples dimensiones:
- Thanos y Cortex han sido donados a la Fundación CNCF y están en etapa de incubación, con mejor neutralidad, mientras que la licencia AGPL v3 de Mimir no es lo suficientemente amigable;
- Según los indicadores de algunos proyectos de código abierto, Thanos es más popular y tiene más seguidores;
- Mimir es una versión de código abierto de los productos comerciales de Grafana Lab, con mejor escalabilidad horizontal;
- Mimir y VictoriaMetrics tienen mejor documentación;
- Mimir y VictoriaMetrics son mejores en términos de funciones de nivel empresarial, como multiusuario, control de acceso y diversidad de fuentes de datos de acceso;
- M3 no es dominante en todas las dimensiones.
Resumir
En resumen, podemos sacar las siguientes conclusiones.
- VictoriaMetrics es una mejor opción para la persistencia de datos en el disco duro, pero debe tenerse en cuenta que VictoriaMetrics no tiene una función de reducción de resolución de código abierto.Si necesita agregar y consultar en un rango de tiempo largo, llevará mucho tiempo.
- En la solución de persistencia de datos para el almacenamiento de objetos, Thanos es más popular y Grafana Mimir tiene más potencial.
- Thanos puede usar datos de inventario local en lugar de almacenamiento de objetos (Cortex/Mimir por verificar).
- Grafana Fork Cortex, creó Mimir y modificó la Licencia a AGPL-3.0. El nivel de inversión en Grafana y la comunidad en el futuro es dudoso y no se recomienda seguir usando Cortex.
- Thanos/Cortex/Mimir se toman prestados y tienen arquitecturas similares. Cortex/Mimir toma prestado el acceso y la persistencia del almacenamiento de objetos de Thanos. Thanos toma prestado de QueryFrontend de Cortex. Como versión de código abierto de Grafana Cloud, Mimir ha realizado más optimizaciones basadas en la arquitectura de Thanos y Cortex.
- En términos generales, si no le importa la licencia, puede usar Mimir.Si le interesa una licencia más relajada, Thanos del proyecto de incubación CNCF es una mejor opción.
- Si no hay almacenamiento de objetos, se recomienda usar VictoriaMetrics (algunas funciones importantes no son de código abierto), y si hay almacenamiento de objetos, intente usar Thanos o Mimir.
- Trate de no usar M3 sin razones especiales.
¡Este artículo es publicado por OpenWrite , una plataforma de publicación múltiple para blogs!