Fundamentos SNMP para gerenciamento de rede corporativa

Fundamentos de
gerenciamento de redes
corporativas e proposta de
implementação utilizando
SNMP
Rafael Rodrigues de Oliveira

Conteúdo
• Motivação.
• Aspectos teóricos.
• Estudo de caso.
• Conclusão.
• Bibliografia.

Motivação
• Sociedade dependente dos sistemas informatizados.
• Indisponibilidade dos computadores trazem transtornos
e prejuízos.
• Prevenir e detectar as falhas rapidamente.
• Monitoramento manual inviável.
• Automatização do gerenciamento de redes.

Desafios atuais do
gerenciamento de redes
• Crescimento da internet (rede global).
• Redes locais maiores e mais complexas.
• Gerenciamento remoto dos ativos.
• Prestadoras de serviço precisam atingir obrigações
contratuais.
• Detectar falhas de hardware e software.
• Necessidade de notificação de infecção a rede.

Vantagens da automatização
do monitoramento
• Administrador pode se dedicar a outras tarefas.
• Aumento da disponibilidade dos serviços.
• Auxílio no cumprimento dos SLAs.
• Notificação automática dos problemas.
• Verificação da carga de uso dos equipamentos.
• Redução de gastos.

SNMP (Simple Network
Management Protocol)
• Padrão na internet.
• Definido na RFC1157.
• Camada de aplicação (OSI/ISO).
• Atualmente na versão 3.
• Contido em vários ativos (roteadores, impressoras, etc).

Componentes do SNMP
• Gerente SNMP.
• Dispositivo gerenciado
(servidor, switch, etc).
• Agente SNMP.
• Management
Information Base
(MIB).
Fonte: http://www.cisco.com

Funcionamento do SNMP
• Protocolo UDP no transporte (sem confirmação).
• Overhead mínimo.
• Troca de informações através de mensagens SNMP.
• Mensagens possuem: versão, comunidade e uma das
PDUs (Protocols Data Units).
• Comunidade SNMP (“senha”).

MIB (Management
Information Base)
• Organização hierárquica.
• Separação por pontos.
• Identificação através do OID (Object Identifier).
• Exemplo de item: .1.3.6.1.2.1.25.3.3.1.2.2.

Fonte: http://www.cisco.com.br

Limitações do SNMP
• Administrador necessita conectar ao ativo manualmente.
• Não possui histórico dos dados.
• O único “alerta” SNMP é o “trap”.
• Alguns valores não são claros.

Ferramentas de
monitoramento
• Potencializam o uso do SNMP.
• Armazenam informações de histórico.
• Geram gráficos e mapas da rede.
• Enviam alertas para diversas mídias.
• Várias opções livres (Zabbix, Nagios, etc) ou
proprietárias.

• http://oss.oetiker.ch/mrtg
• Desenvolvido por Tobias Oetiker.
• Programado em Perl.
• Faz uso do SNMP para coleta dos dados.
• Permite gerar gráficos de processador, memória, etc.
• Gera os gráficos e o arquivo HTML para visualizá-los.
• Instalação simples.
• Configuração através de arquivos texto.
• Não envia alertas.

Fonte: http://linux.softpedia.com

• http://www.cacti.net
• Desenvolvido inicialmente por Ian Berry.
• Programado em PHP.
• Banco de dados MySQL.
• Aceita scripts em Bash, Perl, XML, etc.
• Coleta dos dados através do SNMP.
• Interface web para exibição dos gráficos.
• Não envia alertas.

• http://www.nagios.org
• Desenvolvido sob liderança de Ethan Galstad.
• Possui interface web.
• Permite monitorar os serviços.
• Envia alertas através de e-mail, pager, etc.
• Configuração através de arquivos texto.
• Possui plugins para monitorar diferentes plataformas.
• Não gera gráficos.
• Existem vários “add-ons”.

• http://www.zabbix.com
• Mantido pela Zabbix SIA.
• Programado em C e PHP.
• Compatível com vários banco de dados (MySQL,
Postgree, Oracle).
• Configuração dos itens através da interface web.
• Suporta auto-descoberta de ativos.
• Suporte a gráficos.
• Agentes para vários sistemas operacionais.

• Envia alertas através de e-mail, SMS, Jabber, etc.
• Permite a criação de mapas da rede.
• Utiliza “templates” na associação dos itens.
• Suporta diferentes níveis de privilégio para os usuários.
• Suporte a alertas sonoros no frontend web.
• Compatível com o SNMP.
• Suporta “traps” SNMP.

A empresa
• Finamax S/A C.F.I.
• Ramo financeiro.
• Fundada em 1995.
• Matriz em Jundiaí, SP.
• Agências em várias cidades do interior de São Paulo.

Servidor de monitoramento
• Sistema operacional: Ubuntu Server 10.04 AMD_64.
• Processador: AMD Athlon 64 X2 2.3 GHz.
• Memória RAM: 4 GBytes.
• Disco rígido: 80 GBytes.
• Ferramenta de monitoramento: Zabbix 1.8.3.
• Banco de dados: MySQL 5.1.

Ativos de rede
Ativo Quantidade
Switches 17
Servidores Linux1 2
Servidores Windows 33
Servidores OpenBSD2 15
Rádios 2
Terminais de Saque2 2
Roteadores 2
Links de internet2 4
Storage 1
No-Break 1
Total 79
1. Está incluso o servidor de monitoramento.
2. Ativos não monitorados através do SNMP.

Exemplos de configuração
Exemplos de instalações do Zabbix (Zabbix SIA, 2010)

Por que foi utilizado o SNMP?
• Problemas com o agente da ferramenta.
• Compatibilidade do SNMP com múltiplos ativos.
• Baixo consumo de recursos.
• MIB contém muitos itens.

Processador
• OID do item .1.3.6.1.2.1.25.3.3.1.2.[índice].
• Windows: índice começa por 2.
• Linux: inicia por 768.
• Valor retornado: inteiro de 0 a 99.
• Verificado a cada 60 segundos.

Item de processador configurado no Zabbix

Processador
• Linux: itens de CPU adicionados ao “template” padrão.
• Windows: Um “template” cada CPU (core).
Template Item criado no Zabbix OID
Template_CPU0 CPU0 Load .1.3.6.1.2.1.25.3.3.1.2.2

Gráfico de utilização de
CPU

Disco
• OID do item .1.3.6.1.2.1.25.2.3.1.5.[índice]: tamanho total
do volume.
• OID do item .1.3.6.1.2.1.25.2.3.1.6.[índice]: espaço
ocupado.
• Índice variável, não há padrão.
• Desenvolvido um shell script que recebe nome do
volume e S.O.
• Valor retornado: quantidade de blocos (clusters).
• Intervalo para o tamanho total: 86400 segundos (1 dia).
• Intervalo para os demais (espaço livre e usado): 120
segundos.

Item de partição para um servidor Linux

Disco
• No início, itens de disco foram associados ao “template”
padrão do S.O.
• Posteriormente, foi criado um “template” para cada
volume.

Gráfico de utilização de disco

Memória
• OID SNMP semelhante ao disco.
• Dois shell scripts que verificam a memória total e a
utilizada.
• Recebe os parâmetros “virtual” ou “fisica”.
• Valor retornado em unidades de alocação.
• Linux: 1024. Windows: 65535.
• Intervalo de verificação para memória total: 86400
segundos.
• Intervalo para a quantidade utilizada: 120 segundos.

Item de verificação da utilização de memória em um servidor Windows

Serviços
• Aplicações fornecidas aos usuários.
• Uma solução seria verificar se a porta está “aberta”.
• Verificar se o processo está em execução.
• A tabela de processos em execução está em
.1.3.6.1.2.1.25.4.2.1.7 .[índice].
• Índice do processo variável.
• Utilização de um shell script que recebe o nome do
processo.
• Retorna “1” para OK, “0” para falha.
• Intervalo de verificação: 45 segundos.

Item de verificação de serviço em um servidor Linux

Alguns serviços monitorados
Serviço Executável
Servidor DHCP (Windows) Tcpsvcs.exe
Servidor DNS (Windows) Dns.exe
SQL Server Sqlservr.exe
SQL Server Agent SQLAGENT.EXE
IIS Admin Service Inetinfo.exe
Oracle (Windows) Oracle.exe
Oracle (Linux) Oracle

Uptime
• Tempo desde a última
inicialização do sistema.
• OID na MIB .1.3.6.1.2.1.1.3 .
• Intervalo de verificação: 300
segundos.
• Windows: Multiplicador de
.001.
• Linux: multiplicador de .01.
• Tipo configurado: uptime.

Tráfego de rede
• OID .1.3.6.1.2.1.2.2.1.10.[índice] (in).
• OID .1.3.6.1.2.1.2.2.1.16.[índice] (out).
• Servidores com mais de uma interface.
• Várias sub-redes.
• Shell script recebe “I” ou “O”; qual sub-rede pertence a
interface; versão do SNMP; comunidade.
• Valor retornado: número de octetos.
• Intervalo de verificação: 60 segundos.

Status da interface
• OID .1.3.6.1.2.1.2.2.1.8.[índice].
• Interface não conectada ao Zabbix.
• Shell script recebe: a sub-rede; versão do SNMP;
comunidade.
• Retorna um número que indica o status.

Item de verificação status da interface

Eventos do Windows
• Event to Trap Translator (evntwin).
• Eventos configurados geram um “trap” SNMP.
• Configurados eventos relacionados ao serviço em
execução no servidor.

Tela de configuração do evntwin

Servidores Dell
• Open Manage acrescenta a MIB do S.O. vários novos
itens.
• Temperatura, rotação dos fans, status do chassis, fontes
de alimentação, etc.
• Intervalo de verificação 45 segundos.

Alguns itens acrescentados
a MIB
Nome do item OID na MIB SNMP do S.O.
Disk controller 1 status .1.3.6.1.4.1.674.10893.1.20.130.1.1.37.1
Power Supply status .1.3.6.1.4.1.674.10892.1.200.10.1.9.1
BMC Fan 1 RPM .1.3.6.1.4.1.674.10892.1.700.12.1.6.1.1
PROC_1 Temp .1.3.6.1.4.1.674.10892.1.700.20.1.6.1.1
Fan Status .1.3.6.1.4.1.674.10892.1.200.10.1.21.1

Gráfico de temperatura de
CPU

Switches
• Monitoração do “uptime” (mesmo OID dos servidores).
• Foram configurados para enviar “traps”.
• Inviável monitorar o tráfego de todas as portas.

No-Break
• Equipamento da APC.
• Possui na MIB itens para monitorar diversos
componentes.
Baterias.
Módulos de inteligência.
Tensão.
Tempo em bateria.
Entre outros.

Alguns itens contidos na
MIB
Descrição do item OID do item na MIB
Battery status .1.3.6.1.4.1.318.1.1.1.2.1.1.0
Battery temperature .1.3.6.1.4.1.318.1.1.1.2.2.2.0
Time on battery .1.3.6.1.4.1.318.1.1.1.2.1.2.0
Power module 1 status .1.3.6.1.4.1.318.1.1.1.13.2.2.1.2.1
Inteligence module (MIM) status .1.3.6.1.4.1.318.1.1.1.13.1.2.1.3.1

Gráfico de temperatura da
bateria do No-Break

Rádios
• Interligam os dois prédios.
• Monitorado o tráfego das
interfaces.
• Status da interface
“wireless”.
• Uptime.

Roteadores
• Tráfego nas interfaces.
• Status das interfaces.
• Uptime.

Storage
• MIB SNMP limitada.
• Item de OID
1.3.6.1.3.94.1.6.1.6.5.0.0.6.0.1.6.0.11.8.14.0.0.13.2.15:
status geral do equipamento.
• Retorna: 3 OK; 4 problema menos grave; 5 para
anomalia crítica.
• Uptime.
• Envia “traps” SNMP.

Triggers
• Utilizados para indicar um problema em algum item.
• Permite o uso de expressões com comparações ( <, >, =,
etc).
• Também são associados aos “templates”.

Alguns triggers configurados
Item Trigger Condição normal Expressão
Free disk space on
{PARTIÇÃO}
Volume {PARTIÇÃO}
low free disk space
Espaço livre >= 2.4
GB
Espaço livre < 2.4 GB
Storage Status Storage Status:
Warning
Status do storage = 3 Status do storage = 4
PROC Temp PROC Temp Max
Failure
Temperatura <= 90°C Temperatura > 90°C
Battery Temperature High Battery
Temperature
Temperatura <= 40°C Temperatura > 40°C
CPU Load CPU Load is too high
on {HOSTNAME}
Uso de CPU <= 85% Uso de CPU > 85%
Host uptime {HOSTNAME} has
just been restarted
Tempo >= 1h Tempo < 1h

Alertas
• Definidos a partir dos triggers.
• “Traps” SNMP são enviados por
e-mail.
• Demais são visualizados através
da TV LCD.

• Administrador fica livre para outras tarefas.
• Detecção rápida de uma anomalia.
• Prever a ocorrência de um problema.
• Possuir histórico de informações acerca dos ativos.
• Tirar proveito do potencial do SNMP.
• Ótimas soluções livres para monitoramento de redes.
Conclusão

Bibliografia
Cisco. Simple Network Management Protocol (SNMP).
URL: http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNMP.html.
Dell®. Dell OpenManage Server Administrator Version 1.0 to 6.2 SNMP reference guide. URL:
http://support.dell.com/support/edocs/software/svradmin/6.3/en/SNMP/1.0-6.2/HTML/index.htm.
HALL, Eric A. Trapping Windows Events with SNMP. URL: http://www.eric-a-
hall.com/articles/20050715.html.
KUROSE, James F; ROSS, Keith W. Redes de computadores e a internet: Uma abordagem top-
down. 3 ed. São Paulo: Pearson, 2006.
NETO, Arlindo Follador; UCHÔA Joaquim Quintero. Ferramentas livres para monitoração de
servidores. URL: http://www.ginux.ufla.br/files/artigo-ArlindoNeto,JoaquimUchoa.pdf.
Zabbix SIA. Zabbix 1.8 Manual. URL: http://www.zabbix.com/documentation/1.8/complete.

Rafael Rodrigues de Oliveira
rafa.tecoy@gmail.com
http://tecoytech.blogspot.com
Perguntas?

Fundamentos SNMP para gerenciamento de rede corporativa

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Fundamentos SNMP para gerenciamento de rede corporativa

Semelhante a Fundamentos SNMP para gerenciamento de rede corporativa (20)

Mais de marleigrolli

Mais de marleigrolli (13)

Fundamentos SNMP para gerenciamento de rede corporativa