Alertas en el Elastic Stack
Las alertas son fundamentales para los casos de uso de Elastic. Desde la introducción de Watcher (nuestro conjunto original de características de alerta para Elasticsearch) en 2015, hemos recibido muchos comentarios que nos ayudaron a redefinir cómo debe ser un sistema de alertas y qué debería implicar la experiencia del usuario. El objetivo de este blog es resumir algunas cuestiones clave que aprendimos, cómo han influenciado nuestro trabajo en 2019 y el futuro de las alertas para el Elastic Stack.
¿Qué aprendimos?
Cuatro años de alertas en Elastic han creado una gran cantidad de conocimiento sobre los sistemas de alertas. Intentamos sintetizar lo que aprendimos en tres observaciones orientadas al futuro: vemos alertas en todos los casos de uso, debemos darle sentido en todos los casos de uso, y la detección de alertas y la respuesta a estas son cada vez más sofisticadas. Estos aprendizajes moldean nuestro pensamiento sobre el futuro de las alertas.
Alertas en todas partes
Las alertas abarcan todos nuestros productos y casos de uso. Si tienes datos en vivo, es un caso para alertas. Esta es la razón por la que creamos Watcher y por la que ha tenido éxito. Sin embargo, si observamos los casos de uso, es evidente que no hay una sola alerta que se adapte a todo.
Las alertas y notificaciones tienen un rol fundamental tanto en productos como Elastic Logs, SIEM, APM, Uptime, Infrastructure y Maps como en características de monitoreo, Machine Learning y una gran cantidad de dashboards de Kibana; sin embargo, cada uno posee necesidades diferentes para detectar condiciones, expresarlas y mostrarlas en contexto. Las alertas y el monitoreo necesitan integrarse en profundidad con un producto para ser eficaces. Con la evolución del stack y sus usos, ha quedado claro que las alertas de Elasticsearch necesitan un complemento que permita una expresión de alertas en cada caso de uso que sea completa y que esté estrechamente integrada.
Darle sentido a las alertas
El corolario de las “alertas en todas partes” es que, a medida que estos distintos casos de uso generan alertas, las alertas se convierten en su propia fuente de datos y crean oportunidades para comprender los sistemas y sus estados. O, como diría la comunidad de ingeniería de confiabilidad de sitios (SRE), hay oportunidades para mejorar la observabilidad de un sistema general.
Cada caso de uso interpreta los datos a su manera, y las alertas muestran facetas diferentes de una situación. La respuesta correcta a un incidente suele depender de los datos de varias fuentes y de la correlación de distintos tipos de alertas y eventos para comprender una situación. En algunos dominios, como SIEM, las alertas de nivel más alto se activan desde patrones en las alertas de nivel más bajo.
Como el Elastic Stack se convierte en el hogar de cada vez más casos de uso, un sistema de alertas bien hecho no solo generará alertas, sino que te ayudará a darle sentido en todos los casos de uso. Por ejemplo, las alertas de Uptime pueden mostrar una interrupción del servicio, las alertas de APM explican cuál transacción la causó, y las alertas de monitoreo identifican por qué sucedió. Un sistema de alertas debería proporcionar contexto, permitir la correlación y mejorar la percepción; tanto para las personas como las máquinas.
Detección y acción
El corolario de “darle sentido a las alertas” es que, con un sistema más observable, puedes detectar condiciones más complejas y tomar medidas más sofisticadas. Esto supera cada vez más lo que tradicionalmente considerábamos como alertas.
Las alertas generalmente se enfocan en detectar una condición y luego atraer la atención de una persona, y a menudo ahí termina todo. Sin embargo, si miramos el panorama general, un sistema de alertas puede pensarse como parte de un bucle de control o comentarios: observar, detectar una condición, tomar medidas, volver a observar.
En la actualidad, una “acción” generalmente involucra la notificación: incluir a una persona en el bucle para que controle el sistema e intente corregirlo. Pero con la mejora de la información del sistema, la “acción” puede asumir mayor control, por lo general, con la supervisión de una persona. Este podría ser un sistema semiautónomo regido por una comunicación bidireccional (por ejemplo, chatbots) o un sistema completamente autónomo como el que observamos en la tendencia hacia las aplicaciones de autoescalado, autoreparación y autoptimización.
Un sistema de alertas debe soportar detección y acciones sofisticadas, reconociendo que la “detección” puede ser más que una búsqueda en Elasticsearch y que la “acción” se está convirtiendo en algo más que enviar un correo electrónico o llamar un webhook.
Aplicación de lo aprendido
En otoño de 2018, decidimos que necesitábamos que las alertas soportaran las tres observaciones anteriores.
También decidimos que tener alertas como entidades de primera clase en Kibana sería la mejor manera de hacerlo:
- Alertas en todas partes: integraciones completas de alertas en todos nuestros productos, a nivel de plugins, API y UI
- Darle sentido a las alertas: proporcionar una interfaz intuitiva para todos los tipos de alertas
- Detección y acción: mecanismos sofisticados de detección y acción a través de plugins de Kibana
También sabemos, gracias a Watcher, que las alertas deben escalarse a cargas de alertas de producción, tener alta disponibilidad y ser confiables. Los contratos de API, UI y plugins/bibliotecas para soportar las tres observaciones deben crearse sobre una base sólida y escalable. En conjunto, podemos ver cuatro capas del sistema de alertas de Elastic:
Durante 2019 hemos sentado las bases del nuevo sistema de alertas en Kibana.
En enero, agregamos Task Manager como parte de la versión 6.7. Esto le proporcionó a Kibana la programación en segundo plano con tareas persistentes que pueden distribuirse en varias instancias de Kibana por motivos de escalabilidad y disponibilidad. Los componentes de la capa base de alertas, como Task Manager, pueden impulsar más que simples alertas. Por ejemplo, Task Manager podría brindar una experiencia de reporte mejor programada en Kibana.
En junio, agregamos dos conjuntos nuevos de API en Kibana: la API de alertas y la API de acciones.
La API de acciones permite a Kibana registrar y ejecutar acciones, y proporciona un contrato simple para que puedas definir las tuyas propias, lo que facilita la personalización. La versión inicial también incluyó algunos ejemplos de acciones para logging, Slack y notificaciones por correo electrónico.
La API de alertas permite a Kibana registrar formas de detección como “tipos de alertas” y luego ejecutar estas comprobaciones de forma programada a través del sistema de administración de tareas. Como con las acciones, hay un contrato de alertas simple: si puedes expresarlo en una función de JavaScript que se ejecute en el servidor Kibana, puede impulsar una alerta.
El Elastic Stack 7.4 se enfoca en completar los niveles más bajos del sistema de alertas: estamos mejorando la seguridad de las API, agregando soporte para seguridad y espacios, y agregando algunas otras acciones integradas, como indexación, webhooks y PagerDuty.
¿Qué sigue?
El desarrollo del sistema de alertas de Kibana ha estado en su apogeo durante los últimos meses, lo cual continuará hasta el ciclo de lanzamiento de la versión 7.x. Nuestro plan es lanzar el sistema en tres fases.
La primera se ha estado desarrollando durante gran parte de 2019: sentar las bases. Se enfoca en la administración y programación escalables de tareas, contratos de alertas y acciones, y API.
Ahora estamos pasando a la segunda fase, en la cual diferentes casos de uso pueden integrar el sistema de alertas a nivel de API y bibliotecas. Esto también incluye el diseño y la creación de una UI en Kibana como parte de darle sentido a las alertas y validarlas con casos de uso específicos (como monitoreo, tiempo de actividad o SIEM, por ejemplo).
La tercera fase extenderá las alertas a todas partes y los temas de detección y acción permitiendo alertas definidas por el usuario en todo Kibana, ya sea a través de alertas basadas en plantillas o incluso en expresiones mediante expresiones de Canvas o similares.
El objetivo final es un sistema que satisfaga nuestra visión de alertas en el Elastic Stack:
- Alertas en todas partes: las alertas son una entidad de primera clase que tiene en cuenta el espacio dentro de Kibana. Esto posibilita segmentar la creación y visualización de alertas en todos los grupos y permite la integración completa de alertas en productos como SIEM, Monitoring y Uptime (entre otros). Las alertas complementan y trabajan con Watcher, no lo reemplazan.
- Darle sentido a las alertas: las integraciones completas de alertas estarán acompañadas por la UI de Kibana que proporciona vistas integrales de todos los tipos de alertas, además de herramientas para correlacionar y darle sentido al historial de alertas.
- Detección y acción: las API y los plugins están diseñados de manera que un mecanismo de detección o acción pueda ser cualquier cosa, siempre y cuando pueda expresarse en JavaScript ejecutándose en el servidor Kibana. Esto da lugar a las detecciones y acciones sofisticadas que aparecerán en Kibana a través de productos como SIEM o nuestras soluciones de observabilidad.