🗄️ 🥂 👩 Observabilidad de SRE: espacios de nombres y estructura métrica 💇🏼 👨‍🎨 👰🏻

Spyglass de Shorai-san

Los espacios de nombres métricos estructurados son importantes para un acceso rápido a la información durante los incidentes. Planifique cuidadosamente los nombres y las dimensiones métricas para admitir una amplia gama de consultas y extensiones. Una forma efectiva de crear un modelo métrico flexible es pensar en ellos como un árbol.

Esto proporciona varias ventajas: ver ciertos subconjuntos de datos, definir una métrica en términos de sus elementos secundarios y establecer relaciones entre las métricas. Artículo traducido del

equipo de Mail.ru Cloud Solutions , que analiza las propiedades de los espacios de nombres de métricas, lo que le permite aumentar gradualmente el detalle de las consultas y pasar a subconjuntos de datos, así como ver la métrica desde el punto de vista de la métrica en la que consiste. Muchos de estos conceptos le son familiares, ya que se implementan en soluciones nativas de monitoreo en la nube, como Prometheus y DogStatsD.

Espacios de nombres métricos y su estructura

Los espacios de nombres de métricas son los espacios conceptuales en los que viven las métricas. A menudo se limitan a una base de datos o cuenta:

El espacio de nombres de la métrica también es la estructura de las métricas dentro del espacio de nombres. El nombre y la estructura propios abren una serie de grandes ventajas.

El espacio de nombres en el diagrama anterior no tiene una estructura explícita. Cada métrica es separada e independiente. Las métricas no tienen nada en común, excepto el hecho de que existen en el mismo espacio de nombres. En esta estructura no relacionada, cada métrica se utilizará individualmente. Para ver la frecuencia de las solicitudes http para un servicio, se debe acceder directamente a la métrica del servicio: service_N_http_requests_total.

Supongamos que queremos ver el número total de solicitudes a todos los servicios. ¿Qué sucede en el ejemplo anterior si creamos un nuevo servicio?

Si el número total de solicitudes se calcula sumando las solicitudes a service_1 y service_2, entonces agregar service_3 no cambia el número total de solicitudes. Para calcular el número total correcto de solicitudes, debe cambiar la regla de conteo agregando service_3_http_requests_total. Eche un vistazo a la gráfica del número de solicitudes a continuación:

Árbol de métricas

Una alternativa a un espacio de nombres sin estructura es aceptar una estructura explícita utilizando el nombre de la métrica como espacio de nombres. En el diagrama a continuación, ve esta estructura como un árbol:

En Prometheus y Datadog, se crea una estructura métrica utilizando etiquetas y etiquetas . Las etiquetas le permiten construir un árbol dinámicamente: cada vez que se agrega un nuevo servicio, se refiere a la métrica raíz.

En Prometheus, el número de solicitudes por segundo para todos los servicios se puede ver al crear una solicitud, como en la imagen a continuación:

Con un espacio de nombres estructurado, puede calcular dinámicamente la suma de consultas en todo el nodo. En este caso, Prometheus calcula el número de solicitudes por segundo para cada servicio como una métrica separada.

Definición de métricas de herencia

Cuando se utiliza el árbol de métricas, cada dimensión de métrica (etiquetada como "servicio") contiene una frecuencia individual de solicitudes para un servicio en particular. Usando el espacio de nombres de métricas, puede obtener no solo la frecuencia de solicitud total, sino también la frecuencia de solicitud para cada servicio:

Con el espacio de nombres, puede seleccionar y visualizar no solo los datos de la métrica general, sino también los datos de la parte de la métrica general, agrupados por algún atributo. Entonces, en la imagen de arriba la frecuencia de las solicitudes a servicios individuales es visible, su suma da la frecuencia de las solicitudes al nodo.

Reduciendo la muestra - subconjuntos de datos

Los espacios de nombres también admiten el estrechamiento de consultas para recuperar subconjuntos específicos de datos. Por ejemplo, hagamos la pregunta: "¿Cuál es el retraso p99 (el 99% de las solicitudes son más rápidas que el retraso especificado) en todas las solicitudes HTTP exitosas para servidores con implementación canaria?".

El árbol anterior modela el concepto de un espacio de nombres y, opcionalmente, modela cómo se almacenan las métricas en el disco. El uso de un espacio de nombres de métricas bien definido le permite extender las métricas a cualquier parámetro.

La siguiente imagen muestra un gráfico de p99 y p50 del árbol de métricas de arriba:

Si realiza una solicitud más específica, puede, por ejemplo, responder a la siguiente pregunta: "¿Cuál es el retraso p99 en todas las solicitudes HTTP exitosas para servidores con implementación canaria en el contexto de cada servidor?"

A continuación se muestra una visualización de una métrica con una selección por machine_id:

Dado que la métrica tiene una estructura bien definida, podemos seleccionar los datos necesarios de la métrica de nivel superior especificando los criterios de selección necesarios, en nuestro caso, machine_id.

Regla de probabilidades

Los coeficientes son otra forma de estructurar datos (correlaciones). Este es un mecanismo muy poderoso y la base para calcular la disponibilidad y la tasa de error de los SLO (estos indicadores fueron popularizados por expertos de Google SRE).

Los coeficientes permiten al usuario final asociar métricas explícitamente, estableciendo una estructura métrica. Estas relaciones se expresan con mayor frecuencia como un porcentaje, es decir, la accesibilidad se puede calcular como la proporción de "solicitudes exitosas / número total de solicitudes" y la tasa de error como "número de errores / número total de solicitudes". Otro ejemplo de coeficiente es la frecuencia con la que surge un estado de varios estados.

Vamos a ilustrar esto y supongamos que hay una aplicación que ejecutó la solicitud, y la solicitud podría conducir a uno de dos estados: datos tomados del caché (cache_hit: verdadero) o datos tomados de la fuente principal (cache_hit: falso). Para ver la proporción de aciertos de caché, los datos deben estructurarse de la siguiente manera:

El siguiente gráfico muestra la frecuencia de aciertos y errores de caché. Cada solicitud obtiene o no ingresa al caché. En total, ocurren alrededor de 160 solicitudes por segundo:

El siguiente gráfico muestra la proporción de aciertos de caché en relación con el número total de solicitudes. El coeficiente de acierto es 0.5 (50%):

Para que pueda relacionar dos métricas. En Datadog y Prometeo, esta relación se expresa mediante una simple operación aritmética.

Preguntas respondidas por datos

Es importante pensar detenidamente las preguntas que los datos deberían responder. En el primer ejemplo, el muestreo de datos no puede responder exactamente la pregunta: “¿Cuántas consultas por segundo procesan todas las instancias?”, Pero el árbol del espacio de nombres ayudaría a obtener la respuesta.

Otro caso común es el espacio de nombres de las métricas del cliente con el nombre del servicio y no con el nombre de la biblioteca del cliente. Agregar el nombre de la biblioteca del cliente al espacio de nombres responderá la pregunta: "¿El número total de solicitudes de todos los clientes?".

Las preguntas generales útiles responden a las cuatro señales doradas de Google . Cada pregunta se plantea de manera general, y luego se especifica:

¿Cuántas solicitudes hacen todos los clientes en total?
¿Cuántas solicitudes hace cada cliente?
¿Cuántas solicitudes realiza cada cliente a cada nodo?
¿Cuál es el porcentaje de solicitudes de servidor exitosas para cada RPC?

La misma estrategia se aplica a retrasos, tasas de error y saturación de recursos.

Métricas etiquetadas genéricas

Esto es lo que leí en las mejores prácticas para la optimización de consultas y el almacenamiento de datos para Datadog y Prometheus.

Para obtener una vista global que admita detalles para segmentos específicos, comience con un espacio de nombres superior común y agregue etiquetas y etiquetas (comience con las comunes, luego agregue las más específicas). Al hacerlo, considere la siguiente recomendación.

Cuidado con la cardinalidad

Tanto Datadog como Prometheus recomiendan limitar el número de etiquetas. Para citar el manual de Prometheus :

, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

Si agrega cuotas FS por usuario, alcanzará rápidamente decenas de millones de series temporales de 10,000 usuarios por 10,000 nodos. Esto es demasiado para la implementación actual de Prometheus. Incluso con números más bajos, ya no tendrá otros indicadores potencialmente más útiles en este monitoreo.

Comience sin etiquetas y agregue más etiquetas con el tiempo según sea necesario.

El monitoreo conveniente a nivel de usuario a menudo se logra mejor a través del rastreo distribuido . El rastreo distribuido tiene su propio espacio de métricas y mejores prácticas.

Conclusión

Es importante comprender qué preguntas pueden responderse estructurando las métricas. Una estructura incorrecta conduce a dificultades para obtener respuestas. Aunque estructurar el espacio métrico no es complicado, requiere una planificación previa para aprovechar al máximo los datos.

Cuando surgen problemas, la capacidad de expandir manualmente la métrica para ver todos los estados es crítica, y es importante que el espacio de nombres no interfiera con esto.

¡Buena suerte!

¿Qué más leer ?

Observabilidad de SRE: espacios de nombres y estructura métrica