El cuaderno de trabajo de la fiabilidad del sitio web

Capítulo 4. Monitoreo

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

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

El monitoreo puede incluir muchos tipos de datos, como las métricas, el registro de texto, el registro estructurado de eventos, el rastreo distribuido, y la introspección de eventos. Aunque todos estos enfoques son útiles por sí mismos, este capítulo aborda principalmente las métricas y el registro estructurado. Según nuestra experiencia, estas dos fuentes de datos son las que mejor se adaptan a las necesidades fundamentales de monitoreo de la SRE.

En el nivel más básico, el monitoreo te permite obtener visibilidad de un sistema, que es un requisito básico para juzgar la salud del servicio y diagnosticarlo cuando las cosas van mal. El capítulo 6 del primer libro de SRE proporciona algunas definiciones básicas de monitoreo y explica que los SRE monitorean sus sistemas para:

• Alerta sobre las condiciones que requieren atención.

• Investiga y diagnostica esos problemas.

• Muestra visualmente información sobre el sistema.

• Obtén información sobre las tendencias en el uso de los recursos o la salud de los servicios para planificar a largo plazo.

• Compara 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 llevarte a hacer concesiones a la hora de seleccionar o construir un sistema de monitoreo.

En este capítulo se explica cómo gestiona Google los sistemas de monitoreo y se dan algunas pautas para las preguntas que pueden surgir al elegir y poner en marcha un sistema de monitoreo.

Características deseables de una estrategia de monitoreo

Al elegir un sistema de monitoreo, es importante comprender y priorizar las características que te importan. Si estás evaluando distintos sistemas de monitoreo, los atributos de esta sección pueden ayudarte a orientar tu reflexión sobre qué solución o soluciones se adaptan mejor a tus necesidades. Si ya tienes una estrategia de monitoreo, puedes plantearte utilizar algunas capacidades adicionales de tu solución actual. Dependiendo de tus necesidades, un sistema de monitoreo puede abordar todos tus casos de uso, o puede que quieras utilizar una combinación de sistemas.

Velocidad

Las distintas organizaciones tendrán necesidades diferentes en cuanto a la frescura de los datos y la velocidad de recuperación de los datos.

Los datos deben estar disponibles cuando los necesites: la frescura influye en el tiempo que tardará tu sistema de monitoreo en avisarte cuando algo vaya mal. Además, los datos lentos pueden llevarte 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 tu monitoreo) es demasiado largo, podrías suponer 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 podrían afectar significativamente a la rapidez con la que puedes responder a un incidente.

Si vas a elegir un sistema de monitoreo basándote en este criterio, tienes que calcular de antemano tus requisitos de velocidad. La velocidad de recuperación de datos es sobre todo un problema cuando consultas grandes cantidades de datos. Un gráfico puede tardar en cargarse si tiene que recopilar muchos datos de muchos sistemas monitorizados. Para acelerar tus gráficos más lentos, es útil que el sistema de monitoreo pueda crear y almacenar nuevas series temporales basadas en los datos entrantes; así podrá precalcular las respuestas a las consultas habituales.

Cálculos

El soporte de los cálculos puede abarcar una gran variedad de casos de uso, a través de un abanico de complejidades. Como mínimo, probablemente querrás que tu sistema conserve datos durante un período de varios meses. Sin una visión a largo plazo de tus datos, no puedes 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 puedes 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, tu sistema de monitoreo 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 a lo largo de una ventana más larga (hasta un mes) te permite implementar los bloques de construcción para la alerta basada en la quema de SLO (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 monitoreo que soporte el cálculo de percentiles (es decir, percentiles 50, 95, 99) al registrar la latencia te permitirá ver si el 50%, 5% o 1% de tus solicitudes son demasiado lentas, mientras que la media aritmética sólo puede decirte -sin especificar- que el tiempo de solicitud es más lento. Alternativamente, si tu sistema no admite el cálculo de percentiles directamente, puedes conseguirlo de la siguiente manera:

• Obtención de un valor medio sumando los segundos dedicados a las solicitudes y dividiéndolos por el número de solicitudes

• Registrar cada solicitud y calcular los valores percentiles escaneando o muestreando las entradas del registro

Puede que quieras registrar tus datos métricos sin procesar en un sistema separado para analizarlos 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 tu sistema de monitoreo.

Interfaces

Un sistema de monitoreo sólido debe permitirte mostrar de forma concisa datos de series temporales en gráficos, y también estructurar los datos en tablas o en una serie de estilos de gráficos. Tus cuadros de mando serán las interfaces principales para mostrar el monitoreo, por lo que es importante que elijas los formatos que muestren más claramente los datos que te interesan. Algunas opciones son los mapas térmicos, los histogramas y los gráficos de escala logarítmica.

Es probable que tengas que ofrecer diferentes vistas de los mismos datos en función de la audiencia; los directivos de alto nivel pueden querer ver una información muy diferente a la de los SRE. Sé específico a la hora de crear cuadros de mando que tengan sentido para las personas que consumen el contenido. Para cada conjunto de cuadros de mando, mostrar los mismos tipos de datos de forma coherente es valioso para la comunicación.

Puede que necesites 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 tu equipo se sienta cómodo realizando desgloses ad hoc de tus datos. Al dividir tus datos en función de una variedad de métricas, puedes buscar correlaciones y patrones en los datos cuando lo necesites.

Alertas

Es útil poder clasificar las alertas: múltiples categorías de alertas permiten respuestas proporcionales. También es útil la posibilidad de establecer distintos niveles de gravedad para las distintas alertas: podrías presentar un ticket para investigar un bajo índice de errores que dure más de una hora, mientras que un índice de errores del 100% es una emergencia que merece una respuesta inmediata.

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

• Cuando todos los nodos experimentan la misma tasa elevada de errores, puedes alertar una sola vez de la tasa global de errores en lugar de enviar una alerta individual para cada nodo.

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

También debes poder garantizar que las alertas dejen de suprimirse una vez finalizado el evento.

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

Fuentes de datos de monitoreo

Tu elección del sistema o sistemas de monitoreo dependerá de las fuentes específicas de datos de monitoreo que vayas a utilizar. Esta sección trata de dos fuentes habituales de datos de monitoreo: los registros y las métricas. Hay otras fuentes de monitoreo valiosas que no cubriremos aquí, como el rastreo distribuido y la introspección en tiempo de ejecución.

Las métricas son mediciones numéricas que representan atributos y eventos, normalmente recogidos mediante muchos puntos de datos a intervalos de tiempo regulares. Los logs son un registro de eventos sólo en forma de apéndice. La discusión de este capítulo se centra en los registros estructurados que permiten herramientas de consulta y agregación enriquecidas, en contraposición a los registros de texto plano.

Los sistemas basados en registros de Google procesan grandes volúmenes de datos muy granulares. Existe cierto retraso inherente entre el momento en que se produce un evento y el momento en que es visible en los registros. Para análisis que no sean sensibles al tiempo, estos registros pueden procesarse con un sistema por lotes, interrogarse con consultas ad hoc y visualizarse con cuadros de mando. 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 cuadros de mando.

En cambio, nuestro sistema de monitoreo basado en métricas,, que recoge un gran número de métricas de todos los servicios de Google, proporciona información mucho menos granular, pero casi en tiempo real. Estas características son bastante típicas de otros sistemas de monitoreo 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 cuadros de mando suelen utilizar métricas. La naturaleza en tiempo real de nuestro sistema de monitoreo 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 los informes no son sensibles al tiempo, a menudo generamos informes detallados utilizando sistemas de procesamiento de registros, porque los registros casi siempre producen datos más precisos que las métricas.

Si estás alertas basadas en métricas, puede resultar tentador añadir más alertas basadas en registros; por ejemplo, si necesitas que te avisen cuando se produzca un solo evento excepcional. Seguimos recomendando las alertas basadas en métricas en estos casos: puedes 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 las alertas en un solo lugar, lo que facilita su gestión (consulta "Gestión de tu sistema de monitoreo").

Ejemplos

Los siguientes ejemplos del mundo real ilustran cómo razonar el proceso de elección entre sistemas de monitoreo.

Trasladar la información de los registros a las métricas

Problema

El código de estado HTTP es una señal importante de 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 panel 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 produjo un error.

2. Leer 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 sensación de 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 de la métrica hasta un tamaño poco práctico, pero sí hizo que los datos más pertinentes estuvieran disponibles para gráficos y alertas.

Resultado

Esta nueva etiqueta significaba que el equipo podía 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. Ahora también podíamos establecer umbrales de alerta diferentes para los errores del cliente y del servidor, haciendo que las alertas se activaran con mayor precisión.

Mejora tanto los registros como las métricas

Problema

Un equipo de Ads SRE mantenía ~50 servicios, que estaban escritos en varios lenguajes y frameworks diferentes. El equipo utilizaba los logs como fuente canónica de verdad para el cumplimiento del SLO. Para calcular el presupuesto de errores, cada servicio utilizaba un script de procesamiento de logs con muchos casos especiales específicos del servicio. He aquí un ejemplo de script para procesar una entrada de registro de un solo 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 monitoreo basado en métricas. Como las métricas impulsaban las alertas, a veces éstas no correspondían a errores de cara al usuario. Cada alerta requería un paso explícito de triaje para determinar si estaba orientada al usuario, lo que ralentizaba el tiempo de respuesta.

Solución propuesta

El equipo creó una biblioteca que se enganchaba 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 escribía esta decisión en los registros y la exportaba como métrica al mismo tiempo, mejorando 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 la métrica SLI, sobre la 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 de cada 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.

Mantener los registros como fuente de datos

Problema

Al investigar los problemas de producción, un equipo de SRE solía mirar los ID de entidad afectados para determinar el impacto en el usuario y la causa raíz. Como 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 puntuales a los registros mientras respondían a los incidentes. Este paso añadía tiempo a la recuperación del incidente: 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 distintos, por lo que no sería práctico como etiqueta métrica.

Al final, el equipo decidió escribir una secuencia de comandos para realizar las consultas puntuales de registro que necesitaban, y documentó qué secuencia de comandos ejecutar en los correos electrónicos de alerta. Así podrían copiar el comando directamente en un terminal si fuera necesario.

Resultado

El equipo ya no tenía la carga cognitiva de gestionar la consulta de registro única y correcta. En consecuencia, podían obtener más rápidamente los resultados que necesitaban (aunque no tan rápidamente como con un enfoque basado en métricas). También tenían un plan de respaldo: 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 para recuperar constantemente datos semifrescos.

Gestionar tu sistema de monitoreo

Tu sistema de monitoreo es tan importante como cualquier otro servicio que gestiones. Como tal, debe tratarse con el nivel adecuado de cuidado y atención.

Trata tu configuración como código

Tratar la configuración del sistema como código y almacenarla en el sistema de control de revisiones son prácticas comunes que proporcionan algunas ventajas obvias: historial de cambios, enlaces desde cambios específicos a tu sistema de seguimiento de tareas, reversiones más fáciles y comprobaciones de linting,¹ y procedimientos reforzados de revisión del código.

Recomendamos encarecidamente tratar también la configuración del monitoreo como código (para más información sobre la configuración, consulta el Capítulo 14). Un sistema de monitoreo que admita la configuración basada en la intención es preferible a los sistemas que sólo proporcionan interfaces de usuario web o API 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 interfaz de usuario.

Fomenta la coherencia

Las grandes empresas con múltiples equipos de ingeniería que utilizan el monitoreo 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 tu organización. El enfoque de Google ha evolucionado con el tiempo hacia la convergencia en un único marco que se ejecuta centralmente como un servicio. Esta solución funciona bien para nosotros por varias razones. Un único marco permite a los ingenieros ponerse en marcha más rápidamente cuando cambian de equipo, y facilita la colaboración durante la depuración. También tenemos un servicio centralizado de cuadros de mando, donde los cuadros de mando de cada equipo son descubribles y accesibles. Si entiendes fácilmente el panel de control de otro equipo, puedes depurar tus problemas y los suyos más rápidamente.

Si es posible, haz que la cobertura básica de monitoreo no suponga un esfuerzo. Si todos tus servicios² exportan un conjunto coherente de métricas básicas, puedes recopilar automáticamente esas métricas en toda tu organización y proporcionar un conjunto coherente de cuadros de mando. Este enfoque significa que cualquier nuevo componente que lances tendrá automáticamente un monitoreo básico. Muchos equipos de tu empresa -incluso los que no son de ingeniería- pueden utilizar estos datos de monitoreo.

Prefiere el Acoplamiento Suelto

Los requisitos empresariales cambian, y tu sistema de producción tendrá un aspecto diferente dentro de un año. Del mismo modo, tu sistema de monitoreo tiene que evolucionar con el tiempo a medida que los servicios que monitorea evolucionan a través de diferentes patrones de fallo.

Te recomendamos que mantengas los componentes de tu sistema de monitoreo débilmente acoplados. Debes tener interfaces estables para configurar cada componente y pasar los datos de monitoreo. Componentes separados deben encargarse de recopilar, almacenar, alertar y visualizar tu monitoreo. Las interfaces estables facilitan el cambio 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 monitoreo 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 cuadros de mando(Grafana).

En el momento de escribir esto, existen al menos dos estándares abiertos populares para instrumentar tu software y exponer métricas:

estadísticasd

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

Prometeo

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

Un sistema de cuadros de mando independiente que pueda utilizar múltiples fuentes de datos proporciona una visión general central y unificada de tu servicio. Google ha visto recientemente esta ventaja en la práctica: nuestro sistema de monitoreo heredado (Borgmon³) combinaba cuadros de mando en la misma configuración que reglas de alerta. Mientras migrábamos a un nuevo sistema(Monarch), decidimos trasladar los cuadros de mando a un servicio independiente(Viceroy). Como Viceroy no era un componente de Borgmon ni de Monarch, Monarch tenía menos requisitos funcionales. Como los usuarios podían utilizar Viceroy para mostrar gráficos basados en datos de ambos sistemas de monitoreo, podían migrar gradualmente de Borgmon a Monarch.

Métricas con propósito

Enel Capítulo 5 se explica cómo monitorizar y alertar mediante métricas SLI cuando el presupuesto de errores de un sistema está amenazado. Las métricas SLI son las primeras métricas que querrás comprobar cuando se activen las alertas basadas en SLO. Estas métricas deben aparecer de forma destacada en el panel de control de tu servicio, idealmente en su página de inicio.

Cuando investigues la causa de una infracción de la SLO, lo más probable es que no obtengas suficiente información de los cuadros de mando de la SLO. Estos paneles muestran que estás infringiendo la SLO, pero no necesariamente por qué. ¿Qué otros datos deberían mostrar los paneles de monitoreo?

Las siguientes directrices nos han resultado útiles para implantar métricas. Estas métricas deben proporcionar un monitoreo razonable que te permita investigar los problemas de producción y también proporcionar una amplia gama de información sobre tu servicio.

Cambios previstos

Al diagnosticar una alerta basada en SLO, tienes que ser capaz de pasar de las métricas de alerta que te notifican los problemas que afectan a los usuarios a las métricas que te dicen qué está causando esos problemas. Los recientes cambios previstos en tu servicio podrían ser la causa. Añade un monitoreo que te informe de cualquier cambio en la producción.⁴ Para determinar el desencadenante, te recomendamos lo siguiente:

• Monitorea la versión del binario.

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

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

Si alguna de estas piezas del sistema no está versionada, deberías poder monitorizar la fecha y hora en que se creó o empaquetó por última vez.

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

Dependencias

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

Es razonable exportar el tamaño de la solicitud y la respuesta en bytes, la latencia y los códigos de respuesta de cada dependencia. Cuando elijas 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 del método RPC (llamada a procedimiento remoto) y nombre de la tarea par.

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

A veces te encontrarás con dependencias que ofrecen una API muy estrecha, en la que toda la funcionalidad está disponible a través de un único RPC llamado Get, Query, o algo igualmente poco útil, y el comando real se especifica como argumentos de este RPC. Un único punto de instrumentación en la biblioteca cliente se queda corto con este tipo de dependencia: observarás una gran variación en la latencia y cierto porcentaje de errores que pueden indicar o no 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:

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

• Pide a los propietarios de las dependencias que realicen una reescritura para exportar una API más amplia que admita una funcionalidad separada dividida en servicios y métodos RPC independientes.

Saturación

Procura monitorizar y hacer un seguimiento del uso de cada recurso del que depende el servicio. Algunos recursos tienen límites duros que no puedes sobrepasar, como las cuotas de RAM, disco o CPU asignadas a tu aplicación. Otros recursos -como los descriptores de archivo abiertos, los hilos activos en cualquier grupo de hilos, 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.

Según el lenguaje de programación que utilices, deberás monitorizar recursos adicionales:

• En Java: El tamaño del montón y del metaespacio, y métricas más específicas según el tipo de recolección de basura que utilices

• En Go: El número de goroutines

Las propias lenguas proporcionan un soporte variable para rastrear 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 determinados recursos, como por ejemplo:

• Cuando el recurso tiene un límite duro

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

Debes disponer de métricas de monitoreo para hacer un seguimiento de todos los recursos, incluso de los que el servicio gestiona bien. Estas métricas son vitales para planificar la capacidad y los recursos.

Estado del tráfico servido

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

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

• Si aplicas límites de tarifa o de cuota a tus usuarios, monitorea los agregados de cuántas solicitudes se denegaron por falta de cuota.

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

Implantar métricas con propósito

Cada métrica expuesta debe servir para algo. Resiste la tentación de exportar un puñado de métricas sólo porque son fáciles de generar. En lugar de eso, piensa en cómo se utilizarán esas 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 las 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 otra parte, las métricas de depuración de no tienen estos requisitos: su objetivo es proporcionar información sobre lo que ocurre cuando se activan las alertas. Las buenas métricas de depuración apuntarán a algún aspecto del sistema que esté causando potencialmente los problemas. Cuando escribas una autopsia, piensa qué métricas adicionales te habrían permitido diagnosticar el problema más rápidamente.

Probar la lógica de alerta

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

En Google, probamos nuestro monitoreo 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.

El monitoreo y las alertas son a menudo un proceso de varias etapas, que por lo tanto requiere varias familias de pruebas unitarias. Aunque esta área sigue estando muy poco desarrollada, en caso de que quieras implantar pruebas de monitoreo en algún momento, te recomendamos un enfoque de tres niveles, como se muestra en la Figura 4-1.

Figura 4-1. Niveles del entorno de pruebas de monitoreo

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

2. Configuraciones de monitoreo: Asegúrate de que la evaluación de las reglas produce los resultados esperados, y de que las condiciones específicas producen las alertas esperadas.

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

Si no puedes probar tu monitoreo por medios sintéticos, o hay una fase de tu monitoreo que simplemente no puedes probar, considera la posibilidad de crear un sistema en funcionamiento que exporte métricas conocidas, como el número de peticiones y errores. Puedes utilizar este sistema para validar las series temporales derivadas y las alertas. Es muy probable que tus reglas de alerta no se disparen hasta meses o años después de configurarlas, y necesitas tener la seguridad de que, cuando la métrica supere un determinado umbral, se alertará a los ingenieros correctos con notificaciones que tengan sentido.

Conclusión

Dado que el papel de SRE es responsable de la fiabilidad 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 SRE podrían no saber dónde buscar, cómo identificar un comportamiento anómalo o cómo encontrar la información que necesitan durante una emergencia.

Esperamos que, al señalar las características del sistema de monitoreo que consideramos útiles y por qué, podamos ayudarte a evaluar hasta qué punto tu estrategia de monitoreo se ajusta a tus necesidades, a explorar algunas características adicionales que podrías aprovechar y a considerar los cambios que podrías querer hacer. Probablemente te resulte útil combinar alguna fuente de métricas y registros en tu estrategia de monitoreo; la mezcla exacta que necesitas depende mucho 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 notificarte directamente los problemas.

Una vez establecido el monitoreo, debe ser visible y útil. Para ello, también te recomendamos que pruebes tu sistema de monitoreo. Un buen sistema de monitoreo es rentable. Merece la pena invertir mucho tiempo en pensar qué soluciones se adaptan mejor a tus necesidades, e iterar hasta que lo consigas.

¹ Por ejemplo, utilizando promtool para verificar que tu configuración de Prometheus es sintácticamente correcta.

² Puedes exportar métricas básicas a través de una biblioteca común: un marco de instrumentación como OpenCensus, o una malla de servicios como Istio.

³ Para los conceptos y la estructura de Borgmon, véase el capítulo 10 de Ingeniería de la Fiabilidad del Emplazamiento.

⁴ Éste es un caso en el que resulta atractivo el monitoreo mediante registros, sobre todo porque los cambios de producción son relativamente infrecuentes. Tanto si utilizas registros como métricas, estos cambios deben aparecer en tus paneles de control, de modo que sean fácilmente accesibles para depurar los problemas de producción.

⁵ Consulta https://opencensus.io/ para ver un conjunto de bibliotecas que lo proporcionan.