Cómo gestionar métricas de alta cardinalidad en Prometheus y Kubernetes
En los últimos meses, un tema común y recurrente en nuestras conversaciones con los usuarios ha sido la gestión de los costes de observabilidad, un proceso que está aumentando a un ritmo más rápido que la huella de las aplicaciones y la infraestructura que se monitorizan. A medida que las empresas se decantan por las arquitecturas nativas de la nube y la popularidad de Prometheus continúa creciendo, no es de extrañar que la cardinalidad de las métricas (una combinación cartesiana de métricas y etiquetas) también aumente. Sin embargo, la tasa de crecimiento ha sorprendido a algunas empresas y se ha convertido en la máxima prioridad cuando se trata de desarrollar y mantener sistemas y prácticas de observabilidad.
Si esto te suena familiar y actualmente estás estudiando la forma de controlar el crecimiento de las métricas, te recomendamos este webinar «Cómo controlar el crecimiento de las métricas en Prometheus y Kubernetes con Grafana Cloud» para descubrir consejos y trucos prácticos que puedes comenzar a implementar hoy mismo.
Pero ¿por qué las métricas están creciendo a un ritmo sin precedentes?
Los entornos nativos de la nube y las arquitecturas basadas en microservicios en combinación con la autonomía y la flexibilidad de los desarrolladores, crean el caldo de cultivo ideal para un aumento exponencial de los datos de series temporales. En las infraestructuras nativas de la nube, como Kubernetes, el crecimiento de los niveles de abstracción se traduce en más series temporales. Lo que una vez consistía en un solo servidor bare-metal ejecutando una aplicación, ahora ha sido reemplazado por muchos pods que ejecutan varios microservicios diferentes repartidos en muchos nodos distintos. Cada una de las capas de abstracción necesita una etiqueta para que puedan identificarse de manera única, y cada uno de esos componentes genera sus propias métricas y crea su conjunto único de series temporales.
Además, la naturaleza efímera de las cargas de trabajo en Kubernetes también termina creando más series temporales. Pongamos como ejemplo la métrica kube_pod_status_phase (una de las métricas de kube-state-metrics), que genera una nueva serie temporal cada vez que un pod cambia de estado, digamos de «pendiente» a «en ejecución» y a «fallido» o «exitoso». Dependiendo de la tasa de eventos de clúster, especialmente con muchos trabajos de ejecución corta, el seguimiento del estado de un único pod podría generar muchas métricas.
La facilidad de instrumentación y autonomía creada a través de una arquitectura de microservicios a veces también puede resultar en un aumento de la cardinalidad. Gracias a un amplio conjunto de herramientas de exportación de código abierto, así como librerías cliente para más de 15 lenguajes de programación, ahora es más fácil que nunca instrumentar aplicaciones para exponer las métricas de Prometheus. Puesto que cada equipo está capacitado para añadir métricas a su aplicación, la gestión se vuelve más difícil. A veces, las métricas relevantes en un entorno de desarrollo pueden filtrarse a un entorno de producción y causar un aumento en las series temporales. Al haber tantos equipos instrumentando sus aplicaciones, detectar y prevenir esas fugas se convierte en un desafío para un equipo de observabilidad centralizado.
¿Es únicamente la monitorización nativa en la nube lo que resulta en un aumento en la cardinalidad de las métricas?
Si bien la alta cardinalidad es definitivamente más común en entornos nativos de la nube, también suele ocurrir cuando una infraestructura heredada que no es de Prometheus (hardware o software) se migra a un formato compatible con Prometheus mediante herramientas de exportación. Estas herramientas pueden ser extremadamente ruidosas en la cantidad de métricas que generan, lo que contribuye a una alta cardinalidad. Por ejemplo, el Node exporter de Prometheus, que proporciona métricas a nivel de sistema operativo y de hardware, emite aproximadamente unas 500 series temporales de Prometheus de forma predeterminada. La herramienta de exportación mySQL publica aproximadamente 1000 series temporales y no siempre todas son útiles.
No obstante, uno de los errores más comunes que vemos, sin importar el entorno, es el uso de etiquetas no óptimas en las bases de datos de métricas. Dado que la cardinalidad es un producto cartesiano de dos conjuntos (métricas y etiquetas), la forma en que se definen las etiquetas contribuye en gran medida a mantener la cardinalidad bajo control. Si se usan etiquetas que se generan aleatoriamente y no tienen un límite máximo de valores únicos (por ejemplo, si se genera {session_id} con cada nueva conexión), el número de series temporales podría dispararse cuando aumente el tráfico del sistema. Lo mismo podría decirse de {user_id} o {device_id}.
De acuerdo, la alta cardinalidad es un síntoma del entorno, pero ¿por qué es importante?
Un aumento en la cardinalidad significa que ahora necesitas más infraestructura y capacidad de cómputo para almacenar y procesar esas series temporales. Esto, a su vez, tiene un impacto directo en el gastoen la plataforma de observabilidad. En los últimos tiempos, los operadores y equipos de observabilidad centralizados están tratando este asunto con máxima prioridad.
También afecta al rendimiento de la plataforma de observabilidad. A medida que la base de datos crece, también lo hace el número de series temporales a las que se accede en cualquier consulta determinada, lo que puede ralentizar radicalmente los sistemas durante la consulta o visualización de datos. Los cuadros de mando que tardan en cargarse o las consultas que tardan en devolver los datos prolongan el MTTR durante la resolución de incidencias o fallos de sistema.
Nota: La ventaja de usar una plataforma de observabilidad nativa de la nube, como Grafana Cloud, que funciona con la base de datos de series temporales más escalable, Grafana Mimir, es que no experimentarás estos problemas de rendimiento a medida que aumente el número de series temporales.
Entonces, ¿cómo puedo controlar el crecimiento de las métricas?
Dado que el crecimiento de las métricas es inevitable y tiene consecuencias en sus resultados, es necesario encontrar una forma de controlar y optimizar las métricas y los costes crecientes. Como ocurre con la monitorización y la observabilidad, la solución comienza con tener la visibilidad y los conocimientos correctos sobre los datos.
A continuación describimos tres pasos clave para controlar la cardinalidad y los costes de las métricas:
1. Obtener visibilidad de las métricas relevantes de alta cardinalidad
El primer paso hacia cualquier optimización es obtener visibilidad sobre qué métricas y etiquetas están contribuyendo a la cardinalidad e identificar qué métricas son valiosas. Las métricas que se utilizan en cuadros de mando, alertas y recording rules son obviamente necesarias; sin embargo, otras solo se pueden usar para consultas ad hoc durante un proceso de solución de problemas o no se consultan en absoluto.
El siguiente diagrama muestra métricas divididas en cuatro casillas basadas en la cardinalidad y su relevancia o valor. Lo ideal es comenzar identificando las métricas de la casilla 3, que son de alto coste, pero no se utilizan. Para las métricas que se correspondan con la casilla 4, la reevaluación de la granularidad y la arquitectura de las etiquetas puede producir buenos rendimientos para las métricas y las etiquetas que son valiosas, pero tienen una alta cardinalidad.
Identificar métricas y etiquetas de alta cardinalidad
Los planes Grafana Cloud Pro y Advanced incluyen un conjunto de paneles de administración de cardinalidad para ayudar a identificar métricas y etiquetas de alta cardinalidad y guiar los esfuerzos de optimización de las mismas.
Para obtener más información sobre cómo monitorizar fácilmente la cardinalidad con los cuadros de mando de Grafana, echa un vistazo a:
- Cómo gestionar la cardinalidad con cuadros de mando listos para usar en Grafana Cloud
- Analizar el uso de métricas con paneles de administración de cardinalidad
Si eres usuario de Grafana Cloud y quieres saber más sobre la optimización de métricas, ponte en contacto con nosotros.
Descubrir métricas no utilizadas
Mimirtool es una herramienta de código abierto que se puede usar para identificar métricas en bases de datos de Mimir o Prometheus, o en aquellas compatibles con Prometheus, que no se utilizan en cuadros de mando, alertas o recording rules. Mimirtool se ejecuta a través de la línea de comandos y genera un archivo JSON con métricas no utilizadas.
Las métricas que no se utilizan nunca se pueden eliminar de forma segura, si no son necesarias para consultas ad hoc o futuros proyectos.
Consulta más información sobre el uso de Mimirtool para identificar métricas no utilizadas en estos documentos:
- Cómo encontrar rápidamente métricas no utilizadas y sacarle más partido a Grafana Cloud
- Análisis y reducción del uso de métricas con Grafana Mimirtool
2. Averiguar qué equipos son responsables del crecimiento de las métricas
El siguiente paso será entender qué equipos y entornos contribuyen en mayor medida a la cardinalidad en la organización.
Grafana Cloud Advanced incluye la función «Usage Insights» para ayudar a identificar las fuentes de cardinalidad en su entorno. Realiza un seguimiento del número de series temporales que tienen una determinada etiqueta o conjunto de etiquetas aplicadas a lo largo del tiempo para comprender cómo los diferentes equipos, entornos o aplicaciones contribuyen a su número total de series. Al proporcionar estos datos como una serie temporal, puedes identificar fácilmente cómo un cambio en un momento específico provocó un aumento en el coste de la plataforma de observabilidad.
Para obtener más información sobre el empleo de grupos de uso para monitorizar la asignación de métricas, consulta este post:
3. Comenzar a optimizar las métricas
En esta sección, hablaremos de cómo comenzar a optimizar las métricas, una vez que dispongas de visibilidad sobre las métricas y etiquetas que resultan en una alta cardinalidad y hayas podido identificar las métricas de bajo y alto valor.
Inspeccionar la frecuencia de los datos
Al pronosticar los requisitos de capacidad para las métricas, es importante considerar los requisitos de frecuencia de datos. El scrape_interval predeterminado para Prometheus es de 15 segundos, o 4 puntos de datos por minuto (DPM). Pero si no se requiere esta frecuencia, la configuración predeterminada puede provocar que se almacenen más datos de los previstos.
Para inspeccionar el scrape_interval actual, realiza la siguiente consulta para encontrar el número de muestras extraídas en el último minuto, divididas por objetivos:
count_over_time(scrape_samples_scraped[1m])
A continuación, puedes inspeccionar esas métricas y aumentar el scrape_interval en busca de otras menos críticas para reducir los costes. A menudo, las métricas menos críticas se pueden establecer en un scrape_interval de 60 segundos, lo que puede reducir los costes hasta en un 75 %.
Para obtener más información sobre «scrape_intervals», echa un vistazo a este enlace:
Inspeccionar histogramas
Los histogramas permiten comprender la distribución de una cantidad particular. La precisión de esa distribución viene determinada por el número de apartados que tienes en ese histograma. En Prometheus, cada apartado se rastrea como una serie temporal que tiene un valor específico de la etiqueta le (menor o igual que).
Utilizando el panel de administración de cardinalidad de Grafana en Grafana Cloud, podemos ver los valores de la etiqueta le y descubrir cómo contribuye a la cardinalidad general. Elige los apartados que sean más relevantes para tu entorno. Por ejemplo, si el objetivo de nivel de servicio (SLO, por sus siglas en inglés) es un tiempo de respuesta de 50 ms, es posible que no necesites distinguir entre solicitudes que tardan 5 ms y 10 ms.
Puedes descartar de forma segura la serie de métricas para los apartados que no son necesarios. Esto no resultará en una pérdida de datos, ya que los apartados son acumulativos. Por ejemplo, si se descarta el apartado «menor o igual a 10», estos valores simplemente se incluirán en el apartado «menor o igual a 25». Si no necesitas este nivel de dimensionalidad, puedes descartar de forma segura el valor 10 para la etiqueta le.
A continuación mostramos un ejemplo de una configuración de reetiquetado:
# drop all metric series ending with _bucket and where le="10"
- source_labels: [__name__, le]
separator: _
regex: ".+_bucket_10"
action: "drop"
Para obtener más información sobre cómo reducir el uso de las métricas de Prometheus y cómo configurar un proceso de reetiquetado, consulta nuestra documentación:
Reducir etiquetas
Para las métricas con etiquetas que no se utilizan, el proceso no es tan simple como descartar las etiquetas que no se usan. Descartar una etiqueta podría dar lugar a series duplicadas, que serían eliminadas por Prometheus. Mira los ejemplos que hemos incluido más abajo. En el primer ejemplo, puedes descartar con seguridad la etiqueta «ip», ya que las series restantes son únicas. Sin embargo, en el segundo ejemplo, puedes ver cómo descartar la etiqueta «ip» crearía series temporales duplicadas, que Prometheus desecharía. En este ejemplo, Prometheus recibiría los valores de 1, 3 y 7 para my_metric_total con la misma marca de tiempo y eliminarías 2 de los puntos de datos.
# You can drop ip label, remaining series are still unique
my_metric_total{env=“dev”, ip=“1.1.1.1"} 12
my_metric_total{env=“tst”, ip=“1.1.1.1"} 14
my_metric_total{env=“prd”, ip=“1.1.1.1"} 18
#Remaining values after dropping ip label
my_metric_total{env=“dev”} 12
my_metric_total{env=“tst”} 14
my_metric_total{env=“prd”} 18
# You can not drop ip label, remaining series are not unique
my_metric_total{env=“dev”, ip=“1.1.1.1"} 1
my_metric_total{env=“dev”, ip=“3.3.3.3"} 3
my_metric_total{env=“dev”, ip=“5.5.5.5"} 7
#Remaining values after dropping ip label are not unique
my_metric_total{env=“dev”} 1
my_metric_total{env=“dev”} 3
my_metric_total{env=“dev”} 7Puedes descartar etiquetas de forma segura siempre que al hacerlo no genere series duplicadas.
En entornos donde tienes el control de la aplicación, puedes reconfigurar los agentes utilizados para la recopilación de métricas y descartar las etiquetas que no se utilicen.
Si no tienes control sobre la aplicación y descartar etiquetas da como resultado series duplicadas, aplicar una función (es decir, suma, media, mín., máx.) a través de las reglas de grabación de Prometheus puede permitir conservar los datos agregados y descartar las series individuales. En el siguiente ejemplo, utilizamos la función de suma para almacenar la métrica agregada, lo que nos permite eliminar las series temporales individuales.
# sum by env
my_metric_total{env="dev", ip="1.1.1.1"} 1
my_metric_total{env="dev", ip="3.3.3.3"} 3
my_metric_total{env="dev", ip="5.5.5.5"} 7
# Recording rule
sum by(env) (my_metric_total{})
my_metric_total{env="dev"} 11Puedes obtener más información sobre cómo reducir las recording rules de Prometheus y cómo configurar un proceso de reetiquetado en los siguientes recursos:
- Reglas de grabación de Prometheus
- Reducir el uso de las métricas de Prometheus con el reetiquetado
- Cómo funciona el reetiquetado en Prometheus
Más información sobre la gestión de métricas en Prometheus y Kubernetes con Grafana Cloud
Para comenzar a comprender la cardinalidad en su entorno, a atribuir costes a equipos y entornos, y a optimizar los costes de sus métricas, regístrate en Grafana Cloud. Incluye una prueba de 14 días de Grafana Cloud Pro, por lo que podrás probar los paneles de administración de cardinalidad, los grupos de uso y otras tecnologías en tu entorno.
Para obtener más información sobre cómo controlar los costes de las métricas en los entornos de Prometheus y Kubernetes, también puedes consultar nuestro webinar «Cómo controlar el crecimiento de las métricas en Prometheus y Kubernetes con Grafana Cloud».
Si eres usuario de Grafana Cloud y quieres saber más sobre la optimización de las métricas, contacta con nosotros.