Monitoreo con Prometheus, Grafana, AlertManager y VictoriaMetrics
Autores: Aécio Pires, Alan Santos y Gabriel Monteiro.
Introducción:
El monitoreo de aplicaciones es un gran desafío, y por eso, se utilizan distintas herramientas para entregar un control de alto nivel a los equipos involucrados en el control y análisis de datos. Con esto en mente y aportando un poco de la experiencia de Sensedia, podemos citar los siguientes sistemas que pueden ayudar en el seguimiento de las aplicaciones y servicios de una empresa:
- Prometheus: un sistema de recolección métrica de aplicaciones y servicios para el almacenamiento en un banco de datos de serie temporal resultando muy eficiente.
- AlertManager: trabaja de forma integrada al Prometheus para realizar la evaluación de las reglas de alertas y hacer el envío de notificaciones por email, Jira, Slack y otros sistemas asistidos.
- Grafana: una solución de análisis y observabilidad que ofrece soporte a varios sistemas de recolección de logs y métricas. Cuando está integrado con Prometheus sirve para mostrar las métricas en dashboards bien elegantes y útiles para las distintas áreas de una empresa/organización.
- Prometheus-Operator: un software que tiene el objetivo de simplificar y automatizar la instalación y configuración del Prometheus, AlertManager, Grafana y exporters en clústeres Kubernetes.
- VictoriaMetrics: una solución de monitoreo y banco de datos de serie temporal rápida, económica y escalable. Pero que en nuestro caso se utiliza para el almacenamiento a largo plazo y centralizado de las métricas recolectadas por diferentes servidores Prometheis (plural de Prometheus).
Todas estas herramientas tienen el código fuente abierto y disponible en Github.
Ahora puedes crear el clúster e instalar Prometheus-Operator siguiendo el tutorial disponible en el repositorio sensedia/open-tools. Si no sabes qué es Prometheus-Operator, recomiendo fuertemente ver esta conferencia presentada por Daniel Requena durante el FiqueEmCasaConf y/o ver los enlaces que constan en las referencias
¿Pero cuál es la ventaja de usar estas herramientas?
Podemos destacar varias ventajas por utilizar estas herramientas para aumentar el control de datos. Como estamos mirando mucho al Open finance este año, podemos hablar un poco sobre cómo estas herramientas pueden ayudar a aportar control y gobernanza por encima de los procesos bancarios.
Cuando integras tu software con las APIs del banco, abres un abanico de posibilidades, pero ¿qué pasa con el control de todo eso? ¿Cómo supervisar si los servicios que soportan estas interacciones funcionan correctamente? La respuesta a estas preguntas es la monitorización, que puede realizarse mediante Prometheus, AlertManager, Grafana y otros sistemas.
Al tener un monitoreo efectivo, conseguirás:
- Tener más agilidad en la resolución de problemas;
- Identificar inestabilidades y picos de alto volumen de transacciones;
- Mayor control de datos.
Y estas son solo algunas de las muchas ventajas que el seguimiento de datos puede traer a su negocio.
¿Cómo usamos estas herramientas?
Nuestro ambiente productivo es multi cloud y tenemos varios clústeres Kubernetes distribuidos en AWS y GCP. Es en ellos donde ejecutamos las aplicaciones y servicios utilizados por los clientes.
Básicamente, en cada clúster de Kubernetes se instala el prometheus-operator para gestionar únicamente el prometheus y los exportadores necesarios para recoger las métricas. En lugar de instalar Grafana y Alertmanager en cada clúster, optamos por instalar estos servicios en un único clúster.
Todas las métricas recogidas por Prometheis se envían a VictoriaMetrics, que centraliza su almacenamiento y consultas. Por defecto, Prometheus-Operator almacena las métricas localmente durante solo 2 horas. Con VictoriaMetrics podemos almacenar todas las métricas de todos los Prometheis durante mucho tiempo.
Grafana es entonces configurado para conectar al VictoriaMetrics para consulta y muestra de las métricas. Con relación a los alertas, todos los Prometheis envían a un pool de AlertManager. De esa forma conseguimos garantizar la disponibilidad y centralización de las métricas y alertas. Conviene destacar que todos los datos son traficados de forma criptografiada y el acceso a los datos es realizado por medio de una autenticación y a partir de IPs de origen autorizados.
VictoriaMetrics
Esta herramienta merece una especial atención y explicaremos el motivo a continuación.
De enero a octubre de 2020, utilizábamos el InfluxDB como la solución de almacenamiento de las métricas a largo plazo de los Prometheis, pero llegamos a tener serios problemas en el almacenamiento y visualización de las métricas ante la creciente demanda por la recolección de nuevas métricas. Esto no significa que el InfluxDB sea una mala solución, por el contrario, nos atendió muy bien durante mucho tiempo, pero después de varios estudios, ajustes en los archivos de configuración y aumento muy considerable en los recursos de CPU y memoria, vimos que ejecutar el InfluxDB sin utilizar el modo clúster (que es pago) ya no nos estaba atendiendo bien.
Con eso decidimos hacer una búsqueda por soluciones alternativas y entre ellas estaban:
-Thanos;
Después de varios estudios sobre cada una de las soluciones, conversaciones con amigos y compañeros que ya utilizaban algunas de ellas en otros ambientes, además de reflexionar sobre las necesidades del negocio y el costo x beneficio que cada una agregaría al día, optamos por el VictoriaMetrics.
Los factores claves para tomar esta decisión fueron:
- La simplicidad de instalación y configuración, después de la comparación con las demás herramientas;
- No fue necesario rehacer los dashboards en el Grafana, ya que el VictoriaMetrics tiene soporte al PromQL;
- No era necesario tener un Prometheus de sólo lectura (es decir, utilizando la API remote_read, intermediando la comunicación entre Grafana y VictoriaMetrics);
- Poco uso de recursos de CPU y memoria para almacenar y procesar un alto volumen de métricas. Esto fue observado en algunos casos de uso en ambientes de producción de empresas de relevancia global. Ver página: https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/CaseStudies;
- Benchmark con resultados positivos frente a otras soluciones, realizado por una persona que trabaja en Addidas y en un ambiente de alta volumetría de métricas.
Hicimos una PoC utilizando el VictoriaMetrics (modo clúster) durante el Black Friday (época del año en la cual se realiza el mayor volumen en la generación de métricas frente a la demanda y modelo de negocio de nuestros clientes). En ese periodo no tuvimos ningún problema con la stack de monitoreo y continúa así desde entonces. Antes teníamos algunas veces problemas con la stack de monitoreo, casi todos los días. No impactaba el ambiente de producción de los clientes, pero demandaba un buen tiempo de los equipos de operación durante la realización de troubleshooting.
En el modo clúster, el VictoriaMetrics está compuesto por los siguientes componentes:
- vmstorage: almacena las métricas en un volumen persistente. En nuestro caso, los datos son almacenados en discos EBS;
- vmselect: se utiliza para la lectura/consulta de las métricas. Él recibe las requisiciones de lectura, interactúa con el vmstorage para obtener el acceso a las mismas y después envía los datos solicitados.
- vminsert: se utiliza para la escritura de las métricas. Él recibe las requisiciones de escritura y repasa al vmstorage para el almacenamiento de las mismas;
- vmauth: es un proxy de autenticación simple que redirige las requisiciones de lectura/escritura al vmselect/vminsert. Él valida el nombre de usuario y la contraseña de los encabezados Basic Auth, los compara con las configuraciones de redirección definidas y actúa como proxy de las solicitudes HTTP.
Vamos a los números:
- 28 Prometheis (uno para cada clúster) enviando las métricas al VictoriaMetrics;
- 2 pods del componente vmselect
o CPU: 500 millicolores como mínimo y 1 CPU como máximo
o Memoria: 500 MB como mínimo y 3 GB como máximo
o Volumen: 8 GB
- 2 pods del componente vminsert
o CPU: 500 millicolores como mínimo y 1 CPU como máximo
o Memoria: 500 MB como mínimo y 3 GB como máximo
o Volumen: 8 GB
- 2 pods del componentes vmstorage:
o CPU: 500 millicolores como mínimo y 1 CPU como máximo
o Memoria: 500 MB como mínimo y 4 GB como máximo
Volumen: 1 TB
- 2 pods del componente vmauth
o CPU: 200 millicolores como mínimo y 1 CPU como máximo
o Memoria: 128 MB como mínimo y 1 GB como máximo
- 2 Load Balancers para el vmauth del tipo ALB (Application Load Balancer):
o 1 del tipo internal para recibir las métricas de Prometheis que estuvieron en la misma VPC del VictoriaMetrics;
o 1 del tipo internet-facing para recibir las métricas de los demás Prometheis que estuvieron en otras VPCs o en otro Cloud Provider.
- Active Time Series: 2.3 Millones
- Disk Space Usage: 67 GB (las métricas se rotan cada 15 días)
- Ingestion Rate: 40.1 K points/second
- Requests Rate: 134 req/second
- Total Datapoints: 90,3 mil millones (las métricas se rotan cada 15 días)
- Network Usage:
o 20 Mbps utilizado solo para recibir las métricas de todos los Prometheis.
o 70 Kbps utilizado solo para consulta de las métricas por medio del Grafana.
Durante las actividades de migración al VictoriaMetrics, también necesitamos desarrollar el Helm Chart del componente vmauth. El código de este Helm Chart fue compartido en el repositorio oficial del VictoriaMetrics y también ayudamos a organizar la documentación de los otros Helm Charts utilizando el helm-docs. Esta fue una pequeña forma de retribuir y agradecerle a la comunidad open source.
Si estuviera interesado(a) en hacer una prueba con el VictoriaMetrics en clústeres Kubernetes, recomendamos utilizar los Helm Charts que están disponibles en: https://github.com/VictoriaMetrics/helm-charts. Para obtener más información, ingrese a los enlaces que están en las referencias.
Hay varios dashboards disponibles en el sitio del Grafana para ver las métricas internas del VictoriaMetrics, pero recomendamos la utilización del siguiente: https://grafana.com/grafana/dashboards/11831.
Consideraciones Finales
En este tutorial conocemos un poco sobre un conjunto de herramientas utilizadas para el monitoreo de servicios y aplicaciones y vimos una solución que puede ser utilizada para el almacenamiento a largo plazo y centralizado de las métricas recolectadas por el Prometheus.
Inicie su transformación con nosotros
Sensedia está especializada en soluciones de arquitectura basada en eventos, con experiencia desde la creación de estrategias hasta su implementación.
Contenido relacionado
La combinación perfecta de experiencia, personal y plataforma para gestionar sus API.
Su arquitectura digital es más integrada, ágil y escalable.
Acelere la entrega de sus iniciativas digitales a través de APIs, Microservicios e Integraciones menos complejas y más eficientes que impulsen su negocio.
.svg){kind=logo}
