Monitorização e gestão de eventos

O modelo de eventos define, para cada CI ou serviço, quais as alterações de estado que são relevantes e como devem ser classificadas. Um evento é qualquer alteração de estado com significado para a gestão de serviços, podendo ser informativo (estado normal documentado), de aviso (limiar aproximando-se) ou de excepção (limiar ultrapassado ou falha detectada). A qualidade do modelo determina directamente a relação sinal/ruído da monitorização.

Passos chave

• Mapear CIs críticos a partir da CMDB e do catálogo de serviços
• Definir thresholds de desempenho por CI em conjunto com capacity management
• Estabelecer critérios de classificação: informativo, aviso, excepção
• Definir acção de resposta por tipo de evento (log, alerta, remediação, incidente)
• Documentar o modelo num registo de configuração de monitorização

A monitorização pode ser implementada através de diferentes abordagens consoante o tipo de CI. A monitorização por agente instala software no host que recolhe métricas locais com maior granularidade. A monitorização sem agente usa protocolos externos como SNMP, WMI ou chamadas de API. Para ambientes cloud, a observabilidade baseia-se em métricas, logs e traces (os três pilares do modelo OpenTelemetry). Sistemas SIEM centralizam e correlacionam eventos de múltiplas fontes para detectar padrões de segurança.

Métodos de recolha

• Agentes instalados: maior detalhe, requer gestão do agente
• SNMP e WMI: monitorização sem agente para rede e sistemas Windows
• APIs cloud: AWS CloudWatch, Azure Monitor, Google Cloud Operations
• Logs centralizados: ELK Stack, Splunk, Loki para análise de texto
• Tracing distribuído: Jaeger, Zipkin para rastreio de transacções em microserviços

A detecção ocorre quando um CI reporta uma alteração de estado que ultrapassa um threshold configurado ou corresponde a um padrão definido. A detecção baseada em threshold é directa (CPU acima de 90%) mas pode gerar falsos positivos se o threshold não for calibrado. Abordagens mais avançadas usam detecção de anomalias por machine learning, que identifica desvios do comportamento histórico normal sem threshold fixo, reduzindo falsos positivos em ambientes dinâmicos.

Passos chave

• A ferramenta de monitorização avalia continuamente os dados recolhidos
• Quando um threshold é ultrapassado, é gerado um evento
• O evento é registado com timestamp, CI afectado, valor observado e threshold
• A detecção pode ser por polling (intervalo fixo) ou por trap/push (evento imediato)

Cada evento detectado é classificado num de três tipos, determinando a acção de resposta adequada. Os eventos informativos documentam o estado normal do serviço e são registados para auditoria e análise histórica sem acção imediata. Os eventos de aviso indicam que um limiar de precaução foi atingido e requerem atenção preventiva antes de se tornarem excepção. Os eventos de excepção representam uma condição fora do normal que pode afectar a disponibilidade ou desempenho do serviço e requerem acção imediata.

Critérios de classificação

• Informativo: operação dentro dos parâmetros normais, apenas para registo
• Aviso: 70 a 90% do threshold, tendência preocupante, alerta preventivo
• Excepção: threshold ultrapassado, serviço degradado ou indisponível
• A classificação pode ser automática (baseada em regras) ou revista manualmente

Em ambientes complexos, uma única falha de infraestrutura pode gerar centenas de eventos em cascata, tornando impossível identificar a causa raiz sem correlação. A correlação agrupa eventos relacionados, elimina duplicados (deduplicação), identifica o evento raiz e suprime os eventos secundários. Ferramentas como Moogsoft, BigPanda ou funcionalidades nativas de plataformas como Datadog AIOps aplicam correlação baseada em topologia, tempo e padrões históricos para reduzir o noise ratio em ambientes de produção.

Técnicas de correlação

• Correlação temporal: eventos ocorridos dentro de uma janela de tempo definida
• Correlação topológica: eventos em CIs com relações na CMDB
• Deduplicação: supressão de eventos repetidos do mesmo CI e tipo
• Compressão de alertas: agrupamento de eventos similares num único alerta
• Root cause identification: identificação do evento gerador da cascata

A resposta automática, também designada self-healing, é a capacidade de executar acções correctivas sem intervenção humana quando um evento de aviso ou excepção é detectado. Esta abordagem reduz o MTTD (mean time to detect) e o MTTR, e é especialmente eficaz para cenários recorrentes com resolução conhecida. Os runbooks de automação são activados por regras associadas ao modelo de eventos e podem incluir reinicialização de serviços, limpeza de espaço em disco, escalamento automático ou failover.

Exemplos de automação

• Reinício automático de serviço quando processo fica não responsivo
• Limpeza de logs e ficheiros temporários quando disco ultrapassa 85%
• Escalamento horizontal de pods Kubernetes quando CPU ultrapassa threshold
• Failover automático para réplica de base de dados em caso de falha primária
• Notificação via Slack ou Teams com contexto completo do evento

Quando um evento de excepção não é resolvido automaticamente, é criado um incidente no processo de incident management. Esta integração é um dos pontos de interface mais críticos do processo, pois garante que excepções não detectadas por utilizadores são igualmente geridas. O incidente criado deve incluir todo o contexto do evento: CI afectado, dados de monitorização, timeline, acções automáticas já tentadas e resultado.

Passos chave

• Verificar que a excepção não foi resolvida automaticamente
• Criar ticket de incidente via integração com ferramenta ITSM (API ou webhook)
• Incluir dados de contexto: CI, métricas, logs relevantes, timeline do evento
• Atribuir prioridade com base na criticidade do CI e impacto no serviço
• Notificar a equipa de incident management e o service owner

Os dados acumulados de eventos são analisados periodicamente para identificar tendências, padrões recorrentes e oportunidades de melhoria. Dashboards em tempo real permitem à equipa de operações visualizar o estado actual de todos os CIs monitorizados. Relatórios de tendências revelam quais os CIs com maior frequência de eventos, quais os thresholds que geram mais falsos positivos e quais os serviços com maior risco de indisponibilidade. Esta análise alimenta também o processo de problem management e de capacity management.

Conteúdo do relatório periódico

• Distribuição de eventos por tipo (informativo, aviso, excepção)
• Top 10 CIs por volume de eventos e por taxa de excepções
• Taxa de falsos positivos e tendência de melhoria do modelo
• Taxa de resolução automática versus escalação para incident management
• Evolução do MTTD ao longo do tempo

O modelo de monitorização não é estático: deve ser ajustado com base na análise de tendências, no feedback das equipas operacionais e nas alterações ao ambiente. Thresholds demasiado sensíveis geram ruído excessivo e fadiga de alertas, enquanto thresholds demasiado tolerantes atrasam a detecção de problemas reais. O processo de melhoria contínua do modelo reduz progressivamente a taxa de falsos positivos, aumenta a cobertura de monitorização e melhora a capacidade de resposta automatizada.

Acções de melhoria típicas

• Ajustar thresholds com base em dados históricos de desempenho
• Adicionar novos CIs ao âmbito de monitorização
• Criar novos runbooks de automação para eventos recorrentes resolvidos manualmente
• Rever regras de correlação para reduzir falsos positivos
• Integrar feedback de problem management sobre eventos precursores de problemas