iBOLT, uniPaaS & SNMP

Manoel Frederico

O SNMP (Simple* Network Management Protocol) é um protocolo de comunicação, baseado no protocolo UDP, para monitoração de “status”. Usado principalmente para monitoração e manutenção de dispositivos (switches, impressoras, servidores, etc…), o SNMP inclui também uma camada para que aplicações possam ser gerenciadas e monitoradas.

(* pode haver controvérsia se é realmente “simples” :))

E é sobre isto que escreveremos agora: a interface uniPaaS e iBOLT com o protocolo SNMP.

 

Atores Principais do SNMP

De forma resumida, para entender o funcionamento da estrutura padrão:

NMS (Network Management System) – É o monitor propriamente dito. Aquele que fica recebendo as mensagens SNMP dos diversos dispositivos ou aplicativos, e eventualmente envia mensagens a eles também. Um exemplo pode ser o freeware “MIB Browser”.

SNMP Agent – É o componente do sistema operacional que habilita o suporte ao protocolo SNMP. No caso do MS-Windows, é o “Serviço SNMP”.

MIB (Management Information Base) – Uma estrutura (base) de dados hierárquica que identifica as informações (dados & mensagens). Os MIBs são padronizados pelo IANA de forma que diferentes dispositivos e sistemas operacionais consigam trocar informações entre si (por causa do padrão). Por exemplo, o código (MIB) padrão da informação que identifica o nome do servidor (máquina) é 1.3.6.1.2.1.1.5. Qualquer dispositivo que quiser identificar o nome do seu servidor, pode consultar esta variável via SNMP. Um outro padrão importante é a identificação do fabricante ou fornecedor (Enterprise IANA Numbers). Este padrão é definido como 1.3.6.1.4.1.<UID>. Por exemplo, a MAGIC Software Enterprises está cadastrada com o código 15687. Por isso, toda mensagem SNMP que tiver o nó “enterprise” iniciando por 1.3.6.1.4.1.15687 identifica que a mensagem veio (foi emitida) por um produto da MAGIC (no caso uniPaaS ou iBOLT).

PDU (Protocol Data Unit) – É o tipo (formato) da mensagem SNMP que está sendo enviada. Diferentes ações irão gerar mensagens em diferentes formatações. Por exemplo, o PDUGetRequest” é o formato para consultar dados (variáveis), como no exemplo acima do nome da máquina. “SetRequest” é para enviar comandos ou alterar dados dos dispositivos ou aplicativos. “Trap” é para emitir notificações aleatórias (alertas). E existem alguns outros.

 

Recursos SNMP no uniPaaS e iBOLT

Com os módulos de deployment uniPaaS (uniRTE.exe) e servidor iBOLT (iBoltServer.exe), é possível enviarmos “trapsSNMP. O broker (uniRQBroker.exe) permite também “SetRequest” e “GetRequest”.

Neste ‘post’, vamos falar apenas dos “traps”.

 

Configurando o Ambiente

Inicialmente, temos de instalar/habilitar o agente SNMP do sistema operacional utilizado. A lista dos agentes suportados pelo uniPaaS e pelo iBOLT pode ser acessada aqui. No MS-Windows:

 

 

 

No SNMP, os “traps” são enviados a uma comunidade. No próprio painel de serviços do MS-Windows, devemos definir uma comunidade com permissão de leitura e escrita. O padrão é a comunidade pública (public).

 

Existem outras configurações, como filtrar os IPs de quem pode enviar mensagens SNMP. Mas o básico (criar a comunidade public) já será suficiente.

Depois, precisamos habilitar as notificações SNMP no uniPaaS (e iBOLT) editando a seção [SNMP] do arquivo mgreq.ini. Colocando-se EnableAgent=Y já é suficiente, caso o NMS esteja no mesmo servidor. Senão, é preciso informar onde está o NMS (NMSAddress=). Se a comunidade alvo for outra (diferente de public), informar também a (Community=).

Não é obrigatório, mas importante, registrar os arquivos MIB do uniPaaS/iBOLT no NMS. Estes arquivos são disponibilizados na pasta “support”, durante a instalação. Isso facilita a identificação do transmissor das mensagens (traps). No MIB Browser, seria assim:

 

Enviando mensagens (traps)

Algumas mensagens são transmitidas automaticamente pelo broker (uniRQBroker.exe), deployment uniPaaS (uniRTE.exe) e servidor iBOLT (iBoltServer.exe).  Por exemplo, sempre que o broker iniciar ou finalizar, ele envia um “trap” informando isso:

 

Alguns códigos de retorno do Requester (uniPaaS ou iBOLT) também podem ser notificados ao NMS (configuração ReportStatusCode da seção [SNMP] do mgreq.ini).

Outro exemplo: existe uma configuração no MAGIC.INI ([MAGIC_ENV] DatabaseConnectionsUtilizationThreshold) que define um percentual de segurança em relação ao valor máximo permitido de conexões a um DBMS (gerenciador de banco de dados). Se houver um limite (de segurança) definido, e o número de conexões ultrapassar este limite, um “trap” será automaticamente enviado.

E existem também os “traps” manuais, que podem ser enviados por nossas aplicações e projetos.

No uniPaaS, isso é feito através da função SNMPNotify():

 

No iBOLT, isso é feito através do componente SNMP:

 

Além disso, nos interceptadores de erros dos fluxos iBOLT, uma mensagem (trap) automática pode ser associada a ocorrência de um determinado erro:

 

Manoel Frederico da Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

 

2 comentários

  1. Essa questão está relacionada com os erros apresentados no dispositivo mobile quando utilizada uma aplicação RIA/Mobile? Como exemplo, quando uma aplicação está rodando no Android e o servidor deixa de funcionar o Broker, tem o erro -102 ou -107, teria como suprimir essa informação ou manipular os dizeres dela para ficar mais amigável ao usuário final?

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *