SRE (Site Reliability Engineering) es un enfoque para garantizar la disponibilidad de proyectos web. Se considera un marco para DevOps y habla sobre cómo lograr el éxito en la aplicación de prácticas de DevOps. Traducción en este artículo. Capítulos 6 Monitoreo de sistemas distribuidos libros Ingeniería de confiabilidad del sitio de Google. Yo mismo preparé esta traducción y me basé en mi propia experiencia para comprender los procesos de seguimiento. En el canal de telegramas @monitorim_it и blog en medio También publiqué un enlace a la traducción del Capítulo 4 del mismo libro sobre objetivos de nivel de servicio.

Traducción por gato. ¡Disfruta leyendo!

Los equipos SRE de Google tienen principios básicos y mejores prácticas para crear sistemas exitosos de monitoreo y notificación. Este capítulo proporciona orientación sobre los problemas que puede encontrar un visitante de una página web y cómo resolver los problemas que dificultan la visualización de las páginas web.

definir

No existe un vocabulario único utilizado para discutir temas relacionados con el monitoreo. Incluso en Google, los términos siguientes no se utilizan habitualmente, pero enumeraremos las interpretaciones más comunes.

Monitoreo

Recopilación, procesamiento, agregación y visualización de datos cuantitativos en tiempo real sobre el sistema: número de solicitudes y tipos de solicitudes, número de errores y tipos de errores, tiempo de procesamiento de solicitudes y tiempo de actividad del servidor.

Monitoreo de caja blanca

Monitoreo basado en métricas mostradas por componentes internos del sistema, incluidos registros, métricas de perfiles de máquinas virtuales Java o métricas de controladores HTTP que generan estadísticas internas.

Monitoreo de caja negra

Probar el comportamiento de la aplicación desde el punto de vista del usuario.

Panel

Una interfaz (normalmente web) que proporciona una visión general de los indicadores clave de salud de los servicios. El tablero puede tener filtros, la capacidad de seleccionar los indicadores mostrados, etc. La interfaz está diseñada para identificar los indicadores que son más importantes para los usuarios. El panel también puede mostrar información para el personal de soporte técnico: una cola de solicitudes, una lista de errores de alta prioridad y un ingeniero asignado para un área de responsabilidad determinada.

Alerta (notificación)

Notificaciones destinadas a ser recibidas por una persona a través de correo electrónico u otros medios, que pueden desencadenarse por errores o un aumento en la cola de solicitudes. Las notificaciones se clasifican en: tickets, alertas por correo electrónico y mensajes de mensajería instantánea.

Causa principal

Un defecto de software o error humano que, una vez corregido, no debería volver a ocurrir. El problema puede tener varias causas principales: automatización insuficiente de los procesos, defecto del software, elaboración insuficiente de la lógica de la aplicación. Cada uno de estos factores puede ser la causa raíz y cada uno de ellos debe eliminarse.

Nodo y máquina (nodo y máquina)

Términos intercambiables para referirse a una única instancia de una aplicación en ejecución en un servidor físico, máquina virtual o contenedor. Una máquina puede albergar varios servicios. Los servicios pueden ser:

conectados entre sí: por ejemplo, un servidor de caché y un servidor web;
servicios no relacionados en una sola pieza de hardware: por ejemplo, un repositorio de código y un asistente para un sistema de configuración, como Marioneta o Chef.

Push

Cualquier cambio en la configuración del software.

¿Por qué es necesario el seguimiento?

Hay varias razones por las que es necesario monitorear las aplicaciones:

Análisis de tendencias a largo plazo.

¿Qué tamaño tiene la base de datos y a qué velocidad está creciendo? ¿Cómo cambia el número diario de usuarios?

Comparación de rendimiento

¿Las solicitudes son más rápidas en Acme Bucket of Bytes 2.72 en comparación con Ajax DB 3.14? ¿Cuánto mejor se almacenan en caché las solicitudes después de la aparición de un nodo adicional? ¿El sitio está funcionando más lento en comparación con la semana pasada?

Alertas (notificaciones)

Algo está roto y alguien necesita arreglarlo. O algo se romperá pronto y alguien tendrá que comprobarlo pronto.

Creando paneles

Los paneles deben responder preguntas básicas e incluir algo de "4 señales doradas" — retrasos (latencia), tráfico (tráfico), errores (errores) y tamaño de carga (saturación).

Realización de análisis retrospectivo (depuración)

El retraso en el procesamiento de solicitudes ha aumentado, pero ¿qué más sucedió al mismo tiempo?
Los sistemas de monitorización son útiles como fuente de datos para los sistemas de inteligencia empresarial y para facilitar el análisis de incidentes de seguridad. Debido a que este libro se centra en áreas de ingeniería en las que los SRE tienen experiencia, no discutiremos aquí las técnicas de monitoreo.

El monitoreo y las alertas permiten que el sistema le avise cuando se ha averiado o está a punto de averiarse. Cuando un sistema no puede repararse automáticamente, queremos que un humano analice la alerta, determine si el problema aún está activo, lo resuelva y determine la causa raíz. Si no audita los componentes del sistema, nunca recibirá una alerta simplemente porque "algo parece un poco extraño".

Cargar a una persona con notificaciones es un uso bastante costoso del tiempo de un empleado. Si el empleado está trabajando, la alerta interrumpe el proceso de trabajo. Si el empleado está en casa, la alerta interrumpe su tiempo personal y posiblemente el sueño. Cuando las alertas ocurren con demasiada frecuencia, los empleados las hojean, las posponen o ignoran las alertas entrantes. De vez en cuando ignoran la alerta real, que queda enmascarada por eventos de ruido. Las interrupciones del servicio pueden durar largos períodos de tiempo ya que los eventos de ruido impiden que el problema se diagnostique y corrija rápidamente. Los sistemas de alerta eficaces tienen una buena relación señal-ruido.

Establecer expectativas razonables para el sistema de seguimiento

Configurar el monitoreo para una aplicación compleja es una tarea de ingeniería compleja en sí misma. Incluso con una importante infraestructura de herramientas de recopilación, visualización y alertas, un equipo de Google SRE de 10 a 12 miembros normalmente incluye una o dos personas cuyo objetivo principal es crear y mantener sistemas de monitoreo. Este número ha disminuido con el tiempo a medida que consolidamos y centralizamos la infraestructura de monitoreo, pero cada equipo de SRE generalmente tiene al menos una persona dedicada exclusivamente al monitoreo. Tenemos que decir que, si bien los paneles del sistema de monitoreo son bastante interesantes de ver, los equipos de SRE evitan cuidadosamente situaciones que requieran que alguien mire una pantalla para monitorear los problemas.

En general, Google ha pasado a sistemas de seguimiento simples y rápidos con herramientas óptimas de análisis a posteriori. Evitamos sistemas "mágicos" que intentan predecir umbrales o detectar automáticamente la causa raíz. Los sensores que detectan contenido no deseado en las solicitudes de los usuarios finales son el único contraejemplo; Mientras estos sensores sigan siendo sencillos, podrán detectar rápidamente las causas de anomalías graves. Otros formatos para utilizar datos de seguimiento, como la planificación de capacidad o la previsión de tráfico, son más complejos. La observación durante un período de tiempo muy largo (meses o años) a una frecuencia de muestreo baja (horas o días) revelará una tendencia a largo plazo.

El equipo de Google SRE ha tenido un éxito desigual con jerarquías de dependencia complejas. Rara vez usamos reglas como "si descubro que la base de datos es lenta, recibo una alerta de que la base de datos es lenta; de lo contrario, recibo una alerta de que el sitio es lento". Las reglas basadas en dependencias generalmente se refieren a partes inmutables de nuestro sistema, como el sistema para filtrar el tráfico de usuarios al centro de datos. Por ejemplo, “si se configura el filtrado de tráfico al centro de datos, no me avise sobre retrasos en el procesamiento de las solicitudes de los usuarios” es una regla general para las alertas del centro de datos. Pocos equipos en Google admiten jerarquías de dependencia complejas porque nuestra infraestructura tiene una tasa constante de refactorización continua.

Algunas de las ideas descritas en este capítulo siguen siendo relevantes: siempre existe la oportunidad de pasar más rápido del síntoma a la causa raíz, especialmente en sistemas en constante cambio. Por lo tanto, si bien este capítulo describe algunos objetivos para los sistemas de monitoreo y cómo lograrlos, es importante que los sistemas de monitoreo sean simples y comprensibles para todos los miembros del equipo.

Del mismo modo, para mantener los niveles de ruido bajos y los niveles de señal altos, los enfoques para monitorear los activos alertados deben ser muy simples y confiables. Las reglas que generan advertencias para las personas deben ser fáciles de entender y presentar un problema claro.

Síntomas versus causas

Su sistema de seguimiento debe responder dos preguntas: “qué se rompió” y “por qué se rompió”.
“Lo que se rompió” habla del síntoma y “por qué se rompió” habla de la causa. La siguiente tabla muestra ejemplos de tales conexiones.

Síntoma
Razón

Obteniendo el error HTTP 500 o 404
Los servidores de bases de datos rechazan conexiones

Respuestas lentas del servidor
Alta utilización de la CPU o cable Ethernet dañado

Los usuarios de la Antártida no reciben GIF de gatos
Su CDN odia a los científicos y a los gatos, por lo que algunas direcciones IP terminaron en la lista negra

El contenido privado está disponible en todas partes
El lanzamiento de una nueva versión de software hizo que el firewall olvidara todas las ACL y permitiera que todos

"Qué" y "por qué" son algunos de los elementos más importantes para crear un buen sistema de monitoreo con máxima señal y mínimo ruido.

Caja negra versus caja blanca

Combinamos un extenso monitoreo de caja blanca con un modesto monitoreo de caja negra para métricas críticas. La forma más sencilla de comparar Black-box con White-box es que Black-box se centra en los síntomas y realiza un seguimiento reactivo en lugar de proactivo: "el sistema no está funcionando correctamente en este momento". La caja blanca depende de las capacidades de verificación interna de los sistemas: registros de eventos o servidores web. Así, White-box permite detectar problemas inminentes, fallos que parecen ser una retransmisión de una solicitud, etc.

Tenga en cuenta que en un sistema de múltiples capas, un síntoma en el área de responsabilidad de un ingeniero es un síntoma en el área de responsabilidad de otro ingeniero. Por ejemplo, el rendimiento de la base de datos ha disminuido. Las lecturas lentas de la base de datos son un síntoma del SRE de la base de datos que las detecta. Sin embargo, para un SRE front-end que observa un sitio web lento, la causa de la misma lectura lenta de la base de datos es una base de datos lenta. Por lo tanto, la monitorización de caja blanca a veces se centra en los síntomas y otras veces en la causa, dependiendo de su extensión.

Al recopilar telemetría para la depuración, se requiere monitoreo de caja blanca. Si los servidores web tardan en responder a las consultas de la base de datos, necesita saber qué tan rápido se comunica el servidor web con la base de datos y qué tan rápido responde. De lo contrario, no podrá diferenciar entre un servidor de base de datos lento y un problema de red entre el servidor web y la base de datos.

El monitoreo de caja negra tiene una ventaja clave al enviar alertas: activa la notificación al destinatario cuando el problema ya ha provocado síntomas reales. Por otro lado, la monitorización es inútil ante un problema de Black-box que aún no ha surgido pero que es inminente.

Cuatro señales doradas

Las cuatro señales de oro del monitoreo son latencia, tráfico, errores y saturación. Si sólo puedes medir cuatro métricas del sistema de usuario, concéntrate en esas cuatro.

Retrasado

El tiempo necesario para procesar la solicitud. Es importante distinguir entre la latencia de solicitudes exitosas y no exitosas. Por ejemplo, un error HTTP 500 causado por una pérdida de conexión a una base de datos u otro servidor se puede diagnosticar muy rápidamente; sin embargo, un error HTTP 500 puede indicar una solicitud fallida. Determinar el impacto de un error 500 en la latencia general puede llevar a conclusiones erróneas. Por otro lado, ¡un error lento es incluso un error rápido! Por lo tanto, es importante monitorear la latencia de los errores en lugar de simplemente filtrarlos.

Трафик

La cantidad de solicitudes a su sistema se mide en métricas del sistema de alto nivel. Para un servicio web, esta medida normalmente representa la cantidad de solicitudes HTTP por segundo, dividida por la naturaleza de las solicitudes (por ejemplo, contenido estático o dinámico). Para un sistema de transmisión de audio, esta medición puede centrarse en la velocidad de E/S de la red o el número de sesiones simultáneas. Para un sistema de almacenamiento de valores-clave, esta medida podría ser transacciones o resultados de búsqueda por segundo.

Errores

Esta es la tasa de solicitudes fallidas que son explícitas (por ejemplo, HTTP 500), implícitas (por ejemplo, HTTP 200 pero combinadas con contenido no válido) o políticas (por ejemplo, "Si capturó una respuesta en un segundo, cualquier segundo es un error"). Si los códigos de respuesta HTTP no son suficientes para expresar todas las condiciones de falla, es posible que se requieran protocolos secundarios (internos) para detectar fallas parciales. Es posible que monitorear todas estas solicitudes fallidas no sea informativo, mientras que las pruebas del sistema de un extremo a otro ayudarán a detectar que está procesando contenido incorrecto.

saturación

La métrica muestra la intensidad con la que se utiliza su servicio. Esta es una medida de monitoreo del sistema que identifica los recursos que están más restringidos (por ejemplo, en un sistema con memoria restringida, muestra la memoria, en un sistema con E/S restringidas, muestra el número de E/S). Tenga en cuenta que muchos sistemas degradan el rendimiento antes de alcanzar el 100 % de utilización, por lo que es importante tener un objetivo de utilización.

En sistemas complejos, la saturación se puede complementar con mediciones de carga de nivel superior: ¿puede su servicio manejar adecuadamente el doble de tráfico, manejar solo un 10 % más de tráfico o incluso menos tráfico que el que maneja actualmente? Para servicios simples que no tienen parámetros que cambien la complejidad de la solicitud (por ejemplo, "No me des nada" o "Necesito un entero monótono único"), que rara vez cambian la configuración, un valor de prueba de carga estática puede ser adecuado. Sin embargo, como se analizó en el párrafo anterior, la mayoría de los servicios deben utilizar señales indirectas, como la utilización de la CPU o el ancho de banda de la red, que tienen un límite superior conocido. El aumento de la latencia suele ser un indicador importante de saturación. Medir el tiempo de respuesta del percentil 99 en una ventana pequeña (por ejemplo, un minuto) puede proporcionar una señal de saturación muy temprana.

Finalmente, la saturación también se asocia con predicciones sobre una saturación inminente, por ejemplo: "Parece que su base de datos llenará su disco duro en 4 horas".

Si mides las cuatro señales doradas y cuando hay un problema con una de las métricas (o, en el caso de saturación, un problema cercano), alertas a una persona, tu servicio estará más o menos cubierto por el monitoreo.

Preocupaciones por la "cola" (o la instrumentación y el rendimiento)

Al crear un sistema de monitoreo desde cero, existe la tentación de desarrollar un sistema basado en valores promedio: latencia promedio, utilización promedio de CPU de los nodos o plenitud promedio de la base de datos. El peligro de los dos últimos ejemplos es obvio: los procesadores y las bases de datos se eliminan de una manera muy impredecible. Lo mismo se aplica al retraso. Si ejecuta un servicio web con una latencia promedio de 100 ms con 1000 solicitudes por segundo, el 1 % de las solicitudes pueden tardar 5 segundos. Si los usuarios dependen de varios servicios web de este tipo, el percentil 99 de un backend puede convertirse fácilmente en el tiempo de respuesta medio del frontend.

La forma más sencilla de diferenciar entre el promedio lento y la cola muy lenta de solicitudes es recopilar mediciones de las solicitudes expresadas en estadísticas (una buena herramienta para mostrar son los histogramas) en lugar de latencias reales: cuántas solicitudes atendió el servicio que tardaron entre 0 ms. y 10 ms, entre 10 ms y 30 ms, entre 30 ms y 100 ms, entre 100 ms y 300 ms, etc. Ampliar los límites del histograma aproximadamente exponencialmente (por un factor aproximado de 3) es a menudo una forma sencilla de visualizar la distribución. de solicitudes.

Seleccionar el nivel de detalle apropiado para las mediciones

Se deben medir diferentes elementos del sistema con diferentes niveles de detalle. Por ejemplo:

Monitorear la utilización de la CPU durante un período de tiempo no mostrará picos a largo plazo que generen latencias altas.
Por otro lado, para un servicio web que no tiene como objetivo más de 9 horas de inactividad por año (99,9% de tiempo de actividad anual), es probable que verificar una respuesta HTTP 200 más de una o dos veces por minuto sea innecesariamente frecuente.
Del mismo modo, probablemente no sea necesario comprobar la disponibilidad del 99,9% del espacio en el disco duro más de una vez cada 1 o 2 minutos.

Tenga cuidado al estructurar la granularidad de sus mediciones. Recopilar la carga de la CPU una vez por segundo puede proporcionar datos interesantes, pero mediciones tan frecuentes pueden resultar muy costosas de recopilar, almacenar y analizar. Si su objetivo de monitoreo requiere una alta granularidad y no requiere una alta capacidad de respuesta, puede reducir estos costos configurando la recopilación de métricas en el servidor y luego configurando un sistema externo para recopilar y agregar esas métricas. Podrías:

Mida la carga de la CPU cada segundo.
Reducir el detalle al 5%.
Agregue métricas cada minuto.

Esta estrategia le permitirá recopilar datos con una alta granularidad sin incurrir en una gran sobrecarga de análisis y almacenamiento.

Uniendo los principios

Los principios analizados en este capítulo se pueden combinar en una filosofía de monitoreo y alertas respaldada y seguida por los equipos de SRE de Google. Es deseable adherirse a esta filosofía de monitoreo, es un buen punto de partida para crear o revisar su metodología de alerta y puede ayudarlo a formular las preguntas correctas sobre su función de operaciones, independientemente del tamaño de su organización o la complejidad del servicio o sistema.

Al crear reglas de monitoreo y alertas, hacer las siguientes preguntas puede ayudarlo a evitar falsos positivos y alertas innecesarias:

¿Esta regla detecta un estado del sistema que de otro modo sería indetectable y que es urgente, llama a la acción y afecta inevitablemente al usuario?
¿Puedo ignorar esta advertencia sabiendo que es benigna? ¿Cuándo y por qué puedo ignorar esta advertencia y cómo puedo evitar este escenario?
¿Esta alerta significa que los usuarios se están viendo afectados negativamente? ¿Existen situaciones en las que los usuarios no se ven afectados negativamente, como a través del filtrado de tráfico o cuando se utilizan sistemas de prueba para los cuales se deben filtrar las alertas?
¿Puedo tomar medidas en respuesta a esta alerta? ¿Son urgentes estas medidas o pueden esperar hasta mañana? ¿Se puede automatizar una acción de forma segura? ¿Será esta acción una solución a largo plazo o una solución alternativa a corto plazo?
Algunas personas reciben varias alertas por este problema, entonces, ¿hay alguna manera de reducir la cantidad de alertas?

Estas preguntas reflejan la filosofía fundamental sobre alertas y sistemas de alerta:

Cada vez que llega una alerta, tengo que reaccionar de inmediato. Puedo reaccionar con urgencia varias veces al día antes de cansarme.
Cada alerta debe ser relevante.
Cada respuesta a una alerta debe requerir intervención humana. Si la notificación se puede procesar automáticamente, no debería llegar.
Las alertas deben ser sobre un nuevo problema o evento que no existía antes.

Este enfoque desdibuja ciertas distinciones: si la alerta satisface las cuatro condiciones anteriores, no importa si la alerta se envía desde un sistema de seguimiento de caja blanca o de caja negra. Este enfoque también refuerza ciertas diferencias: es mejor dedicar mucho más esfuerzo a identificar los síntomas que a las causas; cuando se trata de causas, sólo debes preocuparte por las causas inevitables.

Monitoreo a largo plazo

En los entornos de productividad actuales, los sistemas de monitoreo monitorean un sistema de producción en constante evolución con arquitectura de software, características de carga de trabajo y objetivos de rendimiento cambiantes. Las alertas que actualmente son difíciles de automatizar pueden convertirse en algo común y tal vez incluso valga la pena abordarlas. En este punto, alguien debe encontrar y eliminar las causas fundamentales del problema; si dicha resolución no es posible, la respuesta a la alerta requiere una automatización total.

Es importante que las decisiones de seguimiento se tomen teniendo en mente objetivos a largo plazo. Cada alerta que se ejecuta hoy distrae a una persona de mejorar el sistema mañana, por lo que a menudo hay una reducción en la disponibilidad o el rendimiento de un sistema productivo durante el tiempo necesario para mejorar el sistema de monitoreo a largo plazo. Veamos dos ejemplos para ilustrar este fenómeno.

Bigtable SRE: una historia de alerta excesiva

La infraestructura interna de Google normalmente se aprovisiona y se mide según un nivel de servicio (SLO). Hace muchos años, el servicio SLO de Bigtable se basaba en el rendimiento promedio de una transacción sintética que simulaba un cliente real. Debido a problemas en Bigtable y niveles más bajos de la pila de almacenamiento, el rendimiento promedio fue impulsado por una "gran" cola: el peor 5% de las consultas fueron a menudo significativamente más lentas que el resto.

Se enviaron notificaciones por correo electrónico cuando se acercó al umbral de SLO y se enviaron alertas de mensajería cuando se superó el SLO. Ambos tipos de alertas se enviaban con bastante frecuencia, lo que consumía cantidades inaceptables de tiempo de ingeniería: el equipo dedicó una cantidad significativa de tiempo a clasificar las alertas para encontrar las pocas que eran realmente relevantes. A menudo nos perdimos un problema que realmente afectaba a los usuarios porque solo algunas de las alertas eran para ese problema específico. Muchas de las alertas no eran urgentes debido a problemas comprensibles en la infraestructura y se procesaron de forma estándar o no se procesaron en absoluto.

Para remediar la situación, el equipo adoptó un enfoque triple: mientras trabajamos arduamente para mejorar el rendimiento de Bigtable, establecimos temporalmente nuestro objetivo de SLO en el percentil 75 para la latencia de respuesta a consultas. También desactivamos las alertas por correo electrónico porque había tantas que era imposible dedicar tiempo a diagnosticarlas.

Esta estrategia nos dio un respiro para comenzar a solucionar problemas a largo plazo en Bigtable y niveles inferiores de la pila de almacenamiento, en lugar de solucionar problemas tácticos constantemente. De hecho, los ingenieros podían realizar su trabajo sin ser bombardeados con alertas todo el tiempo. En última instancia, posponer temporalmente el procesamiento de alertas nos permitió mejorar la calidad de nuestro servicio.

Gmail: respuestas humanas algorítmicas y predecibles

En sus inicios, Gmail se basó en un sistema de gestión de procesos Workqueue modificado que fue diseñado para procesar por lotes fragmentos de un índice de búsqueda. Workqueue se adaptó a procesos de larga duración y posteriormente se aplicó a Gmail, pero algunos errores en el código opaco del programador resultaron muy difíciles de solucionar.

En ese momento, el monitoreo de Gmail estaba estructurado para que se activaran alertas cuando se cancelaran tareas individuales usando Workqueue. Este enfoque no era ideal, porque incluso en ese momento Gmail realizaba miles de tareas, cada una de las cuales era proporcionada a una fracción del porcentaje de nuestros usuarios. Estábamos muy preocupados por brindarles a los usuarios de Gmail una buena experiencia de usuario, pero manejar tantas alertas estaba fuera de nuestro alcance.

Para solucionar este problema, Gmail SRE creó una herramienta para ayudar a depurar el programador lo mejor posible para minimizar el impacto en los usuarios. El equipo tuvo algunas discusiones sobre si simplemente automatizar todo el ciclo desde el descubrimiento del problema hasta la solución hasta que se encontrara una solución a largo plazo, pero a algunos les preocupaba que dicha solución retrasara la solución del problema.

Esta tensión era común en el equipo y a menudo reflejaba una falta de confianza en la autodisciplina: mientras algunos miembros del equipo quieren dar tiempo para la solución correcta, a otros les preocupa que la solución final se olvide y la solución temporal demore una eternidad. Esta cuestión merece atención porque es demasiado fácil solucionar problemas temporalmente en lugar de hacer que la situación sea permanente. Los gerentes y el personal técnico desempeñan un papel clave en la implementación de soluciones a largo plazo, apoyando y priorizando soluciones potencialmente a largo plazo incluso después de que el "dolor" inicial disminuya.

Las alertas regulares y repetitivas y las respuestas algorítmicas deberían ser una señal de alerta. La renuencia de su equipo a automatizar estas alertas significa que el equipo no confía en poder confiar en los algoritmos. Éste es un problema grave que debe abordarse.

A largo plazo

Un tema común vincula los ejemplos de Bigtable y Gmail: la competencia entre la disponibilidad a corto y largo plazo. A menudo, un gran esfuerzo puede ayudar a un sistema frágil a lograr una alta disponibilidad, pero este camino suele ser de corta duración, plagado de agotamiento del equipo y dependencia de un pequeño número de miembros de ese mismo equipo heroico.

La reducción controlada y a corto plazo de la disponibilidad suele ser dolorosa, pero estratégicamente importante para la estabilidad a largo plazo del sistema. Es importante no analizar cada alerta de forma aislada, sino considerar si el nivel general del volumen de alerta conduce a un sistema saludable y adecuadamente accesible con un equipo viable y un pronóstico favorable. Analizamos las estadísticas de frecuencia de alertas (generalmente expresadas como incidentes por turno, donde un incidente puede consistir en múltiples incidentes relacionados) en informes trimestrales para la gerencia, lo que permite a los tomadores de decisiones tener una visión continua de la carga del sistema de alerta y el estado general del equipo.

Conclusión

El camino hacia un seguimiento y alerta saludables es simple y claro. Se centra en los síntomas del problema que activan las alertas y el seguimiento de la causa sirve como ayuda para depurar los problemas. Monitorear los síntomas es más fácil cuanto más alto esté en la pila que controla, aunque el monitoreo de la carga y el rendimiento de la base de datos debe realizarse directamente en la base de datos misma. Las notificaciones por correo electrónico tienen una utilidad muy limitada y tienden a convertirse fácilmente en ruido; en su lugar, debe utilizar un panel que supervise todos los problemas actuales que activan alertas por correo electrónico. El panel también se puede combinar con un registro de eventos para analizar correlaciones históricas.

A largo plazo, es necesario lograr una exitosa rotación de alertas sobre síntomas y problemas reales inminentes, adaptando los objetivos para garantizar que la monitorización apoye un diagnóstico rápido.

Gracias por leer la traducción hasta el final. Suscríbete a mi canal de Telegram sobre monitoreo. @monitorim_it и blog en medio.

Fuente: habr.com

Supervisión de sistemas distribuidos - Google Experience (traducción del capítulo del libro Google SRE)