En la primera publicación de esta serie, cubrimos la idea general y las ventajas de la observabilidad basada en modelos con Juju. En la segunda publicación, analizamos la topología de Juju y sus ventajas en términos de estabilidad de entidad y continuidad métrica. En esta publicación discutiremos cómo la topología juju Agrupación y gestión de notificaciones, ayuda Prevenir tormentas de alarma, y cómo esto se relaciona con las prácticas de SRE.
Tabla de Contenidos
El ejemplo corriente
En el resto de esta publicación, usaremos el siguiente ejemplo:
En el ejemplo anterior, la relación de «monitorización» entre Prometheus y el clúster de Cassandra hace que Prometheus elimine el punto final métrico proporcionado por los nodos de Cassandra. El encanto Cassandra k8s, junto con un encanto Prometheus, configura automáticamente el exportador Cassandra de Instaclustr en todos los nodos del clúster a través de la relación «monitor», y Prometheus transfiere los puntos finales métricos resultantes sin la intervención manual del administrador de Juju el establecimiento del » relación de supervisión «. (Nos referimos a este tipo de experiencia de usuario mágica como «bajo esfuerzo» en la observabilidad basada en modelos).
¿Qué son las “tormentas de alarma” y cómo surgen?
El software falla inevitablemente, y cuando lo haga (o idealmente algún tiempo antes), su pila de observabilidad lo alertará. Pero los errores se propagan en cascada a través de los sistemas, y una causa raíz eventualmente conduce a muchos síntomas en varios sistemas relacionados y, como tal, se generan muchas alertas. Si las alertas en su buscapersonas son numerosas y siguen apareciendo, tiene una tormenta de alarma. Coloquialmente un Tormenta de alarma es el fenómeno que se produce cuando se activan varias alertas vinculadas en rápida sucesión. A menudo, estas advertencias tienen una causa común o, al menos, están estrechamente relacionadas. Ejemplo: Imagine que un clúster de Cassandra falla y que solo activa una o más advertencias al monitorear el clúster y es muy probable que genere advertencias a partir de las aplicaciones que dependen de ese clúster. Aplicaciones que se basan en el clúster de Cassandra, y antes de que se dé cuenta todo parece que se va a quemar y resulta difícil encontrar un punto de partida para solucionar el problema.
Las tormentas de advertencia tienen efectos graves a corto y largo plazo para los equipos que se enfrentan a ellos. En el corto plazo, un buscapersonas que se dispara continuamente lo distraerá mientras combate un incendio, y se siente como si alguien lo estuviera haciendo. Verter gasolina en una fogata. Entonces esta eso sobrecarga cognitiva No es trivial decidir qué incendio apagar primero, tratar de distinguir la causa del efecto y tomar decisiones bajo presión. Los equipos se desarrollan a largo plazo cansancio al despertar: Cuantas más advertencias esté expuesto a lo largo del tiempo y menos significativa será cada una de estas advertencias («Sí, yo ya saben ¡el grupo está tapiada! ”), es menos probable que los operadores salten rápidamente a la extinción de incendios (“ De todos modos, la cosa se toma prestada con más frecuencia ”). Con el tiempo, los problemas se subestiman o se pasan por alto por completo. Más allá del colapso de la disponibilidad operativa, la fatiga de las alarmas tiene graves efectos personales en los afectados.
Al hablar con cientos de profesionales en los últimos años, primero como expertos en rendimiento y defensores de la gestión del rendimiento de aplicaciones (APM) y más recientemente como gerente de producto de una solución APM moderna, he visto una amplia evidencia de que la naturaleza cada vez más distribuida de los sistemas de producción ha provocado un aumento progresivo pero significativo en el número y la gravedad de las tormentas de alarmas entre los equipos, en gran medida independientemente del software que utilicen (o de su criticidad). Afortunadamente, esto es algo que el trabajo en curso en torno a la observabilidad basada en modelos puede manejar con Juju. Como comentamos anteriormente, las tormentas de alarma surgen de:
- Se generan varias alertas redundantes del mismo subsistema (por ejemplo, un clúster de Cassandra) por la misma causa.
- Problemas que se propagan “aguas arriba” de los sistemas con problemas a los sistemas que dependen de ellos.
En la siguiente sección discutimos cómo abordar fácilmente la topología juju (1). El punto (2) se analiza en la sección “La perspectiva a largo plazo de la alerta y el juju”.
Administre alertas basadas en la topología de Juju
En la publicación anterior de esta serie, presentamos el concepto de «Topología de Juju» cómo «identificar claramente[ing] un software que se ejecuta en todas las implementaciones administradas por Juju“Y use estos metadatos para anotar la telemetría. Hemos discutido cómo anotar la topología juju con Prometheus, pero el mismo concepto se aplica a todos los demás tipos de telemetría, incluidos los protocolos y, como veremos en el resto de esta publicación, Advertencias.
Grupos de notificación
Alertmanager tiene un agrupamiento Función que, correctamente configurada, permite a los equipos de emergencia evitar tormentas de alarma o al menos reducirlas en gran medida. Los grupos en el administrador de alertas son una forma de «evitar enviar constantemente notificaciones diferentes para alertas similares». Observe cuánto trabajo hace la palabra «similar» en esta oración: La clave para evitar una tormenta de alarmas con notificaciones que mantienen su buscapersonas apagado está activada. Definición efectiva de similitud para alertas.
Fuera de la caja, la topología juju nos da una definición general viable de Similitud para las alertas: dos alertas son similares si se refieren al mismo sistema. Si bien puede parecer simple al principio, agrupar las alertas según el sistema que las causó es en realidad un método probado para contener o mitigar las tormentas de advertencia y proporcionar una vista de pájaro de qué sistemas están fallando.
La imagen de arriba muestra alertas en el Administrador de alertas agrupadas según la topología de Juju del sistema desde el cual se originaron. Esto se logra mediante el uso de etiquetas de topología Juju en la configuración group_by de una ruta de administrador de alertas. Las rutas en el administrador de alertas son esencialmente un árbol de decisiones sobre qué hacer con una alerta entrante en el sistema. (La charla «La vida de una alerta» de Stuart Nelson es realmente excelente para explicar cómo las alertas son procesadas por Alertmanager). Para agrupar alertas según la topología de Juju, todo lo que necesita hacer es tener la siguiente ruta raíz:
route:
group_by:
- juju_application
- juju_model
- juju_model_uuidVale la pena señalar que a pesar de la topología juju, que también incluye la etiqueta «juju_unit», no se usa para agrupar. Por el contrario, es más práctico agrupar las advertencias según el uso del juju en lugar de las unidades individuales. Los problemas con las aplicaciones agrupadas, que constituyen la mayoría de las aplicaciones de unidades múltiples de Charmed, suelen estar correlacionados. Por ejemplo, debido a problemas en la cimentación o la infraestructura circundante.
Por supuesto, hay mucho más en una configuración lista para producción de Alertmanager que solo una ruta, como rutas adicionales para refinar aún más qué alerta se informa y dónde (correo electrónico o webhook o sistema de localizador SaaS), pero esta primera pieza es todo lo que es. toma para reducir considerablemente las tormentas de alarma en la infraestructura que administra Juju!
Cesa la alarma
Además de agrupar las notificaciones, el gestor de alertas dispone de otra función denominada Silencios, con la que podrás silenciar la activación de nuevas notificaciones por un breve tiempo. El silencio está diseñado para evitar distracciones al solucionar problemas conocidos o durante las ventanas de mantenimiento. Las reglas de silenciamiento se dan como comparadores en las etiquetas de alerta, por lo que es bastante fácil evitar nuevas alertas de una aplicación problemática con algo como esto:
La perspectiva a largo plazo de la alerta y el juju
Como se mencionó, muchos tipos de problemas se distribuyen entre los sistemas a través de la dependencia: una carga aumentada en un servidor web puede sobrecargar una base de datos, y si esa base de datos es compartida por otras aplicaciones, estas a su vez pueden causar problemas en forma de latencia aumentada. .
La naturaleza declarativa del juju y el modelo de dependencia explícito inherente a las relaciones juju nos brindan los ingredientes correctos para modelar cómo se propagan las advertencias a través de los diferentes componentes de un sistema. Las relaciones de Juju son semánticamente en la naturaleza: un amuleto describe lo que necesita de un Interfaz de relación como «cql» (para: «Quiero un clúster con el que pueda hablar el lenguaje de consulta Cassandra») y la intención está en Nombre de la relaciónB. «Base de datos de usuarios». He estado pensando en cómo usar la información codificada en las relaciones de juju para definir reglas de agrupamiento o posiblemente de bloqueo en Alertmanager para que las advertencias entre dependencias se agrupen según la probabilidad de que estén correlacionadas. Este tipo de alerta orientada a la topología se encuentra a veces en herramientas APM comerciales, que generalmente se basan en la telemetría de seguimiento distribuida (¡que también me gustaría llevar a la observabilidad basada en modelos en el futuro!).
Que sigue
Con la Agrupación de alertas, estamos comenzando a aprovechar las ventajas operativas de la topología Juju para la observabilidad, pero mucho más está por venir. Las siguientes partes de esta serie cubren los siguientes temas:
- Los beneficios de la topología Juju para los paneles de Grafana
- Puede agrupar reglas de alarma con sus encantos y hacer que Prometheus las evalúe automáticamente
- Cómo combinar paneles de Grafana con sus encantos y dejar que los administradores de Juju los importen a sus Grafanas con una relación de Juju
Mientras tanto, puede comenzar a encantar sus aplicaciones que se ejecutan en Kubernetes. Además, consulte los diferentes amuletos disponibles hoy para una amplia variedad de usos.
Además, Canonical se asoció recientemente con reconocidos expertos de AWS, Google, Cloudbees y otros para analizar los resultados de una encuesta completa realizada a más de 1200 participantes de KubeCon. El detallado informe resultante sobre el uso de tecnologías nativas de la nube está disponible aquí:
Informe operativo de Kubernetes y Cloud Native 2021
Referencias y lecturas adicionales
Hay muchos buenos recursos disponibles sobre las mejores prácticas para el monitoreo en general y las alertas en particular. Algunos de mis lugares favoritos y excelentes para comenzar a aprender son los siguientes:
