Capítulo 6 - Supervisión de sistemas distribuidos
Supervisión de sistemas distribuidos Los equipos de SRE de Google cuentan con algunos principios básicos y prácticas recomendadas para crear sistemas de monitoreo y alerta exitosos. Este capítulo ofrece pautas sobre qué problemas deben interrumpir a un humano a través de una página y cómo tratar los problemas que no son lo suficientemente graves como para activar una página.
¿Por qué monitorear?
◼Análisis de tendencias a largo plazo
◼Comparación a lo largo del tiempo o grupos de experimentos
◼Alertando
◼Creación de paneles
◼Realización de análisis retrospectivos ad hoc (es decir, depuración)
Síntomas versus causas
Su sistema de monitoreo debe responder a dos preguntas:¿quéfallayporqué?
El "lo que está roto" indica el síntoma; el "por qué" indica una causa (posiblemente intermedia). La tabla 6-1 enumera algunos síntomas hipotéticos y lascausascorrespondientes.
Síntomas versus causas
Caja negra versus caja blanca
La forma más sencilla de pensar en el monitoreo de caja negra versus el monitoreo de caja blanca es que el monitoreo de caja negra está orientado a los síntomas y representa problemas activos, no previstos: "El sistema no está funcionando correctamente en este momento".
El monitoreo de caja blanca depende de la capacidad de inspeccionar las entrañas del sistema, como registros o puntos finales HTTP, con instrumentación. Por lo tanto, el monitoreo de caja blanca permite la detección de problemas inminentes, fallas enmascaradas por reintentos, etc.
Las cuatro señales doradas
Las cuatro señales doradas del monitoreo son la latencia, el tráfico, los errores y la saturación.Si solo puede medir cuatro métricas de su sistema orientadoalusuario,concéntreseenestascuatro.
◼Latencia ◼Tráfico
◼Errores
◼Saturación
Elección de una resolución adecuada para las mediciones
Los diferentes aspectos de un sistema deben medirse con diferentes niveles de granularidad. Por ejemplo:
◼ La observación de la carga de la CPU durante el lapso de tiempo de un minuto no revelará ni siquiera los picos de larga duración que generan latencias de cola altas.
◼ Por otro lado, para un servicio web que tiene como objetivo no más de 9 horas de tiempo de inactividad agregado por año (99,9 % de tiempo de actividad anual), buscar un estado 200 (éxito) más de una o dos veces por minuto probablemente sea innecesariamente frecuente.
◼ Del mismo modo, es probable que no sea necesario comprobar si el disco duro está lleno para un servicio con una disponibilidad del 99,9 % más de una vez cada 1 o 2 minutos.
Tan simple como sea posible, no más simple
La acumulación de todos estos requisitos uno encima del otro puede sumarse a un sistema de monitoreo muy complejo: su sistema podría terminar con los siguientes niveles de complejidad:
◼ Alertas en diferentes umbrales de latencia, en diferentes percentiles, en todo tipo de métricas diferentes
◼ Código extra para detectar y exponer posibles causas
◼ Paneles asociados para cada una de estas posibles causas
Tan simple como sea posible, no más simple
Las fuentes de complejidad potencial son interminables. Como todos los sistemas de software, el monitoreo puede volverse tan complejo que es frágil, complicado de cambiar y una carga de mantenimiento.
Por lo tanto, diseñe su sistema de monitoreo pensando en la simplicidad. Al elegir qué monitorear, tenga en cuenta las siguientes pautas:
◼ Las reglas que detectan incidentes reales con mayor frecuencia deben ser lo más simples, predecibles y confiables posible.
◼ La recopilación de datos, la agregación y la configuración de alertas que rara vez se realizan (por ejemplo, menos de una vez por trimestre para algunos equipos de SRE) deberían estar listas para su eliminación.
◼ Las señales que se recopilan, pero que no se exponen en ningún panel preconfigurado ni se utilizan en ninguna alerta, son candidatas para su eliminación.
◼https://sre.google/books/
◼https://sre.google/sre-book/monitoring-distri buted-systems/
◼https://sre.google/sre-book/monitoring-distri buted-systems/#xref_monitoring_golden-sig nals
◼https://sre.google/sre-book/service-level-obj