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
Top Related