• Autor de la entrada:
  • Tiempo de lectura:32 minutos de lectura

Escrito por Jess Frame, Anthony Lenton, Steven Thurgood, Anton Tolchanov y Nejc Trdin con Carmela Quinito.

El monitoreo puede incluir muchos tipos de datos, incluidas métricas, registro de texto, registro de eventos estructurado, rastreo distribuido e introspección de eventos. Si bien todos estos enfoques son útiles por derecho propio, este capítulo aborda principalmente las métricas y el registro estructurado. En nuestra experiencia, estas dos fuentes de datos se adaptan mejor a las necesidades fundamentales de monitoreo de SRE.

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

  • Alerta sobre condiciones que requieren atención.
  • Investigue y diagnostique esos problemas.
  • Muestra información sobre el sistema de forma visual.
  • Obtenga información sobre las tendencias en el uso de recursos o el estado del servicio para la planificación a largo plazo.
  • Compare 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 llevarlo a hacer concesiones al seleccionar o construir un sistema de monitoreo.

Este capítulo habla sobre cómo Google administra los sistemas de monitoreo y proporciona algunas pautas para las preguntas que pueden surgir al elegir y ejecutar un sistema de monitoreo.

Características deseables de una estrategia de seguimiento

Al elegir un sistema de monitoreo, es importante comprender y priorizar las funciones que le importan. Si está evaluando diferentes sistemas de monitoreo, los atributos de esta sección pueden ayudarlo a pensar sobre qué soluciones se adaptan mejor a sus necesidades. Si ya tiene una estrategia de monitoreo, podría considerar usar algunas capacidades adicionales de su solución actual. Dependiendo de sus necesidades, un sistema de monitoreo puede abordar todos sus casos de uso, o es posible que desee utilizar una combinación de sistemas.

Velocidad

Las diferentes organizaciones tendrán diferentes necesidades en lo que respecta a la frescura de los datos y la velocidad de recuperación de datos .

Los datos deben estar disponibles cuando los necesite: la actualización afecta el tiempo que le tomará a su sistema de monitoreo ubicarlo cuando algo sale mal. Además, los datos lentos pueden llevarlo a actuar accidentalmente sobre datos incorrectos. Por ejemplo, durante la respuesta a un incidente, si el tiempo entre la causa (tomar una acción) y el efecto (ver esa acción reflejada en su monitoreo) es demasiado largo, puede asumir que un cambio no tuvo ningún efecto o deducir una correlación falsa entre causa y efecto. Los datos obsoletos de más de cuatro a cinco minutos pueden afectar significativamente la rapidez con la que puede responder a un incidente.

Si está seleccionando un sistema de monitoreo basado en estos criterios, debe determinar sus requisitos de velocidad con anticipación. La velocidad de recuperación de datos es principalmente un problema cuando se consultan grandes cantidades de datos. Es posible que un gráfico tarde un poco en cargarse si tiene que contar una gran cantidad de datos de muchos sistemas monitoreados. Para acelerar sus gráficos más lentos, es útil si el sistema de monitoreo puede crear y almacenar nuevas series de tiempo basadas en los datos entrantes; entonces puede calcular previamente las respuestas a consultas habituales.

Cálculos

El soporte para cálculos puede abarcar una variedad de casos de uso, a través de una variedad de complejidades. Como mínimo, probablemente querrá que su sistema retenga datos durante un período de tiempo de varios meses . Sin una visión a largo plazo de sus datos, no puede analizar tendencias a largo plazo como el crecimiento del sistema. En términos de granularidad, los datos resumidos (es decir, 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 pueden ser costosos de almacenar o poco prácticos de recuperar.

Lo ideal es que las métricas que conserve sobre los eventos o el consumo de recursos sean contadores que se incrementen de manera monótona. Con contadores, su sistema de supervisión puede calcular funciones en ventanas a lo largo del tiempo, por ejemplo, para informar la tasa de solicitudes por segundo de ese contador. Calcular estas tasas en una ventana más larga (hasta un mes) le permite implementar los componentes básicos para las alertas basadas en quemaduras de SLO (consulte Alertas sobre SLO ).

Finalmente, el soporte para una gama más completa de funciones estadísticas puede ser útil porque las operaciones triviales pueden enmascarar el mal comportamiento. Un sistema de monitoreo que admita la computación de percentiles (es decir, percentiles 50, 95, 99) al registrar la latencia le permitirá ver si el 50%, 5% o 1% de sus solicitudes son demasiado lentas, mientras que la media aritmética solo puede decirle: sin detalles, que el tiempo de solicitud es más lento. Alternativamente, si su sistema no admite la computación de percentiles directamente, puede lograrlo de la siguiente manera:

  • Obtener un valor medio sumando los segundos dedicados a las solicitudes y dividiendo por la cantidad de solicitudes
  • Registrar cada solicitud y calcular los valores de percentiles escaneando o muestreando las entradas del registro

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

Interfaces

Un sistema de monitoreo robusto debería permitirle mostrar de manera concisa datos de series de tiempo en gráficos, y también estructurar datos en tablas o una variedad de estilos de gráficos. Sus paneles serán interfaces principales para mostrar el monitoreo, por lo que es importante que elija formatos que muestren con mayor claridad los datos que le interesan. Algunas opciones incluyen mapas de calor, histogramas y gráficos de escala logarítmica.

Es probable que deba ofrecer diferentes vistas de los mismos datos según la audiencia; La gerencia de alto nivel puede querer ver información bastante diferente a la de los SRE. Sea específico en la creación de paneles que tengan sentido para las personas que consumen el contenido. Para cada conjunto de paneles, mostrar los mismos tipos de datos consistentemente es valioso para la comunicación.

Es posible que deba graficar información en 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 sus datos de acuerdo con una variedad de métricas, puede buscar correlaciones y patrones en los datos cuando los necesite.

Alertas

Es útil poder clasificar las alertas: múltiples categorías de alertas permiten respuestas proporcionales. La capacidad de establecer diferentes niveles de gravedad para diferentes alertas también es útil: puede presentar un ticket para investigar una tasa baja de errores que dura más de una hora, mientras que una tasa de error 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 experimentan la misma alta tasa de errores, puede alertar solo una vez sobre 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 activación (por ejemplo, un backend lento), no necesita alertar sobre las tasas de error de su servicio.

También debe poder asegurarse de que las alertas ya no se supriman una vez que finaliza el evento.

El nivel de control que necesita sobre su sistema determinará si utiliza un servicio de monitoreo de terceros o si implementa y ejecuta su propio sistema de monitoreo. Google desarrolló su propio sistema de monitoreo interno, pero hay muchos sistemas de monitoreo comerciales y de código abierto disponibles.

Fuentes de datos de seguimiento

Su elección de sistema (s) de monitoreo será informada por las fuentes específicas de datos de monitoreo que utilizará. Esta sección analiza dos fuentes comunes de datos de supervisión: registros y 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 medidas numéricas que representan atributos y eventos, generalmente recopilados a través de muchos puntos de datos a intervalos de tiempo regulares. Los registros son un registro de eventos que solo se adjunta. La discusión de este capítulo se centra en registros estructurados que permiten herramientas de consulta y agregación enriquecidas en lugar de registros de texto sin formato.

Los sistemas basados en registros de Google procesan grandes volúmenes de datos muy granulares. Existe un retraso inherente entre el momento en que ocurre un evento y el momento en que es visible en los registros. Para el análisis que no es urgente, estos registros se pueden procesar con un sistema por lotes, interrogar con consultas ad hoc y visualizar con paneles. Un ejemplo de este flujo de trabajo sería usar Cloud Dataflow para procesar registros, BigQuery para consultas ad hoc y Data Studio para los paneles.

Por el contrario, nuestro sistema de supervisión basado en métricas, que recopila una gran cantidad 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 existen excepciones, como los sistemas de registros en tiempo real o las métricas de alta cardinalidad.

Nuestras alertas y paneles de control 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 problemas muy rápidamente. Solemos 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 urgentes, a menudo generamos informes detallados utilizando sistemas de procesamiento de registros porque los registros casi siempre producirán datos más precisos que las métricas.

Si envía alertas basadas en métricas, podría ser tentador agregar más alertas basadas en registros, por ejemplo, si necesita que se le notifique cuando ocurre un solo evento excepcional. Seguimos recomendando alertas basadas en métricas en tales casos: puede incrementar una métrica de contador cuando ocurre un evento en particular y configurar una alerta basada en el valor de esa métrica. Esta estrategia mantiene toda la configuración de alertas en un solo lugar, lo que facilita su administración (consulte Administración de su sistema de monitoreo ).

Ejemplos de

Los siguientes ejemplos del mundo real ilustran cómo razonar a través del proceso de elegir entre sistemas de monitoreo.

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

Problema. El código de estado HTTP es una señal importante para que los clientes de App Engine depuren sus errores. Esta información estaba disponible en registros, pero no en métricas. El panel de métricas solo podía proporcionar una tasa 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 involucró:

  1. Observe el gráfico de error global para encontrar un momento en el que ocurrió un error.
  2. Lectura de archivos de registro para buscar líneas que contengan un error.
  3. Intentando correlacionar errores en el archivo de registro con el gráfico.

Las herramientas de registro no daban un sentido de escala, lo que dificultaba saber si un error visto en una línea de registro ocurría con frecuencia. Los registros también contenían muchas otras líneas irrelevantes, lo que dificultaba el rastreo de la causa raíz.

Solución propuesta. El equipo de desarrollo de App Engine eligió exportar el código de estado HTTP como una etiqueta en la métrica (p. Ej., requests_total{status=404}Versus requests_total{status=500}). Debido a que la cantidad de códigos de estado HTTP diferentes es relativamente limitada, esto no aumentó el volumen de datos métricos a un tamaño poco práctico, pero hizo que los datos más pertinentes estuvieran disponibles para gráficos y alertas.

Salir. Esta nueva etiqueta significó que el equipo podría actualizar los gráficos para mostrar líneas separadas para diferentes categorías y tipos de errores. Los clientes ahora pueden formular rápidamente conjeturas sobre posibles problemas basándose en los códigos de error expuestos. Ahora también podríamos establecer diferentes umbrales de alerta para errores de cliente y servidor, haciendo que las alertas se activen con mayor precisión.

Mejore tanto los registros como las métricas

Problema. El equipo de One Ads SRE mantuvo ~ 50 servicios, que se escribieron en varios lenguajes y marcos diferentes. El equipo utilizó registros como fuente canónica de la verdad para el cumplimiento de SLO. Para calcular el presupuesto de errores, cada servicio utilizó un script de procesamiento de registros con muchos casos especiales específicos del servicio. Aquí hay un script de ejemplo para procesar una entrada de registro para un solo servicio:

Si el código de estado HTTP estaba en el rango (500, 599)
Y se completa el campo 'ERROR DE SERVIDOR' del registro
Y la cookie DEBUG no se estableció como parte de la solicitud
Y la URL no contenía "/ informes"
Y el campo 'excepción' no contenía 'com.google.ads.PasswordException'
ENTONCES incremente el contador de errores en 1

Estos scripts eran difíciles de mantener y también usaban datos que no estaban disponibles para el sistema de monitoreo basado en métricas. Debido a que las métricas generaban alertas, a veces las alertas no se corresponderían con los errores que enfrenta el usuario. Cada alerta requería un paso de clasificación explícito para determinar si estaba de cara al usuario, lo que ralentizaba el tiempo de respuesta.

Solución propuesta. El equipo creó una biblioteca que se enganchó a la lógica de los lenguajes marco de cada aplicación. La biblioteca decidió si el error estaba afectando a los usuarios en el momento de la solicitud. La instrumentación escribió esta decisión en registros y la exportó 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 los 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 cambiaba las métricas de SLI, sobre las que el equipo podía alertar.

Salir. Al introducir una superficie de control uniforme en múltiples servicios, el equipo reutilizó las herramientas y la lógica de alerta en lugar de implementar múltiples 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 resultó 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 registros como fuente de datos

Problema. Al investigar los problemas de producción, un equipo de SRE a menudo miraba los ID de las entidades afectadas para determinar el impacto del usuario y la causa raíz. Al igual que con el ejemplo anterior de App Engine, esta investigación requirió datos que solo estaban disponibles en los registros. El equipo tuvo que realizar consultas de registro únicas para esto mientras respondían a los incidentes. Este paso agregó tiempo a la recuperación del incidente: unos minutos para armar correctamente la consulta, más el tiempo para consultar los registros.

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

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

Salir. El equipo ya no tenía la carga cognitiva de administrar la consulta de registro única correcta. En consecuencia, podrían obtener los resultados que necesitaban más rápido (aunque no tan rápido como un enfoque basado en métricas). También tenían un plan de respaldo: podían ejecutar el script automáticamente tan pronto como se activara una alerta y usar un pequeño servidor para consultar los registros a intervalos regulares para recuperar constantemente datos semifrescos.

Manejo de su sistema de monitoreo

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

Trate su 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 brindan algunos beneficios obvios: historial de cambios, enlaces de cambios específicos a su sistema de seguimiento de tareas, reversiones más fáciles y verificaciones de pelusa, 1 y procedimientos de revisión de código forzados.

Recomendamos encarecidamente también tratar la configuración de monitoreo como código (para obtener más información sobre la configuración, consulte Diseño de configuración y mejores prácticas ). Es preferible un sistema de supervisión que admita la configuración basada en la intención a los sistemas que solo 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 solo 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.

Fomentar la coherencia

Las grandes empresas con varios equipos de ingeniería que utilizan la supervisión deben lograr un equilibrio preciso: un enfoque centralizado proporciona coherencia, pero, por otro lado, los equipos individuales pueden desear 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 solo marco que se ejecuta de forma centralizada como un servicio. Esta solución nos funciona bien por varias razones. Un solo marco permite a los ingenieros aumentar más rápido cuando cambian de equipo y facilita la colaboración durante la depuración. También contamos con un servicio de panel de control centralizado, donde los paneles de control de cada equipo son visibles y accesibles. Si comprende fácilmente el panel de control de otro equipo, puede depurar tanto sus problemas como los de ellos más rápidamente.

Si es posible, haga que la cobertura de monitoreo básica sea sin esfuerzo. Si todos sus servicios 2 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 paneles. Este enfoque significa que cualquier componente nuevo que lance automáticamente tiene un monitoreo básico. Muchos equipos de su empresa, incluso equipos que no son de ingeniería, pueden usar estos datos de monitoreo.

Prefiero el acoplamiento suelto

Los requisitos comerciales cambian y su sistema de producción se verá diferente dentro de un año. De manera similar, su sistema de monitoreo debe evolucionar con el tiempo a medida que los servicios que monitorea evolucionan a través de diferentes patrones de falla.

Recomendamos mantener los componentes de su sistema de monitorización acoplados de forma flexible. Debe tener interfaces estables para configurar cada componente y pasar datos de monitoreo. Los componentes separados deben estar a cargo de recopilar, almacenar, alertar y visualizar su monitoreo. Las interfaces estables facilitan la sustitución de cualquier componente por una alternativa mejor.

Dividir la funcionalidad en componentes individuales se está volviendo popular en el mundo del código abierto. Hace una década, los sistemas de monitoreo como Zabbix combinaban todas las funciones en un solo componente. El diseño moderno generalmente implica separar la recopilación y la evaluación de reglas (con una solución como el servidor Prometheus ), el almacenamiento de series de tiempo a largo plazo ( InfluxDB ), la agregación de alertas ( Alertmanager ) y el panel de control ( Grafana ).

Al momento de escribir este artículo, existen al menos dos estándares abiertos populares para instrumentar su software y exponer métricas:

statsd

  • El demonio de agregación métrica escrito inicialmente por Etsy y ahora adaptado 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 ahora el formato Prometheus y se está estandarizando como OpenMetrics .

Un sistema de panel de control independiente que puede utilizar varias fuentes de datos proporciona una descripción general centralizada y unificada de su servicio. Google vio recientemente este beneficio en la práctica: nuestro sistema de monitoreo heredado (Borgmon 3 ) combinó paneles en la misma configuración que las reglas de alerta. Al migrar a un nuevo sistema ( Monarch ), decidimos mover el panel de control a un servicio separado ( Viceroy ). Debido a que Viceroy no era un componente de Borgmon o Monarch, Monarch tenía menos requisitos funcionales. Dado que los usuarios podían usar 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

Las alertas sobre SLO cubren 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 desea verificar cuando se activan las alertas basadas en SLO. Estas métricas deben aparecer de manera destacada en el panel de control de su servicio, idealmente en su página de destino.

Al investigar la causa de una infracción de SLO, lo más probable es que no obtenga suficiente información de los paneles de SLO. Estos paneles muestran que está infringiendo el SLO, pero no necesariamente por qué. ¿Qué otros datos deben mostrar los paneles de supervisión?

Hemos encontrado útiles las siguientes pautas para implementar métricas. Estas métricas deben proporcionar un monitoreo razonable que le permita investigar problemas de producción y también brindar una amplia gama de información sobre su servicio.

Cambios previstos

Al diagnosticar una alerta basada en SLO, debe poder pasar de las métricas de alerta que le notifican los problemas que afectan al usuario a las métricas que le dicen qué está causando estos problemas. Los cambios previstos recientes en su servicio pueden ser culpables. Agregue monitoreo que le informe de cualquier cambio en la producción. 4 Para determinar el disparador, recomendamos lo siguiente:

  • Supervise la versión del binario.
  • Supervise los indicadores de la línea de comandos, especialmente cuando utilice estos indicadores para habilitar y deshabilitar 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 partes del sistema no tiene una versión, debería poder monitorear la marca de tiempo en la que se compiló o empaquetó por última vez.

Cuando intenta correlacionar una interrupción con un lanzamiento, es mucho más fácil mirar un gráfico / tablero vinculado desde su alerta que rastrear a través de los registros del sistema CI / CD (integración continua / entrega continua) después del hecho.

Dependencias

Incluso si su servicio no cambió, cualquiera de sus dependencias podría cambiar o tener problemas, por lo que también debe monitorear las respuestas provenientes de dependencias directas.

Es razonable exportar el tamaño de la solicitud y la respuesta en bytes, latencia y códigos de respuesta para cada dependencia. Al elegir las métricas para graficar, tenga en cuenta las cuatro señales doradas . Puede usar etiquetas adicionales en las métricas para desglosarlas por código de respuesta, nombre del método RPC (llamada a procedimiento remoto) y nombre del trabajo del mismo nivel.

Idealmente, puede instrumentar la biblioteca cliente RPC de nivel inferior para exportar estas métricas una vez, en lugar de pedirle a cada biblioteca cliente RPC que las exporte. 5 La instrumentación de la biblioteca cliente proporciona más coherencia y le permite supervisar nuevas dependencias de forma gratuita.

A veces, se encontrará con dependencias que ofrecen una API muy estrecha, donde toda la funcionalidad está disponible a través de un solo RPC llamado Get , Query o algo igualmente inútil, y el comando real se especifica como argumentos para este RPC. Un solo punto de instrumentación en la biblioteca cliente se queda corto con este tipo de dependencia: observará una alta variación en la latencia y algún 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, tiene un par de opciones para monitorearla bien:

  • Exporte 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.
  • Solicite a los propietarios de dependencias que realicen una reescritura para exportar una API más amplia que admita la división de funciones separadas en métodos y servicios RPC separados.

Saturación

Apunta a monitorear y rastrear el uso de cada recurso en el que se basa el servicio. Algunos recursos tienen límites estrictos que no puede exceder, como la cuota de RAM, disco o CPU asignada a su aplicación. Es posible que otros recursos, como descriptores de archivos abiertos, subprocesos activos en cualquier grupo de subprocesos, tiempos de espera en las colas o el volumen de registros escritos, no tengan un límite estricto claro, pero aún así requieran administración.

Dependiendo del lenguaje de programación en uso, debe monitorear recursos adicionales:

  • En Java: el tamaño de la pila y el metaespacio , y métricas más específicas según el tipo de recolección de basura que esté usando
  • In Go: el número de goroutines

Los propios idiomas brindan soporte variable para rastrear estos recursos.

Además de alertar sobre eventos importantes como se describe en Alertas sobre SLO, es posible que también deba configurar alertas que se activen cuando se acerque al agotamiento de recursos específicos, como:

  • Cuando el recurso tiene un límite estricto
  • Cuando cruzar un umbral de uso provoca una degradación del rendimiento

Debe tener métricas de monitoreo para rastrear todos los recursos, incluso los recursos que el servicio administra bien. Estas métricas son vitales en la planificación de la capacidad y los recursos.

Estado del tráfico servido

Es una buena idea agregar métricas o etiquetas de métricas que permitan que los paneles desglosen el tráfico servido por código de estado (a menos que las métricas que usa su servicio para propósitos de SLI ya incluyan esta información). A continuación se ofrecen algunas recomendaciones:

  • Para el tráfico HTTP, supervise todos los códigos de respuesta, incluso si no proporcionan suficiente señal para alertar, porque algunos pueden activarse por un comportamiento incorrecto del cliente.
  • Si aplica límites de tasa o límites de cuota a sus usuarios, supervise los agregados de cuántas solicitudes se denegaron debido a la falta de cuota.

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

Implementación de métricas con propósito

Cada métrica expuesta debe tener un propósito. Resista la tentación de exportar un puñado de métricas solo porque son fáciles de generar. En su lugar, piense en cómo se utilizarán estas métricas. El diseño métrico, o la falta de él, tiene implicaciones.

Idealmente, los valores métricos utilizados para alertar cambian drásticamente solo cuando el sistema entra en un estado de problema y no cambian cuando un sistema está funcionando normalmente. Por otro lado, las métricas para la depuración no tienen estos requisitos; su objetivo es brindar información sobre lo que sucede cuando se activan las alertas. Las buenas métricas de depuración señalarán algún aspecto del sistema que potencialmente está causando los problemas. Cuando escriba una autopsia, piense qué métricas adicionales le habrían permitido diagnosticar el problema más rápido.

Prueba de la lógica de alerta

En un mundo ideal, el código de monitoreo y alerta debería estar sujeto a los mismos estándares de prueba que el desarrollo de código. Si bien los desarrolladores de Prometheus están discutiendo el desarrollo de pruebas unitarias para el monitoreo , actualmente no existe un sistema ampliamente adoptado que le permita hacer esto.

En Google, probamos nuestro monitoreo y alertas utilizando un lenguaje específico de dominio que nos permite crear series de tiempo sintéticas. Luego escribimos afirmaciones basadas en los valores en una serie de tiempo derivada, o el estado de activación y la presencia de etiquetas de alertas específicas.

El monitoreo y la alerta es a menudo un proceso de varias etapas, que por lo tanto requiere múltiples familias de pruebas unitarias. Si bien esta área permanece en gran parte subdesarrollada, si desea implementar las pruebas de monitoreo en algún momento, recomendamos un enfoque de tres niveles, como se muestra en la Figura 4-1 .

niveles de monitorización-prueba-entornoFigura 4-1. Supervisión de los niveles del entorno de prueba

  1. Informes binarios: compruebe que las variables métricas exportadas cambian de valor en determinadas condiciones como se esperaba.
  2. Configuraciones de monitoreo: asegúrese de que la evaluación de reglas produzca los resultados esperados y que las condiciones específicas produzcan las alertas esperadas.
  3. Configuraciones de alertas: prueba que las alertas generadas se enrutan a un destino predeterminado, según los valores de la etiqueta de alerta.

Si no puede probar su monitoreo a través de medios sintéticos, o hay una etapa de su monitoreo que simplemente no puede probar, considere la posibilidad de crear un sistema en ejecución que exporte métricas conocidas, como la cantidad de solicitudes y errores. Puede utilizar este sistema para validar alertas y series de tiempo derivadas. Es muy probable que sus reglas de alerta no se activen durante meses o años después de configurarlas, y debe tener la confianza de que cuando la métrica pase un cierto umbral, los ingenieros correctos recibirán alertas con notificaciones que tengan sentido.


Conclusión

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, es posible que los SRE no sepan 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 monitoreo que nos parezcan útiles y por qué, podamos ayudarlo a evaluar qué tan bien se ajusta su estrategia de monitoreo a sus necesidades, explorar algunas características adicionales que podría aprovechar y considerar los cambios que podría querer hacer. Probablemente le resulte útil combinar alguna fuente de métricas e iniciar sesión en su estrategia de supervisión; la combinación exacta que necesita depende en gran medida del contexto. Asegúrese de recopilar métricas que sirvan para un propósito particular. Ese propósito puede ser permitir una mejor planificación de la capacidad, ayudar en la depuración o notificarle directamente sobre problemas.

Una vez que haya implementado el monitoreo, debe ser visible y útil. Con este fin, también recomendamos probar su configuración de monitoreo. Un buen sistema de seguimiento paga dividendos. Vale la pena la inversión para pensar en profundidad en qué soluciones satisfacen mejor sus necesidades e iterar hasta que lo haga bien.

1 Por ejemplo, usar promtool para verificar que su configuración de Prometheus sea sintácticamente correcta.

2 Puede 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 .

3 Consulte el Capítulo 10 de Ingeniería de confiabilidad del sitio para conocer los conceptos y la estructura de Borgmon.

4 Este es un caso en el que el monitoreo a través de registros es atractivo, particularmente porque los cambios de producción son relativamente poco frecuentes. Ya sea que use registros o métricas, estos cambios deben aparecer en sus paneles para que sean fácilmente accesibles para depurar problemas de producción.

5 Consulte https://opencensus.io/ para ver un conjunto de bibliotecas que proporciona esto.

👉 SIGUIENTE
👈 ANTERIOR


Licencia: Publicado por O’Reilly Media, Inc. bajo licencia CC BY-NC-ND 4.0

Comparte tu opinión