Alerta no Elastic Stack
O alerta é fundamental para os casos de uso da Elastic. Desde que o Watcher (nosso conjunto original de recursos de alerta para o Elasticsearch) foi introduzido em 2015, recebemos muito feedback que ajudou a refinar a nossa compreensão de como deve ser um sistema de alerta e o que a experiência do usuário deve implicar. O objetivo deste post é resumir algumas das principais coisas que aprendemos, como isso influenciou nosso trabalho em 2019 e o que o futuro reserva para os recursos de alerta no Elastic Stack.
O que aprendemos?
Quatro anos de alerta na Elastic geraram um conhecimento riquíssimo sobre sistemas de alerta. Procurei sintetizar o que aprendemos em três observações: vemos alertas em todos os casos de uso; precisamos compreendê-los em todos os casos de uso; e a detecção de alertas e a resposta a eles estão ficando mais sofisticadas. Esses aprendizados moldam o nosso pensamento sobre o futuro do alerta.
Alerta em todos os lugares
O alerta abrange todos os nossos produtos e casos de uso. Se você tem dados ativos, tem um caso de uso de alerta. Foi por isso que criamos o Watcher e por isso ele tem sido bem-sucedido. No entanto, quando analisamos os casos de uso, fica claro que não há um só alerta que sirva para todos eles.
Em produtos como Elastic Logs, SIEM, APM, Uptime, Infraestruture e Maps, bem como em recursos como monitoramento, machine learning e a infinidade de dashboards do Kibana, alertas e notificações desempenham um papel crucial, mas cada um tem necessidades únicas para detectar condições, expressá-las e mostrá-las no contexto. Para serem eficazes, o alerta e o monitoramento requerem uma profunda integração com um produto. À medida que a pilha e seus usos evoluíram, ficou claro que o alerta do Elasticsearch precisava de um complemento que permitisse a expressão rica e fortemente integrada dos alertas em cada caso de uso.
Compreensão dos alertas
A dedução óbvia de “alerta em todo lugar” é que, à medida que esses diferentes casos de uso geram alertas, os alertas passam a ser sua própria fonte de dados e criam oportunidades para a compreensão dos sistemas e de seu estado. Ou, como a comunidade de engenharia de confiabilidade do site (SRE) poderia dizer, há oportunidades para melhorar a observabilidade de um sistema geral.
Cada caso de uso interpreta os dados à sua maneira, e os alertas mostram diferentes facetas de uma situação. A resposta correta a um incidente geralmente depende de dados de várias fontes e correlaciona diferentes tipos de alertas e eventos para entender uma situação. Em alguns domínios, como o SIEM, alertas de nível superior são disparados a partir de padrões em alertas de nível inferior.
Conforme o Elastic Stack vai abrigando cada vez mais casos de uso, um sistema de alerta feito corretamente não só gera alertas, mas também ajuda a compreendê-los em todos os casos de uso. Por exemplo, os alertas do Uptime podem mostrar uma interrupção do serviço, os alertas do APM explicam qual transação a causou, enquanto os alertas de monitoramento identificam por que isso aconteceu. Um sistema de alerta deve fornecer contexto, possibilitar a correlação e melhorar o reconhecimento, tanto para pessoas quanto para máquinas.
Detecção e ação
A dedução óbvia de “compreender os alertas” é que, com um sistema mais observável, você pode detectar condições mais complexas e executar ações mais sofisticadas. Cada vez mais isso vai além do que tradicionalmente consideramos um alerta.
O alerta geralmente se concentra em detectar uma condição e, então, em chamar a atenção de um ser humano — e muitas vezes para por aí. Porém, olhando para o panorama geral, um sistema de alerta pode ser visto como parte de um circuito de controle ou feedback: observar, detectar uma condição, executar alguma ação, observar novamente.
Hoje, uma "ação" geralmente envolve uma notificação — colocar uma pessoa no circuito para controlar o sistema e tentar corrigi-lo. Porém, à medida que o insight do sistema melhora, a “ação” pode assumir mais controle, geralmente sob supervisão humana. Pode ser um sistema semiautônomo, regido por uma conversa bidirecional (chatbots, por exemplo), ou um sistema totalmente autônomo, como vemos na tendência para aplicações de autoampliação, autorrecuperação e auto-otimização.
Um sistema de alerta precisa dar suporte a detecção e ações sofisticadas, reconhecendo que “detecção” pode ser mais do que uma consulta ao Elasticsearch, e “ação” está se tornando mais do que enviar um e-mail ou chamar um webhook.
Como aplicar o que aprendemos
Decidimos no terceiro trimestre de 2018 que precisávamos que o alerta fosse compatível com as três observações acima.
Também decidimos que ter alertas como entidades de primeira classe no Kibana seria a melhor maneira de fazer isso:
- Alerta em todos os lugares: sofisticadas integrações de alerta em todos os nossos produtos, nos níveis de plugin, API e UI
- Compreender os alertas: fornecendo uma interface intuitiva em todos os tipos de alerta
- Detecção e ação: mecanismos sofisticados de detecção e ação por meio de plugins do Kibana
Também sabemos pelo Watcher que o recurso de alerta deve ser ampliado de acordo com as cargas de alerta de produção e deve ser altamente disponível e confiável. APIs, UIs e contratos de plugin/biblioteca para dar suporte às três observações devem ser construídos sobre uma base sólida e escalável. No conjunto, vemos quatro camadas no sistema de alerta da Elastic:
Em 2019, lançamos as bases do novo sistema de alerta no Kibana.
Em janeiro, adicionamos o Task Manager como parte da versão 6.7. Isso deu ao Kibana a capacidade de agendamento em segundo plano, com tarefas persistentes que podem ser distribuídas por várias instâncias do Kibana para escalabilidade e disponibilidade. Os componentes da camada de base de alerta, como o Task Manager, podem fazer mais do que apenas alertar. Por exemplo, o Task Manager poderia fornecer uma melhor experiência de relatório agendado no Kibana.
Em junho, adicionamos dois novos conjuntos de APIs ao Kibana: a API de alertas e a API de ações.
A API de ações permite que o Kibana registre e dispare ações, e fornece um contrato simples para definir as suas próprias, facilitando a personalização. A versão inicial também tinha alguns exemplos de ações para logging, Slack e notificações por e-mail.
A API de alerta permite que o Kibana registre formas de detecção como “tipos de alerta” e execute essas verificações em uma programação usando o sistema de gerenciamento de tarefas. Assim como nas ações, há um contrato de alerta simples: se você pode expressá-lo em uma função JavaScript executada no servidor do Kibana, ele pode ativar um alerta.
O foco do Elastic Stack 7.4 está voltado para o preenchimento dos níveis mais baixos do sistema de alerta: estamos reforçando as APIs; adicionando suporte para segurança e espaços; e adicionando mais algumas ações integradas, como indexação, webhooks e PagerDuty.
O que vem a seguir?
Temos trabalhado a todo vapor no desenvolvimento do sistema de alerta do Kibana nos últimos dois meses e continuaremos durante o ciclo de lançamento das versões 7.x. Nosso plano é implementar o sistema em três fases.
A primeira fase aconteceu durante uma boa parte do ano de 2019: o estabelecimento das bases. Ela se concentrou no gerenciamento e no agendamento escaláveis de tarefas, contratos para alerta e ação, e APIs.
Agora estamos entrando na segunda fase, na qual diferentes casos de uso podem integrar o sistema de alerta nos níveis da API e da biblioteca. Isso também inclui projetar e criar uma UI no Kibana como parte da compreensão dos alertas e validá-la com casos de uso específicos (como monitoramento, tempo de funcionamento ou SIEM, por exemplo).
A terceira fase estenderá os temas “alerta em todos os lugares” e “detecção e ação”, possibilitando a criação de alertas definidos pelo usuário em todo o Kibana, seja por meio de alertas com modelos ou até mesmo alertas baseados em expressão, usando algo como as expressões do Canvas.
O objetivo final é um sistema que satisfaça a nossa visão de alerta no Elastic Stack:
- Alerta em todos os lugares: os alertas são uma entidade de primeira classe com reconhecimento de espaço dentro do Kibana. Isso torna possível segmentar a criação e a visualização de alertas entre grupos e permite uma sofisticada integração de alerta em produtos como SIEM, Monitoring e Uptime (para citar alguns). O alerta complementa o Watcher e funciona junto com ele, mas não o substitui.
- Compreensão dos alertas: as sofisticadas integrações de alerta serão acompanhadas pela UI do Kibana, que fornece visualizações abrangentes de todos os tipos de alerta, além de ferramentas para correlacionar e compreender o histórico de alertas.
- Detecção e ação: as APIs e os plugins foram projetados de forma que um mecanismo de detecção ou ação possa ser qualquer coisa, contanto que possa ser expresso em JavaScript e executado no servidor do Kibana. Isso deixa muito espaço para as sofisticadas detecções e ações que aparecerão no Kibana por meio de produtos como o SIEM ou nossas soluções de observabilidade.