Estandarizar el sistema de alertas y operarlo con IaC
(engineering.ab180.co)Introducción
A medida que el servicio creció, también aumentó la cantidad de señales que había que revisar durante la operación. En este artículo presentamos cómo gestionamos las alertas como código y el proceso de estandarizar el flujo de respuesta que conecta Slack y PagerDuty.
Al principio, el objetivo era simple: crear alertas más fácilmente, enviarlas de una forma más clara y dejar en claro quién debe verlas. Luego, mientras continuamos con la operación, también fuimos refinando las alertas agrupadas, las definiciones repetidas, la automatización de respuestas y hasta la estabilidad del sistema de monitoreo.
Motivación
Hay varias maneras de aumentar la disponibilidad del servicio y reducir el impacto en los usuarios.
Entre ellas, este trabajo se enfocó en mejorar el sistema de alertas.
Las alertas estaban más cerca de ser una interfaz operativa que conecta la prevención de incidentes con la respuesta ante incidentes. Si detectamos antes las señales de riesgo, podemos actuar antes de que se conviertan en una falla real, y aun después de que ocurra un incidente, la persona responsable puede darse cuenta más rápido y empezar a responder antes.
La dirección de mejora que queríamos en ese momento también estaba clara. Queríamos detectar mejor las señales de riesgo, hacer que la persona responsable las notara más rápido, conectarlas de inmediato con la investigación y la respuesta, y reducir los flujos de respuesta repetitivos.
No empezamos midiendo todo cuantitativamente desde el principio, pero sí teníamos muy claro el problema: la alerta no debía ser solo una notificación, sino un sistema operativo que previene incidentes y los conecta con la respuesta.
El papel de las alertas
Para ofrecer un servicio estable, es importante prevenir incidentes, pero también detectar rápidamente señales anómalas en un servicio en operación.
En este punto, las alertas cumplen dos funciones. Antes de que ocurra un incidente, ayudan a identificar rápidamente señales de riesgo y tomar medidas antes de que se conviertan en una falla real; y después de que ocurre un incidente, informan del problema a la persona responsable y la conectan con el contexto y las siguientes acciones necesarias para entender la situación, como Runbook, Dashboard, Log y Silence.
Es decir, una alerta no es simplemente una notificación que dice "hubo un problema", sino algo más cercano a una interfaz operativa que conecta la prevención de incidentes con la respuesta.
Qué faltaba en las alertas existentes
Había tres grandes problemas con las alertas existentes. Eran difíciles de crear, difíciles de entender incluso al recibirlas, y no estaba claro quién debía responderlas y administrarlas.
Era difícil crear alertas
En ese momento, la creación y entrega de alertas involucraba varios sistemas, como Grafana, Slack, PagerDuty, CloudWatch, EventBridge y Lambda, y además las fuentes de datos eran diversas: NewRelic, VictoriaMetrics, Steampipe, OpenSearch, Druid y MySQL, entre otras.
La forma de trabajar también variaba según cada alerta. Algunas se enviaban directamente de Grafana a Slack; a otras se les agregaba Lambda detrás de CloudWatch Alarm; otras evaluaban el estado de recursos de AWS consultándolo con Steampipe; y si se necesitaba integración con PagerDuty, había que considerar configuraciones adicionales.
El problema era que faltaban convenciones a nivel organizacional. No estaba suficientemente definido dónde gestionar cada alerta, si debía enviarse solo a Slack o también conectarse con PagerDuty, qué explicación y qué enlaces debía incluir el mensaje, ni dónde administrar el equipo responsable y la ruta de entrega.
Como resultado, las alertas se iban creando cuando hacían falta, pero con el tiempo la forma de crearlas y administrarlas se fue fragmentando cada vez más.
Era difícil leer las alertas
El hecho de crear una alerta no significaba que el mensaje real en Slack siempre fuera fácil de leer. El formato y la calidad de la información variaban según la persona o el sistema que la había creado; algunas alertas tenían títulos largos y complejos, y a veces valores internos como Value o Labels quedaban expuestos tal cual.
Incluso cuando había enlaces, en algunos casos no quedaba claro qué había que revisar primero, y aunque hubiera botones de Dashboard o Log, a veces la integración real no funcionaba. Además, muchas alertas carecían de suficiente contexto, por lo que la persona responsable tenía que volver a buscar el servicio, el clúster, el recurso o el rango de tiempo por su cuenta.
En una situación de incidente, incluso unos pocos minutos se sienten críticos. Por eso, en el momento de recibir una alerta, tenía que ser posible entender de inmediato qué problema era, qué tan importante era, de qué servicio y recurso se trataba, qué había que revisar primero y cuál era la siguiente acción.
Era difícil gestionar la responsabilidad de respuesta de las alertas
Cuando sonaba una alerta, a veces también era ambiguo quién debía revisarla y responderla. Si no quedaba visible el equipo o la persona responsable, quien veía la alerta primero tenía que empezar por decidir "¿esto lo tengo que ver yo?" o "¿a quién debería preguntarle?", y en una situación de incidente incluso ese breve juicio podía retrasar la respuesta.
Además de la responsabilidad de responder después de que una alerta se activaba, también era importante quién era dueño y quién administraba la alerta misma. Tenía que quedar visible a qué servicio de qué equipo correspondía la alerta, quién podía cambiar sus condiciones, cómo se revisarían el mensaje o los umbrales, e incluso quién se encargaría de limpiar alertas antiguas.
En resumen, las situaciones que queríamos mejorar eran las siguientes:
- La forma de crear y administrar alertas estaba fragmentada
- Incluso al recibir una alerta, era difícil entender de un vistazo qué significaba
- Cuando se activaba una alerta, era ambiguo quién debía revisarla y responderla
- Tampoco estaba claro qué equipo debía ser dueño de la alerta y administrarla
Qué y cómo mejoramos
La dirección de la mejora tenía tres ejes. Estandarizar la forma de crear alertas, ofrecer la información necesaria en una estructura consistente dentro de los mensajes de Slack y ordenar la estructura para que en cada alerta quedaran visibles la persona responsable y la ruta de entrega.
Estandarizar la forma de crear y administrar alertas
Primero unificamos la manera de crear y administrar alertas. La evaluación y ejecución de las reglas de alerta se estandarizó en Grafana; la integración entre Grafana, Slack y PagerDuty se abstrajo con módulos de Terraform; y todas las definiciones de alertas pasaron a gestionarse como IaC bajo el directorio alerts/ del repositorio interno de alerts. También organizamos la conexión de canales de Slack, la integración con PagerDuty, el formato de los mensajes y la creación de botones comunes para que todo lo manejara un módulo compartido.
Ahora, en lugar de tener que entender todo el pipeline de alertas, quien crea una alerta puede concentrarse más en qué condición debe detectar, qué tan importante es la alerta, quién debe revisarla y qué información se necesita para responder.
Dentro del repositorio también administramos en conjunto la forma de escribirlas, la estructura de directorios, los campos necesarios y las convenciones recomendadas, y al gestionar las alertas como código, las revisiones y el historial de cambios quedan registrados por PR y commit.
Estructura de directorios de alertas
Organizamos todas las alertas para que siguieran la estructura {main-category}/{sub-category}/{severity}/{alert-name}.yml.
Por ejemplo:
infra/kubernetes/critical/pod-unhealthy.ymldata/airflow/warning/task-failed.ymlfinops/aws/warning/cost-increase.yml
Gracias a esta estructura, con solo ver la ubicación del archivo ya se podía identificar a qué área pertenecía la alerta y con qué nivel de severidad debía tratarse. También nos permitió usarla como criterio para agrupar alertas de un área específica, revisar alertas duplicadas o antiguas, o vincular canales de Slack, servicios de PagerDuty y CODEOWNERS.
Forma de definir alertas
En cada archivo de alerta incluimos información como datasource, query, threshold, condition y message.
No creamos un DSL aparte. Más bien, era algo cercano a expresar en YAML el contenido serializado en JSON de una alerta de Grafana, y gracias a eso casi cualquier alerta que pudiera definirse en Grafana podía convertirse a IaC con la misma estructura.
Últimamente también estamos usando LLM. Si una persona describe en lenguaje natural "quiero recibir una alerta con este mensaje bajo estas condiciones", el LLM toma como referencia ejemplos y convenciones existentes y genera un borrador de definición de alerta en formato YAML. Gracias a eso, quien escribe la alerta puede concentrarse más en qué quiere detectar y por qué lo necesita que en un formato de serialización complejo.
Hacer que los mensajes de alerta se entiendan y permitan responder de inmediato
También consideramos el mensaje de alerta como una interfaz. En una situación de incidente no suele haber mucho margen para interpretar el mensaje con calma, así que sin importar qué alerta llegue, debía ser posible revisar el mismo tipo de información en el mismo lugar.
Por eso organizamos la estructura de los mensajes de Slack de forma consistente. En el título incluimos el nombre del Alert, el estado y la severidad; en el cuerpo, una descripción que cualquier persona pudiera entender de inmediato, además del responsable, equipo, servicio, región, nombre del recurso y etiquetas principales. También dividimos los botones entre botones comunes y opcionales, para ofrecer por defecto IaC, PagerDuty, Silence y mostrar Runbook, Dashboard, Log solo cuando hiciera falta.
Los botones comunes se generaban automáticamente en el sistema y se enlazaban solos, y también hicimos que todos los cambios de estado del Alert quedaran registrados en el thread de Slack. Así se podía ver en un solo flujo quién hizo Acknowledge, si se manejó desde Slack o desde PagerDuty, cuándo se resolvió y hasta qué notas se dejaron durante la respuesta.
Como resultado, sin importar quién creara un Alert, la forma en que se veía en Slack pasó a ser parecida, y los miembros del equipo pudieron identificar más rápido dónde mirar.
Aclarar la estructura de responsabilidad de los Alert
Tan importante como entender un Alert apenas aparece era hacer visible quién debía responsabilizarse de revisarlo.
Por eso aprovechamos la información de tags y labels de los recursos en el flujo de respuesta. En lugar de asignar manualmente un equipo o una persona responsable a cada Alert, usamos metadatos como servicio, equipo, recurso y entorno para que en el mensaje de Slack se mencionara automáticamente al equipo y a la persona adecuados.
También organizamos la ruta de escalamiento bajo las mismas reglas. Según la clasificación del Alert y su severity, se conectaban automáticamente el canal de Slack, el PagerDuty Service y la Escalation Policy; los Alert de nivel Warning se enviaban solo al canal de Slack, mientras que los Alert Critical con alto impacto al usuario o alta probabilidad de incidente generaban incluso un PagerDuty Incident.
También usamos CODEOWNERS. Separamos los archivos de Alert en directorios según la categoría y el área de servicio, y asignamos en CODEOWNERS el equipo responsable de cada ruta, para que dentro del repositorio quedara claro qué equipo era dueño de cada área de Alert.
Como resultado, la responsabilidad de los Alert pasó a gestionarse en dos puntos. Cuando un Alert sonaba de verdad, se mencionaba al equipo y a la persona responsables con base en tags y labels, y cuando se modificaba la definición del Alert, se podía verificar a qué equipo pertenecía según la estructura de directorios y CODEOWNERS.
El rol del proxy de Alert
Para que esta estructura funcionara de verdad, hacía falta una capa intermedia que interpretara y encaminara los Alert. Por eso colocamos un proxy basado en AWS Lambda entre Grafana, Slack y PagerDuty.
Grafana evalúa las Alert rule y envía webhooks. El proxy recibe esos webhooks e interpreta el contexto del Alert, como category, severity, label, annotation y fingerprint, para decidir a qué canal de Slack enviarlo, qué PagerDuty Incident crear, a quién mencionar, qué botones adjuntar, cómo actualizar el thread existente en Slack y cómo gestionar el lifecycle de Ack/Resolve.
En otras palabras, si el módulo de Terraform y la estructura de directorios estandarizaban "cómo definir un Alert", el proxy cumplía el papel de conectar esa definición para que se viera y funcionara de la misma manera en el flujo operativo real.
Gracias al proxy, pudimos gestionar de forma consistente en un solo lugar el formato de los mensajes de Slack, las menciones a responsables, la integración con PagerDuty, las actualizaciones de threads en Slack y la interacción de Ack/Resolve; además, después fue mucho más fácil ampliar mejoras como grouped Alert, custom action button, integración con agentes de IA y un modelo común de Alert.
Qué más seguía faltando
Después de la primera mejora, la definición de los Alert pasó a gestionarse con IaC y los mensajes de Slack junto con las rutas de entrega empezaron a operar bajo reglas consistentes. Pero el sistema de Alert no era una herramienta que se construye una vez y ya está. Tras operarlo durante casi un año, a medida que aumentaban los Alert empezaron a aparecer nuevos problemas: cómo mostrar varias instancias generadas dentro de un mismo Alert, cómo gestionar definiciones repetidas de Alert, cómo permitir que una persona haga algo útil después de ver un Alert y cómo asegurar y validar la estabilidad del propio sistema de Alert.
Cuando el mismo Alert suena al mismo tiempo para varios objetivos, es difícil de ver
A medida que se volvía más fácil crear Alert, también aumentó naturalmente su cantidad. En ese momento, lo que resultaba especialmente incómodo era cuando una misma Alert rule sonaba al mismo tiempo para varios objetivos.
En Grafana, aunque sea la misma rule, si cambian valores de labels como region, name, node, pod, app, cada uno se considera una Alert instance separada. Por ejemplo, si existe un Alert de Pod unhealthy y varios pods pasan al mismo tiempo a estado unhealthy, se genera una Alert instance por cada pod.
Grafana ya tenía una función de Alert Grouping, pero no bastaba con agruparlos sin más. Lo importante era mostrar el estado de los Alert agrupados de una forma fácil de entender para quien opera el sistema: qué objetivos había dentro del grupo, cuáles seguían en firing, cuáles acababan de resolverse, si había objetivos recién agregados y si los cambios de estado del mismo grupo podían seguirse como un solo flujo.
Aumentan las definiciones de Alert repetidas
Cuantas más definiciones de Alert había, más empezaba a mostrar límites el método de copiar YAML y cambiar unas pocas cosas. Alert como SQS lag, CloudWatch error log, Pod OOM, ALB 5xx o Lambda error/throttle se creaban repetidamente, y al principio bastaba con copiar un archivo existente y cambiar nombre, query, threshold y labels.
Pero cuando aumentó la cantidad de archivos, se volvió más difícil corregir comportamientos comunes, y empezaron a aparecer diferencias pequeñas entre Alert con la misma intención, como enlaces de dashboard, composición de labels o forma de expresar el threshold. Por eso hacía falta una estructura que permitiera reutilizar patrones repetidos.
Incluso después de ver un Alert, todavía había distancia hasta la siguiente acción
Agregar botones de Runbook, Dashboard, IaC y PagerDuty en el mensaje de Slack ayudó, pero en una respuesta real a incidentes muchas veces los enlaces por sí solos no bastaban. En particular, el Runbook tenía una efectividad clara, pero no era fácil adjuntar un buen Runbook a todos los Alert y mantenerlo siempre actualizado.
Además, en la respuesta real se repetían una y otra vez tareas de investigación parecidas, como revisar logs de Kubernetes, verificar el estado de los pods, consultar el rollout history, revisar métricas de SQS o Lambda y comprobar error logs. Casi todo eso ocurría fuera del mensaje de Slack, y la persona responsable tenía que leer labels y values del Alert, moverse a otras herramientas, trasladar esos valores y luego volver a compartir el resultado en el thread de Slack.
Al final, con la primera mejora sí fue posible leer mejor los Alert, pero la investigación y la respuesta seguían quedándose en gran parte fuera del mensaje del Alert.
Aumentan los SPOF en el sistema de monitoreo
Al ordenar el sistema de Alert, también aumentaron los puntos que podían convertirse en SPOF. La definición y el despliegue de las Alert rule quedaron concentrados en el repositorio de alerts y en Terraform, Grafana pasó a encargarse de evaluar las Alert rule, y el proxy se quedó a cargo de los mensajes de Slack, los PagerDuty Incident y el lifecycle de Ack/Resolve.
Que los roles quedaran claros fue un cambio positivo, pero también creció la posibilidad de que todo el flujo de Alert se viera afectado cuando alguno de esos puntos fallara. Lo más difícil era que ese tipo de fallo podía no hacerse visible fácilmente. Si la ruta que avisa de anomalías en otros sistemas se detiene en silencio, puede ocurrir un incidente real sin que nadie se entere.
Al final, esto llevaba a la pregunta: "¿Quién monitorea el sistema de monitoreo?"
Segunda mejora
Con la primera mejora quedó definida la estructura básica del sistema de Alert, pero a medida que se volvió más fácil crear y enviar Alert, también cambiaron los problemas que había que observar en la operación.
En la segunda mejora nos concentramos en cuatro puntos: mostrar de un vistazo, unificando en un solo flujo, los cambios de estado cuando varios objetivos suenan al mismo tiempo dentro de la misma Alert rule, permitir reutilizar definiciones repetidas de Alert como patrones comunes, complementar el Runbook conectando tareas repetidas de investigación y acciones limitadas de mitigación mediante botones de Slack, y medir y validar la estabilidad de las definiciones de Alert, la evaluación y las rutas de entrega que podían convertirse en SPOF.
Manejar correctamente los Grouped Alert
Primero mejoramos la forma de representar las alertas agrupadas. Cuando varias instancias se disparan al mismo tiempo desde la misma regla de alerta, si se envía cada una como un mensaje independiente el canal de Slack se vuelve caótico; pero si se agrupan solo como un único grupo, es fácil perder de vista qué recurso es realmente el que tiene el problema.
La clave era agrupar, pero sin perder el estado dentro del grupo. En Slack, las alertas agrupadas se muestran como un solo mensaje representativo, pero incluyendo también los objetivos afectados en ese momento; y si se agrega un nuevo objetivo o se resuelve uno existente, ese cambio se deja en el mismo thread. Cuando se producen muchos cambios de estado al mismo tiempo, se muestran agrupando varios cambios en batch, y en PagerDuty también se ajustó para que apunte al mismo problema que la alerta agrupada que se ve en Slack.
Como resultado, varias alertas originadas por la misma causa ahora pueden verse en Slack como un solo flujo.
Reducir definiciones de alertas repetidas
El enfoque de copiar y modificar un poco aumenta el costo de mantenimiento y la posibilidad de errores a medida que crece la cantidad de alertas. Para reducirlo, agregamos global/templates y matrix.
global/templates es una función para definir como template común las estructuras de alerta que se repiten, y matrix es una función para expandir la misma alerta en múltiples combinaciones de región, queue, datasource y service, generando así varias alertas.
Convertimos en templates patrones repetitivos como SQS queue lag, CloudWatch error log, Pod OOM en varios clústeres, ALB 5xx y Lambda error/throttle, ECS memory/CPU/max-capacity, y dejamos que solo los valores que cambian, como nombre de queue, región, clúster, threshold o variables de dashboard, se ingresen en la matrix.
Con esto, la estructura común de mensajes, los botones, el manejo de links de Runbook/dashboard y la forma de manejar datasource pudieron corregirse en un solo lugar, y también se redujeron las inconsistencias y el costo de mantenimiento que crecen cuando aumenta la cantidad de alertas.
Empezar a responder directamente desde el mensaje de Slack
Luego ampliamos lo que se puede hacer dentro del mensaje de Slack. Los links al Runbook y al dashboard siguen siendo importantes, pero queríamos reducir dentro del propio mensaje de Slack esas consultas repetitivas o trabajos de mitigación limitada que se hacían siempre de forma parecida.
Por eso, además de los botones existentes, agregamos un custom action button. Si se define un comando en message.actions del YAML de la alerta, este se muestra como botón en el mensaje de Slack; al presionarlo, el proxy ejecuta el comando mediante una invocación separada de Lambda y luego deja en el mismo thread de Slack un comentario con quién presionó qué botón y el resultado de la ejecución.
Con este botón ahora se pueden ofrecer tareas como consultar logs, revisar el estado de rollout de Kubernetes, hacer rollout restart en situaciones limitadas, ejecutar un solo comando o ejecutar varios comandos de forma secuencial.
La parte a la que más atención pusimos fue la seguridad. Si el nombre del botón termina en !, Slack muestra un cuadro de confirmación; los valores de labels como ${labels.namespace} y ${labels.pod} se sustituyen dentro del comando aplicando shell quoting para evitar command injection; y las tareas que requieren permisos adicionales pueden asumir un IAM role mediante actionRole. El uso de roles no permitidos se maneja como fail-closed, y tanto el webhook como las interacciones con Slack se validan respectivamente con Bearer token, firma HMAC-SHA256 y replay protection.
Integración con un agente de IA
También queríamos reducir el proceso de reunir la información necesaria después de recibir una alerta. Por eso conectamos abot, nuestro agente interno de IA, al flujo de alertas.
Cuando se presiona el botón de abot en el mensaje de Slack, el proxy reúne el nombre de la alerta, la descripción, labels, values, link de IaC y el contexto que el usuario agrega adicionalmente desde un modal, y envía una solicitud de análisis. abot está configurado para operar con la identidad basada en OAuth de la persona que presionó el botón, de modo que, aunque consulte información necesaria en Grafana, AWS o Kubernetes, solo obtenga lo que ese usuario realmente puede ver.
El resultado del análisis se deja como comentario en el mismo thread de Slack. También deja qué métricas y logs revisó, qué posibilidades conviene sospechar primero y qué pistas valdría la pena registrar en el RCA, lo que permitió reducir el tiempo de volver a abrir varios sistemas para recopilar información.
Monitorear el sistema de monitoreo
En la segunda mejora, también incluimos como objeto de observación el propio proceso de definir, evaluar y entregar alertas.
Primero recopilamos métricas operativas del proxy. Reunimos métricas como el tiempo hasta Ack, el tiempo hasta Resolve, la cantidad actual de alertas activas, cuánto tiempo permanecen activas y cuántas veces volvió a sonar la misma alerta, y además agregamos un watchdog para detectar cuando Lambda se acerca al timeout. Si el proxy falla durante el procesamiento, configuramos que deje tanto el full stack trace como el event payload original.
Pero el método de que el propio proxy avise tenía limitaciones. Si el proxy muere antes de poder enviar incluso esa notificación, la alerta que debería haberse enviado puede simplemente perderse.
Por eso colocamos mecanismos de detección fuera del proxy, apoyados en sistemas distintos. Uno fue Grafana, haciendo que las métricas enviadas por el proxy se evaluaran como alertas del dominio de monitoreo para exponer anomalías. Sin embargo, como Grafana y VictoriaMetrics están sobre el mismo EKS, si EKS o Grafana caen por completo, no puede detectarse.
El otro fue un deadman switch. Cuando Grafana está sano, envía /api/health como heartbeat, y ese heartbeat lo recibe CloudWatch, que es independiente de EKS. La alarma de CloudWatch considera una falla si el heartbeat se cae o falta, y en ese caso notifica directamente a PagerDuty y Slack sin pasar por Grafana ni por el proxy.
Es decir, el lado que detecta y el lado detectado quedaron sobre infraestructuras distintas, y gracias a eso, salvo que EKS y CloudWatch caigan al mismo tiempo, es posible enterarse de la caída del sistema de monitoreo.
Tareas de mejora posteriores
La segunda mejora se completó, pero todavía quedan puntos por mejorar.
Aprovechar correctamente las métricas operativas recopiladas
A medida que el proxy recopila métricas operativas de alertas, ahora es posible responder con datos preguntas como qué alertas suenan con qué frecuencia en qué canales, si cierta persona responsable o equipo está recibiendo una concentración excesiva de alertas, o si existen alertas que solo repiten firing y auto resolve sin ninguna interacción.
Pero poder ver los datos y realmente ajustar las alertas con base en ellos son cosas distintas. Todavía no hemos avanzado de lleno en mejoras orientadas a ajustar thresholds, agrupar alertas similares, eliminar alertas innecesarias, reducir noisy alerts o disminuir de forma real el tiempo de reconocimiento y de resolución.
Mejoras en Alert IaC
Actualmente, las definiciones de alertas se despliegan desde el repositorio de alerts mediante CI/CD, pero todavía dependen del recurso grafana_rule_group del provider de Terraform de Grafana. El problema es que, aunque se cambie una sola regla, en el PR parece como si hubiera cambiado todo el rule group, lo que dificulta leer el diff; además, como interval_seconds está a nivel de rule group, para dar distintos ciclos de evaluación a cada alerta hay que dividir los grupos en partes más pequeñas.
Recientemente, Grafana incorporó una nueva alerting API que trata las Alert rules como recursos de Kubernetes, y en el provider de Terraform también se agregó el recurso grafana_apps_rules_alertrule_v0alpha1. Como todavía está en alpha, por ahora dejamos en pausa su adopción, pero cuando se estabilice queremos evaluar migrar desde grafana_rule_group.
Lo que esperamos está claro. Definir por separado el rule group y la rule, obtener diffs limpios donde, aunque se cambie una sola rule, solo se vea claramente ese cambio, ajustar con más detalle el ciclo de evaluación por cada rule y usar los recursos de monitoreo de forma más eficiente.
Cierre
El objetivo inicial era simple. Hacer que las alertas sean más fáciles de crear, que al recibirlas se puedan entender de un vistazo y que quede claro quién es responsable.
En la primera mejora reunimos las definiciones de alertas como IaC, estandarizamos los mensajes de Slack y las rutas de entrega, conectamos las menciones de responsables con CODEOWNERS y organizamos la gestión del lifecycle de Slack/PagerDuty a través del proxy.
Los problemas que salieron a la luz mientras se mantenía la operación se ajustaron en la segunda mejora. Se agruparon en una sola vista las alertas que se disparaban en masa desde la misma regla, se redujeron las definiciones repetidas con template y matrix, se hizo posible iniciar la investigación y la mitigación desde el mismo mensaje de Slack, y también se preparó un mecanismo para detectar cuando el propio sistema de monitoreo se detiene.
Gracias a esto, crear alertas, enviarlas y responder a ellas se volvió más fácil que antes.
Aun así, poder ver los datos y mejorar realmente la operación con base en esos datos son cosas distintas. Si hasta ahora se trataba de estandarizar el sistema de alertas y hacerlo medible, a partir de ahora queda por hacer el trabajo de reducirlo y pulirlo de verdad observando esas métricas.
Hay contenido que no pudo incluirse en este artículo por cuestión de extensión. Si quieren conocer más detalles, les recomendamos leer también el artículo original.
Aún no hay comentarios.