Ya sea que sea DevOps, SRE o simplemente una persona basada en datos, probablemente sea adicto a los tableros y las métricas. Observamos nuestras métricas para ver cómo está funcionando nuestro sistema, ya sea en la infraestructura, la aplicación o el nivel comercial. Confiamos en nuestras métricas para mostrarnos el estado de nuestro sistema y dónde se comporta mal. Pero, ¿nuestras métricas nos muestran lo que realmente sucedió? Te sorprendería la frecuencia con la que no es el caso.

En esta publicación, analizaré las matemáticas y la mecánica detrás de las métricas, algunos conceptos erróneos comunes, lo que se necesita para tener métricas precisas y si existe tal cosa.

Aspectos básicos de las métricas

Las métricas son esencialmente resúmenes de eventos sin procesar. Durante este proceso de resumen, los eventos se traducen en puntos de datos numéricos. Un ejemplo simple son los errores que ocurren en el sistema, con una métrica simple para contar los errores. Las métricas también pueden involucrar múltiples variables, como un recuento de solicitudes con un tiempo de respuesta superior a 1 segundo. Cuando se miden a lo largo del tiempo, estos puntos de datos forman una serie temporal .

Las métricas pueden ser de varios tipos, como contadores, indicadores e histogramas. Los contadores se utilizan para el conteo acumulativo de eventos, como vimos en los ejemplos anteriores. Los indicadores suelen representar el último valor de medición. Y luego hay tipos más elaborados, como los histogramas , que pueden muestrear la distribución de valores métricos, contando eventos en "cubos" o "contenedores" configurables. Por ejemplo, es posible que desee comprender el porcentaje de uso de memoria segmentado por pods en su clúster en determinados momentos.

La mecánica de las métricas

En un mundo ideal, ingeriríamos y almacenaríamos todos los eventos sin procesar y luego calcularíamos las métricas en el tiempo de consulta. Esto nos permitiría dividir los eventos de la forma que necesitemos y hacer cualquier pregunta ad-hoc que deseemos.

Sin embargo, en el mundo real, mantener todos los eventos sin procesar durante largos períodos de tiempo puede resultar prohibitivamente costoso debido a los grandes volúmenes de datos. Para superar esto, los eventos se acumulan con frecuencia en métricas en la canalización de recopilación, mientras se descartan los eventos sin procesar o se retienen solo por períodos cortos. A menudo, esto es una cuestión de configuración simple en su agente de recopilación de métricas.

Además de reducir los costos, la agregación en el momento de la recopilación puede mejorar el rendimiento de los análisis en tiempo real con tasas más altas de transmisión e ingesta de métricas a una frecuencia más alta, y al evitar agregaciones y cálculos pesados en el momento de la consulta.

Las matemáticas de las métricas en pocas palabras

Este proceso de enrollado implica algunas matemáticas. Es posible que deseemos calcular la media o la mediana de los tiempos de respuesta, o quizás un percentil o una agregación durante una ventana de tiempo. También es posible que deseemos acumular varios eventos en una métrica compuesta. Por ejemplo, es posible que desee calcular el percentil 95 (comúnmente conocido como P95) de todos los pods de un servicio específico en mi clúster.

Incluso si no te gustan las matemáticas, no puedes evitarlas con las métricas. Debe comprender las diferentes funciones de agregación y la relación entre la pregunta que desea hacer y la métrica y el agregado que necesita para responderla. Veamos la función Promedio como ejemplo, ya que muchas tienden a comenzar allí. Los promedios, por definición, suavizan las cosas y serán menos adecuados para descartar comportamientos anómalos y valores atípicos. Al investigar problemas de latencia, por ejemplo, será bastante inútil mirar los valores promedio de las métricas y será mejor mirar los percentiles.

Determine sus preguntas, diseñe sus métricas en consecuencia

En cierto modo, puede pensar en estas métricas como una compresión con pérdida, durante la cual perdemos datos y contexto de los eventos sin procesar. Si no mantenemos los eventos en bruto, debemos determinar por adelantado qué es importante para nosotros. Por ejemplo, si solo calculo el valor promedio sobre los datos, no podré preguntar sobre el P95 (percentil 95) más adelante sobre los datos preagregados.

Debe determinar qué preguntas desea responder, qué es importante para usted y diseñar sus métricas y agregaciones en consecuencia. Un error común es que las personas evitan esta fase de diseño y simplemente usan las métricas preestablecidas y los valores predeterminados provistos de fábrica con el recopilador de métricas de su elección. Si bien puede pensar que estos valores predeterminados representan algún estándar de la industria, a menudo son bastante heredados y, en la mayoría de los casos, no estarán en sintonía con sus necesidades específicas.

El problema de la medida

Al igual que en la física, el problema de la medición ocurre cuando medimos una propiedad (aparentemente) continua en intervalos discretos, a menudo llamado intervalo de muestreo , que determina la tasa de muestreo. Esto crea una representación distorsionada, en la que es posible que la métrica no refleje realmente la propiedad medida originalmente. Por ejemplo, si medimos la utilización de la CPU cada 60 segundos, cualquier valor atípico de la CPU que ocurra entre estos puntos de muestreo será invisible para nosotros.

Además, para dibujar una línea consecutiva, las herramientas de visualización a menudo promedian puntos de datos consecutivos, lo que da la apariencia engañosa de una línea suave. En algunas ocasiones puede ocurrir lo contrario, donde puede obtener artefactos en sus métricas que no son reales, como picos en sus métricas que realmente no existen. Esto puede suceder cuando se ejecutan agregaciones dentro del backend de almacenamiento, debido a que se realiza el cálculo.

Tiempo medio de detección

El período de muestreo también influye en la rapidez con que un cambio en el sistema será visible en las métricas. La mayoría de los algoritmos requieren cinco puntos de datos para detectar una tendencia. Si el intervalo de muestreo es de 60 segundos, las matemáticas simples determinan que tomará cinco minutos (es decir, 60 segundos X 5 puntos de datos) antes de que veamos que algo anda mal. ¿Podría permitirse el lujo de esperar 5 minutos para saber que su sistema se bloqueó? El uso de intervalos de muestreo más cortos (es decir, tasas de muestreo más altas) acortará este período y nos permitirá detectar y reaccionar más rápido. Por supuesto, las tasas de muestreo más altas generan una sobrecarga en la CPU y el almacenamiento, por lo que debemos encontrar la configuración que logre el equilibrio adecuado para nuestras necesidades.

Resolución variable y reducción de escala

Una práctica común es guardar métricas en diferentes resoluciones en un enfoque por niveles, para reducir costos. Por ejemplo, es posible que desee guardar la métrica cada 10 segundos durante el primer día, pero luego cada 5 minutos durante la próxima semana y quizás cada 1 hora durante el mes siguiente o más. Esta práctica supone que necesitamos la granularidad más fina para el período casi en tiempo real, que podemos necesitar si hay un problema en el sistema, mientras que las investigaciones durante períodos más largos requieren tendencias a mayor escala.

Las diferentes granularidades se pueden lograr reduciendo las métricas, es decir, calculando la métrica menos granular a partir de la de mayor granularidad. Si bien esto suena perfectamente razonable, las matemáticas pueden interferir aquí, ya que algunas funciones de agregación no son compatibles con ciertos cálculos y, por lo tanto, no se pueden agregar más adelante. Por ejemplo, los percentiles no son aditivos y no se pueden sumar. Entonces, siguiendo el ejemplo anterior, si tiene un percentil P99 muestreado con una resolución de 10 segundos, no puede subirlo a una resolución de 5 minutos. Es importante ser consciente de la compatibilidad de las funciones de agregación y, al usar funciones no compatibles, como los percentiles, tomar decisiones de diseño sobre qué resoluciones necesitamos y calcular estas series de tiempo por adelantado.

La resolución variable no se limita únicamente al factor tiempo. Otro ejemplo es guardar datos por pod y luego desear "agrupar por" nodos o clústeres. La misma restricción se aplica aquí, lo que significa que si esperamos estar interesados en dividir y dividir en cubitos una métrica basada en percentiles por nodo, por región, por espacio de nombres o en todo el clúster, debemos agregar previamente en consecuencia.

Otro enfoque es renunciar a la precisión de las mediciones para ganar compatibilidad en el cálculo, mediante el uso de histogramas. Puede tomar histogramas de algunos servidores y resumirlos, o histogramas de varias ventanas de tiempo y resumirlos, y luego reducir la escala. El problema es que, en este caso, los percentiles serán estimaciones en lugar de ser precisos. También es importante tener en cuenta que los histogramas consumen más tiempo en el almacenamiento y el rendimiento, ya que cada muestra no es solo un número, sino algunas muestras (una por cubeta).

Resumen

Las métricas son una forma poderosa de monitorear nuestras aplicaciones. Pero no son necesariamente representativos del estado real del sistema. Requiere una comprensión de las matemáticas y la naturaleza de las métricas, así como un diseño cuidadoso, para garantizar que nuestras métricas sean realmente útiles para responder las preguntas que necesitamos. Tener acceso a los datos sin procesar además de las métricas siempre es bueno, ya que en última instancia es la fuente de la verdad.

¿Querer aprender más? Consulte el episodio de OpenObservability Talks: Todas las métricas son incorrectas, algunas son útiles en Spotify , Apple Podcasts u otras aplicaciones de podcasts .

Este artículo estaba originalmente aquí .