Comprenda estos cuatro tipos de indicadores de Prometheus. ¿Alguien puede convertirse en un conductor de monitoreo veterano?

Las métricas se utilizan para medir tendencias en el rendimiento, el consumo, la eficiencia y muchos otros atributos del software a lo largo del tiempo. Permiten a los ingenieros monitorear la evolución de una variedad de mediciones (como el uso de CPU o memoria, duración de la solicitud, latencia, etc.) a través de alertas y paneles. Las métricas tienen una larga historia en el campo del monitoreo de TI y los ingenieros las utilizan ampliamente, junto con registros y seguimientos de enlaces, para detectar si los sistemas no se comportan como se esperaba.

En su forma más básica, un punto de datos de indicador se compone de tres componentes:

• un nombre de indicador

• La marca de tiempo en la que se recopiló este punto de datos.

• una medida representada por un número

Durante la última década, a medida que los sistemas se han vuelto más complejos, ha surgido el concepto de medidas dimensionales, es decir, una medida también incluye un conjunto de etiquetas o identidades (es decir, dimensiones) para proporcionar contexto adicional. Los sistemas de monitoreo que admiten métricas dimensionales permiten a los ingenieros agregar y analizar fácilmente una métrica en múltiples componentes y dimensiones consultando nombres de métricas específicas y filtrando y agrupando por etiquetas.

Prometheus define un formato de descripción de métricas y un protocolo de escritura remota. La comunidad y muchos proveedores han adoptado este protocolo para convertirse en el estándar de facto para describir y recopilar métricas. OpenMetrics es otro proyecto de CNCF que se basa en el formato de exportación de Prometheus para proporcionar un modelo estandarizado y neutral para el proveedor para recopilar métricas y está destinado a ser parte del Internet Engineering Task Force (IEFT).

Recientemente, surgió otro proyecto de CNCF, OpenTelemetry, cuyo objetivo es proporcionar un nuevo estándar que pueda unificar la recopilación de indicadores, seguimiento de enlaces y registros, facilitando la recopilación y correlación de señales de telemetría entre dominios.

Esperamos que después de leer estos artículos comprenda las diferencias entre cada estándar para que pueda decidir cuál se adapta mejor a sus necesidades actuales (y futuras).

1. Indicadores de Prometeo

Lo primero es lo primero. Hay cuatro tipos de métricas que Prometheus recopila como parte de su formato de exposición.

• Contadores

• medidores

• Histogramas

• Resúmenes

Prometheus utiliza un modelo de extracción para recopilar estas métricas; es decir, Prometheus rastrea activamente los puntos finales HTTP que exponen métricas. Estos puntos finales pueden quedar expuestos de forma natural mediante el componente que se está monitoreando o mediante uno de los cientos de exportadores de Prometheus creados por la comunidad. Prometheus proporciona bibliotecas cliente para diferentes lenguajes de programación que puedes usar para monitorear tu código.

El modelo de extracción funciona bien para monitorear clústeres de Kubernetes debido al mecanismo de descubrimiento de servicios y el acceso a la red compartida dentro del clúster, pero es más difícil monitorear clústeres dinámicos de máquinas virtuales, contenedores de AWS Fargate o funciones Lambda con Prometheus.

¿por qué? La razón principal es que las transacciones determinan los puntos finales métricos que se eliminarán y el acceso a estos puntos finales puede estar restringido por las políticas de seguridad de la red. Para abordar algunos de estos problemas, la comunidad lanzó Prometheus Agent Mode a finales de 2021, que solo recopila métricas y las envía al backend de monitoreo mediante el protocolo de escritura remota.

Prometheus puede capturar métricas en formato de exposición Prometheus y formato OpenMetrics. En ambos casos, los indicadores se exponen a través de una interfaz HTTP, utilizando un formato simple basado en texto (más comúnmente utilizado y ampliamente soportado) o el formato Protobuf, más eficiente y potente. Una de las grandes ventajas del formato de texto es su legibilidad, lo que significa que puede abrirlo en un navegador o utilizar una herramienta como curl para recuperar el conjunto de métricas actualmente expuestas.

Prometheus utiliza un modelo de indicador muy simple con cuatro tipos de indicadores, solo admitidos en el SDK del cliente. Todos los tipos de indicadores están representados en un formato expuesto mediante un único tipo de datos o mediante una combinación de varios tipos de datos únicos. Este tipo de datos consta de un nombre de indicador, un conjunto de etiquetas y un número de punto flotante. Las marcas de tiempo las agrega un backend de monitoreo (como Prometheus) o un agente al rastrear métricas.

Cada combinación única de nombre de métrica y conjunto de etiquetas define una serie temporal, mientras que cada marca de tiempo y flotante define una muestra (es decir, un punto de datos) en la serie.

Se utilizan varias convenciones para representar los diferentes tipos de mediciones.

Una característica muy útil del formato de exposición de Prometheus es la capacidad de asociar metadatos con una métrica para definir su tipo y proporcionar una descripción. Por ejemplo, Prometheus proporciona esta información y Grafana la utiliza para mostrar información contextual adicional a los usuarios, ayudándoles a elegir las métricas adecuadas y aplicar las funciones PromQL adecuadas.

# HELP用来为指标提供描述，# TYPE为指标提供类型。

Ahora, repasemos cada tipo de métrica de Prometheus con más detalle.

Encimera

Los indicadores de tipo contador se utilizan para mediciones crecientes monótonas. Por tanto siempre son valores acumulativos y el valor sólo puede subir. La única excepción es cuando se reinicia el contador, en cuyo caso su valor se pone a cero.

El valor real de un contador no suele ser muy útil por sí solo. El valor de un contador se utiliza a menudo para calcular el delta o tasa de cambio en el tiempo entre dos marcas de tiempo.

Por ejemplo, un caso de uso típico de Counter es registrar el número de llamadas API, una medida que siempre aumenta.

# HELP http_requests_total Total number of http api requests# TYPE http_requests_total counterhttp_requests_total{api="add_product"} 4633433

El nombre de la métrica es http_requests_total, tiene una etiqueta llamada api con un add_productvalor de 4633433 para Contador.

add_productEsto significa que se ha llamado a la API 4633433 veces desde la última vez que se inició el servicio o se restableció el contador . Por convención, los indicadores de tipo contador _totalsuelen tener sufijos.

Este número absoluto no nos brinda mucha información, pero cuando se usa con la función de tasa de PromQL (u otras funciones similares que monitorean el backend), puede ayudarnos a comprender cuántas solicitudes por segundo recibe la API. La siguiente consulta PromQL calcula el número promedio de solicitudes por segundo durante los últimos 5 minutos.

rate(http_requests_total{api="add_product"}[5m])

Para calcular el cambio absoluto durante un período, usaremos la función delta, llamada increate() en PromQL:

increase(http_requests_total{api="add_product"}[5m])

Esto devolverá el número total de solicitudes de los últimos 5 minutos, lo que equivale a multiplicar la velocidad por segundo por el número de segundos del intervalo (5 minutos en nuestro caso):

rate(http_requests_total{api="add_product"}[5m]) * 5 * 60

Otros ejemplos de dónde podría utilizar métricas de tipo contador: medir la cantidad de pedidos en un sitio web de comercio electrónico, la cantidad de bytes enviados y recibidos en una interfaz de red o la cantidad de errores en una aplicación. Si es un indicador que sigue subiendo, entonces use uno Counter.

A continuación se muestra un ejemplo de cómo crear e incrementar una métrica de contador en Python usando la biblioteca cliente de Prometheus:

from prometheus_client import Counterapi_requests_counter = Counter(                        'http_requests_total',                        'Total number of http api requests',                        ['api']                       )api_requests_counter.labels(api='add_product').inc()

Es importante tener en cuenta que, dado que el contador se puede restablecer a cero, debe asegurarse de que el backend que utiliza para almacenar y consultar las métricas pueda soportar esta situación y seguir proporcionando resultados precisos incluso si se reinicia el contador.

Prometheus y los sistemas de almacenamiento remoto Prometheus compatibles con PromQL, como Promscale, pueden manejar los reinicios del contador correctamente.

Indicador

El indicador de calibre se utiliza para mediciones que se pueden aumentar o disminuir a voluntad. Este es el tipo de indicador con el que quizás esté más familiarizado, ya que a menudo se utilizan incluso si los valores reales son significativos sin procesamiento adicional. Por ejemplo, las métricas que miden la temperatura, el uso de CPU y memoria, o el tamaño de una cola, son indicadores.

Por ejemplo, para medir el uso de memoria de un host, podemos usar una métrica de calibre, como por ejemplo:

# HELP node_memory_used_bytes Total memory used in the node in bytes# TYPE node_memory_used_bytes gaugenode_memory_used_bytes{hostname="host1.domain.com"} 943348382

Las métricas anteriores indican que el nodo host1.domain.com está utilizando aproximadamente 900 MB de memoria en el momento de la medición. El valor de esta métrica es significativo y no requiere ningún cálculo adicional, ya que nos dice cuánta memoria se consume en este nodo.

A diferencia del uso  Counter de indicadores, las funciones de tasa y delta no tienen significado con Gauge. Sin embargo, con Gauge se suelen utilizar funciones que calculan el promedio, máximo, mínimo o porcentaje de una serie temporal específica.

En Prometheus, los nombres de estas funciones son avg_over_time, y . Para calcular la memoria promedio utilizada en host1.domain.com durante los últimos 10 minutos, puede hacer esto:max_over_timemin_over_timequantile_over_time

avg_over_time(node_memory_used_bytes{hostname="host1.domain.com"}[10m])

Para crear un indicador Gauge en Python usando la biblioteca cliente de Prometheus, puede hacer esto:

from prometheus_client import Gaugememory_used = Gauge(                'node_memory_used_bytes',                'Total memory used in the node in bytes',                ['hostname']              )memory_used.labels(hostname='host1.domain.com').set(943348382)

histograma

Las métricas de histograma son útiles para representar la distribución de mediciones. A menudo se utilizan para medir la duración de la solicitud o el tamaño de la respuesta.

Un histograma divide todo el rango de medición en un conjunto de intervalos, llamados depósitos, y cuenta cuántas mediciones hay en cada depósito.

Un indicador de histograma consta de varios elementos:

1. Un Contador que contiene el número de mediciones. Los nombres de los indicadores utilizan el sufijo _count.

2. Un contador que contiene la suma de todos los valores medidos. Los nombres de los indicadores utilizan el sufijo _sum.

3. El depósito de histograma se expone como una serie de contadores, utilizando el sufijo _bucket en el nombre del indicador y la etiqueta del archivo que indica el límite superior del depósito. El depósito en Prometheus contiene el límite del depósito, es decir, un depósito con un límite superior de N (le etiqueta) incluye todos los puntos de datos con un valor menor o igual a N.

Por ejemplo, una métrica de histograma que mide el tiempo de respuesta de la instancia de punto final add_productAPI que se ejecuta en la instancia host1.domain.com se puede representar como:

# HELP http_request_duration_seconds Api requests response time in seconds# TYPE http_request_duration_seconds histogramhttp_request_duration_seconds_sum{api="add_product" instance="host1.domain.com"} 8953.332http_request_duration_seconds_count{api="add_product" instance="host1.domain.com"} 27892http_request_duration_seconds_bucket{api="add_product" instance="host1.domain.com" le="0"}http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.01"} 0http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.025"} 8http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.05"} 1672http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.1"} 8954http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.25"} 14251http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.5"} 24101http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="1"} 26351http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="2.5"} 27534http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="5"} 27814http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="10"} 27881http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="25"} 27890http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="+Inf"} 27892

El ejemplo anterior incluye suma, contador y 12 depósitos. La suma y el contador se pueden utilizar para calcular el promedio de un valor medido a lo largo del tiempo. En PromQL, el tiempo promedio de respuesta a solicitudes en los últimos 5 minutos se puede calcular de la siguiente manera.

rate(http_request_duration_seconds_sum{api=”add_product”, instance=”host1.domain.com”}[5m]) / rate(http_request_duration_seconds_count{api=”add_product”, instance=”host1.domain.com”}[5m])

También se puede utilizar para calcular el promedio de cada serie temporal. La siguiente consulta PromQL calculará el tiempo promedio de respuesta de solicitud para todas las API e instancias durante los últimos 5 minutos.

sum(rate(http_request_duration_seconds_sum[5m])) / sum(rate(http_request_duration_seconds_count[5m]))

Con Histograma, puede calcular percentiles para una única serie temporal, así como para varias series temporales en el momento de la consulta. En PromQL, usaremos la función histogram_quantile. Prometheus usa cuantiles en lugar de percentiles.

Son esencialmente iguales, pero se expresan en una escala de 0 a 1, mientras que los percentiles se expresan en una escala de 0 a 100. Para calcular el percentil 99 (cuartil 0,99) del tiempo de respuesta de la API add_product que se ejecuta en host1.domain.com, puede utilizar la siguiente consulta.

histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{api=”add_product”, instance=”host1.domain.com”}[5m]))

Una de las grandes ventajas de los histogramas es que se pueden resumir. La siguiente consulta devuelve el percentil 99 del tiempo de respuesta para todas las API e instancias:

histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

En un entorno nativo de la nube, donde a menudo hay varias instancias de los mismos componentes ejecutándose, la capacidad de agregar datos entre instancias es clave.

Los histogramas tienen tres desventajas principales:

• En primer lugar, los depósitos deben estar predefinidos, lo que requiere un diseño inicial. Si sus depósitos no están bien definidos, es posible que no pueda calcular los porcentajes que necesita o que consuma recursos innecesarios. Por ejemplo, si tiene una API que siempre tarda más de un segundo, entonces tener depósitos con etiquetas de menos de un segundo sería inútil y solo consumiría los recursos informáticos y de almacenamiento del servidor backend de monitoreo. Por otro lado, si el 99,9 % de las solicitudes de API tardan menos de 50 milisegundos, tener un depósito inicial limitado a 100 milisegundos no le permitirá medir con precisión el rendimiento de su API.

• En segundo lugar, proporcionan percentiles aproximados en lugar de percentiles exactos. Esto suele estar bien, siempre y cuando su depósito esté diseñado para proporcionar resultados con una precisión razonable.

• En tercer lugar, dado que los percentiles deben calcularse en el lado del servidor, su costo computacional puede ser muy alto cuando hay una gran cantidad de datos para procesar. Una forma de mitigar esto en Prometheus es utilizar reglas de registro para calcular previamente los percentiles requeridos.

El siguiente ejemplo muestra cómo crear un indicador de histograma con depósitos personalizados utilizando la biblioteca cliente Python de Prometheus.

from prometheus_client import Histogramapi_request_duration = Histogram(                        name='http_request_duration_seconds',                        documentation='Api requests response time in seconds',                        labelnames=['api', 'instance'],                        buckets=(0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10, 25 )                       )api_request_duration.labels(    api='add_product',    instance='host1.domain.com').observe(0.3672)

Resumen

Al igual que los histogramas, las métricas de resumen son útiles para medir la duración de la solicitud y el tamaño del cuerpo de la respuesta.

Al igual que los histogramas, las métricas de resumen son útiles para medir la duración de la solicitud y el tamaño de la respuesta.

Un indicador de resumen incluye estos indicadores:

• Un Contador que contiene el número total de mediciones. Los nombres de los indicadores utilizan _countsufijos.

• Un contador que contiene la suma de todos los valores medidos. Los nombres de los indicadores utilizan el sufijo _sum. Opcionalmente, puede exponer métricas cuantiles para algunas mediciones utilizando nombres de métricas con etiquetas cuantiles. Dado que no desea que estas cantidades se midan durante todo el tiempo que se ejecuta la aplicación, la biblioteca cliente de Prometheus generalmente utilizará valores de cuantiles de transmisión que se miden de forma deslizante (generalmente configurable) calculados a lo largo de la ventana de tiempo.

Por ejemplo, una métrica de resumen que mide el tiempo de respuesta de una instancia de punto final add_productAPI que se ejecuta en host1.domain.com podría representarse como:

# HELP http_request_duration_seconds Api requests response time in seconds# TYPE http_request_duration_seconds summaryhttp_request_duration_seconds_sum{api="add_product" instance="host1.domain.com"} 8953.332http_request_duration_seconds_count{api="add_product" instance="host1.domain.com"} 27892http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0"}http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.5"} 0.232227334http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.90"} 0.821139321http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.95"} 1.528948804http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.99"} 2.829188272http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="1"} 34.283829292

El ejemplo anterior incluye sumas y recuentos y cinco cuantiles. El cuantil 0 corresponde al valor mínimo y el cuantil 1 corresponde al valor máximo. El cuantil 0,5 es la mediana y los cuantiles 0,90, 0,95 y 0,99 son equivalentes a los tiempos de respuesta de los percentiles 90, 95 y 99 para el punto final de la API add_product que se ejecuta en host1.domain.com.

Al igual que los histogramas, los indicadores de resumen incluyen sumas y recuentos y se pueden utilizar para calcular promedios a lo largo del tiempo, así como promedios en diferentes series temporales.

El resumen proporciona cálculos de percentiles más precisos que el histograma, pero estos percentiles tienen tres desventajas principales:

• En primer lugar, calcular los percentiles del lado del cliente es caro. Esto se debe a que la biblioteca cliente debe mantener una lista ordenada de puntos de datos para poder realizar este cálculo. La implementación en el SDK de Prometheus limita la cantidad de puntos de datos retenidos y ordenados en la memoria, lo que reduce la precisión a cambio de una mayor eficiencia. Tenga en cuenta que no todas las bibliotecas cliente de Prometheus admiten valores de magnitud en métricas agregadas. Por ejemplo, el SDK de Python no lo admite.

• En segundo lugar, la cantidad que desea consultar debe estar predefinida por el cliente. La consulta solo puede devolver aquellas cantidades para las que se han proporcionado indicadores. No hay forma de calcular otros percentiles en el momento de la consulta. Agregar un nuevo indicador percentil requiere modificar el código antes de que se pueda utilizar el indicador.

• En tercer lugar, y lo más importante, es imposible agregar y calcular múltiples indicadores de resumen. Esto los hace inútiles para la mayoría de los casos de uso en sistemas dinámicos modernos, donde normalmente estamos interesados ​​en un componente específico y la perspectiva es global, no está vinculada a una instancia específica.

Imaginemos, en nuestro caso, que el punto final de la API add_product se ejecuta en 10 hosts, con un equilibrador de carga delante de esos servicios. No tenemos ninguna función agregada que pueda usarse para calcular el percentil 99 de los tiempos de respuesta para la interfaz API add_product en todas las solicitudes, independientemente de la instancia de backend a la que se enviaron esas solicitudes. Solo vemos el percentil 99 para cada anfitrión.

De manera similar, solo podemos conocer el percentil 99 (en una determinada instancia) de una determinada interfaz, como el punto final add_productAPI, pero no podemos agregar diferentes interfaces.

El siguiente código crea un indicador de resumen utilizando la biblioteca cliente Python de Prometheus.

from prometheus_client import Summaryapi_request_duration = Summary(                        'http_request_duration_seconds',                        'Api requests response time in seconds',                        ['api', 'instance']                       )api_request_duration.labels(api='add_product', instance='host1.domain.com').observe(0.3672)

El código anterior no define ninguna métrica cuantitativa y solo producirá métricas de suma y conteo. El SDK de Python para Prometheus no admite cálculos cuantiles en indicadores de resumen.

¿Histograma o resumen?

En la mayoría de los casos, se prefiere un histograma porque es más flexible y permite resumir percentiles.

La agregación es útil cuando no se requieren percentiles sino sólo promedios, o cuando se requieren percentiles muy precisos. Por ejemplo, en el caso del cumplimiento de responsabilidades contractuales para sistemas críticos.

La siguiente tabla resume las ventajas y desventajas de los histogramas y las tablas de resumen.