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
