Cisco Embedded Event Manager (EEM)

O Embedded Event Manager (EEM)  ou Gerenciador de eventos incorporados

É uma abordagem distribuída e personalizada para a detecção e recuperação de eventos oferecida diretamente em um dispositivo Cisco IOS. O EEM oferece a capacidade de monitorar eventos e tomar ações informativas, corretivas ou qualquer ação EEM desejada quando os eventos monitorados ocorrem ou quando um limite é atingido. 

Uma política EEM é uma entidade que define um evento e as ações a serem tomadas quando esse evento ocorre.

Existem dois tipos de políticas de EEM: um applet ou um script.

1. Um applet é uma forma simples de política que é definida dentro da configuração do CLI. 
2. Um script é uma forma de diretiva que é escrita em Tool Command Language (Tcl).

Um applet EEM é um método conciso para definir critérios de triagem de eventos e as ações a serem tomadas quando esse evento ocorre. No modo de configuração do applet, três tipos de instruções de configuração são suportados. Os comandos de evento são usados para especificar os critérios de evento para acionar o applet a ser executado, os comandos de ação são usados para especificar uma ação a ser executada quando o applet EEM é disparado eo comando set é usado para definir o valor de uma variável de applet EEM . Atualmente, somente a variável _exit_status é suportada para o comando set.

CLI Event Detector

O Detector de eventos CLI exibe comandos de interface de linha de comando (CLI) para uma através de uma expressão regular. Quando uma correspondência é encontrada, um evento é publicado. A lógica de correspondência é executada no comando CLI totalmente expandido após o comando ser analisado com êxito e antes de ser executado.

O detector de eventos CLI suporta três modos de publicação:

• Publicação síncrona de eventos CLI - O comando CLI não é executado até que a política EEM seja encerrada e a política EEM possa controlar se o comando é executado. A variável de leitura / gravação, _exit_status, permite que você defina o status de saída na saída de diretiva para diretivas disparadas de eventos síncronos. 

• Se _exit_status for 0, o comando será ignorado, 
• Se _exit_status for 1, o comando será executado.

• Publicação assíncrona de eventos CLI - O evento CLI é publicado e, em seguida, o comando CLI é executado.

• Publicação assíncrona de eventos CLI com comando ignorando - O evento CLI é publicado, mas o comando CLI não é executado.

Counter Event Detector - Detector de Eventos Contador

O detector de contador de eventos publica um evento quando um contador nomeado cruza um limite especificado.

Há dois ou mais participantes que afetam processamento de contador. 

1. O detector de contador pode modificar o contador, e um ou mais assinantes definem os critérios que fazem com que o evento seja publicado. 
2. Após a publicação de um evento de contador, a lógica de monitoração do contador pode ser reinicializada para iniciar o monitoramento imediato do contador ou pode ser redefinida quando um segundo limite - chamado de valor de saída - é cruzado.

Custom CLI Event Detector - Detector de Eventos CLI personalizado

O detector de eventos CLI personalizado publica um evento para adicionar e aprimorar a sintaxe do comando CLI existente. Quando os caracteres do analisador especial Tab,? (Ponto de interrogação) e Enter, o analisador envia a entrada para o detector de eventos CLI personalizado para processamento. O detector de eventos CLI personalizado compara esta entrada com as cadeias registradas para determinar se este é um comando CLI novo ou aprimorado. Em cima de um fósforo o detetor feito sob encomenda do evento de CLI faz exame de ações apropriadas, tais como indicar a ajuda para o comando se? É inserido, exibindo todo o comando se Tab for inserido, ou executando o comando se Enter foi inserido. Se uma correspondência não ocorrer, o analisador recupera o controle e processa as informações como de costume.

Enhanced Object Tracking Event Detector 

O detector de eventos de rastreamento de objeto avançado (EOT) publica um evento quando o status de um objeto rastreado é alterado. O rastreamento de objetos foi introduzido pela primeira vez no HSRP (Hot Standby Router Protocol) como um simples mecanismo de rastreamento que permitia rastrear apenas o estado do protocolo de linha de interface. Se o estado do protocolo de linha da interface caísse, a prioridade HSRP do roteador foi reduzida, permitindo que outro roteador HSRP com prioridade mais alta se tornasse ativo.

O rastreamento de objetos foi aprimorado para fornecer uma separação completa entre os objetos a serem rastreados ea ação a ser tomada por um cliente quando um objeto rastreado muda. Assim, vários clientes como HSRP, VRRP ou GLBP podem registrar seu interesse com o processo de rastreamento, rastrear o mesmo objeto e cada um tomar ações diferentes quando o objeto muda. Cada objeto controlado é identificado por um número exclusivo que é especificado na interface de linha de comando de controle (CLI). Os processos cliente usam esse número para rastrear um objeto específico. O processo de rastreamento periodicamente examina os objetos rastreados e anota qualquer alteração de valor. As alterações no objeto rastreado são comunicadas aos processos cliente interessados, imediatamente ou após um atraso especificado. Os valores de objeto são relatados como para cima ou para baixo.

O acompanhamento avançado de objetos agora está integrado ao EEM para permitir que o EEM relate uma mudança de status de um objeto rastreado e permita o acompanhamento avançado de objetos para rastrear objetos EEM. Um novo tipo de objeto de rastreamento - um objeto stub - é criado. O objeto stub pode ser manipulado usando os comandos CLI existentes que já permitem que objetos controlados sejam manipulados.

GOLD Event Detector

O detector de eventos GOLD publica um evento quando um evento de falha GOLD é detectado em um cartão especificado e subcard.

Interface Counter Event Detector

O detector de eventos de contador de interface publica um evento quando um contador de interface genérico Cisco IOS para uma interface especificada cruza um limite definido. Um limite pode ser especificado como um valor absoluto ou um valor incremental. Se o valor incremental for definido como 50, por exemplo, um evento seria publicado quando o contador de interface aumenta em 50.

Depois de um evento de contador de interface ter sido publicado, a lógica de monitoramento do contador de interface é redefinida usando dois métodos.

• O contador de interface é redefinido quando um segundo limite - chamado de valor de saída - é cruzado ou quando ocorre um período de tempo decorrido.

Environment Variable

• _interface_is_increment = A value to indicate whether the current interface counter value is an absolute value (0) or an increment value (1).

• _interface_name = The name of the interface to be monitored.

• _interface_parameter = The name of the interface counter to be monitored.

• _interface_value = A value with which the current interface counter value is compared

O exemplo a seguir mostra como uma diretiva chamada EventInterface é acionada toda vez que o contador receive_throttle para a interface Fast Ethernet 0/0 é incrementado em 5. O intervalo de polling para verificar o contador é especificado para ser executado uma vez a cada 90 segundos.

event manager applet EventInterface

 event interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5

 entry-val-is-increment true poll-interval 90

 action 1.0 syslog msg "Applet EventInterface"

IP SLA Event Detector

O detector de eventos IP SLA publica um evento quando uma reação SLA IP é acionada.

NetFlow Event Detector

O detector de eventos NetFlow publica um evento quando um evento NetFlow é disparado.

None Event Detector

O detector de nenhum evento publica um evento quando o comando de CLI do gerenciador de eventos Cisco IOS executa uma diretiva de EEM. O EEM agende e executa políticas com base em uma especificação de evento contida na própria política. Uma política de EEM deve ser identificada e registrada para ser permitida para ser executada manualmente antes que o comando de execução do gerenciador de eventos seja executado.

OIR Event Detector

O detector de eventos de inserção e remoção on-line (OIR) publica um evento quando ocorre um dos seguintes eventos de inserção ou remoção de hardware:

• Um cartão é removido.
• Um cartão é inserido.

Route Processors (RPs), cartões de linha ou cartões de características podem ser monitorados para eventos OIR.

Resource Event Detector

O detector de eventos de recurso publica um evento quando o Gerenciador de Recursos Incorporado (ERM) relata um evento para a diretiva especificada. A infra-estrutura de ERM controla o esgotamento de recursos e as dependências de recursos entre processos e dentro de um sistema para lidar com várias condições de erro. As condições de erro são tratadas fornecendo uma partilha equitativa de recursos entre várias aplicações. O framework ERM fornece um mecanismo de comunicação para entidades de recursos e permite a comunicação entre essas entidades de recursos de vários locais. A estrutura ERM também ajuda na depuração de CPU e problemas relacionados à memória. O ERM monitora o uso de recursos do sistema para entender melhor as necessidades de escalabilidade, permitindo que você configure valores de limite para recursos, como a CPU, os buffers e a memória. O detector de eventos ERM é o método preferido para monitorar recursos no software Cisco IOS, mas o detector de eventos ERM não é suportado em imagens de Software Modularity. Para obter mais detalhes sobre o ERM, vá para o módulo "Embedded Resource Manager"

RF Event Detector

O detector de eventos de estrutura de redundância (RF) publica um evento quando ocorrem um ou mais eventos de RF durante a sincronização em um sistema de processador de rota dupla (RP). O detector de eventos de RF também pode detectar um evento quando um sistema RP duplo alterna continuamente de um RP para outro RP (referido como situação de ping-pong).

RPC Event Detector

O detector de eventos de chamada de procedimento remoto (RPC) fornece a capacidade de invocar políticas de EEM de fora do roteador por meio de uma conexão criptografada usando o Secure Shell (SSH). O detector de eventos RPC usa a codificação de dados SOAP (Simple Object Access Protocol) para trocar mensagens baseadas em XML. Esse detector de eventos pode ser usado para executar políticas EEM e, em seguida, receber saída em uma resposta SOAP XML-formatado.

Routing Event Detector

O detector de eventos de roteamento publica um evento quando uma entrada de rota muda na Routing Information Base (RIB).

SNMP Event Detector

O detector de eventos SNMP permite que um objeto MIB SNMP padrão seja monitorado e um evento a ser gerado quando o objeto coincide com valores especificados ou cruza limites especificados.

SNMP Notification Event Detector

O detector de eventos de notificação SNMP fornece a capacidade de interceptar SNMP trap e informar as mensagens entrando ou saindo do roteador. Um evento de notificação SNMP é gerado quando uma mensagem SNMP de captura ou de entrada de entrada ou de saída corresponde a valores especificados ou cruza limites especificados. O detector de eventos SNMP pode esperar e interceptar as traps SNMP de saída e informa.

SNMP Object Event Detector

O detector de evento de trap de objeto do SNMP (Simple Network Management Protocol) fornece uma extensão para substituir o valor quando um trap SNMP com o ID de objeto SNMP especificado (OID) for encontrado em uma interface ou endereço específico.

Syslog Event Detector

O detector de eventos syslog permite a triagem de mensagens syslog para uma correspondência de padrão de expressão regular. As mensagens selecionadas podem ser mais qualificadas, exigindo que um número específico de ocorrências seja registrado dentro de um tempo especificado. Uma correspondência em um critério de evento especificado aciona uma ação de política configurada.

System Manager Event Detector

O detector de eventos do gerenciador de sistema gera eventos para o início do processo de Cisco IOS Software Modularity, parada normal ou anormal e reinício de eventos. Os eventos gerados pelo gerenciador de sistema permitem que as políticas alterem o comportamento padrão do reinício do processo.

Timer Event Detector

O detector de eventos do temporizador publica eventos para os seguintes quatro tipos diferentes de temporizadores:

1. Um temporizador de tempo absoluto do dia publica um evento quando ocorre uma data e hora absolutas especificadas.
2. Um temporizador de contagem decrescente publica um evento quando um contador de tempo contagem decrescente para zero.
3. Um temporizador de vigilância publica um evento quando um temporizador conta para baixo para zero e, em seguida, o temporizador automaticamente restabelece a si próprio para o seu valor inicial e começa a contagem regressiva novamente.
4. Um temporizador CRON publica um evento utilizando uma especificação CRON padrão UNIX para indicar quando o evento deve ser publicado. Um temporizador CRON nunca publica eventos mais do que uma vez por minuto.

Embedded Event Manager Actions

As ações corretivas baseadas em CLI que são tomadas quando detectores de eventos relatam eventos permitem um poderoso mecanismo de gerenciamento de eventos no dispositivo. Algumas ações do EEM estão disponíveis em cada versão do Cisco IOS, mas a maioria das ações do EEM foi introduzida em uma versão específica. Para obter detalhes sobre qual ação do EEM é suportada em cada versão do Cisco IOS, consulte o conceito EEM Actions Available pelo Cisco IOS Release na seção "Redação de políticas do Embedded Event Manager usando o CLI do IOS Cisco" ou os módulos "Writing Embedded Event Manager Policies Using Tcl" .

A EEM apoia as seguintes ações:

• Executando um comando da interface de linha de comando do Cisco IOS (CLI).
• Gerando um evento CNS para processamento upstream por dispositivos Cisco CNS.
• Definir ou modificar um contador nomeado.
• Mudando para um processador secundário em uma configuração de hardware totalmente redundante.
• Solicitando informações do sistema quando ocorre um evento.
• Enviando um e-mail curto.
• Executando manualmente uma política de EEM.
• Publicando um evento específico do aplicativo.
• Recarregar o software Cisco IOS.
• Gerando uma armadilha SNMP.
• Gerando mensagens syslog priorizadas.
• Lendo o estado de um objeto rastreado.
• Definindo o estado de um objeto rastreado.

Os comandos de CLI da ação EEM contêm um rótulo de ação EEM que é um identificador exclusivo que pode ser qualquer valor de seqüência de caracteres. As ações são classificadas e executadas em seqüência alfanumérica ascendente (lexicográfica) usando o rótulo como a chave de classificação. Se você estiver usando números como rótulos, esteja ciente de que a classificação alfanumérica classificará 10.0 depois de 1.0, mas antes de 2.0, e nessa situação, recomendamos que você use números como 01.0, 02.0 e assim por diante ou use uma letra inicial seguida por números .

Embedded Event Manager Environment Variables

O EEM permite que variáveis ​​de ambiente sejam usadas em políticas de EEM. O Tool Command Language (Tcl) permite definir variáveis ​​globais conhecidas por todos os procedimentos dentro de um script Tcl. O EEM permite que as variáveis ​​de ambiente sejam definidas usando um comando CLI, o comando de ambiente do gerenciador de eventos, para uso dentro de uma diretiva de EEM. Todas as variáveis ​​de ambiente EEM são automaticamente atribuídas a variáveis ​​globais Tcl antes que um script Tcl seja executado.

Existem três tipos diferentes de variáveis ​​de ambiente associadas ao Embedded Event Manager:

• Definido pelo usuário - Definido por você se você criar uma variável de ambiente em uma diretiva que você escreveu.

• Definido pela Cisco - Definido pela Cisco para uma política de amostra específica.

• Cisco built-in (disponível em applets EEM) - Definido pela Cisco e pode ser somente leitura ou leitura / gravação. As variáveis ​​somente leitura são definidas pelo sistema antes que um applet comece a ser executado. A única variável de leitura / gravação, _exit_status, permite que você defina o status de saída na saída de diretiva para diretivas disparadas de eventos síncronos.

Embedded Event Manager Policy Creation

O EEM é um processo orientado por políticas no qual o mecanismo de política EEM recebe notificações quando falhas e outros eventos ocorrem no sistema de software Cisco IOS. As diretivas do Embedded Event Manager implementam a recuperação com base no estado atual do sistema e nas ações especificadas na política para um determinado evento. As ações de recuperação são acionadas quando a diretiva é executada.

Embora existam alguns comandos EEM CLI de configuração e show, o EEM é implementado através da criação de políticas. Uma política EEM é uma entidade que define um evento e as ações a serem tomadas quando esse evento ocorre. Existem dois tipos de políticas de EEM: um applet ou um script. Um applet é uma forma simples de política que é definida dentro da configuração do CLI. Um script é uma forma de política que está escrito em Tcl.

A criação de uma política de EEM envolve:

1. Selecionando o evento para o qual a diretiva é executada.
2. Definir as opções do detector de eventos associadas ao log e responder ao evento.
3. Definindo as variáveis ​​de ambiente, se necessário.
4. Escolhendo as ações a serem realizadas quando o evento ocorre.
5. Há duas maneiras de criar uma política de EEM. O primeiro método é escrever applets usando comandos CLI, eo segundo método é escrever scripts Tcl. A Cisco fornece aprimoramentos para o Tcl na forma de extensões de comando Tcl que facilitam o desenvolvimento de políticas de EEM. Scripts são definidos fora do dispositivo de rede usando um editor ASCII. O script é então copiado para o dispositivo de rede e registrado com o EEM. Quando uma diretiva é registrada no Embedded Event Manager, o software examina a diretiva e registra-a para ser executada quando o evento especificado ocorre. As políticas podem ser canceladas ou suspensas. Ambos os tipos de políticas podem ser usados ​​para implementar o EEM na sua rede.

Pré-requisitos para Redação de Diretivas de EEM Usando o Cisco IOS CLI

• Se o comando action cns-event for usado, o acesso a um gateway de eventos do Cisco Networking Services (CNS) deve ser configurado.
• Se o comando de força de ação for usado, um processador secundário deve ser configurado no dispositivo.
• Se o comando snmp-trap de ação for usado, o comando snmp-server enable traps event-manager deve ser habilitado para permitir que traps SNMP sejam enviados do dispositivo Cisco IOS para o servidor SNMP. Outros comandos snmp-server relevantes também devem ser configurados; Para obter detalhes, consulte a página de comando action snmp-trap.

How to Write EEM Policies Using the Cisco IOS CLI

Fonte:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/eem/configuration/12-4t/eem-12-4t-book/eem-overview.html