4. Monitoreo

Por Jess Frame, Anthony Lenton, Steven Thurgood,
Anton Tolchanov y Nejc Trdin con Carmela Quinito

La monitorización puede incluir muchos tipos de datos, incluyendo métricas, registro de texto, registro de eventos estructurados, rastreo distribuido e introspección de eventos. Aunque todos estos enfoques son útiles por sí mismos, este capítulo trata principalmente de las métricas y el registro estructurado. En nuestra experiencia, estas dos fuentes de datos son las que mejor se adaptan a las necesidades fundamentales de monitorización de SRE. En el nivel más básico, la monitorización le permite ganar visibilidad en un sistema, que es un requisito básico para juzgar la salud del servicio y diagnosticar su servicio cuando las cosas van mal. El capítulo 6 del primer libro de SRE proporciona algunas definiciones básicas de monitorización y explica que los SREs monitorizan sus sistemas para:

• Alertar sobre las condiciones que requieren atención.

• Investigar y diagnosticar esos problemas

• Visualizar información sobre el sistema

• Obtener información sobre las tendencias en el uso de los recursos o el estado del servicio para la planificación a largo plazo.

• Comparar el comportamiento del sistema antes y después de un cambio, o entre dos grupos en un experimento.

La importancia relativa de estos casos de uso puede llevarle a hacer concesiones a la hora de seleccionar o construir un sistema de monitorización.

En este capítulo se explica el modo en que Google gestiona los sistemas de supervisión y se ofrecen algunas directrices sobre las preguntas que pueden surgir al elegir y ejecutar un sistema de supervisión.

A la hora de elegir un sistema de supervisión, es importante comprender y priorizar las características que más le interesan. Si está evaluando distintos sistemas de supervisión, los atributos de esta sección pueden ayudarle a decidir qué solución o soluciones se adaptan mejor a sus necesidades. Si ya dispone de una estrategia de supervisión, puede plantearse utilizar algunas funciones adicionales de su solución actual. Dependiendo de sus necesidades, un sistema de supervisión puede satisfacer todos sus casos de uso, o puede que desee utilizar una combinación de sistemas.

Cada organización tiene necesidades diferentes en cuanto a la frescura de los datos y la velocidad de recuperación.

Los datos deben estar disponibles cuando los necesite: la frescura influye en el tiempo que tardará su sistema de monitorización en avisarle cuando algo va mal. Además, la lentitud de los datos puede llevarle a actuar accidentalmente sobre datos incorrectos. Por ejemplo, durante la respuesta a un incidente, si el tiempo transcurrido entre la causa (tomar una acción) y el efecto (ver esa acción reflejada en su monitorización) es demasiado largo, podría asumir que un cambio no tuvo efecto o deducir una falsa correlación entre causa y efecto. Los datos obsoletos durante más de cuatro o cinco minutos pueden afectar significativamente a la rapidez con la que se puede responder a un incidente.

Si va a seleccionar un sistema de supervisión basándose en estos criterios, deberá determinar de antemano sus requisitos de velocidad. La velocidad de recuperación de datos es un problema sobre todo cuando se consultan grandes cantidades de datos. Un gráfico puede tardar en cargarse si tiene que recopilar muchos datos de muchos sistemas monitorizados. Para acelerar los gráficos más lentos, es útil que el sistema de monitorización pueda crear y almacenar nuevas series temporales basadas en los datos entrantes; así podrá precalcular las respuestas a las consultas más habituales.

El soporte para cálculos puede abarcar una gran variedad de casos de uso, a través de una gama de complejidades. Como mínimo, es probable que desee que su sistema conserve datos durante un periodo de varios meses. Sin una visión a largo plazo de sus datos, no podrá analizar tendencias a largo plazo como el crecimiento del sistema. En términos de granularidad, los datos resumidos (es decir, los datos agregados en los que no se puede profundizar) son suficientes para facilitar la planificación del crecimiento. Conservar todas las métricas individuales detalladas puede ayudar a responder preguntas como: “¿Ha ocurrido antes este comportamiento inusual?”. Sin embargo, los datos podrían ser caros de almacenar o poco prácticos de recuperar.

Lo ideal es que las métricas que retengas sobre eventos o consumo de recursos sean contadores que se incrementen monotónicamente. Utilizando contadores, su sistema de monitorización puede calcular funciones de ventana a lo largo del tiempo, por ejemplo, para informar de la tasa de peticiones por segundo de ese contador. El cálculo de estas tasas sobre una ventana más larga (hasta un mes) le permite implementar los bloques de construcción para el SLO basado en alertas (ver Capítulo 5).

Por último, el soporte de una gama más completa de funciones estadísticas puede ser útil porque las operaciones triviales pueden enmascarar un mal comportamiento. Un sistema de monitorización que soporte el cálculo de porcentajes (es decir, porcentajes 50, 95, 99) al registrar la latencia le permitirá ver si el 50%, el 5% o el 1% de sus peticiones son demasiado lentas, mientras que la media aritmética sólo puede decirle -sin datos específicos- que el tiempo de petición es más lento. Alternativamente, si su sistema no admite el cálculo directo de percentiles, puede lograrlo de la siguiente manera:

• Obtener un valor medio sumando los segundos empleados en las peticiones y dividiéndolos por el número de peticiones.

• Registrando cada solicitud y calculando los valores de los percentiles escaneando o muestreando las entradas del registro.

Es posible que desee registrar sus datos métricos sin procesar en un sistema independiente para su análisis fuera de línea, por ejemplo, para utilizarlos en informes semanales o mensuales, o para realizar cálculos más complejos que son demasiado difíciles de calcular en su sistema de supervisión.

Un sistema de supervisión sólido debe permitirle mostrar de forma concisa los datos de series temporales en gráficos, y también estructurar los datos en tablas o en una gama de estilos de gráficos. Sus tableros serán las principales interfaces de visualización de la supervisión, por lo que es importante que elija los formatos que muestren con mayor claridad los datos que le interesan. Algunas opciones son los mapas térmicos, los histogramas y los gráficos de escala logarítmica.

Es probable que tenga que ofrecer diferentes vistas de los mismos datos en función de la audiencia; es posible que la dirección de alto nivel desee ver una información muy diferente a la de los SRE. Sea específico a la hora de crear tableros que tengan sentido para las personas que consumen el contenido. Para cada conjunto de tableros, mostrar los mismos tipos de datos de forma coherente es valioso para la comunicación.

Es posible que necesite representar gráficamente la información a través de diferentes agregaciones de una métrica, como el tipo de máquina, la versión del servidor o el tipo de solicitud, en tiempo real. Es una buena idea que su equipo se sienta cómodo realizando desgloses ad hoc de sus datos. Al dividir los datos en función de diversas métricas, podrá buscar correlaciones y patrones en los datos cuando lo necesite.

Es útil poder clasificar las alertas: varias categorías de alertas permiten dar respuestas proporcionales. La posibilidad de establecer diferentes niveles de gravedad para las distintas alertas también es útil: puede presentar un ticket para investigar una baja tasa de errores que dure más de una hora, mientras que una tasa de errores del 100% es una emergencia que merece una respuesta inmediata.

La función de supresión de alertas le permite evitar ruidos innecesarios que distraigan a los ingenieros de guardia. Por ejemplo:

• Cuando todos los nodos están experimentando la misma alta tasa de errores, puede alertar una sola vez para la tasa de error global en lugar de enviar una alerta individual para cada nodo.

• Cuando una de sus dependencias de servicio tiene una alerta de disparo (por ejemplo, un backend lento), no necesita alertar de las tasas de error de su servicio.

También necesitas ser capaz de asegurar que las alertas no se suprimen una vez que el evento ha terminado.

El nivel de control que necesites sobre tu sistema dictará si utilizas un servicio de monitorización de terceros o despliegas y ejecutas tu propio sistema de monitorización. Google ha desarrollado su propio sistema de supervisión, pero existen muchos sistemas de código abierto y comerciales.

La elección del sistema o sistemas de monitorización dependerá de las fuentes específicas de datos de monitorización que vaya a utilizar. Esta sección discute dos fuentes comunes de datos de monitorización: logs y métricas. Hay otras fuentes de monitorización valiosas que no cubriremos aquí, como el rastreo distribuido y la introspección en tiempo de ejecución.

Las métricas son medidas numéricas que representan atributos y eventos, típicamente recolectados a través de muchos puntos de datos en intervalos de tiempo regulares. Los registros (logs) son un registro de eventos. En este capítulo nos centraremos en los registros estructurados, que ofrecen herramientas de consulta y agregación más completas que los registros en texto plano.

Los sistemas basados en registros de Google procesan grandes volúmenes de datos muy granulares. Existe un cierto retraso inherente entre el momento en que se produce un evento y el momento en que es visible en los registros. Para los análisis que no dependen del tiempo, estos registros pueden procesarse con un sistema por lotes, interrogarse con consultas ad hoc y visualizarse con tableros. Un ejemplo de este flujo de trabajo sería utilizar Cloud Dataflow para procesar los registros, BigQuery para las consultas ad hoc y Data Studio para los tableros.

En cambio, nuestro sistema de supervisión basado en métricas, que recopila un gran número de métricas de todos los servicios de Google, proporciona información mucho menos detallada, pero casi en tiempo real. Estas características son bastante típicas de otros sistemas de monitorización basados en registros y métricas, aunque hay excepciones, como los sistemas de registros en tiempo real o las métricas de alta cardinalidad.

Nuestras alertas y tableros suelen utilizar métricas. La naturaleza en tiempo real de nuestro sistema de supervisión basado en métricas significa que los ingenieros pueden ser notificados de los problemas muy rápidamente. Tendemos a utilizar registros para encontrar la causa raíz de un problema, ya que la información que necesitamos a menudo no está disponible como métrica.

Cuando la notificación no es urgente, solemos generar informes detallados mediante sistemas de procesamiento de registros, ya que éstos casi siempre producen datos más precisos que las métricas.

Si emite alertas basadas en métricas, puede resultar tentador añadir más alertas basadas en registros, por ejemplo, si necesita que se le notifique incluso cuando se produce un único evento excepcional. En estos casos, seguimos recomendando las alertas basadas en métricas: puede incrementar una métrica de contador cuando se produzca un evento concreto y configurar una alerta basada en el valor de esa métrica. Esta estrategia mantiene toda la configuración de alertas en un único lugar, lo que facilita su gestión (consulte “Gestión de su sistema de monitorización”).

Los siguientes ejemplos reales ilustran cómo razonar el proceso de elección entre sistemas de supervisión.

El Problema

El código de estado HTTP es una señal importante para los clientes de App Engine que depuran sus errores. Esta información estaba disponible en los registros, pero no en las métricas. El tablero de métricas sólo podía proporcionar un índice global de todos los errores, y no incluía ninguna información sobre el código de error exacto o la causa del error. Como resultado, el flujo de trabajo para depurar un problema implicaba:

• 1. Mirar el gráfico global de errores para encontrar el momento en que se producía un error.

• 2. Leer los archivos de registro para buscar líneas que contengan un error.

• 3. Intentar correlacionar los errores del archivo de registro con el gráfico.

Las herramientas de registro no daban una idea de la escala, por lo que era difícil saber si un error visto en una línea de registro se producía con frecuencia. Los registros también contenían muchas otras líneas irrelevantes, lo que dificultaba la localización de la causa raíz.

Solución propuesta

El equipo de desarrollo de App Engine optó por exportar el código de estado HTTP como una etiqueta en la métrica (por ejemplo, requests_total{status=404} frente a requests_total{status=500}). Dado que el número de códigos de estado HTTP diferentes es relativamente limitado, esto no aumentó el volumen de datos métricos a un tamaño poco práctico, pero sí hizo que los datos más pertinentes estuvieran disponibles para gráficos y alertas.

Resultado

Gracias a esta nueva etiqueta, el equipo pudo actualizar los gráficos para mostrar líneas separadas para las distintas categorías y tipos de error. Ahora los clientes podían formarse rápidamente conjeturas sobre posibles problemas basándose en los códigos de error expuestos. También podíamos establecer umbrales de alerta diferentes para los errores de cliente y servidor, lo que hacía que las alertas se activaran con mayor precisión.

El Problema

Un equipo de Ads SRE mantenía ~50 servicios, que estaban escritos en varios lenguajes y frameworks diferentes. El equipo utilizaba los registros como fuente canónica de verdad para el cumplimiento de los SLO. Para calcular el presupuesto de errores, cada servicio utilizaba un script de procesamiento de registros con muchos casos especiales específicos del servicio. A continuación se muestra un script de ejemplo para procesar una entrada de registro de un único servicio:

If the HTTP status code was in the range (500, 599)
AND the 'SERVER ERROR' field of the log is populated
AND DEBUG cookie was not set as part of the request
AND the url did not contain '/reports'
AND the 'exception' field did not contain 'com.google.ads.PasswordException'
THEN increment the error counter by 1

Estos scripts eran difíciles de mantener y además utilizaban datos que no estaban disponibles para el sistema de supervisión basado en métricas. Como las métricas controlaban las alertas, a veces éstas no correspondían a errores de cara al usuario. Cada alerta requería un paso de clasificación explícito para determinar si estaba orientada al usuario, lo que ralentizaba el tiempo de respuesta.

Solución propuesta

El equipo creó una biblioteca que se conectaba a la lógica de los lenguajes marco de cada aplicación. La biblioteca decidía si el error afectaba a los usuarios en el momento de la solicitud. La instrumentación anotaba esta decisión en los registros y la exportaba como métrica al mismo tiempo, lo que mejoraba la coherencia. Si la métrica mostraba que el servicio había devuelto un error, los registros contenían el error exacto, junto con datos relacionados con la solicitud para ayudar a reproducir y depurar el problema. En consecuencia, cualquier error que afectara al SLO y que se manifestara en los registros también modificaba las métricas del SLI, sobre las que el equipo podía alertar.

Resultado

Al introducir una superficie de control uniforme en varios servicios, el equipo reutilizó las herramientas y la lógica de alerta en lugar de implementar varias soluciones personalizadas. Todos los servicios se beneficiaron de la eliminación del complicado código de procesamiento de registros específico del servicio, lo que se tradujo en una mayor escalabilidad. Una vez que las alertas se vincularon directamente a los SLO, fueron más claramente procesables, por lo que la tasa de falsos positivos disminuyó significativamente.

El Problema

Mientras investigaba problemas de producción, un equipo de SRE a menudo miraba los ID de entidad afectados para determinar el impacto en el usuario y la causa raíz. Al igual que en el ejemplo anterior de App Engine, esta investigación requería datos que sólo estaban disponibles en los registros. Para ello, el equipo tenía que realizar consultas de registro puntuales mientras respondían a los incidentes. Este paso añadía tiempo a la recuperación de incidentes: unos minutos para elaborar correctamente la consulta, más el tiempo para consultar los registros.

Solución propuesta

El equipo debatió inicialmente si una métrica debía sustituir a sus herramientas de registro. A diferencia del ejemplo de App Engine, el ID de entidad podría adoptar millones de valores diferentes, por lo que no sería práctico como etiqueta métrica.

Finalmente, el equipo decidió escribir una secuencia de comandos para realizar las consultas de registro puntuales que necesitaban, y documentó qué secuencia de comandos ejecutar en los correos electrónicos de alerta. De este modo, podían copiar el comando directamente en un terminal en caso necesario.

Resultado

El equipo ya no tenía la carga cognitiva de gestionar la consulta de registro puntual correcta. En consecuencia, podían obtener los resultados que necesitaban más rápidamente (aunque no tan rápido como con un enfoque basado en métricas). También disponían de un plan de seguridad: podían ejecutar el script automáticamente en cuanto se disparara una alerta y utilizar un pequeño servidor para consultar los registros a intervalos regulares y recuperar constantemente datos semifrescos.

Su sistema de monitoreo es tan importante como cualquier otro servicio que gestione. Como tal, debe ser tratado con el nivel apropiado de cuidado y atención.

Tratar la configuración del sistema como código y almacenarla en el sistema de control de revisiones son prácticas comunes que proporcionan algunos beneficios obvios: historial de cambios, enlaces desde cambios específicos a su sistema de seguimiento de tareas, reversiones y comprobaciones de linting más sencillas,¹⁾ y procedimientos de revisión de código reforzados.

Recomendamos encarecidamente tratar también la configuración de la monitorización como código (para más información sobre la configuración, véase el Capítulo 14). Un sistema de monitoreo que soporte la configuración basada en intenciones es preferible a los sistemas que sólo proporcionan interfaces de usuario web o APIs de estilo CRUD. Este enfoque de configuración es estándar para muchos binarios de código abierto que sólo leen un archivo de configuración. Algunas soluciones de terceros como grafanalib permiten este enfoque para componentes que tradicionalmente se configuran con una UI.

Las grandes empresas con múltiples equipos de ingeniería que utilizan la monitorización necesitan encontrar un delicado equilibrio: un enfoque centralizado proporciona coherencia, pero, por otro lado, los equipos individuales pueden querer un control total sobre el diseño de su configuración.

La solución adecuada depende de su organización. El enfoque de Google ha evolucionado con el tiempo hacia la convergencia en un único marco que se ejecuta de forma centralizada como un servicio. Esta solución funciona bien para nosotros por varias razones. Un único marco de trabajo permite a los ingenieros trabajar más rápidamente cuando cambian de equipo y facilita la colaboración durante la depuración. También tenemos un servicio centralizado de tableros, en el que los tableros de cada equipo son localizables y accesibles. Si entiendes fácilmente el tablero de otro equipo, puedes depurar tus problemas y los suyos más rápidamente.

Si es posible, haz que la cobertura de supervisión básica no suponga un esfuerzo. Si todos sus servicios²⁾ exportan un conjunto coherente de métricas básicas, puede recopilar automáticamente esas métricas en toda su organización y proporcionar un conjunto coherente de tableros. Este enfoque significa que cualquier nuevo componente que lance dispondrá automáticamente de supervisión básica. Muchos equipos de su empresa, incluso los que no son de ingeniería, pueden utilizar estos datos de supervisión.

Los requisitos de la empresa cambian, y su sistema de producción tendrá un aspecto diferente dentro de un año. Del mismo modo, su sistema de monitorización debe evolucionar con el tiempo a medida que los servicios que monitoriza evolucionan a través de diferentes patrones de fallo.

Recomendamos mantener los componentes de su sistema de monitorización débilmente acoplados. Debe disponer de interfaces estables para configurar cada componente y transmitir los datos de supervisión. Cada componente debe encargarse de recopilar, almacenar, alertar y visualizar la monitorización. Las interfaces estables facilitan la sustitución de cualquier componente por una alternativa mejor.

Dividir la funcionalidad en componentes individuales se está haciendo popular en el mundo del código abierto. Hace una década, los sistemas de monitorización como Zabbix combinaban todas las funciones en un único componente. El diseño moderno suele implicar la separación de la recopilación y la evaluación de reglas (con una solución como el servidor Prometheus), el almacenamiento de series temporales a largo plazo (InfluxDB), la agregación de alertas (Alertmanager) y la creación de tableros (Grafana).

En el momento de escribir estas líneas, existen al menos dos estándares abiertos populares para instrumentar el software y exponer las métricas:

• statsd: El demonio de agregación métrica inicialmente escrito por Etsy y ahora portado a la mayoría de lenguajes de programación.

• Prometheus: Una solución de supervisión de código abierto con un modelo de datos flexible, compatibilidad con etiquetas métricas y una sólida funcionalidad de histograma. Otros sistemas están adoptando el formato Prometheus y se está estandarizando como OpenMetrics.

Un sistema de tableros independiente que puede utilizar múltiples fuentes de datos proporciona una visión general central y unificada de su servicio. Google ha comprobado recientemente esta ventaja en la práctica: nuestro sistema de supervisión heredado (Borgmon³⁾) combinaba tableros en la misma configuración que reglas de alerta. Durante la migración a un nuevo sistema (Monarch), decidimos trasladar los tableros a un servicio independiente (Viceroy). Como Viceroy no era un componente de Borgmon o Monarch, Monarch tenía menos requisitos funcionales. Dado que los usuarios podían utilizar Viceroy para mostrar gráficos basados en datos de ambos sistemas de supervisión, podían migrar gradualmente de Borgmon a Monarch.

El Capítulo 5 cubre cómo monitorear y alertar usando métricas SLI cuando el presupuesto de errores de un sistema está bajo amenaza. Las métricas SLI son las primeras métricas que querrá comprobar cuando se activen las alertas basadas en SLO. Estas métricas deben aparecer prominentemente en el tablero de su servicio, idealmente en su página de aterrizaje.

Al investigar la causa de una violación de SLO, lo más probable es que no obtenga suficiente información de los tableros de SLO. Estos tableros muestran que se está violando el SLO, pero no necesariamente por qué. ¿Qué otros datos deberían mostrar los tableros de control?

Hemos encontrado las siguientes directrices útiles en la implementación de métricas. Estas métricas deben proporcionar una supervisión razonable que le permita investigar los problemas de producción y también proporcionar una amplia gama de información sobre su servicio.

Al diagnosticar una alerta basada en SLO, debe ser capaz de pasar de las métricas de alerta que le notifican los problemas que afectan a los usuarios a las métricas que le indican cuál es la causa de estos problemas. Los recientes cambios previstos en su servicio podrían ser la causa. Añada una monitorización que le informe de cualquier cambio en producción.⁴⁾ Para determinar el desencadenante, recomendamos lo siguiente:

• Supervise la versión del binario.

• Supervise los indicadores de la línea de comandos, especialmente cuando utilice estos indicadores para activar y desactivar funciones del servicio.

• Si los datos de configuración se envían a su servicio de forma dinámica, supervise la versión de esta configuración dinámica.

Si alguna de estas piezas del sistema no está versionada, deberías ser capaz de monitorizar la marca de tiempo en la que se construyó o empaquetó por última vez.

Cuando se trata de correlacionar una interrupción con un despliegue, es mucho más fácil consultar un gráfico o un tablero vinculado a la alerta que buscar en los registros del sistema CI/CD (integración continua/entrega continua) a posteriori.

Aunque su servicio no haya cambiado, cualquiera de sus dependencias podría cambiar o tener problemas, por lo que también debería monitorizar las respuestas procedentes de las dependencias directas.

Es razonable exportar el tamaño de la solicitud y la respuesta en bytes, la latencia y los códigos de respuesta para cada dependencia. A la hora de elegir las métricas a graficar, ten en cuenta las cuatro señales de oro. Puedes utilizar etiquetas adicionales en las métricas para desglosarlas por código de respuesta, nombre de método RPC (llamada a procedimiento remoto) y nombre de trabajo de pares.

Idealmente, puedes instrumentar la librería cliente RPC de nivel inferior para exportar estas métricas una vez, en lugar de pedir a cada librería cliente RPC que las exporte.⁵⁾ Instrumentar la librería cliente proporciona más consistencia y te permite monitorizar nuevas dependencias de forma gratuita.

A veces te encontrarás con dependencias que ofrecen una API muy estrecha, donde toda la funcionalidad está disponible a través de una única RPC llamada Get, Query, o algo igualmente poco útil, y el comando real se especifica como argumentos a esta RPC. Un único punto de instrumentación en la biblioteca del cliente se queda corto con este tipo de dependencia: observará una gran variación en la latencia y un cierto porcentaje de errores que pueden o no indicar que alguna parte de esta API opaca está fallando por completo. Si esta dependencia es crítica, tienes un par de opciones para monitorizarla bien:

• Exportar métricas separadas para adaptarlas a la dependencia, de modo que las métricas puedan descomprimir las solicitudes que reciben para llegar a la señal real.

• Pedir a los propietarios de la dependencia que realicen una reescritura para exportar una API más amplia que admita una funcionalidad independiente dividida en servicios y métodos RPC independientes.

Intente supervisar y realizar un seguimiento del uso de todos los recursos de los que depende el servicio. Algunos recursos tienen límites que no se pueden sobrepasar, como las cuotas de RAM, disco o CPU asignadas a la aplicación. Otros recursos, como los descriptores de archivo abiertos, los subprocesos activos en cualquier grupo de subprocesos, los tiempos de espera en las colas o el volumen de registros escritos, pueden no tener un límite duro claro, pero aún así requieren gestión.

Dependiendo del lenguaje de programación que utilices, deberás monitorizar recursos adicionales:

• En Java: El tamaño de la pila y del metaespacio, y métricas más específicas dependiendo del tipo de recolección de basura que se esté utilizando.

• En Go: El número de goroutines

Los propios lenguajes proporcionan soporte variable para monitorizar estos recursos.

Además de alertar sobre eventos significativos, como se describe en el Capítulo 5, puede que también necesites configurar alertas que se disparen cuando te acerques al agotamiento de recursos específicos, como por ejemplo:

• Cuando el recurso tiene un límite duro

• Cuando cruzar un umbral de uso provoca una degradación del rendimiento

Deberías tener métricas de monitorización para hacer un seguimiento de todos los recursos, incluso de los recursos que el servicio gestiona bien. Estas métricas son vitales para planificar la capacidad y los recursos.

Es una buena idea añadir métricas o etiquetas de métricas que permitan a los tableros desglosar el tráfico servido por código de estado (a menos que las métricas que su servicio utiliza a efectos de SLI ya incluyan esta información). He aquí algunas recomendaciones:

• Para el tráfico HTTP, supervise todos los códigos de respuesta, aunque no proporcionen suficiente señal para alertas, porque algunos pueden ser provocados por un comportamiento incorrecto del cliente.

• Si aplica límites de velocidad o de cuota a sus usuarios, controle los agregados de cuántas solicitudes se denegaron por falta de cuota.

Los gráficos de estos datos pueden ayudarle a identificar cuándo el volumen de errores cambia notablemente durante un cambio de producción.

Cada métrica expuesta debe servir a un propósito. Resista la tentación de exportar un puñado de métricas sólo porque son fáciles de generar. En su lugar, piense en cómo se utilizarán estas métricas. El diseño de las métricas, o su ausencia, tiene implicaciones.

Lo ideal es que los valores de las métricas utilizadas para alertas cambien drásticamente sólo cuando el sistema entra en un estado problemático, y no cambien cuando el sistema funciona con normalidad. Por otro lado, las métricas de depuración no tienen estos requisitos: su objetivo es proporcionar información sobre lo que ocurre cuando se activan las alertas. Una buena métrica de depuración apuntará a algún aspecto del sistema que pueda estar causando problemas. Cuando escriba una autopsia, piense en qué métricas adicionales le habrían permitido diagnosticar el problema más rápidamente.

En un mundo ideal, el código de supervisión y alerta debería estar sujeto a los mismos estándares de prueba que el desarrollo de código. Aunque los desarrolladores de Prometheus están debatiendo el desarrollo de pruebas unitarias para la supervisión, actualmente no existe ningún sistema ampliamente adoptado que permita hacerlo.

En Google, probamos nuestra supervisión y alerta utilizando un lenguaje específico del dominio que nos permite crear series temporales sintéticas. A continuación, escribimos afirmaciones basadas en los valores de una serie temporal derivada, o en el estado de activación y la presencia de etiquetas de alertas específicas.

La supervisión y las alertas suelen ser procesos de varias etapas, por lo que requieren varias familias de pruebas unitarias. Mientras que esta área permanece en gran parte subdesarrollada, en caso de que desee implementar pruebas de monitorización en algún momento, le recomendamos un enfoque de tres niveles, como se muestra en la Figura 4-1.

Figura 4-1. Supervisión de los niveles del entorno de pruebas

• 1. Informes binarios: Comprobar que las variables métricas exportadas cambian de valor en determinadas condiciones según lo esperado.

• 2. Monitorización de configuraciones: Asegúrese de que la evaluación de reglas produce los resultados esperados, y que condiciones específicas producen las alertas esperadas.

• 3. Configuraciones de alerta: Compruebe que las alertas generadas se dirigen a un destino predeterminado, en función de los valores de las etiquetas de alerta.

Si no puede probar su supervisión por medios sintéticos, o hay una fase de su supervisión que simplemente no puede probar, considere la posibilidad de crear un sistema en funcionamiento que exporte métricas conocidas, como el número de solicitudes y errores. Puede utilizar este sistema para validar series temporales y alertas derivadas. Es muy probable que sus reglas de alerta no se activen hasta meses o años después de haberlas configurado, y necesita tener la confianza de que cuando la métrica supere un determinado umbral, los ingenieros correctos serán alertados con notificaciones que tengan sentido.

Debido a que el rol de SRE es responsable de la confiabilidad de los sistemas en producción, a menudo se requiere que los SRE estén íntimamente familiarizados con el sistema de monitoreo de un servicio y sus características. Sin este conocimiento, los SREs podrían no saber dónde buscar, cómo identificar un comportamiento anormal o cómo encontrar la información que necesitan durante una emergencia.

Esperamos que al señalar las características del sistema de monitorización que consideramos útiles y por qué, podamos ayudarle a evaluar hasta qué punto su estrategia de monitorización se ajusta a sus necesidades, a explorar algunas características adicionales que podría aprovechar y a considerar los cambios que podría desear realizar. Probablemente le resulte útil combinar alguna fuente de métricas y registros en su estrategia de supervisión; la combinación exacta que necesita depende en gran medida del contexto. Asegúrate de recopilar métricas que sirvan a un propósito concreto. Ese propósito puede ser permitir una mejor planificación de la capacidad, ayudar en la depuración o notificar directamente los problemas.

Una vez establecida la supervisión, debe ser visible y útil. Para ello, también recomendamos probar la configuración de la monitorización. Un buen sistema de control es rentable. Merece la pena invertir mucho tiempo en pensar qué soluciones se adaptan mejor a sus necesidades y repetirlas hasta que funcionen.

Volver al índice