Como o Sicredi implementou monitoramento em um sistema heterogêneo

Em ambientes de TI cada vez mais complexos, a diversidade de ferramentas e tecnologias utilizadas para monitorar sistemas gera uma proliferação de alertas heterogêneos. Essa fragmentação dificulta a análise, a correlação e a resolução de incidentes, impactando diretamente a disponibilidade e a performance dos serviços.

Neste artigo, exploraremos como o Sicredi, que é uma instituição financeira cooperativa, desenhou um fluxo de alerta para unificar e normalizar alertas provenientes de múltiplas fontes, como Zabbix, Dynatrace e Victoria Metrics (Prometheus). Ao centralizar e padronizar as informações, esse processo permite uma visão consolidada do estado de saúde dos sistemas, facilitando a identificação de padrões, a priorização de incidentes e a tomada de decisões mais assertivas.

Veremos como essa solução, que envolve ferramentas desenvolvidas in-house, ferramentas livres e pagas, contribui para a eficiência da gestão de incidentes, mesmo em ambientes altamente heterogêneos. Ao final deste artigo, o leitor será capaz de compreender os benefícios de um fluxo de alerta unificado e como implementá-lo em sua própria infraestrutura.

A problemática de utilizar várias ferramentas

Em um cenário ideal, o monitoramento de sistemas complexos seria uma orquestra harmoniosa, onde cada instrumento (ferramenta de monitoramento) toca sua parte, contribuindo para uma melodia perfeita. Esse não é o caso do Sicredi, como em muitas empresas, há uma cacofonia de ferramentas, cada uma com sua própria linguagem e foco, dificultando a obtenção de uma visão holística e a identificação rápida de problemas.

O Desafio da Fragmentação

• Dificuldade de correlação: Dados provenientes de diferentes ferramentas são armazenados em formatos distintos, dificultando a correlação entre eventos e a identificação de causas raiz.
• Visão fragmentada: Cada ferramenta oferece uma visão parcial do sistema, dificultando a compreensão do comportamento do sistema como um todo.
• Alarmes duplicados e falsos positivos: A falta de sincronização entre as ferramentas pode gerar alarmes duplicados ou falsos positivos, sobrecarregando as equipes de operações.
• Dificuldade de análise: A necessidade de consultar múltiplas interfaces para obter informações completas sobre um incidente torna a análise mais demorada e complexa.
• Impacto na resolução de problemas: A falta de uma visão unificada dificulta a identificação rápida da causa raiz dos problemas, atrasando a resolução e aumentando o tempo de inatividade.

Consequências da Fragmentação

• Aumento do tempo de resolução de incidentes: A dificuldade em correlacionar dados e identificar a causa raiz dos problemas aumenta o tempo necessário para resolver incidentes.
• Diminuição da eficiência das equipes: As equipes de operações perdem tempo alternando entre diferentes ferramentas e tentando juntar as peças de um quebra-cabeça.
• Aumento dos custos operacionais: A manutenção de múltiplas ferramentas e a complexidade da integração aumentam os custos operacionais.
• Diminuição da satisfação do cliente: Incidentes não resolvidos rapidamente podem impactar negativamente a experiência do cliente.

Para superar esses desafios, o Sicredi precisou buscar uma solução que permitisse:

• Consolidar dados: Integrar dados de diferentes fontes em uma única plataforma.
• Correlacionar eventos: Estabelecer relações entre eventos ocorridos em diferentes sistemas.
• Automatizar a análise: Utilizar ferramentas de inteligência artificial para identificar padrões e anomalias nos dados.
• Simplificar a visualização: Apresentar informações de forma clara e concisa, facilitando a compreensão e a tomada de decisões.

Ao investir em uma plataforma de monitoramento unificada, o Sicredi pôde obter uma visão holística de seus sistemas, identificar problemas rapidamente e tomar medidas corretivas de forma eficaz, garantindo a disponibilidade e o desempenho dos seus serviços.

As diferentes ferramentas que fazem parte do sistema

A nossa solução para monitoramento e geração de alertas é customizada e eficiente, com o objetivo de garantir a integridade e a disponibilidade dos nossos sistemas.

As ferramentas-chave utilizadas em nosso processo são:

• ***Zabbix*:* Responsável por coletar dados de uma ampla variedade de fontes, como servidores, dispositivos de rede, serviços e scripts customizados. Através de agentes e descoberta automática, o Zabbix* monitora métricas como uso de CPU, memória, disco, tráfego de rede e disponibilidade de serviços.
• ***Dynatrace*:* Especializado em monitoramento de desempenho de aplicativos, o Dynatrace* oferece uma visão detalhada do comportamento das aplicações, identificando gargalos, erros e anomalias. Sua capacidade de correlação de dados permite analisar o impacto de problemas em toda a stack tecnológica.
• ***Victoria Metrics*:* Uma solução de armazenamento de séries temporais altamente escalável e econômica, que substitui o Prometheus em nossa solução armazenando as métricas customizadas dos serviços. O Victoria Metrics* oferece um desempenho superior para grandes volumes de dados, além de recursos avançados de compactação e consulta.
• Oracle Enterprise Manager (OEM): Uma solução abrangente para monitoramento e gerenciamento de ambientes Oracle, especialmente útil para monitorar bancos de dados Oracle. O OEM oferece uma visão unificada do ambiente Oracle, permitindo a coleta de métricas, a geração de alertas e a realização de tarefas administrativas.
• VictoriaMetrics Alert (vmalert): Responsável por avaliar as regras de alerta definidas no VictoriaMetrics e gerar alertas quando as condições são atendidas.
• Alertmanager do Prometheus: Uma ferramenta robusta para gerenciar e rotear os alertas gerados pelo vmalert. Ele permite configurar rotas, inibir repetições, e integrar com diversos sistemas de notificação.
• kafka-alerta.io: Desenvolvida internamente, essa ferramenta é responsável por normalizar os alertas gerados pelas ferramentas de monitoramento. O kafka-alerta.io transforma os alertas em um formato comum, facilitando o processamento e a integração com outras ferramentas. Em caso de algum problema é possível descartar alertas nesse ponto via configuração.
• *Alert-broker: Desenvolvido internamente, é um microsserviço que assina o tópico Kafka e consome os alertas e encaminha para o Alerta.io. Esse serviço implementa os conceitos de observabilidade, gerando métricas sobre o seu funcionamento, utilizando bucket4j para limitar o consumo de alertas, descartando um possível storm. *Dessa forma, é possível acompanhar, monitorar e remediar se necessário o consumo de alertas.
• ***Alerta.io*:* A plataforma central para gerenciamento de alertas. O Alerta.io recebe os alertas normalizados pelo kafka-alerta.io, realiza a correlação, notifica as equipes responsáveis e oferece diversas funcionalidades para gestão de incidentes. Há a possibilidade de estender as funcionalidades via plugins. Vários plugins foram escritos e o principal dele é o plugin responsável pelo enriquecimento de alertas. Dessa forma, novas informações são adicionadas a um alerta nesse momento, logo antes de ele ser exibido na console do operador. Outro plugin publica o alerta em outra fila Kafka*, responsável pelas demais integrações e consumos por outras ferramentas.

Cada ferramenta desempenha um papel fundamental no processo:

• Zabbix, Dynatrace e OEM: Coletam dados detalhados sobre a infraestrutura, as aplicações e os bancos de dados Oracle.
• Victoria Metrics: Armazena as métricas de forma eficiente e escalável.
• vmalert: Avalia as regras de alerta e gera alertas.
• Alertmanager: Gerencia e encaminha os alertas.
• kafka-alerta.io: Normaliza os alertas.
• Alerta.io: Centraliza, enriquece, correlaciona e distribui os alertas.

Apache Kafka como Hub Central de Alertas: Armazenamento, Distribuição e Processamento

O Apache Kafka, uma plataforma distribuída de streaming de dados em tempo real, tem se destacado como uma solução robusta e escalável para o armazenamento intermediário e a distribuição de alertas. Sua arquitetura, baseada em tópicos e partições, permite lidar com grandes volumes de dados de forma eficiente e confiável. No Sicredi, o Kafka foi utilizado principalmente como um sistema de back pressure para gerenciar o fluxo de alertas em um ambiente de monitoramento em que é normal que seja recebido um fluxo de alertas maior que a capacidade das ferramentas poderem processar.

Kafka como Distribuidor de Alertas

• Consumidores múltiplos: Diversos consumidores podem se inscrever em um mesmo tópico, permitindo a distribuição dos alertas para diferentes sistemas e aplicações.
• Processamento em tempo real: Os consumidores podem processar os alertas à medida que eles são produzidos, permitindo uma resposta rápida a incidentes.
• Filtragem e roteamento: Os consumidores podem filtrar os alertas com base em critérios específicos, permitindo o roteamento para destinos específicos.

Benefícios do Uso do Kafka para Alertas

• Alta escalabilidade: O Kafka pode lidar com um grande volume de alertas, permitindo o crescimento do sistema de monitoramento.
• Baixa latência: A entrega dos alertas é rápida e eficiente, garantindo uma resposta rápida a incidentes.
• Tolerância a falhas: O Kafka é altamente disponível e tolerante a falhas, garantindo a continuidade do serviço mesmo em caso de falhas de hardware ou software.
• Flexibilidade: O Kafka permite a criação de pipelines de dados complexos, permitindo a integração com diversas ferramentas e sistemas.

É importante destacar que funcionalidades como armazenamento para monitoramento posterior em caso de falhas, como uma fila de mensagens não entregues (dead letter queue), não são muito úteis. Isso porque a eficácia de um alerta depende do momento em que ele é recebido. Um alerta atrasado pode causar mais problemas do que soluções.

A Jornada de um Alerta

Neste tópico, vamos detalhar o processo de geração, formatação e envio de alertas desde sua origem nas diversas fontes de monitoramento até a padronização e enriquecimento no kafka-alerta.io. Compreender esse fluxo é fundamental para garantir a eficiência e a qualidade da resposta a incidentes.

Geração do Alerta na Fonte

Cada ferramenta de monitoramento (Zabbix, Dynatrace, OEM, etc.) possui sua própria lógica para detectar condições anômalas e gerar alertas. Essas condições podem variar desde um simples aumento na utilização da CPU até falhas críticas em serviços essenciais. Ao identificar uma condição que excede os limites estabelecidos, a ferramenta gera um alerta, contendo informações como:

• Timestamp: Horário exato da geração do alerta.
• Host: Nome ou IP do equipamento onde ocorreu o problema.
• Serviço: Serviço ou aplicação afetada.
• Métricas: Valores das métricas que disparam o alerta.
• Descrição: Mensagem descritiva sobre o problema.
• Outros campos: Dependendo da ferramenta, outros campos podem ser incluídos, como tags, prioridades, etc.

Formato Proprietário e Envio para o kafka-alerta.io

Cada ferramenta gera alertas em um formato específico, o que dificulta a integração e a análise de dados de diferentes fontes. Para solucionar esse problema, os alertas são enviados para o kafka-alerta.io, um sistema de coleta e processamento de eventos em tempo real.

O envio para o kafka-alerta.io ocorre por meio de uma api-rest, com processadores especializados em converter o formato de cada ferramenta para o formato interno de um alerta.

Normalização no kafka-alerta.io

Ao chegar ao kafka-alerta.io, o alerta passa por um processo de normalização, que consiste em:

• Padronização do formato: O alerta é convertido para um formato comum, garantindo a uniformidade dos dados.
• Ajuste de campos: Os campos do alerta são renomeados e reorganizados para seguir uma estrutura padrão.
• Preenchimento de valores padrão: Campos que não foram preenchidos na fonte são preenchidos com valores padrão.
• Tradução de severidades: As severidades dos alertas são traduzidas para um conjunto de valores padrão (ex: crítico, alto, médio, baixo).
• Enriquecimento com informações adicionais: O alerta pode ser enriquecido com informações adicionais, como informações sobre a infraestrutura, localização geográfica, etc.

Antes:

{
   'version': 'v1',
   'ProblemTitle': 'Failure rate increase',
   'ProblemURL': f'{PROBLEM_URL}',
   'ProblemDetails': {
       'status': 'OPEN' 
   },
}

Depois:

return Alert(
   event=event,
   resource=resource,
   service=['Dynatrace'],
   text=self._create_text(payload),
   environment="Production",
   severity=severity,
   group=group,
   value="-",
   type="Dynatrace Alert",
   status=status,
   origin="dynatrace",
   attributes=attributes,
   timeout=0,
   raw_data=json.dumps(payload, indent=4)
)

No exemplo anterior, um json é recebido e convertido para um objeto Python comum a toda a ferramenta. O mesmo acontece com qualquer outra integração.

Alertas normalizados dentro do kafka-alerta.io para serem enviados ao Kafka

O consumo de um alerta do Kafka ao envio para o Alerta.io

Conforme apresentado anteriormente, o serviço Alert-broker é responsável por ler os alertas, registrar métricas e encaminha-los para o Alerta.io. Durante esse processo, uma rotina de traffic shape é executada assim como uma lista de banimento é consultada para verificar se o alerta deve seguir adiante ou ser descartado. Essas verificações são importantes para assegurar e manter o bom funcionamento do Alerta.io sem sobrecarregar o seu processamento.

Recebendo um alerta do alert-broker e preparando para a exibição ao usuário no Alerta.io

Após receber um alerta, o Alerta.io alimenta uma esteira de plugins com esse alerta. Entre os plugins destacamos o *Enriquecedor de alertas,* responsável por agregar ainda mais informações como nome do time responsável para o alerta, alguns labels adicionais. Há ainda um plugin responsável por enviar o alerta a outra fila Kafka para ficar disponível para outras integrações que podem executar de forma assíncrona como por exemplo a geração de relatórios, envio a ferramentas de mensagens, e-mail, etc. Essa abordagem gera um desacoplamento entre a solução de alertas e as ferramentas interessadas em processá-los. Esse processo pode ser visualizado na imagem que segue:

ciclo de um alerta no Alerta.io

Conclusão

Em um mundo cada vez mais digitalizado e com foco em observabilidade, a capacidade de monitorar e gerenciar os sistemas de forma eficiente é fundamental para garantir a disponibilidade e a performance dos serviços. Ao convergir diversas soluções de monitoramento em uma solução de gerenciamento de alertas centralizada, o Sicredi pode reduzir custos, aumentar a produtividade e melhorar a satisfação dos clientes.

Em resumo, uma visão centralizada de alertas é essencial para:

• Aumentar a visibilidade: Ter uma visão completa da saúde dos sistemas.
• Acelerar a resolução de incidentes: Identificar e resolver problemas rapidamente.
• Melhorar a colaboração: Facilitar a comunicação entre as equipes.
• Otimizar os processos: Automatizar tarefas e reduzir a carga de trabalho.
• Tomar decisões mais informadas: Utilizar dados para tomar decisões estratégicas.