Observabilidad en Elasticsearch: Adopción de estándares de Prometheus y OpenMetrics para métricas
En este blog abarcaremos lo siguiente:
- La importancia de los estándares abiertos
- El formato de exposición de Prometheus
- La visión de Elastic sobre la observabilidad
- Tres maneras en que Elasticsearch puede usar las métricas de Prometheus
- Un ejemplo de cómo recolectar y visualizar métricas expuestas por el exportador Prometheus para Redis
Estándares abiertos
En opensource.com encontrarás un recurso informativo llamado: "What are Open Standards?" (¿Qué son los estándares abiertos?). En ese documento se incluyen muchos puntos importantes; pero después de muchos años en operaciones, creemos que estos son los más destacados:
- Disponibilidad: los estándares abiertos permiten que todos los lean e implementen.
- Maximización de la elección del usuario final.
- No discriminación (neutralidad del proveedor): los estándares abiertos y las organizaciones que los administran no favorecen a un implementador por sobre otro.
- Sin secretos intencionales: el estándar no debe retener ningún detalle necesario para la implementación interoperable.
Esos son motivos convincentes de por qué son buenos los estándares abiertos, ahora hablemos de por qué el formato de exposición de Prometheus es la base de OpenMetrics. En sus conferencias en PromCon 2018 y KubeCon + CloudNativeCon, USA 2018, Richard Hartmann resumió los motivos para crear un estándar abierto influenciado por el formato de exposición de Prometheus:
- La mayoría de los formatos de datos son de propiedad exclusiva, difíciles de implementar o ambas cosas.
- Prometheus se ha convertido en un estándar de hecho en el monitoreo de métricas nativas de la nube.
- La facilidad de los datos de exposición ha llevado a una explosión en los puntos finales de métricas compatibles.
- El formato de exposición de Prometheus se basa en mucha experiencia operativa, pero se diseñó entre pocas personas.
- Algunos otros proyectos y proveedores no se sienten cómodos adoptando algo de un producto "competidor".
Formato de exposición de Prometheus
Puedes leer acerca del formato de exposición en el repositorio de Github sobre Prometheus. Por ahora, solo veamos un ejemplo. Tenemos un exportador, el exportador Redis de Oliver006, que publica métricas en el puerto 9121 en el punto final /metrics. Aquí solo mostramos información sobre la métrica de Redis "instantaneous ops per second" (operaciones instantáneas por segundo). Hay tres líneas de la lectura:
- Texto de ayuda
- El tipo de métrica (medición en este caso)
- El servidor Redis que se mide (puerto de host local 6379) y la lectura actual (9 operaciones por segundo)
Observabilidad en Elastic
Te recomendamos que leas acerca de la visión de Elastic sobre la observabilidad, pero esta es nuestra frase favorita del blog:
El objetivo de diseñar y crear un sistema “observable” es asegurarse de que cuando se ejecute en producción, los operadores responsables de este puedan detectar comportamientos no deseados (p. ej., tiempo de inactividad del servicio, errores, respuestas lentas) y tengan información procesable para localizar la causa raíz de manera eficaz (p. ej., logs de eventos detallados, información granular de uso de recursos y rastreos de aplicaciones).
Esta afirmación, que respaldamos por completo, nos indica que necesitamos todos los logs, métricas e información de rastreo para ejecutar, reparar y administrar los servicios que proporcionamos. Prometheus es una parte muy importante de la observabilidad debido a su amplia adopción y comunidad activa. El estándar OpenMetrics solo aumentará el valor eliminando barreras, reales o aparentes, para la adopción de un formato de métricas "nativo de operaciones" de sentido común.
La mayoría de las personas con las que hablamos están muy familiarizadas con el Elastic Stack, o ELK, para logging. Si no sabías que el Elastic Stack también es excelente para las métricas y APM, echa un vistazo a lo que ofrecemos para métricas y APM/rastreo distribuido.
Estos son los motivos principales por los que vemos interés en la integración profunda entre la manera del Elastic Stack y Prometheus para exportar métricas:
- La combinación de métricas con logs y APM en Elasticsearch, y su correlación en Kibana. Echa un vistazo a una historia de usuario de NS1 sobre la combinación de logs y métricas en el Elastic Stack.
- El uso de Elasticsearch como almacenamiento a largo plazo para métricas recolectadas por el servidor Prometheus, que actualmente no soporta la agrupación de forma nativa.
- La obtención de una visión global de tus métricas en todas las instancias de Prometheus geográficamente dispersas.
En el resto del blog se describe en detalle cómo abordamos estas integraciones.
Un exportador de muestra
Nuestro entorno de demostración se ejecuta en Google Kubernetes Engine (GKE), por lo que ejecutamos tanto la aplicación Metricbeat como el exportador Prometheus en Kubernetes. Este es un extracto del manifiesto de Oliver006 para el despliegue de un exportador Redis como sidecar junto a la imagen de Redis. Como puedes ver, el exportador publica en el puerto 9121, que es el número de puerto asignado predeterminado para el exportador Prometheus para Redis.
...
- name: redis-exporter
image: oliver006/redis_exporter:latest
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 9121
...
Extracción de métricas con el módulo de Prometheus para Metricbeat
Metricbeat es el cargador ligero para métricas de Elastic. El módulo de Prometheus que se envía con Metricbeat puede reunir métricas de tres maneras:
- Conectándose al servidor Prometheus en el puerto 9090 y extrayendo las métricas ya recolectadas usando la API de federación de Prometheus (para obtener las métricas que Prometheus recolecta)
- Conectándose al servidor Prometheus en el puerto 9090 usando el punto final /metrics (automonitoreo de Prometheus)
- Conectándose a exportadores Prometheus individualmente y parseando el formato de exposición
¿Por qué elegir un enfoque por sobre otro? Depende de tu grado de comodidad con el servidor Prometheus.
- Si ya tienes el servidor Prometheus configurado para extraer métricas y deseas buscar directamente en estas métricas por motivos de integración, puedes comenzar con las opciones (1) y (2).
- Si, por el contrario, aún no tienes un servidor Prometheus o no tienes inconveniente en extraer de los exportadores en paralelo con varias herramientas, puedes elegir la opción (3).
Nota: Algunas de las funcionalidades anteriores de Metricbeat son beta en la versión 7.0 de Metricbeat. Te recomendamos descargar la versión beta 7.0 o copiar los enlaces del contenedor desde https://www.docker.elastic.co/ y ejecutar la versión beta en un entorno que no sea de producción.
API de federación de Prometheus
En general, la federación se usa para permitir el escalado, juntar sets de datos o hacer una copia de los datos disponibles en una ubicación diferente (para recuperación de desastre). El servidor Prometheus proporciona un punto final /federation al que Elastic se conecta para copiar las métricas que recolectó Prometheus por todos los motivos anteriores.
...
- module: prometheus
period: 10s
hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
metrics_path: '/federate'
query:
'match[]': '{__name__!=""}'
...
En el ejemplo anterior, la búsqueda está configurada como cualquier cosa cuyo nombre no esté en blanco (vaci. Quizás no quieras tomar todo, y los documentos de Prometheus tienen información sobre cómo escribir una condición de coincidencia más restrictiva. En el ejemplo también se realiza la conexión al servidor Prometheus cada diez segundos, nuestro servidor de demostración solo recolecta de algunos pods y kube-state-metrics, pero quizás quieras cambiar el intervalo.
Automonitoreo de Prometheus
Prometheus proporciona un punto final /metrics, al igual que los exportadores. Esto es para que puedas recolectar métricas sobre el servidor Prometheus. Está configurado de la siguiente manera:
...
- module: prometheus
period: 10s
hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
metrics_path: /metrics
...
Extracción del exportador Prometheus
Este extracto de YAML de un manifiesto para desplegar un DaemonSet
de Metricbeat le indica a Metricbeat que realice la autodetección
con
kubernetes.labels.app == redis y lea las métricas desde el puerto
9121 de ese pod. Recuerda que el containerPort configurado para el contenedor
del exportador Redis es 9121.
...
- condition.equals:
kubernetes.annotations.prometheus.io/scrape: "true"
config:
- module: prometheus
period: 10s
# Redis pods
hosts: ["${data.host}:9121"]
metrics_path: /metrics
...
Una vez desplegado Metricbeat, a cualquier pod que cumpla con la condición kubernetes.labels.app == redis se le aplica el módulo Prometheus; y las métricas se recolectan del sidecar del exportador en el puerto 9121.
Pero los metadatos hacen que el mundo de k8s gire, ¿verdad? Hagamos más con los metadatos y la característica de autodetección de Beats. Echa un vistazo a este reemplazo del extracto anterior de YAML:
...
- condition.equals:
kubernetes.annotations.prometheus.io/scrape: "true"
config:
- module: prometheus
period: 10s
hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
metrics_path: /metrics
...
Ahora en lugar de buscar exportadores para los pods de Redis, buscamos
exportadores para cualquier pod con una anotación
kubernetes.annotations.prometheus.io/scrape configurada como verdadera. También
de esta forma se configura la autodetección de Prometheus. Generalmente, la autodetección
de Metricbeat está regida por una anotación en el espacio de nombres
elastic.co, pero como estamos hablando de leer desde los exportadores Prometheus,
debemos respetar las anotaciones de k8s estándar asociadas
con Prometheus. Si observas la lista de hosts anterior:
hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
Puedes ver que ya no codificamos de forma rígida el puerto 9121, debido a que
ese es el puerto del exportador Redis. La anotación
prometheus.io/port está configurada con el número de puerto del exportador. Por motivos de integridad, aquí
hay un extracto de guestbook.yami en donde se configuraron estas
anotaciones:
...
kind: Deployment
metadata:
name: redis-master
spec:
replicas: 1
template:
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9121"
labels:
app: redis
...
¿Ya dijimos que los metadatos hacen que el mundo de k8s gire? ¿No había una canción de fines de la década de 1970 que decía así?
Visualización para obtener información
Traer los datos al Elastic Stack es excelente, pero debes poder interactuar con ellos. En el video siguiente veremos cómo abordar la creación de una visualización útil con métricas de Redis extraídas con Prometheus (y luego importadas al Elastic Stack) y eventos de Kubernetes recolectados de kube-state-metrics con Metricbeat directamente.
Si te gustaría ir siguiendo el video y tener instrucciones detalladas, consulta el repositorio de ejemplo.
Retomemos la observabilidad
En la última sección creamos una visualización de Kibana para una métrica de Redis clave (operaciones instantáneas por segundo) expuesta por el exportador Redis de Oliver006. Nuestro siguiente paso será recolectar logs y luego crear un dashboard que combine los logs y las métricas en todas nuestras aplicaciones.
Para conocer cómo recolectar logs en un entorno de Kubernetes, te recomendamos seguir las instrucciones en el repositorio elastic/examples de GitHub. En solo unos minutos puedes lograr que Filebeat, Metricbeat y Packetbeat recolecten datos y los publiquen en Elasticsearch. Hay dashboards de muestra que se envían con los distintos Beats, y siéntete libre de crear tus propias visualizaciones de datos de Prometheus y combinarlas para crear tus propios dashboards para la forma en que trabajas. Y si te encuentras con algún problema o deseas hablar sobre la observabilidad, consulta los foros de debate.