Entenda o que é SNMP, manager e agent, MIB, OID, polling, traps, SNMPv3, segurança e monitoramento de redes e equipamentos de subestações.
Confira!
SNMP é o protocolo mais utilizado para coletar indicadores, estados e alarmes de equipamentos de rede e infraestrutura. Ele permite que uma plataforma de monitoramento consulte switches, roteadores, firewalls, servidores, nobreaks, relógios, gateways e outros ativos, além de receber notificações quando ocorre uma condição relevante.
A arquitetura utiliza um gerenciador, chamado SNMP Manager, e agentes executados nos equipamentos. O gerente solicita informações identificadas por OIDs; o agente responde com valores descritos por uma MIB. Traps e informs permitem que o equipamento envie eventos sem esperar a próxima consulta.
Em subestações, SNMP é especialmente útil para monitorar a infraestrutura de telecomunicações e serviços auxiliares. Ele não substitui protocolos de automação como IEC 61850, DNP3 ou IEC 104. Seu papel é oferecer visibilidade sobre disponibilidade, interfaces, fontes, temperatura, utilização, redundância e falhas dos ativos que sustentam a operação.
O que é SNMP
SNMP significa Simple Network Management Protocol. Ele pertence à camada de aplicação e foi criado para padronizar a supervisão e o gerenciamento de dispositivos conectados a redes IP.
O protocolo trabalha com uma estrutura de objetos gerenciáveis. Cada objeto representa uma informação, como estado de uma interface, contador de bytes, temperatura, nível de bateria ou condição de uma fonte. Esses objetos são identificados por OIDs e organizados em MIBs.
O adjetivo “simple” não significa que a implantação seja trivial. A operação confiável depende de inventário, escolha dos OIDs, frequência de coleta, thresholds, segurança, regras de firewall, sincronismo e integração com a plataforma de monitoramento.
Como funciona a arquitetura manager-agent
O SNMP Manager é a aplicação que consulta os dispositivos, armazena dados, calcula tendências e gera alertas. O agente SNMP é o componente presente no equipamento monitorado. Ele traduz informações internas do dispositivo para objetos acessíveis por SNMP.
A consulta normalmente parte do gerente para o agente. O equipamento responde com o valor solicitado ou com uma indicação de erro. Em sentido inverso, o agente pode enviar traps ou informs ao receptor configurado.
Uma plataforma como o Zabbix pode atuar como gerente, coletando dados de centenas ou milhares de ativos. A capacidade total depende do número de itens, intervalo de polling, latência, quantidade de proxies, retenção histórica e recursos do servidor.
MIB e OID
MIB significa Management Information Base. Ela descreve objetos gerenciáveis, tipos de dados, hierarquia e significado. Uma MIB não contém necessariamente os valores atuais; ela funciona como um modelo que permite interpretar os OIDs expostos pelo equipamento.
OID significa Object Identifier. É uma sequência numérica hierárquica que identifica um objeto. Um OID pode representar, por exemplo, o contador de entrada de uma interface, a temperatura interna ou o estado de uma fonte de alimentação.
Existem objetos padronizados e objetos proprietários. O padrão IF-MIB fornece informações comuns de interfaces, enquanto fabricantes podem publicar MIBs específicas para ventiladores, módulos, alarmes e recursos exclusivos.
A importação da MIB facilita leitura e manutenção, mas a plataforma pode consultar OIDs mesmo sem o arquivo. Nesse caso, a equipe precisa conhecer manualmente o tipo, a escala e o significado de cada objeto.
Índices, tabelas e descoberta
Muitos objetos SNMP pertencem a tabelas. Uma interface não é identificada apenas pelo OID base, mas também por um índice. Esse índice pode mudar após substituição de módulo, atualização ou reinicialização, dependendo do equipamento.
Monitoramentos robustos utilizam descoberta e correlação entre índices, nomes, descrições e identificadores persistentes. Confiar em um número de índice fixo pode fazer com que um item passe a monitorar a interface errada.
A descoberta precisa filtrar interfaces relevantes. Interfaces administrativas, virtuais, de loopback ou temporárias podem produzir milhares de itens sem utilidade operacional. O projeto deve definir quais elementos entram no escopo e como serão nomeados.
Operações GET, GETNEXT, GETBULK e SET
GET solicita o valor de um OID conhecido. GETNEXT retorna o próximo objeto da árvore e é usado para percorrer tabelas. GETBULK, disponível em versões mais recentes, permite recuperar vários objetos de forma mais eficiente.
O comando SET altera um objeto gravável. Em ambientes críticos, sua utilização deve ser excepcional e controlada. A maioria dos projetos de monitoramento precisa apenas de leitura. Habilitar escrita amplia o impacto de credenciais comprometidas ou erros operacionais.
O SNMP Walk é uma sequência de operações que percorre uma parte da árvore. Ele é útil durante levantamento e diagnóstico, mas pode gerar carga elevada em equipamentos sensíveis. O uso deve ser controlado, especialmente em dispositivos legados.
Polling, traps e informs
Polling é a consulta periódica realizada pelo gerente. Ele confirma disponibilidade e coleta valores contínuos, contadores e estados. A vantagem é o controle central da frequência; a desvantagem é que uma mudança pode ocorrer entre duas consultas.
Trap é uma notificação enviada pelo agente sem confirmação de recebimento no nível da aplicação SNMP. Inform é semelhante, mas espera confirmação. O suporte e a nomenclatura variam entre equipamentos.
Traps não substituem polling. Uma notificação pode ser perdida por falha de rede, configuração incorreta ou indisponibilidade do receptor. O polling reconcilia estados e detecta equipamentos que deixaram de responder.
A correlação deve evitar alarmes duplicados. Uma queda de switch pode produzir perda de ping, falhas de polling, traps de vizinhos e indisponibilidade de todos os dispositivos conectados. A plataforma precisa reconhecer dependências para apresentar a causa provável, e não centenas de sintomas isolados.
Como dimensionar a coleta
O intervalo de polling deve refletir a importância e a dinâmica do indicador. Disponibilidade de enlaces críticos pode exigir coleta frequente; capacidade de armazenamento pode ser consultada em intervalos maiores. Aplicar a mesma frequência a todos os itens desperdiça recursos.
O dimensionamento considera quantidade de dispositivos, itens por dispositivo, intervalo, tamanho das respostas, latência, timeout e tentativas. Também precisa prever o volume de histórico e tendências.
Contadores de tráfego devem ser tratados como contadores cumulativos. A plataforma calcula taxas a partir da diferença entre leituras. Reinicializações, rollover e mudanças de velocidade da interface precisam ser interpretados corretamente.
Thresholds fixos nem sempre representam risco. Uma interface operando a 80% por poucos segundos pode ser normal; a mesma utilização sustentada pode indicar saturação. Alertas devem considerar duração, tendência, horário e redundância.
Monitoramento útil começa pela engenharia dos indicadores.
OIDs, intervalos, thresholds, dependências, retenção e capacidade de proxies precisam ser definidos conforme a criticidade de cada ativo.
SNMPv1, SNMPv2c e SNMPv3
SNMPv1 é a versão inicial e possui limitações de desempenho e segurança. SNMPv2c introduziu melhorias, incluindo GETBULK e tratamento mais eficiente de erros, mas continuou utilizando community strings sem proteção criptográfica.
Community strings funcionam como credenciais compartilhadas. Elas são transmitidas sem criptografia no protocolo clássico. Nomes padrão, reutilização entre sites e permissões de escrita aumentam o risco.
SNMPv3 adiciona um modelo de segurança baseado em usuários. Ele pode fornecer autenticação e privacidade, dependendo do nível configurado. Os níveis comuns são noAuthNoPriv, authNoPriv e authPriv.
authPriv é normalmente a escolha mais adequada quando o equipamento e a plataforma oferecem algoritmos compatíveis. Entretanto, a migração precisa avaliar capacidade de CPU, suporte real do firmware, interoperabilidade e procedimentos de rotação de credenciais.
Segurança no SNMPv3
SNMPv3 separa nome de usuário, autenticação e criptografia. O projeto deve definir algoritmos permitidos, senhas, responsáveis, rotação e armazenamento seguro.
Credenciais não devem ser idênticas em todos os ativos. A segmentação por grupos ou sites reduz o impacto de exposição. Contas de leitura e escrita precisam ser separadas, e escrita deve permanecer desabilitada quando não houver necessidade formal.
A segurança também depende da origem autorizada. Mesmo com SNMPv3, o firewall deve permitir consultas apenas dos servidores ou proxies de monitoramento. Dispositivos de campo não devem responder a qualquer host da rede corporativa.
O hardening de servidores e endpoints também se aplica ao gerente, proxies e coletores. Contas, serviços, atualizações, logs e backup da configuração fazem parte da proteção.
Portas, firewall e segmentação
Consultas SNMP utilizam normalmente UDP 161. Traps e informs são enviados normalmente para UDP 162. Esses números não justificam regras amplas; origem, destino e direção devem ser especificados.
O servidor de monitoramento pode estar em uma zona central, enquanto proxies ficam próximos às subestações. Essa arquitetura reduz tráfego através de enlaces WAN e permite armazenar dados durante interrupções.
Quando a plataforma corporativa consome dados de uma rede operacional, a DMZ entre TI e OT pode hospedar coletores, proxies ou serviços intermediários. O desenho deve evitar acesso direto e indiscriminado da TI aos ativos de campo.
Listas de controle precisam considerar redundância. Um segundo servidor ou proxy não pode falhar porque seu endereço não foi incluído nas regras. Alterações devem passar por gestão de mudanças e testes.
SNMPv3 não elimina a necessidade de segmentação e governança.
Usuários, algoritmos, origens autorizadas, proxies, UDP 161/162 e regras de firewall devem fazer parte do projeto de telecomunicações e segurança OT.
Arquitetura de monitoramento em subestações
O monitoramento de uma subestação deve separar ativos de automação, telecomunicações, serviços auxiliares e segurança física. SNMP é mais comum nos equipamentos de rede e infraestrutura, enquanto protocolos específicos atendem proteção e controle.
Switches industriais podem fornecer estado das portas, velocidade, erros, temperatura, fontes e anéis redundantes. Roteadores e firewalls disponibilizam interfaces, túneis, sessões e recursos. Nobreaks e retificadores podem expor bateria, autonomia, falhas e grandezas elétricas.
Relógios e servidores de tempo podem disponibilizar estado de sincronismo, fonte, offset e alarmes. Esses indicadores complementam o projeto de servidor NTP em subestações.
A arquitetura precisa definir o que acontece quando o enlace da subestação falha. O sistema central deve diferenciar perda de comunicação do site e falha individual de dezenas de equipamentos. Proxies locais podem manter coleta e reenviar dados após a recuperação.
O que monitorar em switches e roteadores
Disponibilidade por ICMP não é suficiente. Um equipamento pode responder a ping e, ainda assim, apresentar fonte degradada, erros de interface ou saturação.
Indicadores relevantes incluem estado operacional, velocidade negociada, utilização, descartes, erros, temperatura, CPU, memória, fontes, ventiladores, tabela de vizinhos, redundância e alterações de configuração.
Em anéis industriais, a plataforma deve acompanhar papel e estado do protocolo de redundância. A simples disponibilidade dos switches não demonstra que o caminho alternativo está funcional.
O monitoramento de interfaces precisa considerar propósito. Um uplink, uma porta de IED e uma porta administrativa possuem criticidades diferentes. Nomes e tags devem refletir site, equipamento, bay e função.
Integração com Zabbix
No Zabbix, templates organizam itens, triggers, gráficos, descoberta e macros. Um template genérico pode servir como base, mas equipamentos industriais frequentemente exigem MIBs e thresholds específicos.
A descoberta automática reduz trabalho repetitivo, porém precisa de filtros. Criar itens para todas as interfaces e sensores pode aumentar carga sem gerar valor. O template deve manter apenas os indicadores necessários à operação.
Proxies Zabbix são úteis em sites remotos. Eles coletam localmente e encaminham dados ao servidor. O dimensionamento considera quantidade de valores por segundo, retenção offline, banco local e capacidade do enlace.
A integração pode encaminhar eventos relevantes a um SIEM ou plataforma corporativa, mas a separação entre falha operacional e evento de segurança precisa ser preservada.
Qualidade de alarmes e dependências
Alarmes devem ser acionáveis. Um alerta precisa indicar ativo, condição, impacto, severidade e evidência. Mensagens genéricas como “SNMP unavailable” não explicam se houve perda de rede, credencial incorreta ou agente desabilitado.
Dependências reduzem tempestades. Se o roteador de acesso ao site está indisponível, os dispositivos atrás dele podem ser suprimidos ou marcados como dependentes. Isso mantém foco na causa provável.
Janelas de manutenção evitam alertas durante intervenções autorizadas. Elas devem possuir responsável, período e escopo. Manutenções permanentes ou genéricas ocultam falhas reais.
Projeto e documentação
O projeto deve produzir inventário de ativos, endereços, versão SNMP, credenciais ou perfis, MIBs, OIDs, intervalos, thresholds, dependências, retenção, regras de firewall e arquitetura de servidores e proxies.
Cada item monitorado precisa de nome, unidade, transformação, frequência e condição de alarme. Objetos proprietários devem ser vinculados à documentação do fabricante.
A solução de Redes Industriais deve considerar monitoramento desde a concepção. Adicionar SNMP após a implantação normalmente resulta em credenciais improvisadas, MIBs ausentes e thresholds genéricos.
Comissionamento e aceite
O comissionamento deve validar conectividade, autenticação, leitura dos OIDs, traps, horário, thresholds, dependências e recuperação após perda de comunicação.
Um roteiro mínimo inclui:
- consultar objetos padronizados e proprietários;
- simular falha de porta, fonte ou sensor quando seguro;
- verificar recebimento, severidade e normalização de traps;
- bloquear uma origem não autorizada e confirmar a regra de firewall;
- interromper o enlace do site e validar dependências e recuperação;
- confirmar histórico, tendências, retenção e sincronismo.
Os testes precisam ser registrados. A ausência de evidência torna difícil diferenciar uma função não ensaiada de uma falha surgida depois da entrega.
O aceite deve provar alarmes, dependências e recuperação.
Não basta consultar um OID: traps, perda de enlace, retenção offline, correlação de causa e retorno ao normal precisam ser ensaiados com evidências.
Diagnóstico de falhas
Sem resposta, devem ser verificados rota, ACL, UDP 161, versão, usuário ou community, contexto e agente. Timeout excessivo pode indicar latência, sobrecarga, fragmentação ou equipamento com baixa capacidade.
Resposta com “no such object” pode indicar OID incorreto, MIB incompatível, índice diferente ou objeto não suportado. Valores incoerentes podem exigir transformação, divisão por fator ou interpretação de enumeração.
Traps ausentes exigem verificar endereço do receptor, UDP 162, versão, credencial, rota e configuração de eventos. Também é necessário confirmar se a condição realmente gera trap naquele firmware.
Erros comuns
Os erros mais frequentes são manter SNMPv2c com community padrão, habilitar escrita sem necessidade, liberar UDP 161 para redes inteiras e monitorar apenas ping.
Também é comum importar uma MIB e presumir que todos os objetos precisam ser coletados. Monitoramento excessivo aumenta carga e ruído. O objetivo é selecionar indicadores que apoiem operação, capacidade, manutenção e segurança.
Outro problema é configurar traps sem polling ou polling sem dependências. A arquitetura precisa combinar os mecanismos e representar corretamente as relações entre ativos.
Conclusão
SNMP fornece uma base madura para monitorar equipamentos de rede e infraestrutura. Manager, agent, MIB, OID, polling e traps formam um modelo flexível, mas que precisa ser projetado de acordo com criticidade e capacidade.
Em subestações, SNMP amplia a visibilidade sobre telecomunicações, energia auxiliar e serviços que sustentam o SCADA. A confiabilidade depende de SNMPv3, segmentação, templates, dependências, thresholds e testes de falha. Quando esses elementos são documentados, a plataforma deixa de ser um painel de disponibilidade e passa a apoiar operação e manutenção.
Referências técnicas
[1] CASE, J. et al. RFC 3411 — An Architecture for Describing Simple Network Management Protocol Management Frameworks. IETF, 2002.
[2] PRESUHN, R. et al. RFC 3414 — User-based Security Model for SNMPv3. IETF, 2002.
[3] PRESUHN, R. et al. RFC 3415 — View-based Access Control Model for SNMP. IETF, 2002.
[4] MCCLOGHRIE, K.; ROSE, M. RFC 2863 — The Interfaces Group MIB. IETF, 2000.
[5] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security. Gaithersburg, 2023.
[6] ZABBIX. Documentation — SNMP monitoring, templates and proxies. Disponível em: https://www.zabbix.com/documentation/current/. Acesso em: 13 jul. 2026.
Perguntas frequentes
SNMP é um protocolo de aplicação usado para consultar indicadores e estados de equipamentos, além de receber notificações de eventos.
MIB descreve os objetos gerenciáveis e seu significado. OID é o identificador hierárquico de cada objeto.
Polling é a consulta periódica iniciada pelo gerente. Trap é uma notificação enviada pelo agente sem aguardar a próxima consulta.
Consultas utilizam normalmente UDP 161. Traps e informs são enviados normalmente para UDP 162.
SNMPv2c utiliza community strings sem criptografia. A proteção depende de segmentação e restrição de origem, mas SNMPv3 é preferível quando suportado.
É o nível que combina autenticação e privacidade, protegendo identidade e conteúdo das mensagens conforme os algoritmos configurados.
Objetos graváveis podem ser modificados com SET, mas escrita deve permanecer desabilitada quando não houver necessidade formal.
Não. Traps podem ser perdidos. Polling confirma disponibilidade e reconcilia o estado atual.
É necessário definir ativos, OIDs, MIBs, intervalos, thresholds, dependências, proxies, segurança e testes de falha.
Devem ser verificados versão, credenciais, rota, firewall, agente, OID, índice, MIB e suporte do firmware.
Materiais técnicos complementares
Soluções relacionadas
- Zabbix — Monitoramento de Infraestrutura
- Redes Industriais
- Sistemas SCADA
- Teleassistência e Monitoramento Operativo
Serviços relacionados
Artigos e materiais técnicos relacionados
