Sistema de Detecção de Falhas baseando em Naive

Bayes

Ricardo ClementeJun - 2007

Índice Problema Proposta de solução Trabalho realizado Experimentos Conclusão

Problema Ambiente de TI com centenas de servidores,

roteadores, aplicativos, etc sendo constantemente monitorados.

Cada ponto de monitoração é capaz de gerar alarmes para um sistema central quando está fora de sua operação padrão.

Nem sempre um alarme signfica uma falha real Threshold mal configurados, ou desatualizados

(ex: número máximo de sessões) Alarmes não significativos (ex: query lenta)

Problema Grande volume de alarmes por

intervalo de tempo torna inviável uma análise humana em tempo real para identificar falhas reais.

Sistema capaz de correlacionar eventos de alarmes e gerar uma informação de alto nível seria grande utilidade

Proposta da solução Inspirada em soluções anti-spam Utilizar Naive-bayses como base do

algoritmo de classificação Sistema capaz de calcular a

probabilidade de uma falha de indisponibilidade, dado os eventos de alarme que ocorreram em uma janela de tempo definida P(falha indisponibilidade | eventos alarmes)

Proposta da solução O sistema a ser criado é composto

por: Módulo de diagnóstico Módulo de treinamento Módulo coletor (acesso ao banco)

Proposta da solução O processo de treinamento deve funcionar da seguinte

forma: Em intervalos de 10 minutos o módulo coletor varre os

30 minutos anteriores. O coletor entrega para o módulo de treinamento uma

tabela com os alarmes e uma contagem de quantas vezes ele apareceu em um determinado tempo.

O módulo de treinamento consulta a base de falhas para saber se existem falha para o período

O módulo de treinamento atualiza a base de conhecimento com a contagem de cada alarme para casos de falha e não-falha

Proposta da solução O processo de diagnóstico deve funcionar da seguinte forma:

Em intervalos de 10 minutos o módulo coletor varre os 30 minutos anteriores.

O coletor entrega para o módulo de diagnóstico uma tabela com os alarmes e uma contagem de quantas vezes ele apareceu em um determinado tempo.

O módulo de dignóstico consulta a base de conhecimento que possui a contagem de cada alarme para casos de falha e não-falha

Com base nesta informação, o módulo de diagnóstico calcula a probabilidade de ter ocorrido uma falha

Se a probabilidade for maior que 90%, o módulo de diagnóstico alarma.

Trabalho realizado Transformação dos dados dos

alarmes Estrutura de dados atual é imprópria Criado software de transformação Executado o software em base de 3GB

Desenvolvimento do módulo de treinamento

Desenvolvimento do módulo de diagnóstico

Trabalho realizado Realização de dois experimentos Limitações:

Registro de falhas só dos meses de maio

Confiabilidade baixa destes registros Registros não estruturado de falhas

Experimentos Experimento 1

Treinar com as falhas disponíveis; Diagnosticar os eventos de alarmes

disponíves Salvar os diagnósticos em planilhas Analisar os resultados

Experimentos Experimento 2

Treinar com as falhas disponíveis menos uma;

Diagnosticar os eventos de alarmes disponíves

Salvar os diagnósticos em planilhas Analisar os resultados Verificar o resultado para a falha retirada

Experimentos - Alarmes

• Base de dados é formada por eventos de alarmes coletados entre os dias 01 e 24 de maio de 2007

• Total de 73.520 alarmes

•Cada evento de alarme possui um código que identifica o alarme e um timestamp.

Experimento - Falhas

ID INÍCIO FIM1 5/8/2007 9:48 5/8/2007 11:302 5/8/2007 13:13 5/8/2007 13:333 5/8/2007 21:25 5/8/2007 23:504 5/20/2007 19:34 5/20/2007 19:365 5/22/2007 15:40 5/22/2007 15:56

• Cinco falhas que representaram indisponibilidade de algum serviço no mês de maio.

Experimentos - 1 Janela de 30 minutos Período de 10 minutos Total de 3687 observações Todas salvas em uma planilha

Experimentos - 1 Total de observações classificadas com

mais de 90% que se enquadram dentro das falhas cadastradas: 108

Total de observações classificadas com menos de 90% que se enquadram dentro das falhas cadastradas: 8

Estas oito observações correspondem a um único período de falha. Provavelmente a falha ocorrida não deveria ter alarmes específicos e significativos.

Experimentos - 1 Total de observações classificadas

com mais de 90% que não se enquadram dentro das falhas cadastradas: 143

Este número deve corresponder: Falhas não registradas Manutenções realizadas sem

desligamento dos alarmes

Experimentos - 1 Número de alarme não é por si só

um bom indicador: Número de alarmes pequeno e alta

probabilidade

Número de alarmes grande e baixa probabilidade

observação probabilidade número de alarmes5/7/2007 17:21 0.9828656 2

observação probabilidade número de alarmes5/15/2007 17:31 0.01 17

Experimentos - 2 Retirar de 1 falha do treinamento

Verificar o comportamento do classificador durante o espaço de tempo correspondente a falha retirada

ID INÍCIO FIM1 5/8/2007 9:48 5/8/2007 11:302 5/8/2007 13:13 5/8/2007 13:333 5/8/2007 21:25 5/8/2007 23:504 5/20/2007 19:34 5/20/2007 19:365 5/22/2007 15:40 5/22/2007 15:56

Experimentos - 2 Comportamento no período:

observação probabilidade número de alarmes5/20/2007 19:31 0.01 25/20/2007 19:41 0.99 245/20/2007 19:51 0.99 245/20/2007 20:01 0.99 275/20/2007 20:11 0.01 95/20/2007 20:21 0.01 8

Experimentos - Limitações Somente 5 registros de falhas Registro é falho: nem todas as falhas

são devidamente registradas. Não há classificação das falhas. Se

houvesse uma classificação, no sentido de identificar o serviço afetado, seria possível ter probabilidades de falhas por serviço.

Conclusão Registro completo das falhas é

determinante para um bom treinamento

Resultados fazem sentido Séries de com alta probabilidade são

indícios de falhas Resultados dos experimentos (excel)

Para ter maior certeza somente com mais dados