Aprimorando a Análise IBM Tivoli Netcool/OMNIbus Mttrapd

Usando a IBM Tivoli Netcool/OMNIbus Knowledge Library e o utilitário MIB2Rules

Este artigo descreve como aprimorar a análise IBM® Tivoli® Netcool®/OMNIbus™ Mttrapd para permitir o processamento de arquivos customizados/novos de management information base (MIB) para sistemas que comunicam status usando o Protocolo Simples de Gerenciamento de Rede (SNMP). A solução utiliza a IBM Tivoli Netcool/OMNIbus Knowledge Library e o utilitário MIB2Rules (m2r) fornecido pela IBM. Um arquivo MIB de exemplo é fornecido e usado para demonstrar os pontos principais.

Peter Tuton, Software Engineer, IBM

Peter TutonPeter Tuton é engenheiro de software da equipe Tivoli Security Integration Factory trabalhando em Gold Coast, na Austrália. Nessa função, Peter é Technical Lead para a equipe que desenvolve soluções de integração para Tivoli Access Manager e Tivoli Federated Identity Manager. Peter participou da certificação de várias soluções de integração da IBM com empresas líderes do setor de software, como Siebel, PeopleSoft e SAP.



Yulei YL Liu, Tivoli Netcool Consultant, IBM

Yulei LiuYulei Liu é consultor senior de Netcool no IBM Australia Development Lab, em Sydney, Austrália. Ele trabalha no segmento de mercado de TI/telecomunicação há mais de 12 anos. Yulei participou de vários projetos Netcool na Austrália e Nova Zelândia.



15/Out/2012

Introdução

A análise IBM Tivoli Netcool/OMNIbus Mttrapd é o listener de trap de Protocolo Simples de Gerenciamento de Rede (SNMP) do IBM Tivoli Netcool/OMNIbus. A análise recebe na rede traps SNMP vindos de vários dispositivos, sistemas e aplicativos (chamados aqui de "dispositivo"), converte-os em eventos com base em um conjunto de regras definidas no arquivo de regras da análise e envia-os a uma instância do IBM Tivoli Netcool/OMNIbus, chamada de ObjectServer. O arquivo de regras é criado com base na definição de Message Information Base (MIB) do dispositivo, geralmente disponibilizado pelo seu fornecedor como um arquivo de texto. O arquivo de regras pode ser processado pela análise Mttrapd como um arquivo independente ou como parte da IBM Tivoli Netcool/OMNIbus Netcool Knowledge Library (KcKL).

A NcKL é um conjunto de arquivos de regras lançado pela IBM para aprimorar a integridade entre dispositivos de terceiros e a análise Mttrapd. Ela contém arquivos de regras predefinidos para centenas de dispositivos populares, criados por especialistas no assunto com conhecimento aprofundado do funcionamento interno de cada dispositivo. Além disso, os arquivos de regras são criados com conhecimento dos alarmes/eventos que o dispositivo pode gerar e seus significados. Por isso, os administradores de IBM Tivoli Netcool devem usar a NcKL sempre que possível para garantir o processamento correto dos traps.

Mas existem muitos dispositivos sem um arquivo de regras de NcKL. Nesse caso, o utilitário MIB2Rules, fornecido pela IBM, pode ser usado para converter qualquer arquivo MIB em um arquivo de regras com suporte a NcKL, para implementação mais rápida. O utilitário MIB2Rules evoluiu além do propósito original de conversão de MIB para regras, o que fez com que ele parecesse difícil de usar quando, na verdade, é muito simples.

Vale mencionar que SNMP não tem conceito padrão de severidade de trap, ou correção de problema/resolução. O protocolo pode definir a funcionalidade disponível para o gerente de SNMP (neste caso, a análise Mtrapd), mas não pode descrever o propósito do dispositivo ou seus componentes. Por esses e outros motivos, é virtualmente impossível criar uma ferramenta que possa automatizar a criação de um arquivo de regras que seja suficiente sem mais modificações.

O restante deste artigo irá delinear as tarefas necessárias para converter um arquivo MIB para um arquivo de regras que possa usar os recursos eficientes de correlação do IBM Tivoli Netcool/OMNIbus. O artigo usará o MIB definido no arquivo SYMTRAP-MIB.mib, disponível na seção downloads. Observação: Não é garantido que esse arquivo MIB seja da versão correta. Ele é fornecido apenas como um exemplo. Procure o proprietário do MIB para obter a sua versão mais atualizada.

Este artigo supõe que a KcKL já está instalada e configurada. Essas informações estão além do escopo do artigo. Para mais informações sobre a KcKL, consulte o centro de informações.


Determinando o MIB

A primeira etapa no processo é determinar e localizar o arquivo MIB que contém a definição dos traps. Traps para os quais não há regras irão manifestar-se como eventos no ObjectServer com Summary de: Unknown Specific Trap Number (specific-trap) Received for Enterprise enterprise, no qual specific-trap é o número do trap e enterprise é o identificador de objeto corporativo alocado pelo fabricante do dispositivo.

Usando o arquivo MIB fornecido como exemplo, um trap para "Symbios SCSI Agent is down" apareceria no campo ObjectServer Summary desta forma:

Unknown Specific Trap Number (102) Received for Enterprise .1.3.6.1.4.1.2.1123

Obviamente, esse valor de Summary não fornece informações para determinar como lidar com o evento. Portanto, o arquivo MIB deve ser localizado e convertido em um arquivo de regras.

A localização do arquivo de regras depende do fornecedor do dispositivo que gera o trap. Na maioria dos casos, o fornecedor fornece o MIB em formato digital, online ou em uma mídia. Além disso, deve haver referências ao MIB na documentação apropriada do produto.

Observe que a maioria dos arquivos MIB tem alguns MIBs dependentes, por exemplo, RFC1212.mib. A maioria dos arquivos MIB dependentes padrão são fornecidos com o utilitário MIB2Rules. Se o MIB não tiver sido fornecido, pode provavelmente ser encontrado na Internet.

Para fins de ilustração, este artigo fornece o MIB de exemplo definido no arquivo SYMTRAP-MIB.mib, que se encontra na seção downloads.

Quando o MIB tiver sido localizado, ele pode ser convertido em um arquivo de regras. A seção a seguir tem mais informações sobre o processo de conversão.


Convertendo o MIB em Regras

Onde encontro o utilitário MIB2Rules?

website de Integrated Service Management Library

Quando o arquivo ou arquivos MIB tiverem sido identificados e localizados, eles podem agora ser convertidos em um arquivo de regras usando o utilitário MIB2Rule. O processo de conversão envolve duas etapas simples:

  1. Importar o MIB para MIB2Rules
  2. Exportar as regras do MIB2Rules

Cada etapa é explicada em mais detalhes abaixo.

Importando o MIB

Siga as instruções abaixo para importar os MIBs do utilitário MIB2Rules:

  • Copie o MIB (por exemplo, SYMTRAP-MIB.mib) e suas dependências não básicas para o diretório $MIB2Rules_Dir/mibs/downloads.
  • Inicie o MIB2Rules usando o método apropriado do sistema operacional
  • Clique no botão Import, ou selecione File - Import... no menu
  • Na janela Import, localize e selecione o diretório $MIB2Rules_Dir/mibs/downloads
  • (Opcional) Se os arquivos MIB estiverem em uma estrutura de diretório com mais de um nível, não deixe de selecionar a opção Traverse Subdirectories.
  • Clique no botão Import.

Após realizar as etapas acima, a janela Status aparece, à medida que o MIB2Rules processa cada arquivo MIB localizado no diretório de importação. Quando concluir, supondo que não haja erros, você receberá uma solicitação para Allow MIB Module Upload?; qualquer opção (Yes/No) é adequada. A notificação dos erros será mostrada na janela Status. Os erros devem ser resolvidos para que o MIB seja exportado. Geralmente os erros estão relacionados a MIBs dependentes que não estão disponíveis.

Quando a importação for concluída, a janela Status exibirá os módulos que foram processados. Leia os detalhes e clique em OK quando concluir. A Figura 1 abaixo mostra os resultados da importação do arquivo SYMTRAP-MIB, fornecido com este artigo.

Figura 1. Importando SYMTRAP-MIB

Dica de Procura

MIB2Rules irá agora exibir o MIB importado na sua janela principal, usando um controle de árvore. Os traps identificados na seção anterior (por exemplo, aqueles sob .1.3.6.1.4.1.2.1123) podem ser localizados filtrando-se a exibição para traps/notificações. Para isso, selecione View - Traps/Notifications. Para localizar os traps apropriados, atravesse o controle de árvore, ou insira um termo de procura apropriado (por exemplo, "symbios") no campo Search e clique em Find. Se o trap estiver na lista, o MIB foi importado com sucesso e está pronto para ser exportado como um arquivo de regras.

A Figura 2 abaixo mostra o MIB importado na janela principal.

Figura 2. SYMTRAP-MIB Importado

Exportando as regras

Siga as instruções abaixo para criar arquivos de regras a partir dos MIBs importados:

  • Localize o OID mais alto (por exemplo, .1.3.6.1.4.1.2.1123.3.1.2.2.0).
  • Clique no botão Export.
  • Selecione o diretório apropriado para o qual exportar o arquivo de regras. Por exemplo, ao exportar para a KcKL, selecione $MIB2Rules_Dir/export/rules/NCKL. Observe que o nome do diretório de exportação não é relevante para o uso desejado do arquivo de regras.
  • Selecione o File type: de Netcool Knowledge Library.
  • A opção Scope pode ser ignorada, pois apenas traps serão exportados para um tipo de arquivo KcKL.
  • Clique no botão Export.

Os arquivos de regras serão criados no diretório selecionado. Se você estiver usando o arquivo MIB de exemplo fornecido, encontrará 9 arquivos no diretório de exportação. Os mais relevantes são aqueles que começam com symbios- (total de três) - os outros arquivos podem ser ignorados. Os arquivos resultantes de uma exportação do MIB de exemplo são fornecidos na seção downloads.

A próxima seção irá discutir como modificar os arquivos recém-criados para que sejam adequados a uma instalação existente da KcKL.


Modificando as regras

Esta seção descreve como modificar os novos arquivos de regras para que sejam adequados à KcKL. Esse processo inclui as seguintes atividades:

  1. Designar severidade, tipo e expiração de trap;
  2. Determinar traps relacionados para correlação de evento e,
  3. Determinar mudanças genéricas.

Cada atividade é descrita em detalhes abaixo.

Designando severidade, tipo e expiração de trap

O processo de designação de severidade, tipo e expiração de trap exige algum conhecimento de cada trap. Se você não for o responsável pela criação do MIB, precisará provavelmente contar com informações de outras pessoas para determinar o propósito de cada trap no MIB. No entanto, qualquer MIB bem escrito contém informações relevantes no campo DESCRIPTION, dando ao menos uma ideia do propósito de cada trap. Os comentários (linhas começando com "--") também podem ter mais informações. Examine o arquivo MIB fornecido, especialmente as linhas 160 - 164, para ver um exemplo.

156:	symSCSI1	TRAP-TYPE
157:		ENTERPRISE  symTrap
158:		DESCRIPTION
159:		"Symbios SCSI Agent is up."
160:		--#SUMMARY "Symbios SCSI Agent is up."
161:		--#SEVERITY INFORMATIONAL
162:		--#STATE OPERATIONAL
163:		--#HELP "symscsi.hlp"
164:		--#HELPTAG 101
165:		::=  101

Cada trap está listado no arquivo de regras exportado com a extensão ".sev.snmptrap.lookup". No nosso exemplo, o arquivo é symbios-SYMTRAP-MIB.sev.snmptrap.lookup. Esse arquivo de consulta contém três colunas: severidade (padrão: 1), tipo (padrão: 0) e expiração (padrão: 0). Examine o conteúdo do MIB para cada trap e determine os valores apropriados dessas colunas.

Severidade mapeia para o campo Severity do evento no ObjectServer com o qual a análise comunica-se. Os valores válidos dependem da implementação, sendo o padrão entre 0 (limpo) e 5 (crítico). Também é possível usar o valor "d" para simplesmente descartar o evento, sem passá-lo ao ObjectServer.

Tipo pode receber o valor 1 (problema) ou 2 (resolução), dependendo do trap, e mapeia para o campo Type do evento no ObjectServer. Observe que traps de resolução devem receber severidade 1. O impacto da designação do campo Type também é discutido em definindo correlação.

Expiração determina o período no qual o evento deve residir no ObjectServer antes de ser removido. O valor é especificado em segundos, sendo o valor padrão 0 (nunca expira). Novamente, o valor a ser usado depende do trap e da importância relativa dele para o ambiente.

Por exemplo, SYMTRAP-MIB define o trap chamado symSCSI5. A DESCRIPTION desse trap é "The SCSI Controller# %d has Failed", com mais comentários sugerindo que o trap tem a severidade CRITICAL. Portanto, os valores recomendados para esse trap são: SNMPTRAP-symbios-SYMTRAP-MIB-symSCSI5 5 1 0, o que significa que o trap receberá a severidade 5 (crítico), tipo 1 (problema) e expiração 0 (nunca expira). Observação: Ignore o "%d" na descrição por ora. Esse marcador é discutido melhor em determinando mudanças genéricas abaixo.

Observe que, em alguns casos, os valores de severidade, tipo e expiração dependem de condições complexas. Por exemplo, a severidade pode ser determinada por um valor contido no trap. Nesses casos, o arquivo de consulta de severidade (o arquivo que termina em ".sev.snmptrap.lookup") não pode ser usado para designar a severidade, tipo ou expiração. Em vez disso, designe o valor no arquivo de regras apropriado (ou seja, o arquivo que termina em ".include.snmptrap.rules"). Além disso, remova ou comente a linha correspondente no arquivo de consulta de severidade.

Por exemplo, podemos querer designar a severidade de traps symSCSI9 dependendo do número de dispositivo específico do Controlador SCSI (cujo valor é designado na linha 171: $scsiController = $1). Modifique o arquivo de regras de acordo com a sua lógica e, em seguida, designe a severidade, tipo e expiração usando os campos, $DEFAULT_Severity, $DEFAULT_Type e $DEFAULT_ExpireTime. Por fim, inclua o caractere "#" no começo da linha 48 em symbios-SYMTRAP-MIB.sev.snmptrap.lookup para comentá-la, desta forma: SNMPTRAP-symbios-SYMTRAP-MIB-symSCSI9 1 0 0.

Definindo correlação

Em muitos casos, traps de problema têm um trap de resolução correspondente. Por exemplo, usando o MIB de exemplo, o trap symSCSI6 é um trap de resolução para o trap de problema symSCSI5, com o significado "SCSI Controller# %d recovered". Portanto, queremos que nosso ObjectServer correlacione os eventos gerados por esses traps.

Por padrão, ObjectServer correlaciona eventos usando o acionador generic_clear (definido em ObjectServer Automations). O acionador generic_clear padroniza as correlações ao examinar o conteúdo do campo Type em vez de examinar resoluções específicas (Link Ativo, Porta Restaurada) e correlacionar com problemas específicos (Link Inativo, Falha da Porta).

Por questão de eficiência, o código que faz a correlação parece complicado, mas o princípio é simples: encontre todos os eventos de resolução (Tipo 2) e associe-os com os eventos de problema correspondentes (Tipo 1) que têm valores idênticos em certos campos (por padrão: Manager, Node, AlertGroup, AlertKey) e têm o relacionamento de tempo correto (o problema ocorreu antes da resolução) e remova-os.

Considerando a funcionalidade do acionador generic_clear, precisamos garantir que os arquivos de regras exportados designem corretamente os valores para os campos usados para correlação. Examinando o arquivo de regras exportado para o MIB de exemplo, observe o valor designado ao campo AlertGroup para o trap symSCSI5 (linha 91): @AlertGroup = "symSCSI5". Esse valor não corresponde ao valor atribuído ao trap symSCSI6 correspondente, que tem o valor a seguir (linha 109): @AlertGroup = "symSCSI6". A alteração desses valores para que sejam iguais (por exemplo, @AlertGroup = "SCSIController") garante que os eventos do ObjectServer sejam correlacionados corretamente (neste caso, os outros campos relacionados à correlação são os mesmos e não necessitam de modificações).

Determinando mudanças genéricas

MIB2Rules tenta designar valores a campos específicos de ObjectServer baseados nas informações disponíveis para ele. No entanto, às vezes os valores designados não são suficientes. Por isso, o arquivo de regras deve ser examinado para determinar se há designações insuficientes e para ser corrigido se necessário.

Usando o arquivo de regras de exemplo, consulte a linha 53 (mostrada aqui como duas linhas):

@Summary = "symSCSI3: The SCSI Controller# %d with ControllerName %s
 and ManagerName Id %s has been discovered"

Observe o uso de "%d" e "%s" - esses valores são designados literalmente no campo Summary, o que obviamente não é correto. Portanto, a linha deve ser modificada desta forma:

@Summary = "The SCSI Controller# " + $scsiController + " with ControllerName "
 + $controllerName + " and ManagerName Id " + $managerName + " has been discovered"

Outro campo que exige atenção especial com frequência é @Identifier. Atenção quando @Identifier incluir variáveis que são data+hora (geralmente a data e hora em que o trap ocorreu). Isso quebra a funcionalidade de correção do ObjectServer (especificamente, a deduplicação).

Agora as regras modificadas estão prontas para mesclagem em uma instalação da KcKL.


Mesclando as Regras

A mesclagem dos novos arquivos de regras na KcKL é um processo simples que inclui as seguintes tarefas:

  • Copie os novos arquivos para o diretório $NC_RULES_HOME/include-snmptrap
  • Modifique $NC_RULES_HOME/snmptrap.rules para:
    • Integre os novos arquivos de regras (por exemplo, symbios-SYMTRAP-MIB.include.snmptrap.rules e symbios-SYMTRAP-MIB.adv.include.snmptrap.rules). Para isso, localize a seção de includes e inclua a seguinte linha:
include "$NC_RULES_HOME/include-snmptrap/symbios-SYMTRAP-MIB.include.snmptrap.rules
    • Inclua a nova tabela de consulta de severidade (por exemplo, symbios.SYMTRAP-MIB.sev.snmptrap.lookup). Para fazer isso, localize a seção de tabelas e inclua as seguintes linhas (Observação: As duas primeiras linhas devem ser inseridas como uma única linha):
table symbios-SYMTRAP-MIB_sev =
	"$NC_RULES_HOME/include-snmptrap/symbios-SYMTRAP-MIB.sev.snmptrap.lookup"
default = {"Unknown","Unknown","Unknown"}
  • Force a análise Mttrapd a reler o arquivo de regras, por exemplo, kill -HUP pid (onde pid é o PID)
  • Realize uma verificação de sintaxe de análise, por exemplo, nco_p_syntax -rulesfile $NC_RULES_HOME/snmptrap.rules. Observação: Essa tarefa exige a análise nco_p_syntax, que pode ser obtida de seu representante IBM.

As regras mescladas estão agora prontas para teste.


Testando as regras

O teste dos novos arquivos de regras envolve simplesmente forçar a geração de um trap. Às vezes isso é fácil de dizer e difícil de fazer. No entanto, alguns dispositivos permitem a geração de um trap de teste, cuja definição deve ser incluída no MIB.

Quando o trap tiver sido recebido e um evento tiver sido gerado no ObjectServer, confirme se os campos relevantes estão corretos, incluindo entre outros: Summary, AlertGroup, AlertKey, Type e Identifier.

Para testar a correlação de evento, caso o ambiente permita, envie um evento de problema seguido de um evento de resolução. Verifique se o evento de problema foi removido depois que o evento de resolução foi gerado. Se os eventos não forem correlacionados, confirme se os campos de correlação correspondem, especialmente o campo AlertGroup.

Por fim, verifique se mais de um trap (com o mesmo valor) geram apenas um evento, com o campo de contagem do evento aumentando para cada trap. Se um novo evento for gerado para cada trap exclusiva, verifique a designação do campo Identifier no arquivo de regras.


Conclusão

A extensibilidade e flexibilidade do IBM Tivoli Netcool OMNIbus permite que diversos dispositivos sejam suportados com esforço mínimo na solução de gerenciamento de eventos. O uso da IBM Tivoli Netcool/OMNIbus Knowledge Library com o utilitário MIB2Rules estende o suporte de dispositivos da análise Mttrapd com pouco esforço e nenhum tempo de inatividade. Observe que a solução não está limitada a dispositivos de rede: ela pode ser estendida a qualquer sistema que se comunica via SNMP, incluindo aplicativos e outras soluções de monitoramento. Isso coloca o IBM Tivoli Netcool/OMNIbus como candidato ideal para a função de "gerenciador de gerenciadores".


Downloads

DescriçãoNomeTamanho
Example MIB1SYMTRAP-MIB.mib17KB
Resulting exported files using example MIBExported-Files.rar6KB

Nota

  1. A versão mais recente do MIB deve ser obtida da Engenio Information Technologies, Inc.

Recursos

Aprender

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli
ArticleID=840479
ArticleTitle=Aprimorando a Análise IBM Tivoli Netcool/OMNIbus Mttrapd
publish-date=10152012