4linux-Zabbix PDF

Soluções de Monitoramento com
Zabbix
Valter Douglas Lisbôa Júnior
www.4linux.com.br
-2
Sumário
Capítulo 1
Conhecendo o Zabbix..................................................................................................................12
1.1. Conhecendo a ferramenta................................................................................................13
1.2. Comunidades e forums....................................................................................................13
Capítulo 2
Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema..........................................14
2.1. Introdução........................................................................................................................15
2.2. Configurando os componentes de recebimento de alertas............................................15
2.2.1. Configurando o cliente de correio eletrônico........................................................................16
2.2.2. Mensagens instantâneas.........................................................................................................24
2.3. Obtendo os fontes do Zabbix...........................................................................................27
2.4. Preparando o banco de dados.........................................................................................27
2.4.1. Instalação................................................................................................................................28
2.4.2. Criando o usuário e o banco...................................................................................................28
2.4.3. Carga inicial............................................................................................................................30
2.4.4. Concedendo as permissões necessárias ao usuário...............................................................30
2.5. Instalação do servidor Zabbix via código fonte..............................................................31
2.5.1. Dependências de compilação..................................................................................................34
2.5.2. Compilando e instalando.........................................................................................................35
2.5.3. Serviços de rede......................................................................................................................37
2.5.4. Arquivos de configuração.......................................................................................................37
2.5.5. Testando sua instalação..........................................................................................................39
2.5.6. Scripts de boot........................................................................................................................41
2.6. Instalação do agente Zabbix via compilação..................................................................41
2.6.1. Exercício: compile e instale o agente nas VM com Gnu/Linux..............................................42
2.6.2. Acesso ao agente pelo servidor..............................................................................................42
2.6.3. Exercício sobre instalação de agente em Linux.....................................................................46
2.7. Instalando o agente em ambientes Windows..................................................................46
2.7.1. Executando o agente como serviço........................................................................................50
2.8. Instalação do agente Zapcat para JBoss.........................................................................52
2.8.1. Obtenção do binário................................................................................................................52
2.8.2. Deployment.............................................................................................................................52
2.8.3. Opções de inicialização do JBoss............................................................................................53
2.8.4. Liberando o firewall para acesso ao Zapcat...........................................................................55
2.9. Testando o acesso via SNMP...........................................................................................55
2.9.1. Conceitos de SNMP.................................................................................................................56
-3
2.10. Instalando o servidor Zabbix via pacote.......................................................................57

2.11. Preparando o servidor web............................................................................................58
2.11.1. Instalação do Apache e PHP5...............................................................................................58
2.11.2. Configuração do Virtual Host...............................................................................................58
2.11.3. Configurando o front end......................................................................................................61
2.12. Exercícios de revisão.....................................................................................................72
Capítulo 3
Criando uma Infraestrutura de Monitoramento - Parte 2, Front end.......................................74
3.1. Introdução........................................................................................................................75
3.1.1. Organização do front end.......................................................................................................75
3.2. Gerenciamento de usuários.............................................................................................77
3.2.1. Cadastrando os usuários do LDAP no Zabbix........................................................................81
3.3. Meios de alertas...............................................................................................................83
3.3.1. Correio eletrônico...................................................................................................................84
3.3.2. Mensagens instantâneas.........................................................................................................84
3.3.3. Apontando os alertas aos usuários.........................................................................................85
3.3.4. Boas práticas com Media types..............................................................................................87
3.4. Hosts, host groups e templates.......................................................................................87
3.4.1. Templates para o caso de estudo............................................................................................88
3.4.2. Vínculo entre templates..........................................................................................................90
3.4.3. Backup dos templates.............................................................................................................91
3.4.4. Hosts........................................................................................................................................91
3.4.5. Gerenciando os Host Groups..................................................................................................92
3.4.6. Criando um novo host.............................................................................................................93
3.4.7. Fazendo backup dos hosts......................................................................................................95
3.4.8. Configurando uma permissão de acesso................................................................................95
3.4.9. Exercícios sobre usuários, hosts, grupos e permissões.........................................................97
3.5. Mapas...............................................................................................................................98
3.5.1. Importando imagens para o mapa..........................................................................................98
3.5.2. Criando um mapa..................................................................................................................100
3.5.3. Adicionando um elemento.....................................................................................................103
3.5.4. Editando um elemento do mapa...........................................................................................104
3.5.5. Salvando o mapa...................................................................................................................106
3.5.6. Adicionando os outros elementos.........................................................................................106
3.5.7. Criando e editando links.......................................................................................................110
3.5.8. Prática Dirigida.....................................................................................................................111
3.5.9. Exercícios sobre Mapas........................................................................................................113
3.6. Templates, applications e items....................................................................................114
3.6.1. Criando um Application e um Item dentro de um template................................................115
3.6.2. Interdependência de templates............................................................................................118
3.7. Associando os templates aos hosts................................................................................120
-4
3.8. Ativando um host............................................................................................................123

3.8.1. Throubleshooting para itens com problemas.......................................................................124
Capítulo 4
Monitoramento voltado para disponibilidade..........................................................................128
4.1. Introdução......................................................................................................................129
4.2. Checagens manual via front end...................................................................................129
4.2.1. Adequando o script de traceroute........................................................................................132
4.2.2. Criando novos comandos para o menu.................................................................................135
4.2.3. Exercícios..............................................................................................................................138
4.3. Checando disponibilidade via protocolo ICMP.............................................................138
4.3.1. Como funciona o ping ICMP.................................................................................................138
4.3.2. Visualizando o ping ICMP no Front end...............................................................................139
4.3.3. Criando um gatilho de parada de host.................................................................................141
4.3.4. Lidando com os eventos........................................................................................................146
4.3.5. Criando uma action para envio de alerta.............................................................................150
4.3.6. Exercícios..............................................................................................................................153
4.3.7. Boas práticas com triggers...................................................................................................154
4.4. Checagem genérica de portas e serviços......................................................................156
4.4.1. Conexões TCP e handshakes................................................................................................157
4.4.2. Criando um teste de serviço via varredura de portas.........................................................159
4.4.3. Exercício sobre checagem de portas....................................................................................162
4.5. Validação de páginas WEB.............................................................................................163
4.5.1. Disponibilidade do site..........................................................................................................163
4.5.2. Exercícios..............................................................................................................................168
4.6. Checando disponibilidade via agentes..........................................................................169
4.6.1. Checando se o agente esta operacional...............................................................................169
4.6.2. Criando um trigger com a função nodata()..........................................................................171
4.6.3. Exercícios..............................................................................................................................175
4.7. Tempo on-line e última inicialização do S.O..................................................................175
4.7.1. Trigger para alerta de reinicialização..................................................................................180
4.7.2. Exercícios..............................................................................................................................181
4.8. Checando serviços pelo agente.....................................................................................181
4.8.1. Verificando os processos ativos na memória........................................................................181
4.8.2. Checagem de portas e serviços localmente via agente.......................................................185
4.8.3. Exercícios..............................................................................................................................190
4.8.4. Verificando serviços no Windows.........................................................................................190
4.8.5. Restabelecendo serviços offline via Zabbix.........................................................................198
4.8.6. Exercícios..............................................................................................................................202
4.9. Medindo a “saúde” de sua rede.....................................................................................202
4.9.1. Latência de rede....................................................................................................................202
4.9.2. Macro para o limiar da latência de rede..............................................................................204
-5
4.9.3. Nosso primeiro gráfico.........................................................................................................205

4.9.4. Personalizando o mapa para exibição de informações........................................................208
4.9.5. Exercícios..............................................................................................................................210
4.10. Espaço disponível em disco.........................................................................................210
4.10.1. Gráficos para espaço em disco...........................................................................................213
4.10.2. Gatilhos para alertas de espaço em disco..........................................................................216
4.10.3. Exercícios............................................................................................................................217
4.11. Scripts externos...........................................................................................................218
4.11.1. Checando a disponibilidade do PostgreSQL......................................................................218
4.11.2. Medindo a disponibilidade de um link Internet.................................................................223
4.11.3. Exercícios............................................................................................................................227
REFERÊNCIAS
BIBLIOGRÁFICAS......................................................................................................................228
Anexo I
Performance do Sistema Operacional..................................................................................230
Introdução.......................................................................................................................................230
Processamento.................................................................................................................................230
Métricas de memória......................................................................................................................231
Throughput e banda de rede...........................................................................................................232
Performance de Disco.....................................................................................................................232
Anexo II
Performance de serviços.......................................................................................................233
Introdução.......................................................................................................................................233
PostgreSQL......................................................................................................................................233
JBoss................................................................................................................................................234
Apache.............................................................................................................................................234
Índice de tabelas
Tabela 1: Opções de compilação do Zabbix............................................................................34
Tabela 2: Binários de uma instalação de servidor e agente do Zabbix.................................36
Tabela 3: Arquivos e diretórios de configuração....................................................................38
Tabela 4: Função dos menus no front end..............................................................................77
Table 5: Usuários do cenário do curso...................................................................................81
Tabela 6: Relação de permissões entre hosts e usuários.......................................................98
Tabela 7: Lista de imagens iniciais para o mapa.................................................................100
Tabela 8: Serviços do cenário do curso................................................................................163
Tabela 9: Responsáveis de cada host...................................................................................175
Table 10: Valores da key service_state.................................................................................193
-6
Índice de Figuras
Figura 2.1: Configuração do evolution (1/10)........................................................................16
Figura 2.10: Configuração do evolution (10/10)....................................................................24
Figura 2.11: Tela de boas vindas do Pidgin............................................................................25
Figura 2.12: Configurando uma conta Jabber no Pidgin.......................................................25
Figura 2.13: Definindo o uso de criptografia.........................................................................26
Figura 2.14: Baixando o agente do Zabbix no Windows........................................................47
Figura 2.15: Instalando os executáveis no Windows.............................................................48
Figura 2.16: Diretório de configuração do Zabbix no Windows............................................48
Figura 2.17: Configurando o agente no Windows..................................................................49
Figura 2.18: Desbloqueando o agente no Windows...............................................................50
Figura 2.19: O agente do Zabbix sendo executado como serviço automático......................51
Figura 2.20: Tela de entrada do Zapcat.................................................................................54
Figura 2.21: Configuração do front end (1/10)......................................................................61
Figura 2.30: Configuração do front end (10/10)....................................................................71
Figura 2.31: Tela inicial do Zabbix após o primeiro login.....................................................71
Figura 3.1: Gerenciamento de usuários do Zabbix................................................................78
Figura 3.2: Editando o Admin.................................................................................................79
Figura 3.3: Configurando a autenticação LDAP....................................................................80
Figura 3.4: Novo Grupo JBoss Administrators.......................................................................81
Figura 3.5: Novo usuário Sysadmin.......................................................................................82
-7
Figura 3.6: Media Types.........................................................................................................83

Figura 3.7: Configurando o Zabbix para enviar e-mails........................................................84
Figura 3.8: Configurando o Zabbix para enviar mensagens instantâneas...........................84
Figura 3.9: Media Types de um usuário sem apontamentos.................................................85
Figura 3.10: Adicionando o Media Type Email a um usuário................................................85
Figura 3.11: Adicionando um media type Jabber a um usuário............................................86
Figura 3.12: Media Types de um usuário após o cadastro....................................................86
Figura 3.13: Selecionando todos os templates pré cadastrados...........................................88
Figura 3.14: Excluindo os templates selecionados................................................................89
Figura 3.15: Criando um novo template.................................................................................89
Figura 3.16: Cadastrando um novo template.........................................................................89
Figura 3.17: Vinculando um template a outro.......................................................................90
Figura 3.18: Exportando um template...................................................................................91
Figura 3.19: Layout dos hosts a serem monitorados.............................................................92
Figura 3.20: Como criar um novo grupo de hosts.................................................................93
Figura 3.21: Novo host group.................................................................................................93
Figura 3.22: Host pré-cadastrado no front end na tela de Hosts..........................................93
Figura 3.23: Botão para criar um host...................................................................................93
Figura 3.24: Todos os hosts do cenário cadastrados.............................................................95
Figura 3.25: Concedendo permissões de acesso (1/4)...........................................................95
Figura 3.29: Tela inicial das imagens.....................................................................................99
Figura 3.30: Importando uma nova imagem..........................................................................99
Figura 3.31: Imagem do primeiro mapa a ser criado..........................................................100
Figura 3.32: Mapas pré-cadastrados....................................................................................101
Figura 3.33: Novo mapa........................................................................................................101
Figura 3.34: Barra de ferramentas para edição de mapas..................................................103
Figura 3.35: Criando um novo elemento..............................................................................103
Figura 3.36: Posicionando um novo elemento com o mouse...............................................104
Figura 3.37: Editando um elemento na tela.........................................................................105
Figura 3.38: Botão Save do mapa.........................................................................................106
Figura 3.39: Dialogo de salvar mapa....................................................................................106
Figura 3.40: Outros elementos gráficos a serem adicionados............................................107
Figura 3.41: Editando o elemento que representa o host Presentation.............................108
Figura 3.42: Detalhes do host switch dentro do mapa........................................................109
Figura 3.43: Hosts acrescentados no mapa.........................................................................110
Figura 3.44: Criando um novo link entre o host Presentation e a imagem Internet..........111
-8
Figura 3.45: Editando as propriedades do novo link...........................................................112

Figura 3.46: Link entre o host Presentation e o Switch......................................................113
Figura 3.47: Mapa final.........................................................................................................114
Figura 3.48: Templates e seus elementos............................................................................114
Figura 3.49: Criando um application (1/4)...........................................................................115
Figura 3.53: Criando seu primeiro item (1/3)......................................................................116
Figura 3.56: Campo para associação de templates.............................................................119
Figura 3.57: Tela para escolha de templates.......................................................................119
Figura 3.58: Template associado..........................................................................................119
Figura 3.59: Template associado na lista de templates.......................................................119
Figura 3.60: Inter-relação dos templates base....................................................................120
Figura 3.61: Associando o template do JBoss ao host JBoss AS (1/6).................................120
Figura 3.65: Associando templates a hosts (5/11)...............................................................121
Figura 3.67: Templates para Windows e SNMP associados aos seus respectivos hosts. . .121
Figura 3.68: Associando um template a múltiplos hosts simultaneamente (1/4)..............122
Figura 3.72: Todos os templates associados aos hosts do cenário....................................123
Figura 3.73: Host presentation não monitorado..................................................................124
Figura 3.74: Dialogo de confirmação de ativação...............................................................124
Figura 3.75: Host presentation monitorado.........................................................................124
Figura 3.76: Item não suportado..........................................................................................125
Figura 3.77: Item suportado e ativo.....................................................................................127
Figura 4.1: Menu de Ferramentas acessado pelo mapa......................................................130
Figura 4.2: Saída de um comando ping................................................................................130
Figura 4.3: Saída de um comando que falhou do traceroute..............................................131
Figura 4.4: Saída do traceroute adequando a nova necessidade .......................................135
Figura 4.5: Criando um novo script para testar portas SSH (1/2)......................................136
Figura 4.6: Criando um novo script para testar portas SSH (2/2)......................................136
-9
Figura 4.7: Nova entrada de menu com o script criado......................................................137

Figura 4.8: Resultado do comando ativado no host.............................................................137
Figura 4.9: Diagrama de comportamento do echo ICMP....................................................139
Figura 4.10: Hosts ativos com ping ICMP em funcionamento............................................140
Figura 4.11: Um value maps de estado de serviços............................................................140
Figura 4.12: Editando o value map para nossa necessidade...............................................140
Figura 4.13: Value map editado e pronto para uso..............................................................141
Figura 4.14: Selecionando um value map no trigger..........................................................141
Figura 4.15: Values maps no overview.................................................................................141
Figura 4.16: Pausando o host Database...............................................................................142
Figura 4.17: Host database parado no overview.................................................................142
Figura 4.18: Criando um trigger para a parada do host (1/9).............................................143
Figura 4.27: Indicação de problemas no Dashboard...........................................................146
Figura 4.28: Overview com indicação dos items com alerta...............................................147
Figura 4.29: Overview com visualização dos triggers ativos..............................................147
Figura 4.30: Mapa indicando o host Database como down.................................................148
Figura 4.31: Tela de Events, indicando a queda e o retorno dos hosts..............................148
Figura 4.32: Tela de acknowledgement...............................................................................149
Figura 4.33: Acknowledge (confirmação) aplicado..............................................................149
Figura 4.34: Criando uma action para enviar o alerta (1/9)................................................150
Figura 4.43: Mensagens de alerta recebidas no Evolution.................................................153
Figura 4.44: Reiniciando o host Database...........................................................................154
Figura 4.45: Lógica de um gatilho com tempo de segurança.............................................155
- 10
Figura 4.46: Simple check para o SSH................................................................................161

Figura 4.47: Overview exibindo os serviços de SSH...........................................................162
Figura 4.48: Criando um cenário para disponibilidade Web (1/6)......................................164
Figura 4.54: Visualizando a checagem Web.........................................................................167
Figura 4.55: Detalhes do monitoramento Web....................................................................167
Figura 4.56: Gráfico de velocidade de download para o cenário Web................................168
Figura 4.57: Gráfico de tempo de resposta para o cenário Web.........................................168
Figura 4.58: Novo item para monitorar o agente................................................................170
Figura 4.59: Copiando o item de ping de agente para o template do JBoss (1/2)..............170
Figura 4.60: Copiando o item de ping de agente para o template do JBoss (2/2)..............171
Figura 4.61: Criando um trigger para o agent.ping (1/5)....................................................172
Figura 4.66: Trigger para o agent ping criado e ativo........................................................173
Figura 4.67: Trigger de agente ativado...............................................................................174
Figura 4.68: Dependência entre triggers evitando que o gatilho filho seja ativado..........174
Figura 4.69: Item para tempo de uptime.............................................................................177
Figura 4.70: Uptime via Zapcat............................................................................................178
Figura 4.71: Uptime via SNMP.............................................................................................178
Figura 4.72: Overview exibindo os uptimes a partir do agente padrão, Zapcat e SNMP..179
Figura 4.73: Um trigger para a reinicialização de um host................................................180
Figura 4.74: Item para verificação de número de processos..............................................183
Figura 4.75: Overview refletindo o número de processos...................................................183
Figura 4.76: Trigger para queda do daemon.......................................................................184
Figura 4.77: Teste de queda do sshd....................................................................................185
Figura 4.78: Reflexo da queda do daemon SSH no overview..............................................185
Figura 4.79: Item para verificação da porta local...............................................................186
Figura 4.80: Fluxograma da dependência entre triggers para análise de serviços...........187
Figura 4.81: Trigger para verificação da porta local...........................................................189
Figura 4.82: Trigger para verificação de porta remota.......................................................189
Figura 4.83: Serviço telnet do Windows..............................................................................190
Figura 4.84: Habilitando o serviço de telnet do Windows...................................................191
Capítulo 1 Conhecendo o Zabbix - 11
Figura 4.85: Ativando o serviço de telnet............................................................................191

Figura 4.86: Processo do telnet na memória.......................................................................192
Figura 4.87: Liberando o telnet no firewall do Windows (1/3)............................................194
Figura 4.90: item para monitorar serviços Windows...........................................................197
Figura 4.91: Estado do serviço Telnet no Overview............................................................197
Figura 4.92: Action para parada do SSH (1/3).....................................................................200
Figura 4.95: Comando remoto para o action de parada do serviço de SSH.......................201
Figura 4.96: Item para latência de rede...............................................................................203
Figura 4.97: Macro para latência de rede............................................................................205
Figura 4.98: Trigger para latência de rede usando a macro...............................................205
Figura 4.99: Gráfico para medir a latência de rede............................................................206
Figura 4.100: Criando um gráfico de latência de rede........................................................206
Figura 4.101: Adicionando métricas ao gráfico...................................................................207
Figura 4.102: Mapa com labels personalizadas exibindo dados.........................................209
Figura 4.103: Exemplo de labels com valores de métricas.................................................209
Figura 4.104: Exemplo de gráfico de latência de serviços para exercícios........................210
Figura 4.105: Macro para limite de espaço em disco utilizado...........................................211
Figura 4.106: Primeiro item de espaço em disco.................................................................212
Figura 4.107: Items a serem clonados para espaço em disco.............................................213
Figura 4.108: Botão para clonar items.................................................................................213
Figura 4.109: Gráfico de pizza para exibição de espaço livre e ocupado...........................214
Figura 4.110: Criando um gráfico de pizza..........................................................................214
Figura 4.111: Gráfico de histórico de espaço em disco.......................................................215
Figura 4.112: Criando o gráfico de histórico de uso de disco.............................................215
Figura 4.113: Trigger para cálculo de espaço em disco......................................................217
Figura 4.114: Trocando o template do host database para o PostgreSQL.........................222
Figura 4.115: Disponibilidade do PostgreSQL ativa no database.......................................223
Figura 4.116: Latência sendo exibida no label do link........................................................226
Figura 4.117: Latência de rede e trigger associados ao link com a Internet no mapa......226
Figura 4.118: Link no mapa identificando status do trigger...............................................226
Capítulo 1
Conhecendo o Zabbix
OBJETIVOS
• Apresentar a ferramento ao aluno.
• Como o “front end” organiza os componentes dentro do Zabbix.
• Componentes visuais de monitoramento.
• Alertas de incidentes.
• Reinicialização de serviços.
• Mostrar ao aluno onde obter informações.
1.1. Conhecendo a ferramenta
Siga os passos indicados pelo professor para acesso ao exemplo pronto na máquina dele.
Você vai fazer um passoapasso conhecendo a ferramenta como um usuário comum (não
superusuário).
1.2. Comunidades e forums
O Zabbix tem uma documentação online que será usada durante o curso para consultas.
O link de acesso é http://www.zabbix.com/documentation/.
As comunidades também mantém uma série de fóruns em

http://www.zabbix.com/forum/. Em destaque os seguinte:
• Zabbix announcements: anúncios e novas versões
• Zabbix help: fórum principal de ajuda
• Zabbix cookbook: várias configurações prontas postadas e comentadas. Muito útil.
• Zabbix throubleshooting: se um problema persiste, este é o local para postar erros e
soluções.
• Zabbix em português y em espanhol: fórum em português e espanhol, útil quando você
não lê inglês muito bem.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 14
Capítulo 2
Criando uma Infraestrutura de Monitoramento
– Parte 1, Sistema
OBJETIVOS
• Preparar o ambiente de recebimento de alertas:
• Configurar o Evolution para receber emails de alertas;
• Configurar o Pidgin para receber mensagens instantâneas de alertas.
• Preparar o ambiente para instalar o servidor do Zabbix:
• Obter os fontes da ferramenta;
• Preparar o PostgreSQL para servir de back end.
• Instalar o servidor e agente:
• Compilar o servidor e agente na máquina destinada a ser o monitorador e nas demais;
• Instalação dos binários dentro do Windows 2003 (com inicialização do agente como
serviço);
• Executar deploy do agente Zapcat no JBoss para monitoramento do servidor de

aplicações
• Configuração de um virtual host dentro do Apache para o front end, incluindo modificação
dos parâmetros do PHP.
2.1. Introdução
Este capítulo apresenta todas as tarefas relacionadas a criação da base de sua solução
de monitoramento. Aqui é onde será abordado a maior parte do conhecimento técnico de console
Linux, deploying em JBoss, serviços de Windows e acesso à SNMP, visando incutir as
competências necessárias para que, sozinho, você seja capaz de reproduzir estes passos em um
ambiente de produção.
Além disso, serão vistos os primeiros passos na utilização e familiarização com a interface
web do Zabbix, mostrando como gerenciar os elementos mais básicos da ferramenta: usuários,
hosts, templates, grupos de hosts e mapas.
2.2. Configurando os componentes de recebimento de alertas
Por padrão o Zabbix possui quatro formas de alertas embutidos dentro de seu sistema: e
mails, cliente jabber, SMS via modem GSM e SMS via serviço de torpedos. De todos, o último não
é muito útil aqui no Brasil, devido seguir os padrões das operadoras no Canadá e Estados Unidos.
Dos restantes vamos ver o funcionamento do sistema de correios e de jabber dentro da
sala de aula, devido a natureza do hardware, a emulação das máquinas virtuais do cenário e
custos de mensagem não abordamos o uso dentro do nosso cenário com SMS. No entanto temos
um apêndice que cobre o sistema de SMS com throubleshooting e dicas de configuração.
Receber mensagens por cliente de email é a maneira mais tradicional de todas. Para
caso de estudos precisamos configurar o Evolution, cliente de email padrão do Gnome. Abra o
Evolution pelo menu principal do Gnome e siga os passos descritos a seguir.
2.2.1. Configurando o cliente de correio eletrônico
Figura 2.1: Configuração do evolution (1/10)
Esta é apenas um tela de boas vindas, clique em Avançar.
Não há nada para ser restaurado, clique novamente em Avançar.
Começaremos a configurar as contas de usuários dentro do sistema de LDAP que o

cenário possui. Preencha os campos como abaixo para configurar a primeira conta e, em seguida,
clique em Avançar.
1) Nome Completo: System administrator
2) Endereço de email: sysadmin@curso468.4linux.com.br.
3) Tipo de Servidor: devemos escolher POP, que é o recurso implantado para recepção
de emails no cenário.
4) Servidor: é o endereço externo do servidor de email.
5) Nome do usuário: o primeiro usuário que usaremos é o sysadmin.
6) Lembrar senha: para comodidade dos testes em curso ative o recurso de
armazenamento de senha.
Esta opção não é segura para ser usada em produção! Mas como no curso os
usuários são fictícios e possuem a senha 123456 isso não vai nos impactar.
Nesta tela, configure o recebimento automático a cada 1 minuto, assim não precisamos
ficar esperando emails chegarem e, também não precisamos ficar clicando em Enviar/Receber a
todo momento.
Apesar de não utilizar o envio de email sob o ponto de vista do usuário, é interessante
configurar o SMTP para averiguar se os emails estão caminhando dentro do cenário.
1) No Tipo de Servidor escolha SMTP.
2) No Servidor coloque o mesmo endereço de email que colocamos no POP3.
Não reproduza este comportamento de aceite de emails sem autenticação em
produção! O servidor de correio eletrônico dentro do cenário é apenas um meio de
sabermos que as mensagens de alertas do Zabbix estão sendo enviadas por email.
1) Nome: Por final, configure um nome para esta conta. Isto é usado apenas para
exibição no Evolution.
Esta é apenas uma tela de finalização, clique em Aplicar.
Torne o Evolution o seu cliente de email padrão.
Na primeira vez que você entrar ele irá pedir a senha (123456) do usuário, digitea e
verifique se não houve nenhum erro. Não há nenhum email na caixa de mensagens do sysadmin,
logo nenhuma mensagem vai aparecer.
Agora que o Evolution esta é funcionamento, acesse o menu Editar → Preferências e

clique no ícone Contas de Correio a esquerda. Através do botão Adicionar cadastre mais três
contas seguindo os mesmos passos que anteriormente, mudando apenas os nomes e usuários.
As contas a serem acrescentadas são Windows Administrator (winadmin), Java Engineer
(javaeng) e DBA (dba). Após o término, escolha duas contas e teste o envio de mensagens entre
elas.
2.2.2. Mensagens instantâneas
Receber mensagens de alertas via Instant Messaging é útil em empresas que possuem
um sistema interno de IM e os funcionários estão logados constantemente. O Zabbix suporta o
envio destas mensagens via protocolo Jabber e o cenário já possui este tipo de serviço através de
um servidor OpenFire instalado na máquina mestra do Zabbix.
Vamos então configurar o Pidgin, um cliente de IM simples e eficiente para receber os

alertas enviados via protocolo Jabber pelo servidor do Zabbix. Abra o aplicativo pelo menu
principal do Gnome e siga os passos a seguir.
Figura 2.11: Tela de boas vindas do Pidgin
Na tela de boas vindas clique em Adicionar.
Figura 2.12: Configurando uma conta Jabber no Pidgin

1) O protocolo Jabber usa a opção XMPP.
2) No nome do usuário use sysadmin.
3) No domínio, você deve apontar o nome da máquina cadastrada para IM e não o
domínio.
4) Na senha coloque 123456.
5) Ative o Lembrar Senha.
Não ative a opção “Lembrar Senha” em produção! Isso seria uma terrível falha de
segurança. Ela só esta sendo ativada para comodidade do curso.
Figura 2.13: Definindo o uso de criptografia
1) Clique na aba Avançado.
2) Escolha para usar criptografia apenas se estiver disponível.
Clique em Adicionar e ative a conta na interface do Pidgin.
2.3. Obtendo os fontes do Zabbix
Antes de começar a trabalhar com as diversas partes básicas da instalação, precisamos
baixar o código fonte do Zabbix. Você sempre pode fazêlo através da URL
http://www.zabbix.com/download.php, mas o comando abaixo já vai colocar o pacote de fontes no
local apropriado dentro da máquina virtual “zabbixsrv”.
# cd /usr/src
# wget http://ufpr.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest
%20Stable/1.8.4/zabbix1.8.4.tar.gz
# tar xf zabbix1.8.4.tar.gz
Você também pode escolher outros mirrors e trocar o endereço acima se desejar.
2.4. Preparando o banco de dados
O Zabbix não utiliza recursos como o RRDTools para armazenar dados, ele faz uso
apenas de um SGBD ou de um banco de dados mais simplório (como o sqlite) para armazenar
configurações, hosts, templates, histórico, etc.
Por isso precisamos selecionar um dos bancos nativos ou usar ODBC (este último não é
recomendado). No caso deste curso elegemos o PostgreSQL, um SGBD livre e de alta
performance capaz de manipular uma grande quantidade de dados. Apesar da maioria das
instalações de Zabbix estar em MySQL recomendamos fortemente que seja usado o PostgreSQL
pois sua robustez se mostrou mais adequada aos tipos de dados que o Zabbix manipula.
Embora não pareça a princípio, o banco de dados do Zabbix é de extrema valia para a
empresa, pois ele contém todo o histórico de funcionamento de sua infraestrutura e através dele
podemos coletar SLAs e informações de “capacity plan”.
É recomendado também que seu banco de dados possua um plano de backups regular
via PITR – Point in Time Recovery.
2.4.1. Instalação
Para instalar a versão do repositório do PostgreSQL:
# aptitude install postgresql8.4
# yum install postgresql84server
2.4.2. Criando o usuário e o banco
Com o banco de dados instalado devemos criar uma base de dados e um usuário com as
devidas permissões de acesso ao mesmo. O nome de ambos elementos são totalmente
opcionais, mas neste material vamos convencionar que o banco de dados se chamará zabbixdb e
o usuário será zabbix.
Muitas documentações e até o próprio arquivo padrão de configuração do zabbix server
utiliza o nome do banco como zabbix, mas isso pode causar algumas confusões entre
ele e o nome do usuário, foi por isso que optamos pela convenção acima.
Somente o superusuário do PostgreSQL, chamado postgres tem permissão de realizar a
criação dos objetos citados acima, logo, para podermos acessar o terminal de console do banco
(psql) temos que entrar como usuário postgres no Gnu/Linux e então usar o comando correto.
Note que o prompt de comando irá se alterar indicando que estamos no console do PostgreSQL.
# su – postgres
$ psql
psql (8.4.5)
Digite "help" para ajuda.
postgres=#
Agora que conseguimos o acesso como superusuário, vamos primeiro criar o banco de
dados. O comando “create database” irá cuidar desta tarefa. Note que todos os comandos
digitados dentro deste console terminam com pontoevírgula (;).
postgres=# CREATE DATABASE zabbixdb;
Com o banco de dados criado com sucesso vamos criar o usuário e definir sua senha.
Para propósito de organização deste material a senha do banco de dados do zabbix será
zabbixdbpw. Ao digitar a senha note que ela não aparece como no quadro de comando abaixo!
Este é apenas um demonstrativo didático.
postgres=# CREATE ROLE zabbix LOGIN;
postgres=# \password zabbix
Digite nova senha: zabbixdbpw
Digitea novamente: zabbixdbpw
É interessante definir a senha por \password pois assim ela não fica armazenada no
histórico de comandos do usuário.
Agora precisamos liberar a conexão do servidor ao banco de dados do zabbix, para isso
edite o arquivo “pg_hba.conf” conforme abaixo e acrescente a linha em destaque.
postgres=# \q
$ logout
# vim /etc/postgresql/8.4/main/pg_hba.conf
…
host zabbixdb zabbix 127.0.0.1/32 md5
Reinicie o banco de dados e realize o teste de conexão.
# /etc/init.d/postgresql restart
# psql h localhost U zabbix zabbixdb
psql (8.4.5)
conexão SSL (cifra: DHERSAAES256SHA, bits: 256)
Digite "help" para ajuda.
zabbixdb=> \q
#
Se você estiver usando a versão 9.0 do PostgreSQL é importante lembrar que o

suporte a imagens do Zabbix assume que o banco utiliza a forma antiga de
armazenamento bytea (escape em vez de hex). Para configurar o comportamento
antigo use o comando “ALTER DATABASE nomedabase SET
bytea_output=escape;” dentro do console do psql. Isso pode ser configurado no
usuário ou no “postgresql.conf” também.
2.4.3. Carga inicial
Agora vamos fazer a carga inicial do banco carregando os esquemas, os dados mais
básicos.
# su postgres
$ cd /usr/src/zabbix1.8.4/create/schema
$ cat postgresql.sql | psql zabbixdb
$ cd ../data
$ cat data.sql | psql zabbixdb
Não faça a carga do arquivos de imagens, iremos abordar como colocar figuras
personalizadas e de melhor definição mais a frente, neste capítulo.
2.4.4. Concedendo as permissões necessárias ao usuário
Agora é o momento de conceder as permissões de acesso nas tabelas. O usuário Zabbix
precisa de permissões de SELECT, INSERT, UPDATE e DELETE apenas. Com a sequência de
comandos abaixo você conseguirá ativar todas as permissões necessárias.
Embora este processo seja mais complicado do que fazer deixar o usuário zabbix como
dono do banco ele é muito mais seguro e deve ser utilizado assim em produção
$ psql zabbixdb
1 postgres=# \t 
2 postgres=# \a 
3 postgres=# \o /tmp/grantzabbix.sql 
4 postgres=# SELECT 'GRANT SELECT,UPDATE,DELETE,INSERT ON ' || schemaname || '.'
|| tablename || ' TO zabbix ;' FROM pg_tables; 
5 postgres=# \o
6 postgres=# \i /tmp/grantzabbix.sql 
7 postgres=# \q
$ logout
1) O comando \a remove o alinhamento dos elementos na tabela;
2) O \t mostra apenas tuplas, eliminando cabeçalhos e rodapés;
3) O comando \o grava o “output” no arquivo definido (/tmp/grantzabbix.sql). Note que é
preciso de outro \o sem o nome do arquivo para encerrar o “output”;
4) Este comando em SQL seleciona todas as tabelas do banco de dados e monta uma
“string” com o comando de permissão (GRANT), você pode ver o conteúdo deste
comando no arquivo “/tmp/grantzabbix.sql”;
5) O comando \i carrega e executa o conteúdo do arquivo gerado acima.
2.5. Instalação do servidor Zabbix via código fonte
Em alguns casos a distribuição Gnu/Linux que você escolher pode possuir em seu
repositório uma versão satisfatória do Zabbix disponível. Se for este o caso, ótimo! Simplesmente
instale o pacote e comece a configurar.
No entanto isso nem sempre é verdade e pode ser necessário uma versão mais recente
(devido a recursos novos, etc.) na sua solução de monitoramento. Para suprir esta necessidade é
preciso compilar o Zabbix a partir de seu código fonte.
Esta sessão toda é dedicada ao processo de criar os binários, cobrindo quais

dependências devem ser instaladas e como escolher os recursos a serem compilados. Via de
regra se algum tipo de recurso não se mostrar necessário a princípio não o ative, isso gera
binários mais leves (com menos código embutido) e alivia o consumo de memória em servidores
com altas cargas de métricas sendo monitoradas.
Para começar, vamos instalar os dois pacotes mais básicos para compilação de fontes no
Debian, o buildessential e o make. O primeiro é um meta pacote que irá instalar todos os
pacotes mínimos de compilação de fontes (compilador, linkeditor, cabeçalhos do kernel e da libc,
etc.) e o segundo é um automatizador de compilação. No terminal do zabbixsrv rode os seguintes
comandos.
# aptitude install buildessential make
# cd /usr/src/zabbix1.8.4
# ./configure help | less
O configure é um script gerado a partir do “autotools”, que é um conjunto de ferramentas
para facilitar a compilação de fontes em C. A opção help fornecida acima irá listar todas as
opções que podemos ativar ou não para compilar o Zabbix. Note que o configure não compila
nada ele apenas “prepara a cama” para realizar a compilação com o “make”.
Na tabela a seguir estão as opções relevantes do configure para a nossa tarefa.
Opção do configure Descrição

--prefix=diretório Define onde o Zabbix será instalado. É importante
lembrar que se nada for configurado nesta opção os
binários e manuais serão colocados em /usr/local como
padrão. No entanto para manter a instalação organizada
e facilitar atualizações de versões do Zabbix nós o
colocaremos em /opt/zabbix-1.8.4.
--mandir=/usr/share/man Aponta a localização correta das páginas de manual,
assim podemos usar o comando man para acessar as
opções dos binários do Zabbix.
--enable-static Ativa a geração de binários em forma estática (sem
shared libraries). É recomendado deixar esta opção
desligada.
--enable-server Ativa a compilação do servidor. No caso presente iremos
ativar esta opção, quando formos compilar apenas o
agente iremos desabilitá-la.
--enable-proxy Compila os binários para sistemas distribuídos. Como
neste curso não abordaremos o sistema de proxy do
Zabbix vamos deixar esta opção sempre desabilitada.
--enable-agent Compila os binários para os agentes. É uma excelente
ideia sempre deixar esta opção ativada. Mesmo em
servidores dedicados do Zabbix é uma boa prática
monitorar a própria máquina.

--enable-ipv6 Compila com suporte a IPV6. Embora não seja
absolutamente necessário, dado ao recente anúncio do
esgotamento de endereços IP da IANA o IPV6 logo será
necessário em muitos ambiente.
--with-ibm-db2 Ativa o suporte ao “back end” do bando de dados IBM
DB2. Vamos deixá-lo desabilitado uma vez que usaremos
o PostgreSQL. Você pode escolher apenas um “back end”.
--with-mysql Ativa o suporte ao “back end” do bando de dados MySQL.
Vamos deixá-lo desabilitado uma vez que usaremos o
PostgreSQL. Você pode escolher apenas um “back end”.
--with-oracle Ativa o suporte ao “back end” do bando de dados Oracle.
Vamos deixá-lo desabilitado uma vez que usaremos o
PostgreSQL. Você pode escolher apenas um “back end”.
--with-pgsql Ativa o suporte ao “back end” do bando de dados
PostgreSQL, vamos deixá-lo habilitado. Você pode
escolher apenas um “back end”.
--with-sqlite3 Ativa o suporte ao “back end” do bando de dados sqlite
versão 3. Vamos deixá-lo desabilitado uma vez que
usaremos o PostgreSQL. Você pode escolher apenas um
“back end”.
--with-jabber Ativa o suporte do servidor de contato com servidores
Jabber permitindo que o Zabbix envie alertas taravés
deste serviço de mensagens instantâneas. Vamos ativar
essa opção.
--with-libcurl Ativa o suporte a biblioteca de HTTP CURL. É necessária
para o monitoramento de serviços Web e autenticação via
HTTP.
--with-iodbc Ativa o suporte ao “back end” do bando de dados via
ODBC. Não é recomendado.
--with-unixodbc Como o anterior mas usa unixODBC ao invés de iODBC.
Este pacote é mais encontrado do que o iODBC.
--with-net-snmp Ativa o suporte a monitoramento via SNMP usando a
biblioteca “net-snmp” do unix. Vamos deixá-la ativada.
--with-ucd-snmp Mesmo que o anterior, mas usando a biblioteca ucd,
menos comum. Vamos deixá-la desativada.
--with-ssh2 Ativa suporte a monitoramento via SSH e verificação de
status de um serviço de conexão remota segura. Vamos
deixá-lo ativado.
--with-openipmi Ativa suporte a comandos e monitoramento de hardware
por IPMI. Só é relevante quando o hardware que você vai
monitorar e o S.O. Instalado nele possuem esta
especificação. Para este curso deixaremos ele desativado.

--with-ldap Ativa suporte a autenticação via LDAP e monitoramento
do status de um serviço de diretórios remoto. Vamos
deixá-la ativada.
Tabela 1: Opções de compilação do Zabbix
2.5.1. Dependências de compilação.
Ao executar o comando abaixo, colete cada erro que aparecer e aponte na tabela o
pacote que deve ser instalado para resolver a dependência. Isto vai servir de referência para você
em futuras instalações e também tem como intenção ensinar a lidar com erros de dependências
de compilação.
Use o comando “aptitude” para encontrar os pacotes corretos.
./configure prefix=/opt/zabbix1.8.4 –mandir=/usr/share/man enableserver disablestatic
disableproxy enableagent enableipv6 withpgsql withjabber withlibcurl withnet
snmp withssh2 withoutopenipmi withldap
Erro Dependência
Você pode otimizar os binários tornando o Zabbix mais rápido mas dependente de uma
CPU compatível se você exportar as variáveis de ambiente CFLAGS e CXXFLAGS
com o seguinte valor “O2 pipe march=native”, antes de executar o configure. Se você
estiver usando um sistema de 32 bits acrescente ainda fomitframepointer. Cuidado
com outros flags de compilação! Você pode acabar com um binário defeituoso!
2.5.2. Compilando e instalando
Agora que o “configure” chegou ao ponto final e todas as dependências foram resolvidas é
hora de executar a compilação com o comando “make”. Na verdade o “make” não é um
compilador, ele apenas chama os comandos necessários para construir os binário através de um
arquivo Makefile que foi gerado pelo “configure”.
Execute conforme abaixo, os comandos. No final o comando “ln” irá criar um link
simbólico para /opt/zabbix. Isso é uma boa prática para ajudar a trocar as versões do Zabbix
durante uma migração, apontando o link para a pasta com os novos binários, enquanto mantemos
os anteriores para o caso de um “downgrade” emergencial.
Você pode substituir o j2 por outro número para acelerar a sua compilação se você
tiver múltiplos cores. Uma regra geral é 2xCores+1.
# make j2
# make install
# ln svf /opt/zabbix1.8.4 /opt/zabbix
# tree /opt/zabbix
O comando “tree” vai mostrar a hierarquia de diretórios e arquivos abaixo do caminho da
instalação. A tabela abaixo tem o descritivo de cada um deles.
Binário Funcionalidade
zabbix_get Utilitário para realizar consultas nos
agentes via linha de comando. Muito útil
e nós o utilizaremos extensamente
durante o curso.
zabbix_sender Utilitário para envio de “traps” para o

servidor do Zabbix. É necessário criar um
Binário Funcionalidade
item especial do tipo “Zabbix trap” para
lidar com estes envios. Útil para alertar
incidentes instantaneamente para o
servidor como o início, termino ou erro
de um backup.
zabbix_agent Agente para ser usado com o “super
daemon xinetd” ou similar. Não é
necessário na grande maioria dos casos e
será removido do diretório.
zabbix_agentd O daemon do agente do Zabbix que fica
na memória a espera das requisições do
servidor.
zabbix_server O daemon do servidor do Zabbix. Este é o
componente principal de toda a
infraestrutura.
Tabela 2: Binários de uma instalação de servidor e agente do Zabbix
É preciso remover o “zabbix_agent” e sua página de manual, uma vez que iremos usar
apenas o “daemon zabbix_agentd”. Também é uma boa prática não manter os símbolos de
depuração nos binários de produção. O comando “strip” irá retirar estes símbolos e o executável
final será ligeiramente menor em tamanho (o que ajuda a consumir menos memória também).
# rm /opt/zabbix1.8.4/sbin/zabbix_agent
# rm /usr/share/man/man1/zabbix_agent.1*
# strip stripall /opt/zabbix1.8.4/*/*
Não é aconselhável executar daemons de sistema com o usuário root, por isso vamos
criar um grupo e usuário de nome zabbix para que o serviço entre na memória como usuário não
privilegiado.
O nome do usuário que o Zabbix usa é hadcoded, ou seja, ele é programado dentro do
código fonte e não pode ser alterado via configuração. Desse modo sempre temos que
criar o usuário com o nome zabbix, já o nome do grupo é totalmente opcional.
# groupadd zabbix
# useradd g zabbix m s /bin/bash zabbix
Ambos os daemons, do agente e do servidor, precisam de dois diretórios para armazenar
os logs e o arquivo de PID. Com os comandos abaixo crie e dê as permissões necessárias para
ambos.
# mkdir /var/{log,run}/zabbix p
# chown zabbix. /var/{run,log}/zabbix
2.5.3. Serviços de rede
Acrescente ao “/etc/services” o mapeamento de portas do “Zabbix Agent” e “Zabbix
Trapper”.
# vim /etc/services
…
zabbixagent 10050/tcp Zabbix Agent
zabbixagent 10050/udp Zabbix Agent
zabbixtrapper 10051/tcp Zabbix Trapper
zabbixtrapper 10051/udp Zabbix Trapper
Estas entradas permitem que programas como “wireshark” e “netstat” reconheçam as
portas do Zabbix.
2.5.4. Arquivos de configuração
Os arquivos de configuração do Zabbix acompanham os seus fontes, mas a 4Linux
preparou um conjunto de arquivos para uso em produção com uma organização melhorada. Ao
invés de simplesmente colocar todas as configurações em um único arquivo, os parâmetros foram
distribuídos em grupos lógicos separados em vários arquivos e diretórios.
O Zabbix por padrão procura pelos seus arquivos em /etc/zabbix, a partir dos arquivos
principais (zabbix_server.conf e zabbix_agentd.conf) outros arquivos foram chamados e inseridos
na configuração. A tabela abaixo demonstra como ficaram organizados os diretórios e seu
conteúdo.
Diretório ou arquivo Descrição

/etc/zabbix/agent.d Diretório para configurações extras do
Diretório ou arquivo Descrição

agente (carregado pelo arquivo
principal)
/etc/zabbix/agent.d/checkings.conf Configuração de checagens ativas e
passivas do agente.
/etc/zabbix/agent.d/logs.conf Configuração de logs (local, nível de
debug, etc.) do agente.
/etc/zabbix/agent.d/network.conf Configurações de rede do agente.
/etc/zabbix/agent.d/remote_commands.conf Configuração de recebimento de
comandos remotos no agente.
/etc/zabbix/alert.d Diretório para scripts de alertas
externos
/etc/zabbix/externalscripts Diretório para scripts de extensão do
agente do Zabbix.
/etc/zabbix/server.d Diretório para configurações extras do
servidor (carregado pelo arquivo
principal)
/etc/zabbix/server.d/database.conf Configuração do “back end” de banco
de dados do servidor.
/etc/zabbix/server.d/logs.conf Configuração de logs (local, nível de
debug, etc.) do servidor.
/etc/zabbix/server.d/network.conf Configurações de rede do servidor.
/etc/zabbix/server.d/process.conf Configurações de quais daemons
devem iniciar e quantos de cada um
deles, além de consumo de memória
do servidor.
/etc/zabbix/server.d/proxy.conf Configuração de monitoramento
distribuído do servidor.
/etc/zabbix/zabbix_agentd.conf Arquivo principal de configuração do
agente
/etc/zabbix/zabbix_server.conf Arquivo principal de configuração do
servidor
Tabela 3: Arquivos e diretórios de configuração
Copie o arquivo compactado do DVD (confs/configserver.tar.bz2 e confs/config

agent.tar.bz2) para dentro do /tmp da máquina virtual. Este arquivos tem vários valores padrões
razoáveis para começar e necessitam de pouca configuração. Não é de intenção deste material
dissecar cada uma das opções de configuração, vamos abordar apenas as mais relevantes,
porém os arquivos tem extensos comentários em português criados pelo autor deste material.
# cd /
# tar xf /tmp/configserver.tar.bz2
# tar xf /tmp/configagent.tar.bz2
# chown root.zabbix /etc/zabbix R 
# find /etc/zabbix type d exec chmod 0750 {} \; 
# find /etc/zabbix type f exec chmod 0640 {} \; 
1) Note que o grupo dos diretórios e seus arquivos foram apontados para “zabbix”. O
dono continuou a ser o root;
2) Todos os diretórios tiveram a permissão de acesso global revogada, nenhum usuário
do sistema tem que acessar esta pasta exceto o do Zabbix (existem informações
sensíveis como senhas em text/plain nestes arquivos). Também, apenas o root tem
direitos de gravação nessas pastas o grupo zabbix tem apenas acesso de leitura.
3) Os arquivos seguem a mesma lógica que os diretórios.
Não deixe de fazer o procedimento das permissões, ele vai tornar a sua instalação do
Zabbix muito mais segura.
Para finalizar vamos configurar o sistema para apontar o PATH para o link simbólico de
instalação. Isso vai facilitar o acesso aos comandos.
# vim /etc/profile.d/zabbixpath.sh
8 export PATH=”$PATH:/opt/zabbix/sbin:/opt/zabbix/bin”
# . /etc/profile
# zabbix_get help
# zabbix_agentd help
2.5.5. Testando sua instalação
Utilize o manual do “zabbix_agentd” para descobrir como listar as métricas suportadas
pelo ambiente e como testar um delas individualmente. Depois inicie o agente, veja o conteúdo do
arquivo de logs e use os comandos “ps” e “netstat” para ver quais os processos que ele iniciou e
em quais portas eles se vincularam.
Depois do término com o agente vamos configurar o servidor conforme os passos a seguir
e realizar o mesmo procedimento de inicialização e pesquisa que no agente.
# vim /etc/zabbix/server.d/database.conf
DBHost=127.0.0.1 
DBPort=5432 
DBName=zabbixdb 
DBUser=zabbix 
DBPassword=zabbixdbpw 
1) O endereço IP ou nome DNS do servidor que esta com o banco de dados. Como no
nosso cenário o banco e o servidor Zabbix estão na mesma máquina virtual utilizamos
o endereço de “loopback”;
2) A porta TCP de acesso do banco. Esta é a porta padrão do PostgreSQL;
3) Nome do banco de dados que criamos no início do capítulo;
4) Nome do usuário que criamos e demos permissão;
5) Senha do usuário acima.
Agora execute os comandos de inicialização dos daemons conforme indicado abaixo.
# zabbix_agentd
# zabbix_server
Verifique se as últimas linhas do log indicam se ambos iniciaram corretamente e também
se todos os processos estão na memória.
# tail n1 /var/log/zabbix/zabbix_server.log
1203:20110207:092633.044 server #1 started [DB Cache]
# tail n1 /var/log/zabbix/zabbix_agentd.log
871:20110207:092607.522 zabbix_agentd collector started
# ps u C zabbix_agentd
SER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
zabbix 863 0.0 0.1 4836 496 ? SN 09:25 0:00 /opt/zabbix/sbin/zabbix_agentd
…
# ps u C zabbix_server
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
zabbix 1201 0.0 1.0 46696 2636 ? SN 09:26 0:03 /opt/zabbix/sbin/zabbix_server
…
Note que a saída do último comando é muito grande. Ao final dos testes mate os
processos com o comando “killall”:
# killall zabbix_server zabbix_agentd
2.5.6. Scripts de boot
No CD temos alguns scripts de boot prontos para uso no Debian, copie os arquivos
“boot/debian/serverbootscripts.tar.bz2” e “boot/debian/agentbootscripts.tar.bz2” para o “/tmp” e
descompacteos na raiz.
# cd /
# tar xvf /tmp/serverbootscripts.tar.bz2
# tar xvf /tmp/agentbootscripts.tar.bz2
Teste a instalação dos scripts.
# /etc/init.d/zabbixserver start
# /etc/init.d/zabbixagent start
Por fim, coloque os scripts no boot da máquina virtual.
# updaterc.d zabbixagent defaults
# updaterc.d zabbixserver defaults
2.6. Instalação do agente Zabbix via compilação
Agora chegou o momento de instalar o agente do Zabbix nas outras máquinas virtuais
com Gnu/Linux. O procedimento de instalação é similar ao do servidor, mas não iremos habilitar a
opção “enableserver” no “configure”. Também não são necessários todos as opções de “with”
usadas acima. O agente é certamente mais simples que o servidor em termos de funcionamento e
só precisa do suporte a LDAP.
2.6.1. Exercício: compile e instale o agente nas VM com Gnu/Linux
Com as informações acima em mãos realize os procedimentos de instalação dos agentes
na máquina virtual Presentation. Não se esqueça também de colocar os scripts de boot e os
arquivos de configuração nela e iniciar o processo na memória.
2.6.2. Acesso ao agente pelo servidor
Agora que o agente esta instalado e rodando é preciso realizar algumas configurações
básicas para que ele permita o acesso vindo do servidor.
Primeiro vamos verificar se suas configurações de porta e rede estão de acordo, usando o
comando “netstat” para listar as portas que ele esta escutando.
# netstat lntp | grep zabbix
tcp 0 0 127.0.0.1:10050 0.0.0.0:* OUÇA 592/zabbix_agentd
A saída do comando mostra que o daemon esta apenas vinculado ao endereço localhost
da máquina, vamos modificar seu arquivo de configuração e reiniciálo. Identifique qual o IP local
da máquina que pertence a DMZ (rede 172.27.0.0/24) e substitua 127.0.0.1 por ele dentro do
arquivo /etc/zabbix/agent.d/networks.conf no parâmetro ListenIP.
# vim /etc/zabbix/agent.d/network.conf
1 # Este é o arquivo de configuração de rede do agente do Zabbix.
2
3 #====================================================================
4 # Qual porta e IP que o agente vai se vincular para receber checagens passivas do servidor.
5 #
6 ListenIP=172.27.0.1 
7 ListenPort=10050
8
9 #====================================================================
10 # IP o qual o agente do Zabbix irá usar para enviar dados, é opcional pois o sistema usa o IP
o qual esta designado a enviar dados conforme a tabela de oteamento.
11 #
12 SourceIP=
1) Mudar para o IP interno do Presentation.
Agora reinicie o agente e confira novamente a qual IP ele esta vinculado.
# /etc/init.d/zabbixagent restart
Stopping Zabbix agent daemon: zabbix_agentd
Starting Zabbix agent daemon: zabbix_agentd
# netstat lntp | grep zabbix
Se o serviço agora estiver vinculado ao IP correto repita estes passos em cada VM.
Neste ponto é importante paramos para verificar uma possível falha de conexão. Vamos
forçar a VM “zabbixsrv” a se comunicar com o gateway (presentation) via “zabbix_get”. Vamos
usar a “key agent.ping” como exemplo.
# zabbix_get s gateway k 'agent.ping'
zabbix_get [6646]: Get value error: *** Cannot connect to [gateway]:10050 [Connection timed
out]
Note a mensagem 'Connection timed out' no final da linha de erro, também repare que
levou algum tempo para que o comando retornasse a mensagem. Isso acontece porque o filtro de
pacotes da máquina esta bloqueando conexões, podemos averiguar isto com mais precisão
usando a ferramenta “nmap” conforme abaixo:
# nmap P0 p 10050 gateway
Starting Nmap 5.00 ( http://nmap.org ) at 20110130 02:17 BRST
Interesting ports on gateway.curso468.4linux.com.br (172.27.0.1):
PORT STATE SERVICE
10050/tcp filtered unknown
MAC Address: 08:00:27:BD:55:12 (Cadmus Computer Systems)
Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds
O estado da porta que o nmap retornou é “filtered”, ou seja, não há retorno de pacotes do
sistema. Para podermos liberar o acesso use o procedimento abaixo no terminal da máquina
“presentation”.
# iptables A INPUT j ACCEPT p tcp dport 10050 s 172.27.0.10
# iptablessave > /etc/iptables/rules
Repetindo o “nmap” a partir do servidor do Zabbix:
# nmap P0 p 10050 gateway
PORT STATE SERVICE
10050/tcp open unknown
Se o estado retornado for “open”, então o servidor é capaz de se conectar ao agente no
nível da camada TCP, mas ainda precisamos ter certeza absoluta que ele esta permitindo
conexões no nível de camada de aplicação. Vamos repetir o teste com o zabbix_get e ver se o
agente retorna o valor 1.
←
Note que ele não retorna nada! Apenas uma linha em branco aparece no resultado do
comando. Isso esta ocorrendo porque o agente precisa liberar a consulta para o servidor, por
padrão os arquivos de configuração apenas permitem que ele seja acessado a partir do localhost.
Para liberar o acesso temos que editar o arquivo “/etc/zabbix/agent.d/checkings.conf” e mudar
dois parâmetros.
O primeiro, obviamente é o “Server” que aceita uma lista separada por vírgula (,) dos
endereços que são permitidos fazer a consulta. O segundo é o “Hostname” representando o
nome da máquina com o qual o agente deve se apresentar ao servidor. Este nome deve ser único
e não necessariamente precisa ser igual ao hostname real da máquina, de fato no nosso cenário
iremos deixálo diferente.
# vim /etc/zabbix/agent.d/checkings.conf
1 # Este é o arquivo para configuração de checagens no agente. Há dois tipos de checagens, a
passiva e a ativa.
2 #
3 # Checagens passivas são o padrão, o servidor faz o agendamento das métricas e manda
uma requisição ao agente que aguarda passivamente (dai o nome), este então coleta o dado
do sistema e envia de volta ao servidor.
4 #
5 # Uma checagem ativa permite que o agente receba uma lista de itens a serem monitorados
do servidor e ao invés deste último cuidar do agendamento e requisições é o agente que toma
para si esta tarefa.
6 #
7 # Checagens ativas são úteis quando o Firewall não permite que o servidor de monitoramento
alcance o agente via rede ou quando se utiliza um sistema de monitoramento de logs onde o
monitoramento ativo é obrigatório.
8 #====================================================================
9 # Quais são os servidores para recebimento de requisições ou obtenção da lista de
checagens ativas.
10 Server=172.27.0.10 
11
12 #====================================================================
13 # Como este host esta cadastrado dentro do Zabbix isto não precisa corrsponder ao
hostname da máquina ele é uma string de identificação do agente para com o servidor do
Zabbix.
14 #
15 Hostname=Presentation 
…
1) Sempre temos que mudar este parâmetro para o endereço do servidor ou nome DNS
do mesmo. Se houverem mais de um servidor, separe os endereços/nome por vírgula;
2) Este é o nome a ser cadastrado no “front end” do Zabbix e não o nome de DNS
(apesar de poderem ser os mesmos).
Reinicie o agente mais uma vez e faça o teste com “zabbix_get” a partir do servidor.
1 ←
Se o comando resultante retornou 1 então o servidor poderá acessar o agente a partir de
agora.
2.6.3. Exercício sobre instalação de agente em Linux
1) Instale o agente do Zabbix via compilação nas máquinas virtuais Application e
Database conforme mostrado neste capítulo.
2.7. Instalando o agente em ambientes Windows
Um dos objetivos do curso é demonstrar como o Zabbix é capaz de monitorar redes
heterogêneas com vários sistemas operacionais e ativos de rede. Esta sessão cuida de instalar o
agente do Zabbix em um Windows 2003.
Figura 2.14: Baixando o agente do Zabbix no Windows
Primeiro é preciso baixar os executáveis pelo endereço

http://www.zabbix.com/downloads.php, localize o link de binários para Windows como na Figura
2.14.
Clique no link de download e escolha um local para colocar o arquivo compactado, no
exemplo da apostila ele foi colocado em C:\Downloads. Abra a pasta em que o arquivo foi salvo e
descompacte o arquivo. Dentro dele você encontrará outras duas pastas para arquiteturas de 32 e
64 bits. No nosso caso iremos usar os de 32 bits.
Figura 2.15: Instalando os executáveis no Windows
Volte a raiz e crie um diretório chamado Zabbix e dentro dele ainda crie mais três
diretórios: conf, log e bin e copie os executáveis descompactados dentro deste último.
Obtenha os arquivos do DVD com a configuração do agente do Windows (conf/agentwin
config.zip) e descompacte dentro da conf o seu conteúdo. Apague o arquivo zip depois disso.
O arquivo zabbix_agentd.conf deve ficar na raiz da pasta conf, assim como os

diretórios agent e externalscripts. Cuidado na hora de descompactar.
Figura 2.16: Diretório de configuração do Zabbix no Windows
Edite o arquivo c:\Zabbix\conf\agent\checkings.conf e mude os parâmetros Server e

HostName conforme a Figura 2.17, para permitir o acesso do servidor e o arquivo
c:\Zabbix\conf\agent\network.conf para vinculálo ao endereço IP da placa de rede.
Use o Wordpad para alterar estes arquivos, o Notepad tem vários problemas com
codificação e finais de linha.
Figura 2.17: Configurando o agente no Windows
Agora vamos testar a instalação, abra dois prompts de comando, no primeiro acesse o
diretório dos binários e execute o comando conforme abaixo.
cd C:\Zabbix\bin
zabbix_agentd c ..\zabbix_agentd.conf
Note que uma mensagem dizendo que ele foi iniciado pelo console irá aparecer na tela. É
porque o Windows não é capaz de executar o agente como um daemon da maneira que o Linux
faz, mais a frente veremos como iniciálo como serviço do Windows que é maneira correta de se
fazer. Outra mensagem, desta vez via caixa de dialogo, também vai aparecer na tela. É o serviço
de segurança do Windows que esta perguntado se deve bloquear ou não esta aplicação.
Obviamente devemos clicar em Desbloquear.
Figura 2.18: Desbloqueando o agente no Windows
Agora no segundo prompt de comando, use o comando “netstat” como abaixo para
verificar se ele esta escutando no endereço correto.
netstat an
2.7.1. Executando o agente como serviço
Instalar o agente do Zabbix como serviço é muito simples. No prompt de comando onde
você o testou pressione “CTRL+C” para cancelar a execução do programa (demora alguns
segundos). Quando o prompt retornar digite:
zabbix_agentd.exe c c:\Zabbix\conf\zabbix_agentd.conf install
Duas mensagens irão aparecer indicando a instalação do agente como “Service” e “Event
Source”. Para conferir se o agente esta mesmo no ar abra o Painel de Controle → Ferramentas
Administrativas → Serviços e procure pelo serviço chamado “Zabbix Agent”.
Figura 2.19: O agente do Zabbix sendo executado como serviço automático.
Nesta tela é também possível parar, reiniciar, etc. o agente através da barra de ícones na
parte superior da janela. Como o serviço inicia parado devemos clicar sobre ele e no ícone Iniciar
o Serviço (representado pelo símbolo de “play”).
Certifiquese que ele esta para ser iniciado automaticamente, assim quando o sistema for
reiniciado o serviço também será. Teste no servidor do Zabbix se ele esta conseguindo alcançar o
agente.
# zabbix_get s win2003 k 'agent.ping'
1
Se ele retornar 1 como acima, então a instalação esta concluída.
2.8. Instalação do agente Zapcat para JBoss
O Zabbix possui alguns agentes programados por terceiros além do nativo que
acompanha os fontes padrão. Um destes agentes é o Zapcat, que é capaz de monitorar através
de um “deploy”, servidores JBoss e Tomcat. No nosso cenário temos um servidor JBoss na
máquina virtual Application que será monitorado pelo Zapcat. O resto desta sessão é dedicado à
instalação e configuração deste agente.
O Zapcat é na verdade um JMX Bridge, ele é capaz de coletar os MBeans JMX do
servidor e expôlo para o Zabbix via Zabbix API. Diferente do agente, ele escuta na porta 10051
(mas isso é configurável) e requer que outro “host” a parte seja criado dentro da interface do
Zabbix (veremos isso mais adiante).
2.8.1. Obtenção do binário
Siga o procedimento abaixo para obter o binário do zapcat. Você irá baixálo do Source
Forge.
# cd /var/tmp
# wget http://ufpr.dl.sourceforge.net/project/zapcat/zapcat/zapcat1.2/zapcat1.2.zip
# unzip zapcat1.2.zip
# cd zapcat1.2
# ls
bin build.xml COPYING lib openfire README samples src templates webapp zapcat
1.2.jar zapcat1.2.war zapcatopenfire1.2.jar
Note que o zapcat vem na forma de um .war (aplicação web java) e .jar (applicativo java).
Vamos nos ater apenas ao modo web.
2.8.2. Deployment
Para instalar o Zapcat, simplesmente copie o binário para a pasta de “deploy” da instância
em execução do JBoss. No nosso caso esta pasta é /opt/jboss/server/application/deploy/.
# cp zapcat1.2.war /opt/jboss/server/application/deploy/
# tail /opt/jboss/server/application/log/server.log
…
20110130 06:08:10,616 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel)
[4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)] Started in 27s:81ms
20110130 06:10:25,679 INFO [org.jboss.web.tomcat.service.TomcatDeployer] deploy,
ctxPath=/zapcat1.2, warUrl=.../tmp/deploy/tmp3690979215130123277zapcat1.2exp.war/
A última mensagem do log indica que o pacote foi instalado com sucesso (deployed). Ele
já esta funcionando e podemos averiguar isso com o comando “netstat” como fizemos
anteriormente.
# netstat lntp | grep ':1005'
tcp 0 0 0.0.0.0:10052 0.0.0.0:* OUÇA 29181/java
Repare que, como ele é um aplicativo java, o “netstat” não vai informar o nome dele
(Zapcat) na saída com p.
2.8.3. Opções de inicialização do JBoss
O JBoss precisa de três opções para permitir que o Zapcat possa ler todos os seus
MBeans ( O Tomcat só precisa da primeira). Edite o arquivo de configurações do JBoss e e
acrescente ao final dele o seguinte conteúdo.
# vim /opt/jboss/bin/run.conf
…
1 JAVA_OPTS="$JAVA_OPTS Dcom.sun.management.jmxremote"
2 JAVA_OPTS="$JAVA_OPTS Djboss.platform.mbeanserver"
3 JAVA_OPTS="$JAVA_OPTS
Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImp
l"
4 JAVA_OPTS="$JAVA_OPTS Dorg.kjkoster.zapcat.zabbix.port=10052”
5 JAVA_OPTS="$JAVA_OPTS Dorg.kjkoster.zapcat.zabbix.address=0.0.0.0”
1) O “JMX remote” ativa o sistema de consultas via JMX no JBoss e Tomcat. No caso do
segundo apenas este parâmetro é necessário;
2) O “Mbean server” é a implementação do JBoss para acesso aos JMX via servidor;
3) Indica a classe que deve ser usada para manipular os Mbeans internamente no
JBoss;
4) Esta opção define a porta do Zapcat. Ela é opcional e por padrão o Zapcat escuta na
porta 10052;
5) Esta opção define a qual IP o zapcat deve se vincular. Ela é opcional e por padrão ele
se vincula a todos os endereços disponíveis do host (0.0.0.0).
Reinicie o JBoss e teste o acesso ao Zapcat pelo endereço

http://javaapp.curso468.4linux.com.br/zapcat1.2/, a tela abaixo deve aparecer.
Figura 2.20: Tela de entrada do Zapcat
No próximo capítulo voltaremos a este acesso. Por hora já basta verificar se o Zapcat esta
funcionando.
2.8.4. Liberando o firewall para acesso ao Zapcat
No filtro de pacotes libere o acesso à porta 10052/TCP com os comandos abaixo.
# iptables A INPUT j ACCEPT p tcp dport 10052
2.9. Testando o acesso via SNMP
Uma das máquinas virtuais representa um ativo de rede, um “switch” para ser mais exato.
Nele nenhum agente pode ser instalado e vamos usar o SNMP para realizar o monitoramento.
Para testar se o acesso ao SNMP esta OK, instale as ferramentas de “snmp” no Debian.
# aptitude install snmp snmpmibsdownloader
Libere o acesso a todas as MIBs do seu sistema.
# vim /etc/snmp/snmp.conf
1 #
2 # As the snmp packages come without MIB files due to license reasons, loading
3 # of MIBs is disabled by default. If you added the MIBs you can reenable
4 # loaging them by commenting out the following line.
5 #mibs :
Agora utilize o comando snmpwalk para verificar se o switch retorna os dados de
interfaces de rede.
# snmpwalk c public v2c 172.27.0.135 if
IFMIB::ifIndex.1 = INTEGER: 1
IFMIB::ifDescr.1 = STRING: lo
IFMIB::ifDescr.2 = STRING: eth0
IFMIB::ifDescr.6 = STRING: switch0
…
IFMIB::ifSpecific.1 = OID: SNMPv2SMI::zeroDotZero
Se o comando retornou a lista acima (que foi truncada pelo tamanho) então seu sistema já
consegue ler o SNMP do “switch”.
Se você estiver usando um hardware com uma MIB proprietária, localize e baixe o
arquivo na Internet e copieo no diretório /usr/share/snmp/mibs/
2.9.1. Conceitos de SNMP
O SNMP é um protocolo de monitoramento bem difundido, principalmente entre
equipamentos de rede. A grande maioria do hardware embarcado para rede suporta algum tipo de
versão do mesmo. A mais comum é a versão 2, mas a versão 1 (considerada obsoleta) e a versão
3 (a mais segura) tem uma incidência regular. Se você tiver que optar por uma delas, sempre
tente escolher a mais recente possível. Apesar de adicionar uma certa complexidade, a versão 3
ajuda em muito na segurança pois trabalha com ACLs por autenticação e criptografia. No curso
veremos a versão 2 que é mais comum de se encontrar nos equipamentos (opção v2c no
comando usado anteriormente), mas a diferença de trabalho entre elas é bem pequena
(praticamente alguns campos a mais na versão 3).
Todas as três versões trabalham com MIBS, arquivos texto com definições de como
coletar as OIDS, as strings de acesso das métricas. Uma OID pode ser representada por um texto
como DISMANEVENTMIB::sysUpTimeInstance ou por uma representação numérica como .
1.3.6.1.2.1.1.3.0.
Se você possuir a MIB de um equipamento monitorado pelo Zabbix e quiser utilizar a
forma textual mostrada acima em vez da numérica, terá que copiar o arquivo de texto dela dentro
do diretório de sua distribuição Gnu/Linux onde o servidor estiver instalado.
Normalmente este diretório esta em /usr/share/snmp/mibs/, mas é recomendado que
você confirme se isto vale para a distro que você esta usando.
Por fim, a partir da versão 2 do protocolo SNMP passouse a trabalhar com uma “string”
de comunidade (community). Por padrão esta “string” tem o valor “public” armazenado dentro dela
(parâmetro c do comando snmpwalk). Este valor tem como objetivo permitir apenas que quem
conheça a “community” seja capaz de acessar o SNMP.
Francamente, colocar a segurança de um sistema em cima de um valor em texto plano
que viaja sem criptografia na rede não é nada seguro. Se você realmente quiser
segurança deve usar a versão 3. Também proteja ao máximo o acesso a porta 161 (ou
a qual você definiu) de acessos indevidos, o ideal é permitir apenas acesso dos
endereços dos servidores de monitoramento. Apenas se lembre que ainda assim,
nada é inviolável e o SNMP não é exceção.
2.10. Instalando o servidor Zabbix via pacote
No caso do repositório de uma versão de Debian possuir uma versão do Zabbix que é
adequado a suas necessidades então ao invés de compilar é recomendado que você o utilize. No
presente momento da escrita deste material esse não era o caso.
# aptitude install zabbixserverpgsql
# aptitude install zabbixagent
O CentOS não tem pacotes no seu repositório.
2.11. Preparando o servidor web
Como visto anteriormente o Zabbix é um sistema componentizado e sua interface web
roda dentro de um servidor com suporte a PHP. Esta sessão descreve como instalar e configurar
um servidor Apache 2.2 para tal intento.
2.11.1. Instalação do Apache e PHP5
Para instalar um novo pacote apache com suporte a PHP siga os passos abaixo. O Zabbix
precisa ainda do suporte a GD (uma biblioteca gráfica) para geração de imagens e acesso ao
PostgreSQL.
# aptitude install apache2 libapache2modphp5 php5gd php5pgsql php5ldap
No centOS, use o seguinte comando.
# yum install php http phpgd phppgsql phpldap
2.11.2. Configuração do Virtual Host
Para criar uma configuração de “host” virtual no Apache para o Zabbix, vamos primeiro
criar um diretório e copiar o conteúdo da pasta “front ends” do seu diretório de fontes.
# mkdir p /var/lib/zabbix/frontend
# cd /usr/src/zabbix1.8.4/frontends/php/
# cp * /var/lib/zabbix/frontend/ a
Para assegurar que o apache tenha acesso apenas de leitura a pasta e seus arquivos
execute o procedimento abaixo.
# cd /var/lib/zabbix/
# find frontend type d exec chmod 0750 {} \;
# find frontend type f exec chmod 0640 {} \;
# chown root.wwwdata frontend R
# chmod 0770 frontend/conf
O último comando dá permissões de escrita na pasta “conf” ao servidor, isso é

necessário apenas inicialmente e será removido depois do termino da configuração do
“front end”.
Agora vamos criar o arquivo de “virtual host”. Note que o diretório criado acima é
apontado como raiz e os arquivos de logs são separados do padrão para facilitar a depuração de
erros.
# cd /etc/apache2/sitesavailable
# vim zabbixfront end.conf
1 <VirtualHost *:80>
2 ServerAdmin sysadmin@curso468.4linux.com.br
3
4 DocumentRoot /var/lib/zabbix/frontend 
5
6 <Directory />
7 Options FollowSymLinks
8 AllowOverride None
9 </Directory>
10 <Directory /var/lib/zabbix/front end>
11 Options Indexes FollowSymLinks MultiViews
12 AllowOverride None
13 Order allow,deny
14 allow from all
15 </Directory>
16
17 ErrorLog ${APACHE_LOG_DIR}/errorzabbixfrontend.log 
18
19 # Possible values include: debug, info, notice, warn, error, crit,
20 # alert, emerg.
21 LogLevel warn
22
23 CustomLog ${APACHE_LOG_DIR}/accesszabbixfrontend.log combined 
24
25 </VirtualHost>
1) DocumentRoot precisa apontar para o diretório onde instalamos o “front end”.
2) Em ErrorLog, vamos direcionar os logs de erros para um arquivo específico deste
“virtual host”.
3) O mesmo deve ser feito com o CustomLog, apontando para um arquivo específico de
acessos.
Este passo esta substituindo o site padrão pelo do Zabbix. Se houverem outros hosts
virtuais na mesma máquina não é necessário removêlos, apenas ajuste as configurações do
arquivo acima para receber conexões apenas de uma URL em particular.
# cd /etc/apache2/sitesenabled
# rm 000default
# ln sv ../sitesavailable/zabbixfront end 000zabbixfront end
Reinicie o Apache, abra a porta 80 do firewall e teste acessando a URL

http://zabbix.curso468.4linux.com.br/.
# /etc/init.d/apache2 restart
O primeiro acesso ao “front end” vai enviar o browser direto para o “wizzard” de
inicialização do site. Siga os passos como descrito a seguir para ativar a interface.
2.11.3. Configurando o front end
Figura 2.21: Configuração do front end (1/10)
A primeira tela é apenas uma mensagem de boas vindas. Clique em “Next” para começar.
Marque a opção “I agree” para concordar com a licença do Zabbix e clique em “Next”.
Nesta tela muitos alertas de falha irão aparecer, isso porque o Zabbix requer uma
configuração muito além dos padrões do PHP. Neste ponto é preciso editar o arquivo de
configuração do PHP e modificar os valores necessários.
Note que o status de cada parâmetro pode ser um OK em verde (o servidor já esta
configurado para o recomendado ou superior), Ok em vermelho claro (o servidor já esta
configurado para o mínimo, mas não alcançou o ideal) ou “Fail” em vermelho que indica que nem
o mínimo foi atingido. O ideal é deixar tudo no “Recommended”, porém é preciso avaliar se o
servidor terá os recursos necessários para a execução dessas configurações. Normalmente
teremos servidores que são capazes de fornecer recursos o suficiente para tal.
Com o “vim” abra o arquivo conforme abaixo.
# vim /etc/php5/apache2/php.ini
Procure com o apoio da tabela abaixo e da tela de configuração todas as opções

relevantes e configureas para atingir o “Recommended”.
Parâmetro do PHP Significado

date.timezone Qual fuso horário o PHP deve usar?
Mesmo que o seu sistema esteja
corretamente configurado é importante
configurar este parâmetro para o seu
fuso horário (usualmente
America/Sao_Paulo).
max_execution_time Tempo máximo que um processo do PHP
pode rodar antes de ser morto.
max_input_time Tempo máximo que um processo do PHP
pode gastar interpretando dados.
memory_limit O quanto uma única instância de
execução do PHP pode usar de memória.
post_max_size O máximo tamanho que uma requisição
POST pode enviar ao servidor.
upload_max_filesize Tamanho máximo para “upload” de um
arquivo.
Depois de alterar e salvar o arquivo, reinicie o apache.
# /etc/init.d/apache2 reload
Então clique no botão “Retry”. A tela que será recarregada irá ser similar a abaixo.
Se todos os prérequisitos foram supridos clique em “Next”. Senão refaça os passos

acima até conseguir chegar aos valores recomendados.
O suporte a GD do PHP no Debian Squeeze não atinge o recomendado mas funciona
sem problemas com o Zabbix.
A tela de conexão ao banco de dados precisa ser preenchida conforme explicação abaixo
e Figura 2.26.
1) Escolha o banco de dados, no nosso cenário é o PostgreSQL.
2) Coloque o nome ou IP do “host” do banco de dados, no nosso caso é localhost.
3) Coloque a porta TCP para o acesso, por padrão a do PostgreSQL é 5432.
4) Em Name coloque o nome do banco de dados, “zabbixdb” em nosso caso.
5) Em User coloque o nome do usuário que criamos anteriormente, “zabbix”.
6) Em Password coloque a senha do usuário acima.
Depois de preencher o formulário clique em “test connection” para se certificar de que
tudo correu bem. Se um Ok aparecer acima do botão, clique em “Next”.
Preencha o formulário com os dados do serviço de monitoramento,
1) O servidor de Zabbix esta em localhost, mas atenção para ambientes de produção

onde o servidor do Zabbix esta em outra máquina, neste caso deve ser preenchido o
endereço ou nome da máquina remota.
2) O campo Port corresponde a porta TCP em que o Zabbix esta escutando (Zabbix
trapper), normalmente esta porta é a 10051.
3) O Name é um título do serviço de “front end” do Zabbix. Este título vai ficar
estampando na barra do browser e somente ajuda a identificar o “front end” quando
você tem várias barras de navegação.
Repasse as configurações nesta tela e clique em “Next” se tudo estiver OK.
Esta janela indica que o arquivo de configuração foi gravado com sucesso no diretório
“conf” que deixamos com permissões de escrita anteriormente. É hora de revogar as permissões
de escrita neste diretório.
# cd /var/lib/zabbix/frontend/
# ls lhd conf
drwxrwx 2 root wwwdata 4,0K Jan 27 22:58 conf
# chmod 0750 conf
# ls lh conf
total 28K
…
rwrr 1 wwwdata wwwdata 440 Jan 27 22:58 zabbix.conf.php
…
# chown root.wwwdata conf/zabbix.conf.php
# chmod 0640 conf/zabbix.conf.php
Agora pressione “Next” para ir para a próxima tela.
Clique em “Finish”. O “front end” irá abrir uma tela de login, você pode acessar usando o
usuário Admin (com o A em maiúscula) e a senha zabbix. A tela a seguir será a mostrada para
você.
Figura 2.31: Tela inicial do Zabbix após o primeiro login

2.12. Exercícios de revisão
1) É possível colocar o agente do Zabbix para ser executado no Windows como serviço?
Como?
________________________________________________________________________
________________________________________________________________________
2) Quais os possíveis backends de bancos de dados que o servidor do Zabbix suporta?
________________________________________________________________________
________________________________________________________________________
3) É possível instalar a Interface do “front end” em qualquer servidor que suporte PHP?
________________________________________________________________________
________________________________________________________________________
4) Com o “snmpwalk” podemos listar várias partes ou mesmo todas as métricas SNMP.
Qual o comando você usaria para pegar apenas uma métrica?
________________________________________________________________________
________________________________________________________________________
5) Realize uma breve pesquisa na Internet e relacione todos os agentes de Zabbix que
você encontrar.
________________________________________________________________________
________________________________________________________________________
6) Com o “zabbix_get”, colete via terminal de console o valor das chaves abaixo dos
hosts “win2003” e “application”:
6.1) agent.version: _________________________________________
6.2) system.cpu.num: _________________________________________
6.3) vm.memory.size: _________________________________________
7) (Desafio) Se você tentar usar o “zabbix_get” para coletar dados do Zapcat verá que
ele vai falhar retornando um valor não suportado. Você consegue descobrir como, via
linha de comando poderíamos coletar os valores deste agente? Se sim crie um
pequeno script para fazer a coleta passando para ele host, porta e chave.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 74
Capítulo 3
Criando uma Infraestrutura de Monitoramento
Parte 2, Front end
OBJETIVOS
• Conhecer a configuração do Zabbix via Front end.
• Gerenciar os hosts e templates para o monitoramento.
• Criar métricas de monitoramento.
• Depurar itens não suportados.
• Gerenciar acessos e permissões aos hosts monitorados através de usuários

cadastrados numa base LDAP.
• Configurar os meios de alerta.
• Criar mapas.
• Realizar backups das configurações.
3.1. Introdução
A partir deste ponto a interação administrativa via console vai diminuir consideravelmente,
pois vamos começar a trabalhar com a interface web do Zabbix. Quase 100% de todas as tarefas
com a ferramenta é executada através dessa interface.
Nesta sessão e nas próximas serão apresentadas dicas de uso, organização, todas as
configurações do núcleo do “front end” e criação dos elementos mais básicos de monitoramento
(hosts, templates, grupos, etc.).
3.1.1. Organização do front end
OK, você colocou no ar toda a infraestrutura da solução de monitoramento, agora um web
site com alguns menus esta diante de você. E agora?
Bom, o primeiro passo é entender como os menus do Zabbix trabalham e aprender a
encontrar as opções que você deseja trabalhar. Esta interface é extremamente poderosa e ao
mesmo tempo simples de se operar. No início é provável que haja uma certa confusão na
distribuição das janelas e funções, mas acredite, ela foi desenvolvida para ser fácil de usar após
aprender os entremeios dos menus.
Aproveite e passeie com o mouse nos menus. Note que não é necessário clicar em
nenhum dos menus superiores, somente a passagem do ponteiro já exibirá as opções dos
submenus. Nestes sim é necessário clicar para abrir a tela desejada! Na Tabela abaixo há uma
descrição superficial do que cada item de menu faz.
Menu Função
Monitoring Menu para acesso ao monitoramento, depois que o Zabbix estiver
completamente configurado este é o menu mais acessado de todos.
• Dashboard Tela de centralização das informações de monitoramento.
• Overview Permite a visualização global ou por grupos das métricas
monitoradas e dos alarmes.
• Web Visualização do monitoramento dos serviços de web (não confundir
com monitoramento do servidor web).
• Latest data Mostra os últimos dados (e quando eles foram coletados) do
monitoramento de um host.
Menu Função
• Triggers Mostra o status dos últimos triggers (gatilhos) e permite interação
com eles (como por exemplo dar um Acknowledge a um
determinado gatilho)
• Events Mostra os últimos eventos causados pelos triggers ou pelo
autodiscovery.
• Graphs Visualização individual dos gráficos cadastrados nos hosts.
• Screens Visualização dos screens. Telas que agrupam elementos
monitorados (como mapas, gráficos e widgets).
• Maps Visualização dos mapas.
• Discovery Hosts e elementos que foram descobertos pelo sistema de auto
detecção de hosts.
• IT Services Visualização de SLA baseada no monitoramento de hosts, ativos
e/ou serviços.
Inventory Inventário de hosts
• Hosts Hosts que fazem parte do inventário.
Report Menu de relatório.
• Status do Zabbix Uma tela de resumo (que também é mostrada no Dashboard) para
avalização da performance do servidor Zabbix.
• Avaliability Report Relatórios de disponibilidade por hosts ou triggers.
• Most busy triggers Os 100 triggers mais ativos no sistema.
Top 100
• Bar Report Mostra dados agregados dentro de gráficos de barra, por exemplo,
você poderia ver a média de uso de link por semana ao invés de
usar os gráficos padrão.
Configuration Menu para acesso as opções de configuração de monitoramento.
• Host groups Grupos lógicos para dividir os hosts.
• Templates Gerenciamento de templates (modelos), uma das telas que mais
vamos acessar durante o curso.
• Hosts Gerenciamento dos hosts monitorados.
• Maintenance Tela para colocar ou tirar um determinado host em estado de
manutenção.
• Web Configuração de cenários de teste de serviços web.
• Actions Gerenciamento de ações que os triggers devem tomar ao alertarem
algum comportamento (exemplo: enviar um email quando o
servidor XYZ cair).
• Screens Gerenciamento e construção de screens.
• Slides Gerenciamento e construção de slide shows.
• Maps Gerenciamento e construção de mapas.
Menu Função
• IT Services Gerenciamento dos serviços para cálculo de SLA
• Discovery Gerenciamento do “auto discovery”.
Administration Menu para acesso às opções de administração do front end.
• General Opções globais do front end.
• DM Configuração de monitoramento distribuído.
• Authentication Métodos de autenticação.
• Users Gerenciamento de usuários para acesso ao “front end”.
• Media Types Gerenciamento de formas de alertas (emails, SMS, etc.)
• Scripts Gerenciamento de scripts para testes online pelo “front end”.
• Audit Logs de auditoria de ações dos usuários e de eventos gerados
pelas Actions.
• Queue Fila de alertas a serem “acknowledged”.
• Notifications Notificações enviadas por usuário/tempo.
• Locales Personalização das strings de exibição para tradução (português
brasileiro já esta pronto, portanto não precisamos mexer aqui).
• Instalation Telas de instalação (as mesmas que passamos agora a pouco para
configurar o “front end”).
Tabela 4: Função dos menus no front end
Não é intenção do curso detalhar todos os itens de todas as telas (isso provavelmente
seria tarefa de um livro bem grande). Embora simples a interface do Zabbix tem uma magnitude
de opções bem grande e vamos nos concentrar nelas aos poucos conforme a necessidade e
escopo do curso.
3.2. Gerenciamento de usuários
O ponto mais lógico para começar é administrar quem pode acessar o “front end” e definir
uma senha ao usuário Admin. Vamos entrar no menu Administration → Users. No canto direito
da tela que vai aparecer, você verá um “combobox” ao lado do botão “Create User” clique sobre
ele e selecione “Users”. A Figura 3.1 mostra a tela que irá ser exibida.
Figura 3.1: Gerenciamento de usuários do Zabbix
Dois usuários serão exibidos: Admin, superusuário do “front end”, com o qual estamos
logados e guest, usado para acesso sem autenticação.
Não tente apagar o usuário “guest”. Ele é necessário para a tela de login quando
entramos na interface.
Esta tela mostra várias informações interessantes, como por exemplo, quando foi
realizado o ultimo login e quem esta online no “front end”.
Para editar o Admin clique sobre o link com o nome dele. Uma nova tela ira aparecer.
Figura 3.2: Editando o Admin
Clique em “Change password” e coloque a senha a sua escolha, não esqueça essa senha
ou vai ser necessário reiniciála no banco de dados. Para evitar que o Zabbix fique desligando
nossa sessão a todo momento desligue a opção “Autologout”. Depois de terminar clique no botão
“Save”. Isso é apenas um salvaguarda em casos de problemas de autenticação com o LDAP,
como você verá logo a seguir iremos passar toda a autenticação para o sistema de diretório (que
também possui um usuário Admin).
Em produção não desligue o “autologout” de nenhum usuário a menos que seja

absolutamente necessário! Para ser exato, o único motivo válido que o autor encontrou
em deixar um usuário 100% do tempo logado é quando o Zabbix esta sendo usado
para exibir um mapa, screens ou slide show em um telão ou TV com acompanhamento
visual 24x7.
Agora que o Admin teve a senha modificada, é o momento de configurar o Zabbix para
autenticar no diretório LDAP instalado no servidor. Entre em Administration → Authetication,
selecione em “Default Authetication” a opção LDAP e preencha os campos conforme abaixo.
Figura 3.3: Configurando a autenticação LDAP
Os dados aqui preenchidos variam de um ambiente para outro, no caso de estudo do
curso estamos dizendo ao Zabbix onde está o servidor (LDAP Host e Port), qual é a raiz do
domínio (Base DN), qual o atributo usado em busca (por profundidade), não foi fornecido usuário
e senha de acesso ao LDAP, ou seja, ele é “read only guest based” (Bind DN e Bind Password) e
ativamos a autenticação (LDAP Authentication Enabled).
É possível e recomendado que a senha do usuário Admin cadastrada dentro do LDAP
seja testada, preencha a senha e clique no botão “Test”. O Zabbix vai dizer se foi bem sucedido
ou não. Para salvar também é obrigatório que a senha seja digitada corretamente.
Normalmente teremos um usuário e senha com “read only” para acesso do LDAP em
produção. Permitir acesso “read only guest based” não é a forma mais segura de se
fazer acesso a base de diretórios.
3.2.1. Cadastrando os usuários do LDAP no Zabbix
Apesar do Zabbix estar apontando para o LDAP e o Admin estar funcionando é preciso
mapear quais usuários da árvore de diretórios para dentro do “front end”. Se você não o fizer, não
será capaz de logar com um determinado usuário.
No cenário que estamos usando temos alguns usuários descritos na Tabela que devem
ser adicionados e alguns novos grupos de usuários que irão organizar alguns deles.
Usuário Descrição Grupos

sysadmin Administrador de Network Administrators, UNIX
sistemas UNIX Administrators, Web Administrators
winadmin Administrador de Network Administrators, Windows
sistemas Windows Administrators
javaeng Administrador do JBoss Administratros
JBoss AS
dba Administrador do Database Administrators
banco de dados
Table 5: Usuários do cenário do curso
Não temos os grupos “Windows Administrators” e “JBoss Administrators” pré cadastrados
no Zabbix. Portanto o primeiro passo é justamente criálos. Entre em Administration → Users e
clique no botão “Create Group”. Na Figura 3.4 temos um exemplo da tela de criação do “JBoss
Administrators”. Não é necessário mais do que o nome do grupo no campo “Group Name”, pois
iremos definir suas permissões mais adiante.
Figura 3.4: Novo Grupo JBoss Administrators

Salve e escolha Users no combobox ao lado do botão “Create Group”, isso vai nos fazer
voltar à tela de usuários onde editamos o Admin. Clique no botão “Create User” e cadastre os
usuários da Tabela 5 conforme a Figura 3.5.
Figura 3.5: Novo usuário Sysadmin
O “Alias” é o campo com o nome do usuário e deve estar 100% igual ao dentro do LDAP.
“Name” e “Surname” são apenas “labels” para exibição e no quadro “Groups” use o botão “add”
para acrescentar a quais grupos o usuário pertence.
Um campo que merece uma atenção especial é o “User Type” que permite dar alguns

privilégios iniciais à conta. No nosso caso iremos utilizar o tipo mais simples, o “Zabbix User”, que
permite apenas acesso ao menu de monitoramento.
Podemos ainda criar outros dois tipos de usuários, como o “Zabbix Admin” que pode
acessar o monitoramento e a configuração de hosts. Este caso é útil quando alguém deve ter
permissões de verificação e também direito de cadastrar e modificar hosts monitorados assim
como seus “templates” e grupos. Por fim temos o “Zabbix Super Admin” que é o caso do nosso
usuário Admin. Este último pode fazer tudo, inclusive adicionar e remover direitos ao usuários.
Mais a frente iremos acrescentar direitos aos usuários e também mudaremos seus tipos
conforme a necessidade.
3.3. Meios de alertas
Os “Media Types” os nomes que o Zabbix atribui aos meios de envio de alertas. Como já
foi dito o Zabbix suporta correio eletrônico, SMS via modem, SMS via serviço de rede (EUA e
Canada apenas), mensageiro instantâneo via Jabber e chamada de scripts externos. No nosso
cenário de curso iremos aprender a trabalhar com estes recursos usando o sistema de email e
jabber (os quais configuramos os clientes no início do capítulo). Entre em Administration →
Media Types a tela da Figura 3.6 será exibida com os três meios de comunicação pré
configurados no servidor. Para editar qualquer um deles clique no nome da coluna Description.
Para criar um novo, clique em “Create Media Type”.
É possível ter múltiplos meios do mesmo tipo, por exemplo, ter vários servidores de email
para ajudar na redundância do serviço de alerta ou dedicar determinados tipos de emails para
diferentes servidores.
Figura 3.6: Media Types

Também é aconselhável limpar os “Media Types” não usados, como no nosso caso de

uso, não usa SMS, marque no “checkbox” a frente de seu nome, e em seguida selecione “Delete
selected” na caixa de ações ao fim da tabela e clique em Go (1). Confirme a exclusão.
Ambas, a operação de limpeza e o modo de fazêla, são bem triviais e serão muito
comuns no curso. Ela será repetida em muitos outros locais.
3.3.1. Correio eletrônico
Agora edite o item de email, a tela da Figura 3.7 será exibida. Preencha os campos
conforme a mesma. Description é um campo descritivo apenas e não tem efeitos na configuração
a não ser identificar este “Media type” na interface; SMTP Server aponta para o nome/IP do
servidor de emails (porta TCP/25); SMTP helo é usado na mensagem inicial trocada entre Zabbix
e servidores, é aconselhável colocar o domínio da própria empresa; SMTP email é o endereço de
remetente que o Zabbix usará para enviar a mensagem.
Figura 3.7: Configurando o Zabbix para enviar e-mails
Clique em “Save” quando terminar.
3.3.2. Mensagens instantâneas
Agora iremos editar o Jabber, clique sobre o nome dele e preencha os campos conforme
a Figura 3.8.
Figura 3.8: Configurando o Zabbix para enviar mensagens instantâneas

Os campos “Jabber identifier” e “Password” são o usuário e senha de uma conta

cadastrada no IM destinada exclusivamente ao Zabbix, a senha no curso é 123456. Salve os
dados.
Sempre que utilizar um identificador de usuário no Jabber você deve incluir o nome do
servidor completo após o @ e não apenas o domínio.
3.3.3. Apontando os alertas aos usuários
Agora vamos dizer quais usuários usam qual “Media Type”. Edite o usuário “sysadmin” e
note que no final da tela um campo “Media” esta com o valor “No media defined”.
Figura 3.9: Media Types de um usuário sem apontamentos
Clique em “Add” para adicionar um novo meio de alerta ao usuário. Vamos começar pelo
email.
Figura 3.10: Adicionando o Media Type Email a um usuário
Coloque o email do usuário (que é o mesmo que seu “Alias” mais o domínio do curso no
exemplo: sysadmin@curso468.4linux.com.br). Nesta tela podemos ainda escolher quando este
meio vai ficar ativo no campo “When active”. Este campo tem uma sintaxe bem peculiar, ele indica
quais os dias da semana e a faixa de horário que o usuário pode receber alertas. Isso é útil para
não enviar alertas a pessoas fora do expediente, isso é claro, supondo que haja outra pessoa de
prontidão no horário determinado.
A sintaxe do “When Active” usa 1 como segunda e 7 como domingo, definir por exemplo
segunda a sexta ficaria “15”. Uma vírgula separa o dia do horário, segunda a sexta das 09:00 até
as 18:00 ficaria “15,09:0018:00”. Podemos ainda usar o pontoevírgula para definir outras faixas,
por exemplo segunda a sexta, das 09:00 às 18:00 e sábado das 09:00 às 13:00 ficaria “15,09:00
18:00;6,09:0013:00”.
O “Use if severity “filtra os tipos de severidade de um campo. Eles são importantes para
que meios de alertas com custo (SMS) não sejam usados para alertas de pouca importância.
Também são usados para não causar avalanches de alertas em um meio os quais eles mais
incomodariam do que ajudariam, imagine ser alertado todo minuto por mensagem instantânea
que um serviço foi reiniciado! Seria totalmente improdutivo.
Por fim, “Status” controla se este “Media Type” estará ou não ativo. Isso é particularmente
útil quando o funcionário responsável estiver de folga, afastado ou de férias.
Clique em “Add” para salvar e adicione outro “Media Type” para o Jabber.
Figura 3.11: Adicionando um media type Jabber a um

usuário
No nosso exemplo deixe o Jabber apenas com severidade “High” e “Disaster”. O nome do
usuário em “Send to” é o mesmo que o Alias. Salve e veja na Figura 3.12 como o campo “Media”
ficará.
Figura 3.12: Media Types de um usuário após o cadastro
Salve e repita para todos os usuários agora.
3.3.4. Boas práticas com Media types
Há algumas recomendações a serem feitas quando se trabalha com alertas de sistemas
monitorados.
1) Mantenha mais de um meio de alerta para sistemas críticos. Isso pode ser feito
mantendo vários serviços de mesmo tipo (dois servidores de email, dois modems
SMS, etc.) ou melhor, fazendo com que ele seja enviado por várias mídias (SMS,
Jabber e email, todos aos mesmo tempo).
2) Escolha os “Media Types” de maneira lógica. Não adianta enviar alertas via Jabber se
os técnicos raramente estão online do sistema de mensagens instantâneas. Também
não adianta enviar um email de desastre as três da madrugada quando ninguém esta
olhando emails.
3) Procure deixar alertas que precisam de resposta imediata em meios que alcançam o
usuário com facilidade. SMS é mais clássico, mas o autor já implementou um que se
vinculava ao “asterisk” e fazia uma ligação descrevendo o problema (como uma URA
ativa).
4) Planeje! Faça escalas entre os funcionários, evite dar alta prioridade a alertas triviais e
cuidado com os falsos positivos, eles podem gerar o “problema do lobo”.
“O problema do lobo” é aquela história do menino pastor que gritava “LOBO! LOBO!” na
vila onde morava e todos iam correr ao seu socorro, para descobrir que era apenas
uma brincadeira. Após vários episódios, os aldeões começaram a ignorar os apelos
falsos do garoto, e justo neste dia um lobo apareceu de verdade.
Receber alertas seguidos vai treinar o nosso cérebro a ignorálos se eles se
comprovarem falsos positivos. Veremos ao longo do curso como diminuir os falsos
positivos.
3.4. Hosts, host groups e templates
Nesta sessão iremos abordar os conceitos mais fundamentais de monitoramento do

Zabbix: hosts, host groups e templates.
Hosts são a representação de um servidor, serviço ou ativo de rede a ser monitorado.
Eles normalmente representam um sistema físico, mas isso não é totalmente verdade, o agente
do Zapcat por exemplo, será representado por um host a parte e ele não é um hardware.
Host groups separam logicamente os hosts e permitem que sejam atribuídas permissões
de acessos dos usuários a um determinado host.
Templates (modelos) são os blocos de construção do monitoramento, enquanto não são
obrigatórios, pois podemos acrescentar métricas de monitoramentos direto a um host, eles
ajudam a gerenciar de maneira efetiva os diversos tipos de monitoramentos possíveis e replicálos
a tantos hosts quanto quisermos (ou o quanto nossos sistemas aguentarem, o que vier primeiro).
Os templates agregam métricas de monitoramento chamados items, macros e outros valores que
são importantes para construir uma solução de monitoramento. A maior parte do seu trabalho no
curso será em cima dos templates.
3.4.1. Templates para o caso de estudo
O primeiro passo é limpar todos os templates preexistentes no Zabbix. Apesar de parecer
um tanto agressivo excluir todos os modelos pré criados, parte do intuito do curso é construir os
seus templates de maneira adequada a sua necessidade. Em produção você pode conserválos
se desejar, mas isso não é um requerimento a menos que você tenha garantidamente um
equipamento para o qual um dos modelos tenha sido construído. Outra opção é fazer backup dos
originais (veja a próxima sessão).
Figura 3.13: Selecionando todos os templates pré

cadastrados
Para selecionar todos os templates, entre em Configuration → Templates e clique no

“checkbox” do topo da tabela conforme indicado a Figura 3.13.
Figura 3.14: Excluindo os templates selecionados
Depois escolha no “combobox” no final da tabela o valor “Delete selected with linked
elements” e pressione o botão “Go”.
Perceba que o Zabbix indica quantos elementos serão afetados pela ação do
“combobox” no botão “Go” no número entre parênteses.
Esta operação pode demorar alguns minutos dependendo da CPU e do I/O de disco
que seu equipamento possui.
Agora é o momento de criar o primeiro template.
Figura 3.15: Criando um novo

template
Para criar um novo template, clique no botão a direita da tela “Create Template” conforme
indicado na Figura 3.15. Uma nova tela vai se abrir conforme a figura a seguir.
Figura 3.16: Cadastrando um novo template

1) No campo Name será colocado o nome do novo template. Que será “4Linux – ICMP
base”. Este template conterá as métricas mais básicas de testes por ICMP.
2) No campo Groups, quadro “In Groups” o grupo Templates deve ficar selecionado.

Note que os grupos para hosts são misturados com os grupos de templates.
Você pode criar um novo grupo usando o campo “New group” sem a necessidade de
fazêlo na tela de grupos de hosts.
3.4.2. Vínculo entre templates
É possível estabelecer um relação de dependências entre um modelo e outro, isso é
extremamente útil para criar estruturas de templates que são compostos por várias partes, por
exemplo, um conjunto de templates que testa um serviço sobre um sistema operacional. Quando
o template de serviço é adicionado ao host todos os outros aos quais ele dependem são
adicionados.
Um detalhe de extrema importância deste recurso é que podemos criar uma dependência
entre as triggers (gatilhos) que ativam os alertas do Zabbix. Isso é importante porque uma trigger
de alto nível não deve ser ativada se uma mais básica estiver ativa (não é preciso testar se o
agente do Zabbix está em pé se o ping ICMP estiver acusando host inalcançável).
Seguindo as mesmas instruções mencionadas acima, crie mais um modelo chamado

“4Linux – S.O. Base”.
Figura 3.17: Vinculando um template a outro
1) Na parte inferior da tela você verá um botão “Add” ao lado do campo “Link with
template”
2) Escolha o template relacionado (4Linux – ICMP no nosso caso).
3) Salve o template.
Agora se associarmos um host com o template “4Linux – S.O. Base” ele automaticamente
vai receber todos os objetos definidos no “4Linux – ICMP”. Aproveite e crie mais um último
template para usarmos na prática dirigida, “4Linux – SNMP Base” também vinculado ao “4Linux –
ICMP”.
3.4.3. Backup dos templates
Uma ação importante em todo sistema é criar um backup das configurações. A partir de
agora toda modificação que fizermos nos mapas, templates, grupos e hosts deverá ser seguida de
um backup. A operação de backup, chamada “Export” é bastante padronizada, todas as telas
pertinentes a fazer backup utilizam o mesmo procedimento explicado abaixo. O resultado é um
arquivo XML contendo os dados de configuração.
Figura 3.18: Exportando um template

1) Selecione todos os templates que você desejar.
2) Selecione “Export Selected” na caixa de opções do final da tabela.
3) Clique no botão “Go”.
Uma tela de download irá ser exibida, escolha o nome e local do arquivo e salveo.
Mantenha estes dados em um local seguro e sempre realize esta operação após algum
tipo de alteração.
3.4.4. Hosts
Agora que um template foi definido vamos criar um host e associálo a este modelo. Na
Figura 3.19 esta uma representação de como as máquinas virtuais estão dispostas em termos de
“layout” de rede. Em nossa prática dirigida iremos cadastrar os hosts “Presentation“ e “Switch”,
além de modificar o “Zabbix Server“ que é criado automaticamente no momento do importe de
dados do PostgreSQL.
Figura 3.19: Layout dos hosts a serem monitorados
Também devemos criar alguns grupos adicionais para separar logicamente cada servidor,
para isso vamos gerenciar os “Host Groups”.
3.4.5. Gerenciando os Host Groups
Um “Host group“ tem duas funções dentro do Zabbix: a primeira e mais óbvia é manter
os hosts organizados de tal forma que seja mais fácil localizar ou exibir um grupo de servidores
com serviços correlacionados. A segunda é o sistema de permissionamento de acesso aos hosts
que será trabalhado ao longo do curso.
Para exemplificar a criação dos hosts vamos criar apenas um deles, que conterá os
equipamentos de rede. Clique no menu Configuration → Host Groups, e clique no botão
“Create Group” conforme a Figura .
Figura 3.20: Como criar um novo grupo

de hosts
A seguinte tela irá surgir.
Figura 3.21: Novo host group

1) No campo “Group name“ coloque o nome do novo grupo (Network Devices no nosso
caso).
3.4.6. Criando um novo host
Agora que geramos um “host group”, vamos criar os hosts, acesse Configuration →
Hosts, algo similar a Figura 3.22 irá aparecer. Como dito anteriormente a lista de hosts já possui o
próprio servidor do Zabbix précadastrado.
Figura 3.22: Host pré-cadastrado no front end na tela de Hosts
Para criar um novo host para o “host Presentation” da infraestrutura clique no botão
“Create Host” (Figura 3.23).
Figura 3.23: Botão para criar um host
E preencha os dados conforme a figura a seguir.
1) O campo Name coloque o nome do host (Presentation no nosso caso).
2) No Groups escolha quais grupos este host deve pertencer. Lembrese que estes
grupos vão indicar quem pode ou não acessar este host pelo “front end”.
3) Se houver um novo grupo não cadastrado acima é possível criálo aqui.
4) Qual o nome DNS da máquina.
5) Qual o endereço da máquina.
6) O campo “Connect to” permite que seja escolhido o acesso pelo endereço IP ou pelo
nome de DNS. O clássico é usar o endereço (evitando consultas DNS excessivas no
lado do servidor), mas é possível que seja necessário monitorar estações de usuários
ou servidores que estejam em ambientes com IP dinâmico (via DHCP) e neste caso
somente via DNS é possível encontrar o host .
7) Qual a porta TCP do agente. Vamos mudar isto para monitorar o “Zapcat”, mas em
todos os outros casos deixaremos ela no padrão 10050.
8) Não monitoraremos este host via proxy.
9) No Status deixe como “Not monitored” por enquanto, quando associarmos os
templates iremos ativar este host.
Crie todos os hosts do cenário conforme indicado na Figura 3.24.
Figura 3.24: Todos os hosts do cenário cadastrados

10)
3.4.7. Fazendo backup dos hosts
O processo de backup dos hosts segue o mesmo procedimento do template. Selecione
todos os hosts criados e faça o backup dos mesmos.
3.4.8. Configurando uma permissão de acesso
Com os usuários, grupos, máquinas e modelos definidos, vamos ver como dar o acesso
ao monitoramento de determinadas porções do Zabbix para a conta “sysadmin”. Isso é feito
através dos grupos de usuários e grupo de hosts. Acesse Administration → Users.
Figura 3.25: Concedendo permissões de acesso (1/4)
1) Selecione “User groups” se já não estiver nesta opção.
2) Clique no nome do grupo “Unix administrators”.
Dentro da tela do grupo localize na parte inferior da tela as caixas de permissões (Figura
3.26). Clique no botão “Add” da caixa “ReadWrite”.

No dialogo que aparecer selecione o grupo de hosts “Linux Servers” e clique em “select”.
Ao retornar você verá o grupo na caixa. Clique em “Save” e pronto, quem pertencer ao

grupo “Unix administrators” vai poder ler e gravar nos hosts dentro de “Linux servers”.
Os direitos de “deny” tem precedência aos de “read only”, que por sua vez tem
precedência sobre os de “read write”.
3.4.9. Exercícios sobre usuários, hosts, grupos e permissões.
1) O cenário do curso precisa de um conjunto de permissões conforme a Tabela abaixo.
Crie grupos de hosts e usuários, e atribua permissões conforme for necessário para
chegar a este resultado. Note que há um novo usuário.
Usuário Applica- Databa- JBoss AS Presen- Switch Windows Zabbix

tion se tation 2003 server
suporte read only read only read only read only read only read only read only
sysadmin read- read- read only read- read- read only read-
write write write write write
winadmin read only read only read only read only read- read- read only
write write
dba read only read- read only read only read only read only read only
write
javaeng read only read only read- read only read only read only read only
write
Tabela 6: Relação de permissões entre hosts e usuários
Exceto pelos usuários “suporte” e “Admin”, todos os usuários devem ter permissão de
mudança de configuração dos hosts no qual eles tem direito de escrita.
3.5. Mapas
Os mapas são elementos visuais úteis para determinar onde foi o ponto de falha dentro de
uma infraestrutura. Eles são de extrema valia para equipes que avaliam a saúde das máquinas
constantemente e precisam reagir rapidamente diante de um incidente.
O Mapa também pode ajudar a diagramar estruturas físicas de rede e ajudam a mostrar
como os equipamentos se relacionam, embora o “front end” não seja uma ferramenta de
desenhos de diagramas propriamente dita.
3.5.1. Importando imagens para o mapa
Antes de criar um mapa é preciso definir as figurar que farão parte de seu desenho.
Anteriormente nós pulamos o “dump” das figuras padrão do Zabbix, isso foi proposital pois iremos
inserir figuras de melhor qualidade dentro do “front end”.
O conjunto de figuras que utilizaremos esta dentro do fórum do Zabbix através do link
http://www.zabbix.com/wiki/_media/contrib/zabbix_icons_set_generic.zip. Acesseo e baixe o
arquivo para uma pasta em se computador (não é necessário enviálas à máquina destinada ao
servidor, todo o procedimento de inserção será feito pelo “front end”). Depois descompacte o
arquivo para ter acesso ás imagens.
Acesse o menu Administration → General, e escolha na caixa de opções a esquerda. A
opção “Images”.
Figura 3.29: Tela inicial das imagens
Nesta tela clique no botão “Create Image” para abrir o diálogo de importação de uma nova
imagem. Conforme as instruções abaixo importe a primeira imagem.
Figura 3.30: Importando uma nova imagem
1) Nome da imagem a ser inserido, este nome precisa ser único. No primeiro caso
coloque o valor “Server On”.
2) Podemos enviar ícones (Icons) ou fundo de telas (Background) ao “front end”. Ícones
são usados nos elementos como hosts, triggers e imagens estáticas, telas de fundo
obviamente são usadas como um fundo para o mapa.
3) No campo Upload, clique no botão “Browse...” e escolha o local onde a imagem se
encontra, no caso do curso a imagem utilizada é o ícone de tamanho 48x48 e nome
“48_g_srv_tower_on.png”.
Realize o mesmo procedimento para outras imagens conforme a tabela abaixo.
Nome da imagem Ícone

Link 48_g_network_on.png
Server Disable 48_g_srv_tower_disable.png
Server Off 48_g_srv_tower_off.png
Server Unknown 48_g_srv_tower_unknown.png
Switch Disable 48_g_switch_disable.png
Switch Off 48_g_switch_off.png
Switch On 48_g_switch_on.png
Switch Unknown 48_g_switch_unknown.png
Tabela 7: Lista de imagens iniciais para o mapa
Com isso todas as imagens necessárias para o primeiro estágio do mapa foram criadas.
3.5.2. Criando um mapa
Agora que todos os ícones estão dentro do “front end” vamos criar o primeiro protótipo de
mapa. A imagem final dele esta representado na Figura 3.31.
Figura 3.31: Imagem do primeiro

mapa a ser criado
Este mapa não tem todos os elementos a serem inseridos no mapa, mas vai proporcionar
um bom primeiro exemplo. Abra a tela de gerenciamento de mapas acessando o menu
Configuration → Maps, um mapa précadastrado (Local network) irá ser exibido, marque a caixa
de checagem dele e exclua ele da lista.
Figura 3.32: Mapas pré-cadastrados
Depois de apagar o mapa existente crie outro novo clicando no botão “Create Map” no

canto direito da tela. Uma tela como na Figura 3.33 irá surgir e é preciso cadastrar os dados do
novo mapa conforme a seguir.
Figura 3.33: Novo mapa
1) O campo Name indica o nome do novo mapa, no caso desta prática dirigida coloque
“Infraestrutura Curso 468”.
2) A largura em pixels do mapa, “600” é um bom tamanho para o nosso caso.
3) A altura do mapa, “500” é um bom tamanho para o nosso curso.
4) No campo “Background Image” podemos escolher uma figura de fundo para este
mapa. Vamos deixar o mapa sem figura de fundo.
5) A opção “Icon highlighting” serve para pedir ao Zabbix desenhar fundos nos ícones
para representar estados, ela é um tanto redundante em relação a múltiplas figuras de
ícones como vamos ver mais a frente, porém iremos deixálas ligadas mesmo assim.
6) Se o ícone possuir um “trigger” que teve seu estado mudado recentemente, uma
borda será desenha em volta do ícone.
7) No caso de haver um incidente com um item em particular, e ele for único (é somente
um problema para aquele item em particular) podemos deixar o campo “Expand
single problem” ligado para que a descrição do problema seja apresentado no mapa
(evitando ter que clicar no item para exibilo).
8) Qual o tipo de mensagem que será adicionada ao nome do item na tela quando um
“trigger” for exibido. Os valores possíveis são: “Label”, o default indicando que deve
exibir o nome do rótulo; “IP Address”, mostra o endereço de rede do host; “Element
name”, o nome do elemento que esta apresentando problemas; “Status only”, que
indica o status do “trigger” (OK ou PROBLEM); “Nothing”, nada é mostrado.
9) Localização padrão dos labels.
10) No campo “Problem display” podemos escolher se desejamos mostrar todos
os problemas em uma única linha (All), duas linhas com os problemas com
“acknowlegment” e outro sem (Separated), ou ainda somente os problemas sem
“acknowlegment “ chamados de “Unacknowledged”.
Depois clique no botão “Save”. Você irá retornar a tela anterior. Agora para criar o mapa
visual clique sobre o nome do mapa.
Não se preocupe em decorar e testar todas as opções de mapas, iremos detalhar a
maior parte delas durante o curso.
Decidir o tamanho da área de mapas é uma arte, ela depende de vários fatores como
por exemplo o tamanho do monitor onde ele será exibido. Não se acanhe de retornar a
edição de configurações do mapa se o tamanho da área não ficar a seu gosto em um
primeiro momento.
3.5.3. Adicionando um elemento
Dentro da tela de mapas, uma área em branco dividida por linhas de alinhamento será
exibida. Seu tamanho é o definido na tela de cadastro de mapas. Na parte superior da tela você
pode ver uma barra de ferramentas como na Figura 3.34, a explicação que segue define o uso de
cada botão.
Figura 3.34: Barra de ferramentas para edição de mapas

1) O botão com sinal de mais (+) adiciona um novo ícone, que é o elemento principal
dentro de um mapa. Este ícone pode ser uma figura estática, um “trigger”, um link
para outro mapa, etc. Se você selecionar um ou mais elementos e clicar no botão com
sinal de menos () você irá excluir estes elementos.
2) Ao clicar em dois elementos é possível criar um link entre eles, representado por uma
linha (cor, formato, etc. podem ser personalizados). Este link pode conter uma “label” e
indicar a mudança de estados de um gatilho.
3) No campo “Grid” podemos deixar a grade de alinhamento oculta ou não clicando em
“Shown/Hide”.
4) Também podemos ligar ou desligála clicando em “On/Off”.
5) Na caixa de combinação a seguir a resolução da grade pode ser escolhida, variando
desde 20x20 (para ajuste fino de ícones) até 100x100 (para casos de mapas extensos
ou ícones bem grandes).
6) Por fim, o botão “Align Icons” força o Zabbix a alinhar todos os elementos do mapa
nos limites mais próximos da grade.
Para o propósito inicial do curso a resolução de 50x50 é o suficiente. Vamos inserir um
novo ícone para representar o link de internet. Clique no botão mais do campo “Icon” e um novo
elemento irá aparecer no canto superior do mapa. Note que o Zabbix escolherá o primeiro
elemento gráfico disponível para ele.
Figura 3.35: Criando um novo

elemento
Arrasteo até a parte da tela que você desejar para posicionálo.
Figura 3.36: Posicionando um novo elemento com o mouse
Versões anteriores do Zabbix não eram capazes de usar Drag & Drop. Tudo tinha que
ser feito com coordenadas manuais.
3.5.4. Editando um elemento do mapa
Uma vez que o ícone esteja posicionado, é possível editar os seus atributos conforme os
passos descritos a seguir. Um elemento na tela pode ser de vários tipos, ele pode por exemplo
representar uma imagem estática, um host ou um gatilho.
Quando o ícone representa um elemento dinâmico ele vai reagir a mudanças dos estados
de qualquer um dos “triggers” associados visualmente. Como já foi dito antes isso é
extremamente importante para acompanhamentos visuais, especialmente se for utilizado telões
ou monitores numa sala de acompanhamento de incidentes.
Figura 3.37: Editando um elemento na tela
1) Clique sobre o objeto criado anteriormente. A tela a direita irá ser exibida e pode ser
reposicionada na tela permitindo enxergar um determinado trecho do mapa na tela.
2) O campo “Type” indica o tipo de objeto mencionado anteriormente, no primeiro caso
iremos escolher “Image” porque o link não representa nenhum elemento monitorado
(apesar que posteriormente vamos monitorar o estado do link). Conforme o
andamento do curso veremos muitos outros tipos.
3) No campo “Label” digite o texto a ser exibido como rótulo do ícone. Aqui como
veremos mais tarde é possível colocar variáveis especiais chamadas de “Macros” que
o servidor associa a valores dinâmicos.
4) A localização deste rótulo pode ser escolhida em “Label location”. Por padrão ela fica
como foi definido no padrão da criação do Mapa.
5) Qual a imagem do ícone a ser exibida? Neste caso vamos deixar como esta, mas
todas as imagens que fizemos “upload” estão sendo exibidas nesta caixa de seleção.
6) Por fim podemos configurar as coordenadas da posição do elemento dentro do mapa
em “pixels”. Normalmente fazemos isso pelo sistema “Drag and Drop”.
No término clique em “Apply” para aceitar as modificações. Isso não vai fechar a tela de
edição, para isso ainda temos que clicar em “Close”.
3.5.5. Salvando o mapa
É importante que salvemos constantemente o mapa, pois se você clicar em outro link de
menu do “front end” irá perder todas as alterações feitas até esse momento. Para salvar o mapa
clique no botão “Save” (Figura 3.38).
Figura 3.38:
Botão Save do
mapa.
Um diálogo sempre aparecerá ao salvar um mapa. Ele não esta confirmando se você quer
salvar, e sim perguntando se deve retornar a tela anterior ou continuar no mapa. “Cancel” é usado
para continuar no mapa e “OK” para voltar a tela de gerenciamento de mapas.
Figura 3.39: Dialogo de salvar mapa
3.5.6. Adicionando os outros elementos
Agora adicione mais dois elementos no mapa para representar os hosts “Presentation” e
“Switch” e posicioneos como na Figura 3.40.
Figura 3.40: Outros elementos

gráficos a serem adicionados
Clique no elemento do meio para editálo conforme abaixo, ele servirá de representação
para o host “Presentation” agora.
Figura 3.41: Editando o elemento que representa o host Presentation
1) Neste campo vamos escolher o valor “host”. Visto que vamos utilizar um dos
previamente cadastrados, você verá que por ele estar desativado, quando clicar em
“Apply”, o “label” DISABLED será mostrado em vermelho.
2) Neste campo o valor da macro {HOSTNAME} será substituído pelo nome que
cadastramos o host no gerenciamento dos mesmos. Esta macro é interna do Zabbix e
não precisa ser definida pelo usuário. Durante o curso aprenderemos outras e
definiremos várias que serão personalizadas para a nossa necessidade.
3) Neste campo, que aparece sempre que escolhemos Host em “Type” clique em
“Select” e escolha o host desejado. Neste caso é o “Presentation”.
4) Troque o ícone para “Server On”, visualmente ele deve representar uma máquina.
5) Ao ativar “Use advanced icons” os campos do item 6 serão exibidos. Isso permite

escolhermos um ícone diferente para cada estado. Como foi mencionado
anteriormente isso é um tanto redundante com o sistema de “highlighting” do mapa,
mas vamos ativar ambos para que você veja a diferença entre eles.
5.1) Nestes campos escolha os ícones conforme indicado. Cada um dos estados irá
exibir um ícone diferente. Perceba que o exibido na tela ao clicar em “Apply” é o
“Server Disable”.
O mesmo será feito para o elemento do host “Switch”, a Figura 3.42 mostra quais são os
valores utilizados.
Figura 3.42: Detalhes do host switch dentro do mapa
Como resultado final uma imagem parecida com a Figura 3.43 deve estar no meio de sua
área de mapa.
Figura 3.43: Hosts

acrescentados no mapa
3.5.7. Criando e editando links
Com os elementos de hosts e imagens no mapa ainda falta criar os links que interligam
um elemento a outro. Os links podem tanto ser um simples traço para mostrar uma ligação entre
dois elementos como também podem ser usados para demonstrar estados de gatilhos com
problemas.
3.5.8. Prática Dirigida
Figura 3.44: Criando um novo link entre o host Presentation e a imagem Internet
1) Primeiro selecione o ícone da Internet.
2) Pressione “CTRL” e clique no ícone do host “Presentation”. A tela à direita de edição
vai representar uma mescla dos dois itens.
3) Clique no botão de adicionar link. Uma nova parte da janela intitulada “Connectors”
irá surgir.
4) Dentro dela um link chamado “Link_1” vai estar cadastrado e irá indicar quais são os
elementos que ele interliga. Clique sobre o nome dele para exibir suas propriedades
na aba “Connect Editor”.
Figura 3.45: Editando as propriedades do novo link
1) No campo “Label” podemos colocar uma identificação deste link. Assim como o rótulo
dos elementos com imagens ela também aceita macros.
2) Nos dois campos de “Elements” os itens que estão vinculados podem ser alterados.
3) Em “Link indicators“ vamos, mais a frente, associar um link com gatilhos. No
momento deixe o valor como esta.
4) Em “Type (OK)” escolha “Bold line” para poder visualizar o link com mais facilidade.
Este campo é usado quando um ou mais gatilhos ao qual o link esta associado não
estejão ativos.
5) Por fim em “Colour (OK)” podemos escolher uma cor para o link.
Clique em “Apply” e salve o mapa. Agora só é preciso adicionar mais um link entre o

“Presentation” e o “Switch”. A figura 3.46 mostra como este último vinculo deve ser cadastrado
Figura 3.46: Link entre o host Presentation e o Switch
Agora você já tem o mapa final desta prática dirigida. Salve e confirme o retorno para a
tela de gerenciamento de mapas. Não esqueça de fazer o backup do mapa exportandoo do
mesmo modo que fez com os templates e hosts.
3.5.9. Exercícios sobre Mapas
1) Faça upload das figuras do DVD contidas na pasta “Imagens Mapas”. São imagens do
logotipo do servidor Jboss. Os nomes no “front end” devem corresponder aos das
imagens.
2) Construa o mapa final conforme a Figura 3.47.
Figura 3.47: Mapa final
3.6. Templates, applications e items
Dentro dos tempĺates temos diversos elementos usados para realizar a coleta
e análise das métricas. Considere um modelo como o coração de seu gerenciamento
de monitoramento. A Figura 3.48 mostra quais são estes elementos. Acesse
Configuration → Templates para chegar esta tela.
Figura 3.48: Templates e seus elementos

1) Applications são pequenos grupos para organizar o próximo tipo de elemento (os
Items) dentro de um template. Eles são significativos na tela de “Latest data”.
2) Os “Items” são provavelmente o objeto mais importante dentro de todo o Zabbix. Eles
são as definições das métricas de coletas. Quase que 90% de todo o trabalho de
monitoramento gira em torno de um “Item”.
3) Os “Triggers”, ou gatilhos, montam a lógica para gerar alertas baseado na informação
coletada pelos “Items”. A parte mais complexa do Zabbix é montar as expressões
booleanas dos gatilhos de maneira concisa e equilibrada, evitando falsos positivos ao
mesmo tempo que gera alertas em um tempo hábil. Inciaremos o estudo deles no
próximo capítulo.
4) Os “Graphs” são elementos que exibem gráficos. Também iniciaremos seu estudo no
próximo capítulo.
Nesta sessão nos concentraremos apenas nos “Applications” e “Items”.
3.6.1. Criando um Application e um Item dentro de um template
Ainda em Configuration → Templates, clique no link “Applications” (0) como indicado na
Figura 3.49.
Figura 3.49: Criando um application (1/4)
Uma nova tela surgirá. Localize no canto superior direito dela o botão “Create application”
como na Figura 3.50 e clique sobre ele.
A tela de “New application” surgirá conforme abaixo.
1) Coloque o nome da “application” aqui, que neste caso ela será “ICMP”.
2) Podemos opcionalmente escolher outro template ou host para associar este
“application”. Pouco provável que venhamos a alterar este tipo de opção nesta tela.
Clique em “Save” para concluir e retornar a tela que lista todas as “applications”.
Nosso novo “application” esta exibido na tabela. Agora é o momento de criar um novo
“item”. Clique sobre o link “Items” (0) nesta tela (no caso de estar em outra tela, acesse
Configuration → Templates e clique no link de mesmo nome na linha do template que você
deseja acrescentar).
Figura 3.53:
Criando seu
primeiro item
(1/3)
Na tela de “items”, clique no botão “Create Item” para exibir a tela a seguir. Ainda não
será explicado campo a campo do cadastro de um novo item. Isso será feito no decorrer do curso.
Figura 3.54: Criando seu primeiro item (2/3)
1) No campo “Description” coloque um identificador (de preferência único, mas isso não
é necessário). O nome dele será o exibido em gráficos, usado em triggers, etc.
Escolha coerentemente.
2) O “Type” indica como este item vai fazer a coleta de uma métrica. Os diversos tipos
que serão abordados neste curso serão explicados nos próximos capítulos, aqui
vamos usar “Simple check” que significa usar checagens via protocolo de rede.
3) O “Key” é o campo mais importante de todos, ele deve ser único dentro de cada
template e host. Sua função é definir qual métrica será coletada. Como dito
anteriormente um “item” é a parte mais importante de um template e o seu “key” é a
parte mais importante de um “item”. Saber qual usar em qual situação, faz parte da
competência de usar a ferramenta e de criar um monitoramento eficaz. No nosso caso
vamos criar um “item” que faz um “ping” via ICMP no host, logo a chave será
“icmpping”. Clicar em “Select” abre uma janela com infindáveis “keys” e você pode
selecionálas por essa janela, se desejar.
4) Repetindo: “Cada item do Zabbix é capaz de armazenar apenas um, e somente um
valor”. Não é possível armazenar objetos complexos dentro dos “items”, por isso
precisamos definir qual o formato do valor que será armazenado. No caso da “key
icmpping” ele retorna 1 se o “ping” foi bem sucedido e 0 se não. Valores inteiros sem
sinal como estes são “Numeric (Unsigned)”.
5) O “Update interval”, é o tempo entre uma coleta e outra, em segundos. Por padrão o
Zabbix usa 30 segundos. Em nosso cenário usaremos 10, mas tenha em mente que
estes não são bons valores. Enquanto podemos nos sentir tentados a usar intervalos
curtos para termos uma granulidade de dados bem alta (e mais próxima da realidade)
ele impacta pesadamente em duas coisas: espaço em disco, que aparentemente é
pequeno mas começa a tomar grandes proporções em ambiente com milhares de
métricas e o enfileiramento de métricas a serem processadas pelo servidor. A última
em particular é muito ruim, pois causará todo tipo de buraco possível nos seus
gráficos. Veremos como calcular um bom intervalo a partir do próximo capítulo.
6) Os campos “Keep history” e “Keep trends” indicam por quanto tempo, em dias, os
dados coletados serão armazenados. O primeiro é tempo dele na tabela “history” do
banco de dados que mantém os dados “ipsesliteris” como coletados. A segunda é
uma média de 3 horas dos valores coletados para economizar espaço. Como
veremos, o Zabbix tem uma operação rotineira chamada “house keeping” que limpa
os dados vencidos (depois que passar os dias em “keep history”) da tabela “history”,
passando a média para a “trends”. Depois que vencer o tempo em “Keep trends” os
dados são apagados definitivamente.
7) Escolha o “application” ICMP que criamos anteriormente. Se existirem mais de um
“application” nesta lista, você pode pressionar “CTRL” para selecionar vários.
8) Clique em “Save” para finalizar.
Figura 3.55: Criando seu primeiro item (3/3)
O resultado final é mostrado na Figura 3.55.
3.6.2. Interdependência de templates
Em várias situações práticas seremos obrigados a criar uma lógica de checagens entre os
triggers que irão gerar alertas e usar “applications ”que estão em outros “templates”. Isso só
pode ser feito se criarmos “templates” que são associados a outros. No nosso cenário de
exemplos teremos vários casos deste tipo.
Normalmente os templates mais próximos da raiz são aqueles que realizam os testes

mais primários, como o template de ICMP criado anteriormente. De fato ele será a raiz da maioria
dos outros templates, com destaque para o de JBoss, sistemas operacionais e SNMP. Para
exemplificar crie um novo template chamado “4Linux – JBoss Base”. Antes de salvar note que há
um campo no final do formulário chamado “Link with template”.
Figura 3.56: Campo para associação de

templates
Clique no botão “Add” para abrir a tela de templates.
Figura 3.57: Tela para escolha de templates
Na janela de dialogo que aparecer selecione “4Linux – ICMP” e clique em “Select”. Você
pode escolher tantos templates quanto precisar nesta tela.
Figura 3.58: Template associado
A Figura 3.58 mostra como a tela ficará. Ela indica que o novo template é vinculado ao

“4Linux – ICMP”. Finalmente salve o template.
Figura 3.59: Template associado na lista de templates
Note que todo template que tem alguma associação será mostrado na coluna “Linked
templstes” na tela de “Templates List”. Agora todo host que for associado ao template “4Linux –
JBoss” será automaticamente associado ao “4Linux – ICMP”, além disso o primeiro pode utilizar
os “applications” do segundo e seus “triggers” podem depender dos do segundo.
Para finalizar com os templates, crie todos os templates indicados abaixo e associeos
conforme a estrutura de árvore indicada:
Figura 3.60: Inter-relação dos templates base
3.7. Associando os templates aos hosts
Agora que temos os templates criados podemos vincular cada um deles aos hosts
criados. Fazer isso para um host é muito simples, siga os passos abaixo.
Figura 3.61: Associando o template do JBoss ao host JBoss AS (1/6)
Vá até Configuration → Hosts e clique sobre o nome do host (no nosso caso vamos

usar “JBoss AS”) para editar as preferências do mesmo.
Na parte direita da tela localize o quadro “Linked templates” (Figura 3.62) e clique sobre
o botão “Add”.
Figura 3.63: Associando o template do JBoss ao host JBoss AS
(3/6)
No diálogo que surgir, escolha o template desejado (“4Linux – JBoss Base”) e clique em
“Select”. Você pode escolher tantos templates o quanto quiser aqui, desde que eles não estejam
associados entre si e nem tenham um template “pai” em comum.
Você verá o nome dos templates escolhidos aparecerem neste quadro, conforme a Figura
3.64 demonstra.
Figura 3.65: Associando templates a hosts

(5/11)
Para finalizar clique em “Save”.
Note que o template escolhido e suas dependências, entre parênteses, serão exibidas na
Lista de templates.
Figura 3.67: Templates para Windows e SNMP associados aos seus respectivos hosts
Agora vamos fazer um pequeno exercício que vai demonstrar outro recurso interessante
do Zabbix: o “Mass update”. Imagine que você possui uma quantidade grande de hosts e precisa
associálos ao mesmo template, temos um caso destes no nosso cenário: os hosts
“Presentation”, “application”, “Database” e “Zabbix server” precisam ser vinculados ao template
“4Linux – Linux”, uma vez que todas estas máquinas virtuais são servidores Gnu/Linux. Vá até a
tela de hosts e siga os passos a seguir.
Figura 3.68: Associando um

template a múltiplos hosts
simultaneamente (1/4)
1) Selecione todos os 4 hosts indicados
2) Na caixa de opções marque “Mass update”.
3) Clique em Go (4), note que o número de hosts selecionados é indicado neste botão
entre parênteses.
Figura 3.69: Associando um template a múltiplos

hosts simultaneamente (2/4)
1) Marque a opção “Link addictional templates”;
2) Clique em “Add”. Nossa velha tela de templates irá surgir.
Figura 3.70: Associando um template a múltiplos hosts

simultaneamente (3/4)
Marque “4Linux – S.O. Linux” e clique em “Select”.
Figura 3.71: Associando um template a múltiplos hosts simultaneamente (4/4)
Note que o template ficará logo acima dos botões de adicionar e remover. Clique em
“Save” para finalizar.
Figura 3.72: Todos os templates associados aos hosts do cenário
Todos os hosts selecionados estã agora associados ao mesmo template.
3.8. Ativando um host
Criamos os templates e hosts, demos permissões e montamos um mapa, mas

nada esta sendo monitorado ainda. Isso é porque temos que habilitar todos os hosts.
Realizar esta tarefa é muito simples.
Figura 3.73: Host presentation não monitorado
Vá em Configuration → Hosts e clique sobre o link “Not monitored” conforme a Figura

3.73 indica.
Figura 3.74: Dialogo de confirmação de ativação
Um dialogo irá surgir perguntando se o host deve ser mesmo ativado. Confirme clicando
em “OK”.
Figura 3.75: Host presentation monitorado
A coluna onde clicamos inicialmente agora deve estar com o link “Monitored” em verde.
Aproveite e ative todos os hosts.
Ao invés de ativar um por um. Use o recurso de ativação de todos os hosts

simultaneamente ativando “Enable selected” na caixa de opções abaixo da lista de
hosts.
3.8.1. Throubleshooting para itens com problemas
Tecnicamente, com os templates, a instalação e a ativação em ordem, a esta
altura o Zabbix estará coletando dados. Mas se formos até Monitoring → Overview
veremos que nada aparece.
Isso aconteceu porque, deliberadamente, um componente da instalação foi

omitido: é o item que o criamos dentro do template “4Linux – ICMP”. O objetivo
deste tópico é justamente ensinar a você como lidar com itens com problemas dentro
do Zabbix.
Sempre que suspeitar que uma métrica não esta funcionando devidamente, o
lugar correto para descobrir o que pode estar acontecendo, está dentro dos itens do
host. Vá até Configuration → Hosts e clique sobre um dos nomes dos hosts.
Figura 3.76: Item não suportado
A Figura 3.76 mostra como o item “ICMP Ping” deve estar com problemas. Note que o

“Status” do mesmo é “Not supported” e um sinal de erro está aparecendo na última coluna
“Error”.
Passe o mouse por cima do ícone e o Zabbix irá mostrar uma dica do que esta
acontecendo. A mensagem neste caso é “/usr/sbin/fping: [2] No such file or directory”. O servidor
não esta conseguindo encontrar o executável que ele utiliza para realizar os “pings ICMP” (fping).
Um outro lugar que também indica o que pode estar acontecendo é o log do servidor.
Entre no console do Zabbix server e liste o final do arquivo de log conforme abaixo.
# tail /var/log/zabbix/zabbix_server.log
2518:20110201:202018.896 server #18 started [Escalator]
2519:20110201:202018.900 server #19 started [Proxy Poller]
2506:20110201:202020.097 server #6 started [Poller. SNMP:YES]
2511:20110201:202020.108 Deleted 0 records from history and trends
2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]
2509:20110201:202023.022 /usr/sbin/fping: [2] No such file or directory
A última linha mostra a mesma mensagem que no “front end”. Para remediar esta
situação devemos instalar o fping pelo gerenciador de pacotes da distro que estamos utilizando.
No caso do Debian:
# aptitude install fping
Note que mesmo depois de instalar o aplicativo o erro persiste! Novamente consulte os
logs (ou o “front end”).
# tail /var/log/zabbix/zabbix_server.log
2511:20110201:202020.108 Deleted 0 records from history and trends
2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]
Mesmo após instalar o pacote, o erro persiste! Então provavelmente o Zabbix deve estar
procurando o executável no lugar errado. Vamos usar o comando which (pode ser o whereis
também) para saber onde ele está armazenado.
root@zabbixsrv:~# which fping
/usr/bin/fping ←
Note que ele está em “/usr/bin” e o servidor esta procurando ele em “/usr/sbin”. Isso é
claro varia de uma distribuição de Gnu/Linux para outra. O que fazer neste caso? Simples
mudaremos a configuração do servidor para se adequar ao ambiente em que ele foi instalado.
Edite o arquivo “/etc/zabbix/zabbix_server.conf” e procure as linhas com as opções indicadas
abaixo.
# vim /etc/zabbix/zabbix_server.conf
…
#
========================================================================
====
# Localização do programa de ping (ipv4 e ipv6)
#
FpingLocation=/usr/bin/fping 
Fping6Location=/usr/bin/fping6 
…
1) FpingLocaltion: indica o caminho do “fping” para pacotes ICMP usando IPV4.
Mude para “/usr/bin/fping”.
2) Fping6Localtion: como acima, mas para IPV6. Mude para “/usr/bin/fping6”.
Com as opções modificadas reinicie o servidor.
# /etc/init.d/zabbixserver restart
Stopping Zabbix server daemon: zabbix_server
Starting Zabbix server daemon: zabbix_server
Uma outra possibilidade para resolver o problema é fazer um link simbólico no sistema
operacional. A vantagem deste método é que não será necessário alterar nenhum arquivo de
configuração e nem reiniciar o Zabbix.
ln s /usr/bin/fping /usr/sbin/fping
Confira no s logs se alguma outra mensagem apareceu e acesse Coonfiguration →

hosts, se o item aparecer como não suportado ainda não se preocupe ele retornará em breve. Se
quiser que ele seja ativado agora, clique sobre o “Not supported” e ele será restabelecido. A
imagem abaixo mostra como ele deve ficar ao final da operação.
Figura 3.77: Item suportado e ativo

Capítulo 4 Monitoramento voltado para disponibilidade - 128
Capítulo 4
Monitoramento voltado para disponibilidade
OBJETIVOS
• Utilizar o Zabbix como uma ferramenta para medir disponibilidade:
• Medir a disponibilidade dos equipamentos via checagens simples e agente

(incluindo aqui o Zapcat)
• Alertar quedas de hosts, serviços e reinicializações.
• Medir a saúde da infraestrutura:
• Latência de rede e de serviços.
• Espaço em disco nos servidores.
• Serviços ativos.
• Interface
• Teste manual.
• Uso de gráficos e mapas.
• Comandos externos.
4.1. Introdução
Disponibilidade! Provavelmente é o que vem na mente da maioria dos consultores e

gerentes de TI quando ouvem a palavra “monitoramento”. Enquanto a disponibilidade não seja o
único motivo de se monitorar ativos e serviços, ela é o fator que mais impacta em custo e
investimentos realizados. Quanto custa uma hora de seu principal serviço parado para sua
empresa?
Neste capítulo será abordado uma multitude de possibilidades para medir o quão
disponível estão seus servidores, serviços e ativos de rede. O Zabbix possui diversas maneiras de
descobrir se algo não esta funcionando e aqui veremos como fazer isso usando protocolos
básicos de rede, testadores de protocolos, cenários de teste web, o próprio agente do Zabbix,
SNMP e o agente do Zabbix para JBoss.
Também vamos entender como criar triggers (gatilhos) e Actions (ações tomadas quando
um gatilho muda de estado) e enviar alertas de parada de maneira inteligente, para evitar falsos
positivos e permitir que a equipe de suporte reaja a tempo quando um incidente acontecer.
Além disso, vamos ver como medir diversas métricas e gerar nossos primeiros gráficos
dentro do “front end”.
4.2. Checagens manual via front end
Obviamente o Zabbix permite que realizemos várias checagens de maneira automática,
afinal essa é sua principal função, mas antes de começar a coletar métricas e mais métricas,
vamos ver como usar o “front end” para realizar testes manuais, incluindo também a
personalização destes testes.
Vá até Monitoring → Maps e clique sobre o host “Database” com o botão esquerdo do
mouse (de fato pode ser qualquer host a sua escolha). Um menu “popup” irá surgir como na
Figura 4.1.
Figura 4.1: Menu de

Ferramentas acessado pelo
mapa
Note que uma aba divisória chamada “Tools” apresenta duas opções de comando que
podemos pedir ao servidor para realizar: “Ping” e “Traceroute”. Ambos são comandos bem
conhecidos de um administrador de sistemas “*nix”. Realize um teste clicando sobre o comando
“Ping”.
Figura 4.2: Saída de um comando ping
Depois de alguns segundos você verá um dialogo surgir como na Figura 4.2. Ele é a saída
textual do comando. No caso demonstrado o “ping” foi bem sucedido e o comando executado é
inclusive mostrado no título da tela.
Vamos agora ao outro comando. Clique em “Close” para fechar esta janela e execute o
outro comando via o menu “popup”.
Figura 4.3: Saída de um comando que falhou do traceroute
Apesar do comando ter retornado uma saída, ela é extremamente inadequada, pois
sabemos que os hosts do cenário estão a 1 ou dois “hops” (saltos de roteadores) apenas. Isso
aconteceu porque o Firewall das máquinas esta bloqueando pacotes UDP, que são o padrão do
traceroute. Neste caso teríamos duas possibilidades:
1) Liberar no firewall uma regra permitindo que o servidor do Zabbix alcance os hosts por
UDP;
2) Modificar o comando para que ele realize traceroute baseado em ICMP que já esta
liberado no Firewall.
Nesta caso vamos optar pela segunda, para demonstrar como alterar as configurações
destes comandos (que o Zabbix chama de scripts). Mas dependendo de seu cenário real, pode
ser preciso liberar o Firewall para permitir a passagem de determinados pacotes.
Sempre cabe ao administrador ou gerente de rede tomar estas decisões com base na
simplicidade, segurança e necessidade do ambiente. Infelizmente estas são regras que
sempre entram em conflito, pondere bastante para não deixar falhas de segurança e
verifique se o comando a ser habilitado é mesmo necessário.
4.2.1. Adequando o script de traceroute
O servidor do Zabbix, assim como seu agente, são executado em forma de “daemon” e
por questões de segurança eles são executados com permissões do usuário 6zabbix (e grupos ao
qual esta conta pertença).
Este usuário não deve ter permissões de superusuário (conforme sua criação nos
capítulos anteriores) e sendo assim, somos obrigados a checar se os comandos que colocaremos
no “front end” podem ser executados pelo “daemon”.
Primeiro vamos testar como root o funcionamento do comando. No caso do traceroute a
opção para realizar traçamento de rotas via ICMP é o “I”.
# traceroute I win2003
traceroute to win2003 (172.28.0.10), 30 hops max, 60 byte packets
1 gateway.curso468.4linux.com.br (172.27.0.1) 0.954 ms 0.820 ms 0.724 ms
2 172.28.0.10 (172.28.0.10) 1.158 ms 1.066 ms 1.054 ms
Perfeito! Via ICMP o traceroute consegue chegar até o destino e mostrar as rotas. Agora
vamos tentar como usuário Zabbix.
# su – zabbix
$ traceroute I win2003
The specified type of tracerouting is allowed for superuser only
$ logout
#
Você não pensou que seria tão fácil, pensou? Como verificado, o usuário não tem
permissão de executar o traceroute com ICMP. Isso aconteceu porque somente o usuário root tem
direitos de criar pacotes da camada de rede arbitrariamente. Programas como “ping”, “fping”, entre
outros tem permissão SUID ativa para garantir que usuários convencionais sejam capazes de
executar estes programas.
Evite usar SUID para dar permissões de execuções aos usuários normais! Isso pode
causar falhas de segurança.
Felizmente existe uma alternativa no mundo UNIX: o sudo, um programa que verifica se
um usuário tem permissão de execução a partir de suas configurações.
Mesmo o sudo teve seu histórico de segurança comprometido, por isso sempre
mantenha sua distribuição atualizada com os últimos “patches” de segurança, pois
nunca se sabe quando uma nova falha vai sair.
Instale o “sudo” a partir do repositório do Debian no host Zabbix server.
# aptitude install sudo
Agora use o comando visudo para adicionar a permissão do usuário zabbix de

executar o comando traceroute.
# visudo
1 # /etc/sudoers
2 #
3 # This file MUST be edited with the 'visudo' command as root.
4 #
5 # See the man page for details on how to write a sudoers file.
6 #
7
8 Defaults env_reset
9
10 # Host alias specification
11
12 # User alias specification
13
14 # Cmnd alias specification
15
16 # User privilege specification
17 root ALL=(ALL) ALL
18
19 # Allow members of group sudo to execute any command
20 # (Note that later entries override this, so you might need to move
21 # it further down)
22 %sudo ALL=(ALL) ALL
23 #
24 #includedir /etc/sudoers.d
25
26 zabbix ALL = NOPASSWD: /usr/bin/traceroute
Salve o arquivo e teste novamente o comando usando agora o sudo antes dele.
# su – zabbix
$ sudo traceroute I win2003
traceroute to win2003 (172.28.0.10), 30 hops max, 60 byte packets
1 gateway.curso468.4linux.com.br (172.27.0.1) 0.980 ms 0.855 ms 0.926 ms
2 172.28.0.10 (172.28.0.10) 3.805 ms 4.292 ms 4.211 ms
Voilá! Seu usuário Zabbix já consegue usar o comando no sistema. Vamos voltar ao front
end. Entre em Administration → Scripts e clique sobre o nome do comando “Traceroute”. Uma
tela de edição do script irá surgir.
No campo “Command” modifique o valor, colocando “sudo” seguido de espaço antes do
“traceroute” e clique em “Save”. Agora volte até o mapa (Monitoring → Maps) e execute o
comando em vários hosts.
Figura 4.4: Saída do traceroute adequando a nova necessidade
A saída da Figura 4.4 mostra a saída do comando sobre o host “Windows2003”. Note que
ela é idêntica à saída do terminal.
4.2.2. Criando novos comandos para o menu
Quando as coisas começam a dar errado e os alertas chegam, você pode necessitar que
usuários de primeiro nível sem conhecimento profundo de Unix ou Windows, e consequentemente
sem acesso aos consoles do servidor, precisem realizar testes. Logo, existirão casos em que seu
ambiente demande de vários scripts a serem executado a partir do servidor via “front end”. Um
exemplo muito comum é o de testes de portas de serviços TCP.
Para exemplificar este caso, vamos criar um script que chama um comand “nmap” para
testar a porta 22/TCP (SSH) dos servidores Gnu/Linux em nosso cenário. Volte para
Administration → Scripts.
Figura 4.5: Criando um novo script para testar portas SSH (1/2)
Clique sobre o botão “Create script” conforme a Figura 4.5 para acessar a tela de criação
de comandos.
Figura 4.6: Criando um novo script para testar portas SSH (2/2)
1) Name: É o nome do comando a ser exibido no menu;
2) Command: O comando a ser executado, no nosso caso “nmap P04 p 22

{HOST.CONN}”. O parâmetro “P0” do nmap indica que o host não deve ser pingado
antes de testar a porta (p 22). “{HOST.CONN}” é uma macro do Zabbix que contém o
IP do servidor (ou nome DNS do mesmo, depende do que escolhemos na criação do
host). Várias macros, inclusive personalizadas podem ser usadas neste caso.
3) User groups: Indica o grupo usuários que podem executar este comando. Escolha
“All” para este cenário.
Se você possuir vários tipos de usuários que precisem executar apenas alguns
comandos, compensa criar um grupo de usuários só para isso e atribuir quais usuários
pertencem a estes grupos. Não esqueça de dar permissão conforme os campos a
seguir para que ele seja capaz de ver os comandos.
4) Host groups: indica em quais grupos de hosts um comando pode ser executado. Em
combinação com a opção anterior é possível criar regras bem complexas. Além disso
não faz sentido testar um SSH em um Windows por exemplo. Escolha “Linux servers”.
5) Qual tipo de permissão o grupo do usuário deve ter no “host groups” para exibir o
comando. Ao menos a permissão de “READ” é requerida.
Depois de cadastrar os campos clique em “Save” e vá até o mapa para testar o comando.
Clique sobre um host Gnu/Linux.
Figura 4.7: Nova entrada de

menu com o script criado
A Figura 4.7 demonstra como o “popup” será mostrado. Clique sobre o novo scipt “SSH”
para executálo.
Figura 4.8: Resultado do comando ativado no host
Se tudo correu bem a saída do comando deve ser mostrada conforme a Figura 4.8. Note
que os hosts switch, JBoss AS e Windows 2003 não devem exibir este comando.
4.2.3. Exercícios
1) Gerencie o permissionamento para que o comando SSH seja somente executado
pelos usuários “suporte” e “sysadmin”.
2) Crie o seguinte conjunto de comandos para teste de portas:
2.1) Testar a porta 445/TCP dos hosts com sistema operacional Windows. Somente
os usuários “suporte” e “winadmin” devem pode executálo.
2.2) Testar as portas 8009/TCP do servidor de aplicações. Somente os usuários
“suporte” e “javaeng” devem poder executálo
2.3) (Desafio) Testar a porta 80/TCP do “gateway” onde fica o sistema de cache e
proxy reverso e do servidor de aplicações. Somente os usuários “suporte” e
“sysadmin” podem executálos. No caso deste exercício você deve verificar se
foi retornado HTTP 200.
2.4) (Desafio) Testar a porta 5432/TCP do host “Database”. Somente os usuários
“suporte” e “dba” podem executálo. No caso deste exercício você deve verificar
se foi retornado o valor um a partir de um “SELECT 1”.
2.5) (Desafio) O “Varnish” tem um console local de comandos acessado por uma
porta. Na máquina “Presentation” crie um script que acessa este console e
limpa o cache do “Varnish” para ser chamado via script do Zabbix. Somente o
sysadmin pode executar este comando.
4.3. Checando disponibilidade via protocolo ICMP
Criar comandos de teste é interessante mas não automatiza o monitoramento que o

servidor deve fazer constantemente. Logo, chegou o momento de verificar como o host pode
apresentar indisponibilidade a partir da checagem de retorno de pacotes “ICMP reply”.
Nem todos os sistemas permitem pacotes ICMP. Se este for o caso, não adianta criar
testes como o a seguir, pule direto para verificação de agentes e portas.
4.3.1. Como funciona o ping ICMP
O ICMP Internet Control Message Protocol é um protocolo da camada de rede do
modelo TCP/IP responsável por trocar mensagens de controle entre os hosts (por exemplo, falhas
de rotas).
O utilitário ping ou fping (instalado no capítulo anterior e usado pelo Zabbix para enviar
testes de ICMP) e tantos outros, utilizam apenas duas mensagens definidas na RFC 792 para
fazer testes de rede. Um para envio da mensagem e outro para resposta (Figura 4.9).
Figura 4.9: Diagrama de comportamento do echo

ICMP
Este teste já esta sendo realizado em nosso cenário, visto que criamos o item “icmpping”
dentro do template “4Linux – ICMP” e ativamos os hosts. Embora muito primário, este teste valida
todo o caminho físico entre os componentes de rede do destino e da origem (switches, cabos,
placas, roteadores, etc.) e por isso é muito utilizado dentro de vários cenários reais. Podemos ver
a troca de pacotes acontecer através do comando “tshark” a seguir.
# tshark ni eth0 icmp and host 172.27.0.1
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 172.27.0.10 > 172.27.0.1 ICMP Echo (ping) request
0.000959 172.27.0.1 > 172.27.0.10 ICMP Echo (ping) reply
Note que para todos os pacotes “echo request”, um “echo reply” retorna do destino.
4.3.2. Visualizando o ping ICMP no Front end
Podemos visualizar o resultado dentro da tela de “Overview” do “front end”. Acesse
Monitoring → Overview para exibila.
Figura 4.10: Hosts ativos com ping ICMP em funcionamento
Na Figura 4.10 temos um exemplo desta tela mostrando todos os hosts. Se ela não estiver
aparecendo não se esqueça de selecionar no comapo “Type” o valor “Data”.
Embora o “Overview” esteja exibindo corretamente o valor 1 da “key icmpping” não é

muito intuitivo olhar para um número em meio a uma tabela (sem levar em conta que esta tabela
pode ser demasiadamente extensa). Por isso o Zabbix oferece um recurso interessante chamado
“Values Maps” que permitem dar nomes aos valores. Já existem vários deles definidos por
padrão. Entre em Administration → General, no canto direito da tela e selecione
“Value Maps”. Aproveite a oportunidade e apague todos eles, exceto “Service State”
e “Windows Services”, assim mantemos o ambiente limpo.
Figura 4.11: Um value maps de

estado de serviços
Agora conforme a Figura 4.11 indica, clique sobre o nome do “Value Map” chamado
“Service State” para editálo. Vamos transformar seus valores “Up” e “Down” em “Ok “ e “Falha”.
Figura 4.12: Editando o value map para nossa necessidade

1) Name: Aqui é definido o nome do novo conjunto de valores, vamos mudálo para
“Estado”.
2) Mapping e New mapping: Estes campos permitem a edição dos valores que são

mapeados. Clique sobre os valores de “Up” e “Down” e clique no botão “Delete
Selected” para removêlos e depois use o “New Mapping” para adicionar os novos
valores conforme a ilustração demonstra.
Clique em “Save” para salvar e sair.
Figura 4.13: Value map editado e

pronto para uso
Note que o “Value Map” foi alterado. Agora vamos associar o “Ping ICMP” ao novo
“Estado”. Vá até Configuration → templates, clique sobre o valor “items” do “4Linux – ICMP” e
depois sobre o nome do item “ICMP Ping”.
Figura 4.14: Selecionando um value map no trigger
Procure o comando “Show value” conforme indicado na Figura 4.14 e escolha a opção

“Estado”. Salve o item e volte ao “Overview”.
Figura 4.15: Values maps no overview
Note que agora todas as opções que possuem o valor 1 estão com a string “OK”. Isso
facilita e muito a visualização dos valores e sempre que possível iremos criar ou usar “Values
Maps” prontos para melhorar a apresentação de dados.
4.3.3. Criando um gatilho de parada de host
Embora já saibamos qual host esta OK, ainda não pedimos ao servidor para nos alertar
via email/Jabber a parada de um deles. Vamos primeiro testar o que o “front end” já nos mostra e
depois iremos criar nosso primeiro “trigger” que vai avisar quando algo de errado acontecer com
nossos hosts.
Primeiro pause uma das máquinas virtuais (o exemplo utiliza o “Database”), pelo console
do Virtual Box selecione o menu Machine → Pause (Ou use CTRL Direito + P).
Figura 4.16: Pausando o host Database
Depois de alguns segundos (dez para ser mais exato) o “Overview” vai indicar que o

“Database” esta parado.
Figura 4.17: Host database parado no overview

1) Caso deseje podese escolher o grupo “Database servers” para facilitar a visualização
dentro do “Overview”.
Agora que já sabemos que o item esta funcionando corretamente, vamos criar nosso
“trigger”. Antes ative a máquina virtual, assim o “trigger” entrará desligado.
Um trigger, ou gatilho, é um teste de condição que possui um estado (OK, PROBLEM ou
UNKNOWN) e permite que o Zabbix tome uma decisão sobre a ocorrência de um incidente dentro
do cenário monitorado. Um único “trigger” pode conter um simples teste boleano como o que
usaremos daqui a pouco, como também verdadeiras equações boleanas que testam inúmeras
possibilidades para decidir o que aconteceu. Felizmente a grande maioria dos casos requerem
testes simples de valores de um único item. Vá para a tela de templates em Configuration →
Templates onde esta o “4Linux – ICMP”.
Figura 4.18: Criando um trigger para a parada do host (1/9)
Edite os “triggers” do template conforme mostrado na Figura 4.18 .
Figura 4.19: Criando um trigger para a parada do host

(2/9)
No canto direito da tela clique no botão “Create Trigger”. Uma nova tela irá aparecer.

1) Name: indica o nome do gatilho. Este nome será exibido quando o gatilho for
disparado em vários lugares e pode ser referenciado nos emails, SMS e outras
formas de alerta . Por isso o nome permite o uso de macros. No exemplo desta prática
dirigida usamos o valor “Host {HOSTNAME} inalcançável”. Onde {HOSTNAME} será
substituído pelo nome do host cujo trigger for ativado.
2) Expression: é onde iremos escrever o teste do gatilho, ou seja, sua expressão
boleana. Clique em “Toggle input method” para mudar o modo de escrita do gatilho,
por padrão teríamos que escrever a expressão na mão, mas como você ainda esta
iniciando no Zabbix iremos usar o auxiliar de expressões.

Note que a tela vai mudar conforme a Figura 4.21. Para criar nossa expressão use o botão
“Edit”. A tela “Condition” irá surgir para que possamos montar a opção do teste.

1) Item: indica a métrica coletada neste template a ser avaliada. Clique em “Select” e
escolha o “ICMP Ping”.
2) Function: É a função usada para verificar o gatilho. Ao clicar na caixa de combinação
você verá uma grande quantidade de funções possíveis. O Zabbix é muito extenso e é
provável que você não venha a usar todas estas funções em produção, no entanto
elas estão lá se você precisar. No curso veremos apenas as mais relevantes. Escolha
“Last value = N” para que possamos testar se o último valor do “ping” foi uma falha.
3) Last of (T): define o tempo ou contagem de coletas a serem analisadas. Vamos
selecionar 1 coleta (a última).
4) N: O valor de “N” na expressão da função escolhida no item 2. É zerono nosso caso,
que define um “ping” mal sucedido.
Temos ainda o “Time shift” que permite retroceder no tempo para coletar métricas a um
espaço definido de segundos, no passado. Não usaremos ele ainda. Clique no botão “Insert” para
retornar a tela anterior.
Veja que o construtor de expressão já escreveu para nós toda a fórmula. O valor “{4Linux
– ICMP:icmpping.last(#1)}=0” é o resultado final das escolhas feitas na tela anterior. Ela esta no
formato “{Template:item.função(parâmetros)}=valor”. Não se preocupe tanto com isso por
enquanto, mas você deve ser capaz de ler as expressões e comparálas com o gerador
automático, pois no manual as referências são mostradas como o nome de cada função e não
pelos menus. Para acrescentála use o botão “Add”.
É um erro muito comum dos iniciantes (e mesmo de alguns veteranos) que

esqueçamos de clicar em “Add”. No caso de você receber um erro ao salvar dizendo
que a expressão é inválida verifique se você deixou de adicionar a fórmula.
Com a nova expressão ativada podemos nos ater a outros pontos do “trigger”.
O botão “Test” pode ajudar a resolver uma expressão mais complexa, mas tenha em
mente que a entrada de dados da expressão só pode ser obtida manualmente (você vai
digitálas). Não é possível coletar os dados do item para averiguar se você fez certo.

1) The trigger depends on: aqui podemos escolher se este “trigger” depende de outros,
de forma que ele não seja ativado se outro mais básico esta com status “PROBLEM”.
Vamos ver dependências mais a frente, por hora deixe vazio.
2) Event generation: indica se o “trigger” vai gerar um evento apenas uma ou múltiplas
vezes.
3) Severity: um dos campos mais importante de todos, indica o quão grave pode ser a
ocorrência de um incidente.
4) Comments: um texto explicando o que este “trigger” representa e o que acarreta ele
esta ligado. Útil para o pessoal de primeiro nível de suporte que não tem
conhecimento profundo do sistema.
Clique em “Save” para finalizar este passo.
O gatilho deve estar sendo exibido na lista de “triggers”.
4.3.4. Lidando com os eventos
Todo gatilho gera um evento que representa um único incidente, normalmente um evento
representa o início ou término do mesmo. Dentro do Zabbix você deve aprender a lidar com os
eventos e usar o “front end” para verificar se um deles ocorreu. São muitas as telas onde
podemos verificar que um incidente aconteceu em um host. Pause novamente o host Database
para provocar o incidente de chamada dele e vá até Monitoring → Dashboard.
Figura 4.27: Indicação de problemas no Dashboard
Note que a coluna “Disaster” do quadro “System status” esta indicando que um host do
grupo “Database Servers” e “Linux Servers” está com problemas. Na verdade é o mesmo host
“Database” que esta nos dois grupos.
Outro lugar que deve estar refletindo a condição de falha é o próprio “Overviiew”, tanto no
modo de dados como na Figura 4.28 como na de gatilhos na Figura 4.29.
Figura 4.28: Overview com indicação dos items com

alerta
Figura 4.29: Overview com visualização dos triggers

ativos
O Mapa também deve estar mostrando o status do “trigger” no host “Database”. Vá até
Monitoring → Maps e perceba como o Zabbix colocou um círculo vermelho no fundo do host. O
nome do gatilho também esta aparecendo abaixo do label de nome.
Figura 4.30: Mapa indicando o host Database como down
Por fim existe a tela de eventos em Monitoring → Events, onde podemos manipular

estes eventos. Antes de entrar nela, remova a pausa da máquina “Database”. Isso vai forçar o
Zabbix a gerar um evento de retorno que será visualizado na próxima tela.
Figura 4.31: Tela de Events, indicando a queda e o retorno dos hosts

1) Group: filtra as opções de “host groups”.
2) Host: filtra os hosts do grupo escolhido.
3) Source: define a origem dos eventos, um evento pode ser gerado por um gatilho ou
por detecções de hosts feitas pelo Zabbix.
Perceba que a coluna “Status” tem duas linhas: uma para a ativação do “trigger” e outra
para a desativação. Este comportamento é desejado pois para sabemos por quanto tempo um
determinado “trigger” ficou ativo (e por consequência, por quanto tempo o incidente ocorreu na
sua infra), basta analisar a coluna “Duration”.
Na coluna “Duration” se um evento mudou de estado uma última vez, o valor mostrado
indica o tempo desde aquele ponto até o presente momento.
Outro ponto importante é a coluna “Ack” (acknowledgement, ou confirmação). Ela mostra
se um determinado evento foi percebido por alguém, e é de boa prática sempre preenchêlo com
algo relevante, mesmo que seja um simples texto de “esta sendo verificado”. Isso permite que o
Zabbix seja usado como um sinalizador de “tickets”. Clique sobre o link “No” indicado na Figura
4.31 da linha com status “PROBLEM”.
Figura 4.32: Tela de acknowledgement
Na tela que surgir preencha o quadro de texto e clique em “Acknowledge & Return”.
Figura 4.33: Acknowledge (confirmação) aplicado
Note que a coluna “Ack” agora apresenta o valor “Yes” em azul. Faça o mesmo
procedimento para o final do incidente.
Nunca deixe eventos sem “acknowledgement”, isso faz com que o histórico de eventos
do Zabbix fique impreciso e deixe de ser confiável.
ATENÇÃO! A partir de agora você é obrigado a colocar confirmação em todos os

eventos que ocorrerem no curso, principalmente se eles estiverem dentro das práticas
dirigidas e exercícios.
4.3.5. Criando uma action para envio de alerta
Usar a interface web para lidar com eventos é importante, mas você só vai saber que algo
ocorreu se alguém ficar na frente de um monitor. Enquanto esta se tornando comum o uso de
telões (normalmente TVs de LCD modernas) para exibir mapas e “screens” com os status dos
hosts, é de suma importância que o Zabbix envie mensagens pelas mídias de alertas aos
envolvidos.
Para isso temos que criar uma “Action”, que é a cola entre os “Media Types” dos usuários
e a mudança de status dos “triggers”. Vá até Configuration → Actions para exibir a tela de
ações.
Figura 4.34: Criando uma action para enviar o alerta

(1/9)
Conforme na Figura 4.34, no canto direto da tela clique em “Create Action”. Uma janela
de cadastro da ação irá surgir conforme a seguir.
Figura 4.35: Criando uma action para enviar o alerta (2/9)

1) Name: indica o nome da ação e ele deve ser único.
2) Event source: mostra de onde o evento foi originado. No nosso caso é um “trigger”.
3) Default subject: é o campo assunto do email a ser enviado ou valor do
SMS/mensagem jabber. Note que é possível, e indicado, o uso de macros.
4) Default Message: é uma descrição detalhada do evento, também é aconselhável o
uso de macros.
Os outros campos deste quadro não são relevantes no momento, deixeos no default.
Antes de clicar em “Save” há mais dois lugares a serem configurados.
Um deles é o quadro “Action condition” logo abaixo do quadro principal. Clique em
“New” conforme indicado na Figura 4.36.
1) Na primeira caixa de opções, escolha “Trigger”, note que há vários tipos de valores
que podem ser usados para disparar uma ação.
2) Na segunda caixa escolha “=”.
3) Por fim clique em “Select” e ative o “trigger” que criamos anteriormente.
Esta condição diz que toda vez que o gatilho escolhido mudar de estado esta “action” será
disparada. Clique em “Add” para adicionar e finalizar esta parte.
Note que a condição é exibida no “Action conditions”. É possível adicionar quantas

condições você desejar.
Figura 4.39:
Criando uma
action para enviar
o alerta (6/9)
Agora precisamos escolher o que a “action” deve fazer. No quadro “Action operation” a
esquerda do principal, podemos listar várias operações para serem ativadas quando a “action” for
disparada. É aqui onde escolhemos qual meio de alerta será usado para uma “action” em
particular. Clique em “New” conforme mostrado na Figura 4.39.

1) Operation type: podemos escolher se vamos enviar uma mensagem de alerta ou
executar um comando remoto.
2) Send message to: indica para quem a mensagem deve ser enviada. Podemos
escolher grupos ou usuários em particular. Para o nosso caso, uma parada de “ping”
deve ser enviada ao grupo “Network administrattors”.
3) Send only to: aqui escolhemos quais “media types” devemos usar. Podese optar por
usar todos os disponíveis.
4) Default message: envia a mensagem padrão à operação. Geralmente este é o
desejado, mas podem haver casos de operações que precisem de uma mensagem
mais específica, como um SMS com um corpo de texto mais compacto.
Clique em “Add” e você verá que a nova operação será adicionada ao quadro.
Figura 4.41: Criando uma action para enviar o alerta

(8/9)
Após isso clique em “Save” no quadro principal.
Chegou o momento de testar nossa “action”. Pause por alguns minutos a máquina
“Database” e volte ela ao normal. Nesse ínterim, consulte os emails no “Evolution” e as
mensagens no “Pidgin”.
Figura 4.43: Mensagens de alerta recebidas no Evolution
Você deve receber dois alertas: um de parada (PROBLEM) e outro de retorno (OK).
Perceba que os valores das macros foram substituídos pelo Zabbix.
4.3.6. Exercícios
1) Aproveite o momento que você tem com uma “action” plenamente funcional e consulte
o manual online do Zabbix para conhecer as macros disponíveis no servidor, e altere
os textos e títulos das mensagens para experimentar os valores possíveis nas
mensagens.
2) Reinicie a máquina virtual “Database” conforme a Figura abaixo indica, e diga o que
aconteceu com os eventos. Você acha que isso é um comportamento correto?
________________________________________________________________________
________________________________________________________________________
Figura 4.44: Reiniciando o host Database
4.3.7. Boas práticas com triggers
Se você fez o último exercício, deve ter percebido que o evento foi acionado pelo “reboot”
da máquina virtual. Este tipo de comportamento é esperado, afinal a resposta do “ping” deixou de
ser enviado ao servidor. No entanto a máquina não caiu, e uma simples reinicialização
providencial em um servidor ou serviço, não deve ser acusada como queda de host. Ambos são
situações diferentes.
Por isso devemos sempre ter em mente que nossos “triggers” não devem se limitar a
verificar um único valor de mudança de estado. É preciso de uma lógica mais bem trabalhada e
fazer uso de um recurso chamado “janela de tempo”. A Figura 4.45 ilustra como a janela de tempo
funciona.
Figura 4.45: Lógica de um gatilho com tempo de segurança
As janelas de tempo são intervalos de segurança nos quais nos baseamos a fim de
permitir que o servidor de monitoramento se adapte a uma mudança nos valores de coleta. Seu
principal efeito é não alertar falsos positivos, que podem ser piores do que falsos negativos em
certas circunstâncias (lembra da história do lobo?). O alerta de queda de host ao reiniciar o host é
um falso positivo, não houve queda real, apenas uma reinicialização.
Note que quando o servidor parar de responder, nenhum alerta é enviado imediatamente.
O “trigger” irá aguardar o tempo determinado na janela até decidir mudar de estado. O mesmo
acontece com o retorno do host. Embora pareça contra produtivo isso reduz o risco de envio de
mensagens de alerta a toa. Dependendo do tipo de mensagem, isso pode inclusive representar
uma economia para a empresa se o “Media type” usado for pago (como o SMS). Imagine receber
centenas (ou milhares de SMS) por causa de trafego excessivo que impediu que os “pings” ICMP
chegassem ao servidor! Nada saiu do ar, apenas o trafego de rede ficou insuportavelmente lento.
E a intermitência dos pacotes pode gerar mais dores de cabeça do que auxílio.
Obviamente temos que tomar cuidados para que hajam alertas de outros estados que
um host ou toda a infraestrutura pode alcançar. Mais adiante neste capítulo vamos, por
exemplo, criar uma “trigger” para alertas de reinicializações.
Definir gatilhos e ações para todas as possibilidades de sua infraestrutura é justamente
o maior desafio depois de responder a pergunta “o que devo monitorar?”. Geralmente
este tipo de granulação só é alcançado depois de alguns meses com o monitoramento
ativado, e a melhor maneira de se planejar tudo isso é começar pequeno e cobrir novas
necessidades conforme elas aparecem. “Receitas de bolo” como a “ITIL” são
excelentes guias para se decidir por onde e quando começar.
Vamos então criar um “trigger” com uma janela de tempo. Edite a condição do nosso
“trigger” criado anteriormente, acessando Configuration → Templates, clique no valor “triggers”
do template “4Linux – ICMP” e depois abra a condição do gatilho. Dois campos serão alterados
como a seguir:
1) Function: mude a função para “Sum of values for period of time T = N”, justamente o
“T” é nossa janela.
2) Last of (T): a definição da janela, no nosso exemplo, será de 60 segundos, visto que
nosso item “pinga” o host de destino a cada 10 segundos. Procure deixar a janela
próxima ao tempo de coleta entre “x3” a “x6”.
Salve tudo e reinicie o host novamente. Se tudo correr bem a janela vai evitar que o alerta
seja enviado. Se ainda assim você receber o alerta é preciso aumentar a janela de tempo.
Qual um bom tamanho de janela de tempo? Isso é uma pergunta que depende
inteiramente de seus sistemas. A maioria dos casos não requer uma janela menor do
que 5 minutos. Janelas muito extensas podem diminuir o tempo de resposta da equipe
de TI e janelas muito pequenas tendem a gerar falsos positivos. Tente achar o
equilíbrio.
4.4. Checagem genérica de portas e serviços
Como dito anteriormente “ICMP requests” podem ser barrados por Firewalls. Se este for o
seu caso, então você não pode depender deles para medir a sua disponibilidade e deve recorrer a
outros métodos. Neste tópico veremos um muito comum, a checagem de portas TCP.
4.4.1. Conexões TCP e handshakes
Como se dá a verificação remota de um serviço rodando em um soquete TCP? Vamos
fazer uma pequena prática para a verificação do mesmo, e entender o famoso “Three wy
handshake” do protocolo TCP.
Primeiro ative no host “Application” o seguinte comando:
# tshark ni eth0 host 172.27.0.10 and port 8080
Capturing on eth0
O “tshark” é o comando de linhas de console do “Wireshark”, e é muito mais poderoso
que o “tcpdump”. No caso do comando acima pedimos que ele capture todo o trafego da
interface “eth0” que vier do “Zabbix server” e usar a porta “8080”.
Agora no servidor do Zabbix de nosso cenário, use o comando “nmap” para varrer a porta
“8080” do host “Application”.
# nmap sT P0 p 8080 172.27.0.20
Interesting ports on application.curso468.4linux.com.br (172.27.0.20):
PORT STATE SERVICE
8080/tcp open httpproxy
Note que usamos o parâmetro “sT” para forçar o “nmap” a usar o “handshake” completo
em vez do “SYN scan1” padrão. Volte ao “Application” para ver o resultado no “tshark”.
1 O SYN Scan é um método considerado furtivo antigamente. Ele fazia apenas metade dos passos para abertura
de uma conexão.
Capturing on eth0
0.000000 172.27.0.10 > 172.27.0.20 TCP 50952 > 8080 [SYN] Seq=0 Win=5840 Len=0
MSS=1460 TSV=4629163 TSER=0 WS=4
0.000090 172.27.0.20 > 172.27.0.10 TCP 8080 > 50952 [SYN, ACK] Seq=0 Ack=1 Win=5792
Len=0 MSS=1460 TSV=4617797 TSER=4629163 WS=4
0.000602 172.27.0.10 > 172.27.0.20 TCP 50952 > 8080 [ACK] Seq=1 Ack=1 Win=5840
Len=0 TSV=4629163 TSER=4617797
0.000727 172.27.0.10 > 172.27.0.20 TCP 50952 > 8080 [RST, ACK] Seq=1 Ack=1 Win=5840
Len=0 TSV=4629163 TSER=4617797
Perceba que 4 pacotes foram trocados. O primeiro é o “SYN” (syncronization) que pede a
abertura da conexão. O segundo que parte do servidor de destino como resposta é o “SYN/ACK”
(syncronization and acknowledgement) que confirma a abertura de pacotes e o terceiro é o “ACK”
apenas para concluir a abertura. O “nmap” usará ainda um último pacote para “resetar” a conexão
(RST, ACK) que não vem ao caso.
A troca destes pacotes nesta ordem é o esperado pelas funções de soquete do sistema
operacional, se ela for realizada dessa forma isso significa que a porta remota esta em estado de
escuta (listening) ou que esta aberta. Mas ai vem a pergunta e uma porta fechada, o que retorna?
Vamos seguir com a prática, novamente no host “Application” execute os seguintes comandos.
Capturing on eth0
O “iptables” 2libera no filtro de pacotes de entrada a porta 10000/TCP. Agora a partir do
servidor Zabbix teste a porta 10000.
# nmap sT P0 p 10000 172.27.0.20
PORT STATE SERVICE
10000/tcp closed snetsensormgmt
Note o estado “closed” da saída do “nmap”! Vá até o “tshark” do “Application” e veja o
trafego dos pacotes capturado.
Capturing on eth0
0.000000 172.27.0.10 > 172.27.0.20 TCP 47673 > 10000 [SYN] Seq=0 Win=5840 Len=0
MSS=1460 TSV=4696578 TSER=0 WS=4
0.000096 172.27.0.20 > 172.27.0.10 TCP 10000 > 47673 [RST, ACK] Seq=1 Ack=1 Win=0
Len=0
# iptables D INPUT j ACCEPT p tcp dport 10000
Note que há apenas dois pacotes, o “SYN” de início de conexão como no exemplo anterior
e outro com “RST/ACK” pedindo para encerrar imediatamente a conexão. É assim que um
sistema operacional informa que uma porta esta fechada para uma tentativa de conexão remota.
Um “timeout” na abertura de uma conexão TCP é porque o cliente não recebeu nem
um “RST/ACK” ou um “SYN/ACK” após um período (que na maioria das vezes é de 60
segundos).
4.4.2. Criando um teste de serviço via varredura de portas
Com estes dados disponíveis vamos criar uma situação onde haverá três casos de portas:
aberta, fechada e filtrada por firewall.
Não existe uma maneira confiável de se checar serviços que usam "UDP sem apelar
para a camada de apresentação do modelo TCP/IP.
Primeiro pare o serviço de SSH no “Database”.
# /etc/init.d/ssh stop
Depois remova a regras de permissão de acesso de SSH da “Application”.
# iptables D INPUT j ACCEPT p tcp dport 22
A partir do “zabbixsrv” faça a seguinte varredura de portas.
# nmap p 22 application presentation database P0
PORT STATE SERVICE
22/tcp filtered ssh
MAC Address: 08:00:27:4B:97:E3 (Cadmus Computer Systems)
PORT STATE SERVICE
22/tcp open ssh
Interesting ports on database.curso468.4linux.com.br (172.27.0.30):
PORT STATE SERVICE
22/tcp closed ssh
MAC Address: 08:00:27:A3:73:61 (Cadmus Computer Systems)
Nmap done: 3 IP addresses (3 hosts up) scanned in 0.48 seconds
Note que no “Database” que desligamos o SSH retornou “closed” e o firewall do
“Application” retornou “filtered”, somente o “Presentation” deu um “open”. Anote este resultados
pois iremos comparálos com o que o Zabbix retornar.
No template “4Linux – S.O. Linux” crie um novo item de “simple check” com a “key ssh”.
Para que o servidor possa usála é preciso que ele esteja compilado com suporte a libSSH (opção
enablelibssh).
Figura 4.46: Simple check para o SSH
1) Key: a chave “ssh” faz um teste na porta 22 dos servidores.
2) Show value: escolha o “value map” “Estado” como fizemos no ICMP ping. A chave

escolhida também retorna 1 para sucesso e 0 para falha.
3) New application: crie uma aplicação exclusiva para o serviço de SSH.
Não esqueça de preencher os outros campos conforme a ilustração. Depois de salvar
este novo item, consulte a saída do “Overview”.
Figura 4.47: Overview exibindo os serviços de SSH
Note como os dois serviços com firewall e com o SSH desligado retornaram Falha (0) e o
que estava em funcionamento retornou 1.
Uma das grandes vantagens de testar portas TCP é que a possibilidade de incidência de
perdas de pacotes é bem baixa em relação ao teste realizado com o UDP.
Enquanto o manual do Zabbix contém a informação de que a checagem de vários

serviços retornam o valor 2 ao achar um timeout, o autor não foi capaz de reproduzir
este comportamento com sucesso.
4.4.3. Exercício sobre checagem de portas
1) Seguindo o mesmo procedimento do “ICMP Ping”. Crie um “trigger” para alertas de
quedas de portas.
2) Crie os itens para monitorar todos os serviços via “simple check” conforme a tabela
abaixo.
Não é possível monitorar um dos serviços mencionados na tabela, ao descobrir qual
anote o mesmo explicando porque não foi possível realizar um “simple check” nele.
Mais a frente voltaremos a este caso e faremos o monitoramento de outra maneira.
Serviços Porta Host Template Key

OpenSSH 22/TCP Todos os Linux S.O. Linux ssh
Varnish (HTTP 80/TCP Presentation Varnish http
cacher)
Apache (proxy) 8080/TCP Presentation Apache http
JBoss 8009/TCP (AJP) Application JBoss base tcp,8009
(Aplicativo) 8080/TCP http,8080
(HTTP)
Apache 80/TCP Application Apache http
(Aplicativo)
PostgreSQL 5432/TCP Database PostgreSQL tcp,5432
OpenLDAP 389/TCP Database OpenLDAP ldap
Tabela 8: Serviços do cenário do curso
Serviço não monitorável: ___________________________________________________
________________________________________________________________________
4.5. Validação de páginas WEB
Um recurso a parte no sistema de monitoramento do Zabbix é o teste de cenários web. O
servidor é capaz de disparar checagem pelo protocolo HTTP e reconhecimento de padrões HTML
para validar páginas HTML, inclusive com validação de formulários (tanto com GET ou POST).
Para suportar este tipo de checagem o servidor deve ser compilado com suporte à
biblioteca CURL (enablecurl).
4.5.1. Disponibilidade do site.
O Zabbix denomina um teste de um site como um “scenario” (cenário), e dentro deste
cenário há vários elementos chamados de “steps” (passos) que correspondem a uma requisição,
ou seja, a uma URL.
O principal uso deste tipo de teste é verificar se a URL esta respondendo

adequadamente, podemos, por exemplo, verificar se o HTML contém uma determinada “string” ou
se o código de retorno corresponde a um sucesso, que normalmente é “200 OK”. Mas estas
checagens tem outros itens embutidos nela. O servidor calcula automaticamente a latência de
rede e a velocidade de download dos dados na URL e já gera gráficos destas estatísticas. Um
“trigger” também é criado automaticamente para alertar códigos de retornos inesperados ou falta
em uma determinada “string” na página de resposta. Ele no entanto, não gera uma “action”
sozinho.
Muitas destas funcionalidades são encontradas em outras ferramentas como o “JMeter”
(que possui “asserts” capazes de realizar este tipo de verificação), porém uma solução não
substitui a outra, pois a intenção do Zabbix não é ser um validador de aplicativos web e sim um
verificador de funcionalidades pontuais de URL. Ele também não deve ser usado como gerador de
cargas para testes de performance. No entanto o Zabbix consegue armazenar o histórico de
resultados online por um longo tempo.
Para criar um novo cenário acesse Configuration → Web. Na tela que surgir você verá
que o botão de criação estará desabilitado (Figura 4.48). Para habilitálo é preciso escolher um
grupo e host conforme abaixo:
Figura 4.48: Criando um cenário para disponibilidade

Web (1/6)
1) Group: escolha o grupo “Linux servers”.
2) Host: escolha “Application”, que é o host interno de nosso cenário que possui um

JBoss e um Apache executando aplicações.
Ao escolher os dois valores o botão será habilitado. Isso acontece porque não é possível
colocar um cenário dentro de um template, apenas dentro de um host. Daí a necessidade de se
escolher um host.
Figura 4.49: Criando um cenário para disponibilidade

Web (2/6)
Clique sobre “Create scenario”, uma nova janela de cadastro irá surgir.
Figura 4.50: Criando um cenário para disponibilidade Web (3/6)
1) Application: é o “application” de identificação para o cenário. Como ele não é

cadastrado em nenhum template tome cuidado para não escolher um “application”
que existe em outra parte do Zabbix. Coloque “Cenário HTTP” para o nosso exemplo.
2) Name: o identificador único do cenário dentro do host. Este nome vai aparecer no
momento do monitoramento. O valor que colocaremos é “Teste de aplicação PHP no
Apache”.
3) Authetication: no caso da URL requerer algum tipo de autenticação HTTP, você pode
definila aqui. Não há necessidade de autenticação no nosso exemplo.
4) Update inverval (in sec): o tempo entre uma coleta e outra. Deixe 10 segundos para
nosso cenário.
5) Agent: como o Zabbix vai se identificar para o servidor web. Essencialmente é a string
do browser pelo qual ele vai se fazer passar.
6) Status: Se ele está ou não, ativo.
7) Variables: um conjunto de variáveis para serem enviadas ao servidor. Deixe em
branco neste caso.
Note que em lugar algum foi definido qual a URL que este cenário vai acessar. Isso
porque é possível definir várias URLs dentro dele, cada uma é um “step”. Clique no botão “Add”
do campo “Steps” para criar um novo passo.

1) Name: o nome deste “step” normalmente representa a URL a ser testada (por
exemplo página principal, carrinho de compras, blog, etc.)
2) URL: o endereço web a ser acessado. Pode incluir parâmetros de método GET se
desejado. No nosso caso colocaremos “phpapp.curso468.4linux.com.br”.
3) Post: se a página receber dados via “POST”, as variáveis e valores (um em cada
linha) podem ser acrescentados aqui. Neste caso não há nenhuma.
4) Timeout: por quanto tempo o Zabbix vai esperar a resposta do servidor web onde a
URL aponta. O valor é em segundos. Deixe 15. Valores menores podem ser usados se
o teste for executado em infraestruturas locais, sites de baixo movimento ou em
servidores de altíssimo índice de tempo de resposta.
5) Required: um texto que é esperado na página de resposta. Se o servidor falhar em
entregar uma página com esta “string” um “trigger” é acionado.
6) Status code: qual o código HTTP esperado para a resposta. Normalmente ele é “200”
que significa “OK, página encontrada”. Você pode ver a relação de códigos HTTP em
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. Note que este
campo não é obrigatório, você pode simplesmente pedir pro Zabbix ver se o servidor
esta retornando algo, mas isso não é muito útil na maioria das vezes.
Para terminar a inserção do “step” clique em “Add”. Antes de continuar vale mencionar

que a URL de testes usada neste “step” passa pela estrutura de cache e proxy reverso do cenário
(Varnish → Apache+mod_proxy → Apache+PHP5) e por isso esta testando toda esta
infraestrutura. Poderíamos fazer um teste direto no servidor Apache se necessário.
Note que no final do quadro da janela de cenário o novo step fica listado em forma de
tabela. Ainda não vamos acrescentar outros “steps” neste cenário. Salve clicando no botão
“Save”.
Na lista de cenários, temos agora o nosso cadastrado. Para verificar este monitoramento
temos uma tela especial só para ele. Acesse Monitoring → Web.
Figura 4.54: Visualizando a checagem Web
Clique sobre o nome do cenário e note que ele esta sendo organizado pela “application”
escolhida quando o cadastramos.
Figura 4.55: Detalhes do monitoramento Web
Na tela seguinte um resumo da última coleta com a velocidade (Speed), latência de rede
(Response time), último código HTTP de resposta (Response code) e Status dos “triggers”
gerados automaticamente. Logo abaixo deste quadro temos dois gráficos de velocidade e tempo
de resposta prontos.
Figura 4.56: Gráfico de velocidade de download para o cenário Web
Figura 4.57: Gráfico de tempo de resposta para o cenário Web
Como você pode ver, a criação de um cenário é simples, mas permite uma flexibilidade
muito grande. Vamos em seguida ver como realizar uma validação de um formulário web.
4.5.2. Exercícios
1) Crie um “action” para os “triggers” que o cenário gerou e faça os seguintes testes:
1.1) Parar o servidor Apache no host “Application”.
1.2) Parar o servidor Apache no host “Presentation”.
1.3) Parar o servidor Varnish no host “Presentation”.
1.4) Mudar o HTML da página principal para não retornar a string esperada.
4.6. Checando disponibilidade via agentes
As duas “simple checks icmpping” e “ssh” que usamos e o cenário web criado não utilizam
o agente, por isso são denominadas “agentless”. Isso é útil quando o sistema final não permite
que seja instalado o agente por um motivo qualquer e usa apenas protocolos de rede para avaliar
a disponibilidade do objeto final.
Porém essas checagens são muito limitadas e se não houver, ao menos, um agente
SNMP no host de destino não é possível coletar métricas do servidor e determinar o que causou
uma determinada parada. Por isso o Zabbix vem com um agente que pode ser instalado nos hosts
de destino, como fizemos no Capítulo 2. Chegou a hora de utilizar este agente para realizar as
checagens de disponibilidade. Vamos começar com métricas simples e depois passaremos a
checar métricas de sistema operacional muito mais ricas.
4.6.1. Checando se o agente esta operacional
O primeiro passo é verificar se o agente esta funcionando e escutando na sua porta,
normalmente 10050/TCP. Usamos em capítulos anteriores o “zabbix_get” para coletar dados da
“key agent.ping” como um teste. Esta “key” retorna 1 se o agente esta operando, mas considere
que se ele não estiver funcionando não há como ele retornar 0 para alertar uma queda!
Por isso essa “key” tem um tratamento especial dentro do Zabbix. Se algum problema de
rede, firewall, daemon, etc não permitir que o agente seja alcançado e o servidor registrar erro ele
irá gravar um valor nulo na coleta. Este valor poderá ser testado num “trigger” com a função
“nodata()” (veja mais a frente) o que requer um tratamento especial para o caso. Vá até a tela de
i”tems” do template “4Linux – S.O. Base” e crie um novo item.
Ao criar o item aqui os templates “4Linux – S.O. Linux” e “4Linux – S.O. Windows”

automaticamente herdarão ele.
Figura 4.58: Novo item para monitorar o agente
O preenchimento dos campos já é bem trivial a esta altura. A Figura 4.58 mostra quais

são os valores que devem ser colocados em cada um. Como este item é suportado pelo Zapcat
também iremos copiálo para o outro template. Salve e siga os passos abaixo.
Figura 4.59: Copiando o item de ping de agente para o template do JBoss

(1/2)
1) Selecione o item dentro da lista
2) Escolha “Copy selected to...” na caixa de ações.
3) Clique em “Go” (1).
Figura 4.60: Copiando o item de ping de agente para o template do JBoss (2/2)
1) Target Type: esta parte um pouco confusa, pois antigamente o Zabbix não
diferenciava hosts e templates (de fato ele ainda faz pouca dissociação entre eles
algumas vezes). Você vai escolher “Host” neste campo para que logo abaixo possa
escolher os templates.
2) Group: escolha o host group “Templates”.
3) Target: marque o template do JBoss como indicado.
Clique em “Copy” para finalizar a operação. O item agora faz parte de ambos templates.
Confira pelo “Overview” se todos os hosts Gnu/Linux e Window, além do JBoss é claro, estão com
este item funcionando.
4.6.2. Criando um trigger com a função nodata()
Agora vamos criar um “trigger” que opera com a função “nodata()” conforme citação
anterior. O procedimento é muito similar ao do gatilho para o ICMP, exceto pela função usada.
A “nodata()” opera com base em erros de coleta para definir a queda de um agente. Se
algum erro ocorrer ela retorna 1, caso contrário um dado foi recebido e armazenado e ela retorna
0. Usaremos este truque mais a frente para “triggers” que podem parar de receber dados e
apresentar constantemente os indesejáveis estados “UNKNOWN”.
Dentro do template “4Linux – S.O. Base” crie um novo “trigger”.
Note que o “trigger” herdado do ICMP Base esta aparecendo na sua lista de “triggers”
deste template.
Figura 4.61: Criando um trigger para o agent.ping (1/5)
Exceto pelo “Expression” preencha os campos conforme a Figura 4.61. Depois mude o

método de entrada e clique em “Edit”.

1) Item: Escolha o item “Agent Ping” para ser avaliado.
2) Function: Procure no final da lista a função escolhida na imagem. Ela representa a
“nodata()”.
3) Last of (T): Nossa janela de tempo. Como no “icmpping” vamos esperar por um
minuto sem resposta e então ativar o “trigger”.
4) N: O valor esperado para a função. Conforme citado, ele será 1.
Você não pode escolher um valor de “Last of (T)” menor do que 30 segundos para a
função “nodata(sec)”. O Zabbix faz checagens de falta de recebimento a cada meio
minuto, por isso deixar este campo menor que este valor não vai ter função alguma.
Adicione a expressão ao “trigger”.
Agora vamos adicionar uma dependência a este “trigger, ele só deve ser avaliado se o
teste de “ping ICMP” for bem sucedido. Isso evita suas coisas: primeiro que mais de um “action”
seja ativado em caso de um congelamento do host (o que economiza alertas), segundo permite
que o Zabbix não perca tempo com processamento de gatilhos que são desnecessários para a
ocasião (que gastam tempo de CPU no servidor de monitoramento). No nosso cenário se o host
não estiver respondendo à requisição ICMP é inútil testar o agente.
Note que isto pode não ser verdade no cenário de sua empresa! Avaliar a dependência
dos “triggers” é importante quando se está construindo uma solução eficiente de
monitoramento.
Clique no botão “Add” e selecione o “trigger” do ICMP.
Note que agora ele aparece na lista de dependências. Salve o novo gatilho.
Figura 4.66: Trigger para o agent ping criado e ativo

Perceba que ambas, a dependência e a nova função, aparecem na lista de “triggers”.
Vamos realizar um teste agora, parando o agente do “zabbixsrv”.
# /etc/init.d/zabbixagent stop
Vá até o “Overview”, selecione “triggers” no campo “Type” e aguarde o ativamento do

mesmo.
Figura 4.67: Trigger de agente ativado
Note que há setas nos detalhes dos “Triggers” para o servidor. Uma seta para cima
significa que o “trigger” já caiu e voltou ao estado de OK. Uma seta para baixo significa que seu
estado atual é “PROBLEM”. Retorne o agente ao estado normal, atribua um “acknowledgement” e
vamos a outro teste.
Desta vez derrubaremos dois hosts, pausando ambos e verificando se eles vão ativar o
“trigger” de agente além do do ICMP. Pare o host “Windows 2003” e “Database” e retorne ao
“Overview”.
Figura 4.68: Dependência entre triggers evitando que o gatilho filho

seja ativado
Perceba como ambos os “triggers” de agente ficaram cinzas enquanto os de ICMP

alertaram uma queda.
Se o seu teste não funcionou pode ser necessário aumentar a janela de tempo em
relação ao “trigger” pai. Nunca deixe a janela do filho exatamente igual ou menor que a
do pai, a folga pode ser pequena mas deve existir.
Não é possível usar a função “nodata()” para verificar a disponibilidade via SNMP.
4.6.3. Exercícios
1) Copie o “trigger” para o template do “JBoss”.
2) Crie as “actions” necessárias para enviar os alertas de paradas dos hosts a seus
respectivos responsáveis, conforme a tabela abaixo.
Host Responsáveis
Application sysadmin, javaeng
Database sysadmin, dba
JBoss AS javaeng
Presentation sysadmin
Switch sysadmin, winadmin
Windows2003 winadmin
Zabbixsrv sysadmin
Tabela 9: Responsáveis de cada host
4.7. Tempo online e última inicialização do S.O.
Vimos anteriormente que o Zabbix alertou uma queda de host quando nosso “trigger”
ICMP estava realizando uma checagem ruim sem janela de tempo. Ao concertar este
comportamento deixamos de saber quando um host foi reiniciado. Verificar a reinicialização de
hosts é importante na medição da disponibilidade do mesmo. Este tópico trata justamente desta
questão.
Primeiro vamos ao problema prático que temos em mãos: temos que medir o tempo de
“uptime” de todos os hosts incluindo ai os Gnu/Linux, Windows, switch e a máquina virtual java na
qual o JBoss é executado. Isso nos dá três casos de coleta: pelo agente normal, pelo agente
Zapcat e pelo SNMP.
Isso vai demonstrar como o sistema do Zabbix consegue lidar com ambiente
heterogêneos e vai demonstrar que depois da coleta o tratamento, armazenamento e análise não
muda.
O primeiro passo é analisar o retorno dos valores via console. Isso é importante para que
tenhamos parâmetros de tipos de dados (inteiros, float); nome correto das “keys”, “OIDs”, etc e
acesso. O agente do Zabbix possui uma “key” chamada “system.uptime” que retorna o tempo
desde o último boot. De maneira equivalente o JBoss tem um “JMX
java.lang:type=Runtime,Uptime” que também faz isso, mas para a inicialização da JVM e o SNMP
por padrão tem o OID “DISMANEVENTMIB::sysUpTimeInstance”.
A OID do SNMP é muito variável de um equipamento para outro, sempre consulte o
manual ou a MIB do seu fabricante para determinar o que esta disponível para coleta.
Vamos usar os seguintes comandos para os casos de uso.
# zabbix_get k "system.uptime" s application
59545
# echo "jmx[java.lang:type=Runtime][Uptime]" | nc application 10052; echo
ZBX59374361
# snmpget v2c c public 172.27.0.135 DISMANEVENTMIB::sysUpTimeInstance
DISMANEVENTMIB::sysUpTimeInstance = Timeticks: (6026194) 16:44:21.94
Se você fez o desafio do tópico 2.12, página 72 pode usar o seu script em vez do

segundo comando.
Cada comando retornou um valor inteiro, todos representando o “uptime” do sistema. A
grande diferença entre eles é a precisão de tempo utilizada, o agente do Zabbix retorna o valor em
segundos, o Zapcat em milissegundos e o agente SNMP em centésimos de segundos (que ele
chama de “timeticks”).
Não se incomode com a saída em texto de vários desses comandos, o Zabbix lida com
os números destacados em negrito apenas.
Toda essa diferença requer um tratamento no momento da coleta, ou seja, na

configuração de cada item. Primeiro vamos coletar o dado do agente do Zabbix. No template
“4Linux – S.O. Base” crie um novo item conforme a seguir.
Figura 4.69: Item para tempo de uptime

1) Description: coloque a descrição, conforme a figura.
2) Key: como usamos no comando zabbix_get, a chave “system.uptime” vai coletar o

tempo de funcionamento do host.
3) Units: este campo permite que façamos algumas personalizações no tratamento da
saída do item no “Overview” e gráficos. Embora similar ao “Values maps” ele é mais
sofisticado, pois formata a saída conforme necessário em vez de simplesmente dar
um apelido para uma tabela de valores. Neste caso use o “uptime”.
4) New application: defina um novo “application” para os “items” de sistema.
Salve e faça o mesmo para o template “4Linux – JBoss Base” mas com as modificações a
seguir.
Figura 4.70: Uptime via Zapcat

1) Key: aqui usaremos a sintaxe da “key jmx” pela primeira vez. Ela normalmente é
composta por duas partes, o nome do “JMX” e seu atributo cada um dentro de seu
próprio colchetes. Cada “jmx” aponta para um “Mbean” no servidor.
Para saber quais “Mbeans” estão disponíveis em um servidor com Zapcat, acesse a
URL http://<servidor>/zapcat-1.2/mbeans.jsp substituindo <servidor> pelo seu
DNS ou IP conforme for o caso. Um estudo mais aprofundado dos “MBeans” é
realizado nos cursos “436” e “467” sobre JBoss na 4Linux.
2) Use custom multiplier: neste campo faremos o tratamento de dados para converter o
resultado para segundos. Como a JVM retorna um valor em milissegundo, temos que
multiplicar por “.001”.
Salve este item e crie o último, dentro do template “4Linux – SNMP” conforme a seguir.
Figura 4.71: Uptime via SNMP

1) Type: como este item é obtido pelo SNMP, temos que configurar o item para que o
Zabbix entenda como coletálo. No nosso caso estamos usando SNMP versão 2, no
caso de outros equipamentos a versão 1 (obsoleta) ou 3 (mais segura) pode ser
usada. Consulte o manual de seu fabricante. Esta opção requer que o servidor seja
compilado com suporte a “netsnmp” (enablesnmp). Note que os campos abaixo se
alteram conforme você escolhe outros tipos de valores.
2) SNMP OID: coloque a “object identifier” da métrica desejada conforme sua
necessidade, no nosso caso é “DISMANEVENTMIB::sysUpTimeInstance”.
3) SNMP Community: coloque a “string” de comunidade do SNMP, normalmente este
valor é “public”.
4) SNMP Port: A porta UDP em que o agente SNMP esta ouvindo, o padrão é 161.
5) Key: invente uma “key” a seu gosto, ela só não pode conflitar com outras “keys”
criadas ou repetir uma “key” registrada. Para padronizar o curso, todas as chaves de
SNMP são definidas como “snmp.função”. Neste exemplo utilizamos “snmp.uptime”.
6) Units: repita o usado no item do agente.
7) Use custom multiplier: como o SNMP, retorna um valor em centésimos de segundos
temos que multiplicálo por “.01” para converter para segundos.
Salve o item e vá até o “Overview”.
Figura 4.72: Overview exibindo os uptimes a partir do agente padrão, Zapcat e SNMP
A Figura 4.72 mostra todos os hosts, com as métricas de tempo ligado obtidas conforme
sua interface de coleta. Graças ao campo “Unit” todas estão exibindo o tempo em um formato
legível por humanos e o campo “Use custom multiplier” ajustou os valores para segundos, que
uma unidade com a qual o Zabbix sabe trabalhar.
Novamente, isso demonstrou a capacidade em coletar dados de ambiente heterogêneos,
desde que você tenha um agente suportado não há problemas. O agente padrão do Zabbix é
compatível com 9 sistemas operacionais do mercado, as “JVMs” com “Tomcat” e/ou “JBoss” são
suportadas pelo Zapcat e a maioria esmagadora de ativos de redes (desde “switches” até
impressoras, passando por nobreaks) suportam alguma versão de SNMP hoje em dia.
4.7.1. Trigger para alerta de reinicialização
Avaliar se um host foi reinicializado é fácil. Devemos verificar se o “uptime” dele é menor
que um valor pré estabelecido. No entanto, reinicialização de servidores pode não é um incidente
crítico, de fato, normalmente ele é apenas um evento planejado (a menos que você possua uma
hardware com problemas sérios), por isso iremos categorizála como um evento de severidade
“warning” (aviso). Não um erro, mas ainda assim digna de uma atenção mais pontual. Vamos criar
a “trigger” para o “4Linux – S.O. Base” primeiro.
Figura 4.73: Um trigger para a reinicialização de um host

1) Expression: defina a expressão como sendo o último valor da última hora como
sendo menor do que “1800” (meia hora). Dois pontos importantes aqui: primeiro o
tempo de janela da função “last()” deve ser sempre maior do que o valor comparado e
segundo, o tempo de ativação deve ser maior do que o tempo de coleta.
2) Trigger depends on: coloque como dependência deste “trigger” o da verificação do
agente. Não há sentido em tentar analisar uma métrica que não esta sendo recebida.
Isso evita que ela apresente valores desconhecidos.
4.7.2. Exercícios
1) Crie as “triggers” para os templates do JBoss e do SNMP.
2) Crie as devidas “actions” para alerta de reinicialização enviando mensagens apenas
aos indivíduos responsáveis por cada host (consulte a Tabela 9 na página 175 para
detalhes).
4.8. Checando serviços pelo agente
Checar se um determinado serviço está em funcionamento através de sua porta é

funcional, mas algumas vezes precisamos de mais informações do que exatamente ocorreu no
host.
Imagine que por exemplo ao invés de queda do “daemon”, um sistema proteção como o
“OSSEC” barrou acidentalmente a porta de destino de hosts legítimos como o próprio servidor de
monitoramento. Isso não foi uma queda de serviço e outros hosts podem ainda não conseguir se
conectar. Para detectar este tipo de coisa precisamos de mais dados sobre o sistema onde o
serviço esta sendo executado e podemos fazêlo através do agente do Zabbix.
4.8.1. Verificando os processos ativos na memória
O Zabbix tem uma “key” chamada “proc.num” que pode ser usada para verificar o número
de processos na memória. Se usada sem nenhum parâmetro ela faz uma contagem de todos os
processos sem discriminação, para exemplificar o uso dele vamos verificar se o processo do SSH
esta na memória das máquinas Gnu/Linux.
A sintaxe da chave é a seguinte (todos os parâmetros são opcionais):
proc.num[<name>,<user>,<state>,<cmdline>]
Onde,
name: é o nome do processo. Se você estiver checando processos numa máquina

Windows, certifiquese que o processo dele contém a extensão “.exe” (ou similar) no final
do nome.
• user: qual o usuário que esta executando um determinado processo ou conjunto de

processos. O padrão é verificar de todos os processos.
• state: qual o estado do processo. Podendo ser “all” (padrão), “run”, “sleep” ou “zombie”
(este último somente em ambientes “*nix”).
• cmdline: filtra pela linha de comando. Isso é útil para aplicações que sempre iniciam o
mesmo processo, como o java.
Em nossa prática atual, o único parâmetro relevante é o primeiro, pois vamos buscar

apenas um processo bem definido dentro da memória (o “daemon” do SSH). Para descobrir qual
o processo usaremos o comando “ps”. Entre no console do servidor do “Zabbixsrv”.
# ps uax | grep ssh i
root 1161 0.0 0.3 5496 988 ? Ss 14:09 0:00 /usr/sbin/sshd
root 3594 0.2 1.1 8304 2868 ? Ss 14:40 0:00 sshd: root@pts/0
root 3674 0.0 0.3 3316 836 pts/0 S+ 14:41 0:00 grep color ssh
O primeiro processo é o “daemon”, o segundo é uma conexão ssh acontecendo e o

terceiro é o próprio “grep” na memória que usamos na linha de comando e portanto pode ser
ignorado. Note que o nome do processo é “sshd” e não simplesmente ssh. Com isso em mãos,
podemos ser mais pontuais com o “ps”, a opção “C” pouco conhecida e usada, lista apenas os
processos com o nome indicado. Ela é incompatível com as opções “a” e “x”, por isso à usaremos
em combinação com a “u”, apenas.
# ps u C sshd
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1161 0.0 0.2 5496 624 ? Ss 14:09 0:00 /usr/sbin/sshd
root 3594 0.0 0.8 8304 2204 ? Ss 14:40 0:00 sshd: root@pts/0
Guarde esta opção do “ps”, você vai precisar dela no futuro.
Vamos usar o “zabbix_get” para coletar a informação da chave agora.
# zabbix_get s localhost k "proc.num[sshd]"
2 ←
A chave retornou “2”, que é exatamente o número de processos que contamos com o ps.
Com o teste concluído vamos à criação do “item” e “trigger”. Use o template “4Linux – S.O. Linux”.
Figura 4.74: Item para verificação de número de processos
A Figura 4.74 ilustra como o item para contagem de processo deve ser criado, ele é bem
trivial.
Figura 4.75: Overview refletindo o número de processos
No “Overview”, já podemos rastrear o funcionamento da contagem de processos. Note
que o número de processos do host “Zabbix Server” esta com 2 porque há uma conexão ssh
ocorrendo nele, nos outros apenas o “daemon”, aguardando a conexão, está sendo executado.
Com os dados sendo coletado já podemos criar um “trigger”.
Figura 4.76: Trigger para queda do daemon

1) A condição do “trigger” é bem padrão em relação aos nossos gatilhos anteriores: use
a função “sum()” para descobrir se algum processo esta rodando na janela de tempo
de 1 minuto.
2) Ele deve depender da checagem de agente porque não há sentido em testar uma
métrica que depende dela mesmo. Além disso se não o fizermos esta “trigger” vai
resultar em um “unknown” se o agente cair.
3) A severidade deste incidente vai ser classificada como “Average” pois o SSH não é um
serviço prioritário para o funcionamento das aplicações, no entanto ele não é um
“Warning”, pois ainda é classificado como erro e precisa de intervenção imediata.
Salve o “trigger” e vá até o console do host “Database” e para o SSH.
Acesse a lista de eventos em Monitoring → Events para acompanhar a ativação do
“trigger”.
Figura 4.77: Teste de queda do sshd
Também olhe no “Overview” como o “trigger” ficou exibido.
Figura 4.78: Reflexo da queda do daemon SSH no overview
Note que o teste de porta também falhou, mas não emitiu alerta pois ainda não temos
“triggers” associados a ele.
# /etc/init.d/ssh start
4.8.2. Checagem de portas e serviços localmente via agente
Além do teste feito pelo servidor na porta “22/TCP”, também podemos pedir ao agente
para realizar o mesmo teste. Este tipo de teste de agente é útil para criarmos lógicas mais
inteligentes de análise do cenário.
A key “net.tcp.service[ssh]” tem o mesmo efeito e comportamento que a ssh. Sua solene
diferença é que ela é do tipo “zabbix agent” em vez de “simple check”. Crie o item conforme a
Figura a seguir.
Figura 4.79: Item para verificação da porta local
Após a criação do item, verifique se a coleta esta sendo realizada. Se tudo estiver correto,
é hora de passar para a verificação das mudanças de status. Até o momento temos 3 maneiras de
checar o serviço: contando os processos ativos na máquina, checando a porta remotamente pelo
servidor do Zabbix e/ou checando a porta localmente pelo agente do Zabbix.
Todas tem suas vantagens e desvantagens, mas em vez de usálas de forma

discriminada, vamos juntar a força de todas elas e fazer com que a lógica de todos os gatilhos
trabalhem em conjunto. Essa capacidade de oferecer dependência entre uma checagem e outra
que o Zabbix oferece é de extremo poder, e mesmo sem expressões booleanas complexas dentro
de cada “trigger” seremos capazes de determinar qual o possível acontecimento, dependendo de
qual “trigger” foi ativado. Acompanhe a explicação a seguir, começando pela leitura do fluxograma
na Figura 4.80.
Figura 4.80: Fluxograma da dependência entre triggers para

análise de serviços
O primeiro “trigger” (cada um é representado pelo losango) é o que criamos anteriormente
para verificar se há, ao menos, um processo “sshd” sendo executado. No caso de não haver
nenhum, ele deve alertar o administrador responsável pelo serviço. Note que se realmente não há
nenhum tipo de processo do serviço sendo executado, então não há sentido em verificar portas,
correto?
O segundo, é a análise da porta localmente a partir do agente, se não há processos

escutando na porta a partir da própria máquina local então o processo “master” da aplicação
provavelmente caiu. Note que se você parar o ssh pelo serviço de boot as conexões que estão em
andamento não são interrompidas! Logo é possível ter uma situação onde há processos “sshd” na
memória que estão apenas atendendo a conexões que foram estabelecidas anteriormente à
queda do processo principal e só vão morrer se estas conexões forem encerradas.
Esse tipo de comportamento é muito comum em serviços que são baseados em “forks”,
como o Apache, o próprio Zabbix, muitos “daemons” escritos em Perl, etc. Programas que
trabalham puramente com “threads”, como as aplicações feitas em java, incluindo aqui o Tomcat e
o JBoss tem um processo monolítico e não seguem esta regra.
Finalmente, o terceiro “trigger” checa se servidor consegue abrir uma conexão com a

porta remotamente. No caso de um bloqueio por filtro de pacotes no host de destino ou no meio
do caminho, ou falhas de rotas, este gatilho é ativado. Este caso cobre a ocorrência do “daemon”
estar em perfeito funcionamento mas os pacotes de rede não estarem alcançando o destino (ou
não estão voltando apropriadamente).
Como o terceiro só é checado se o segundo estiver com status OK, e este último se o
primeiro estiver com status OK, o Zabbix não gasta processamento com os três gatilhos, a menos
que tudo esteja na mais perfeita ordem. Se um dos primários falharem então os outros não serão
executados.
Obviamente pode haver muito mais tipos de problemas, que vão além da contagem de
processos e verificação de portas. Um binário corrompido pode causar quedas de
conexões legítimas alguns segundos depois de serem estabelecidas pelo serviço, ou
ainda ele pode sempre retornar um erro na cara do cliente sem sair completamente do
ar. Para estes casos continue empilhando outras checagens após verificar estas três
que geralmente estão sempre perto da base.
Mas vamos continuar com nossa prática dirigida e criar os dois “triggers” que faltam, pois
o primeiro já esta pronto desde o tópico anterior.
Figura 4.81: Trigger para verificação da porta local
O “trigger” da Figura 4.81 é a segunda checagem (porta local). Note que ele tem como

dependência o “trigger” da contagem de processos.
Figura 4.82: Trigger para verificação de porta remota

Já o da Figura 4.82 faz a verificação da porta remotamente e tem como dependência o

segundo gatilho. Outro ponto importante é que sua janela de tempo é de 70 segundos (10 a mais
que o anterior), esta folga evita que ambos sejam ativados simultaneamente.
Deixar uma margem entre 10 e 5 segundos na janela de um “trigger” que depende de
outro é uma boa prática.
Como foi dito anteriormente, não há como verificar de maneira confiável se uma porta
UDP está aberta. Mas o agente tem uma chave chamada “net.udp.listen” que verifica
se localmente uma dada porta UDP esta esperando requisições.
4.8.3. Exercícios
1) Agora teste os gatilhos realizando as seguintes tarefas:
1.1) Pare o “daemon” ssh de um Gnu/Linux sem conexões abertas para ele
(somente o primeiro gatilho deve disparar). Restaure o “daemon”.
1.2) Pare o “daemon” ssh de um Gnu/Linux com ao menos uma conexão aberta
(somente o segundo gatilho deve disparar). Restaure o “daemon”.
1.3) Corte a regra de SSH dos filtro de pacotes (iptables) de um dos Gnu/Linux,
somente o terceiro gatilho deve disparar. Restaure a regra após o termino.
4.8.4. Verificando serviços no Windows
Assim como o Gnu/Linux, o Windows tem seu sistema de gerenciamento do serviços
ativos na memória. Usamos ele no tópico 2.7.1. , página 50 para executar o serviço do agente do
Zabbix. Acesse o Painel de Controles → Ferramentas Administrativas → Serviços.
Na tela que lista os serviços, localize o serviço de “Telnet”. Ele deve estar desativado.
Figura 4.83: Serviço telnet do Windows
Vamos usálo como exemplo para monitoramento de serviços no Windows. O “Telnet” é
simples de se colocar em funcionamento, de fato quase nada é configurado. Clique duas vezes
sobre o nome dele.
Figura 4.84: Habilitando o serviço de telnet do Windows
1) Nome do serviço: anote o nome do serviço! O Zabbix precisa dele para conseguir
localizálo no sistema. No nosso caso é “TlntSvr”.
2) Tipo de inicialização: mude para “automático”.
Depois de terminar clique em “OK”, o serviço vai entrar registrado mas ainda não iniciado.
Figura 4.85: Ativando o serviço de telnet
Para iniciar use a barra de ferramentas no topo da tela como indicado na Figura 4.85.
Agora pressione CTRL+ALT+DEL, e abra o Gerenciador de tarefas.
Figura 4.86: Processo do telnet na memória
Confira se um dos processos bate com o nome do serviço. Provavelmente você achará o
processo “tlntsvr.exe”. Anote também este nome.
Antes de cadastrar novos “items” vamos fazer um pequeno teste via console: use o
“zabbix_get” para coletar o número de processos “telnet” na memória (deve retornar 1).
Novamente lembramos que no Windows, devese incluir a extensão “.exe” no final dos
processos para a “key” “proc.num”.
# zabbix_get s win2003 k 'proc.num[tlntsvr.exe]'
1
Agora vamos testar a key “service_state” que faz a verificação dos serviços do Windows
no Zabbix. Use o nome que pegamos das configurações do “Telnet” como parâmetro dela.
# zabbix_get s win2003 k 'service_state[TlntSvr]'
0
Note que o resultado foi zero. Isso porque zero significa rodando, experimente pausar o
serviço no Windows e execute o comando novamente.
# zabbix_get s win2003 k 'service_state[TlntSvr]'
1
Agora retornou 1. Sim, parece contra produtivo, mas esta tabela foi baseada em números
que a própria API do sistema Windows retorna. Os valores possíveis estão na Tabela abaixo.
Valor Estado
0 Rodando
1 Pausado
2 Início requisitado
3 Pausa requisitada
4 Continuação requisitada
5 Parada requisitada
6 Parado
7 Desconhecido
255 Serviço não existe (não esta cadastrado
na lista de serviços do Windows)
Table 10: Valores da key service_state
Mas isso ainda não é suficiente. Temos que pedir ao Windows que libere a porta do
Firewall para o acesso ao Telnet. Por padrão todos os “telnets” usam a porta “23/TCP”. Acesse
Painel de Controles → Firewall para abrir as preferências.
Figura 4.87: Liberando o telnet no firewall do Windows (1/3)
Clique em “Adicionar Porta...” e preencha a janela que aparecer conforme indicado a

seguir.
Figura 4.88: Liberando o telnet no firewall do Windows

(2/3)
1) Nome: o nome do serviço é apenas um “label” para o Firewall. Defina como “telnet”.
2) Número da porta: coloque 23.
3) O protocolo usado é o “TCP”.
Clique em OK para finalizar.
Figura 4.89: Liberando o telnet no firewall do Windows (3/3)
Por fim, clique em “OK” novamente. Para averiguar se tudo esta correto faça um teste a
partir do console do host “Zabbix server”.
# nmap P0 p 23 win2003
Interesting ports on 172.28.0.10:
PORT STATE SERVICE
23/tcp open telnet
# telnet win2003
Trying 172.28.0.10...
Connected to win2003.curso468.4linux.com.br.
Escape character is '^]'.
Welcome to Microsoft Telnet Service
login: administrador
password:
*===============================================================
Bemvindo ao Microsoft Telnet Server.
*===============================================================
C:\Documents and Settings\Administrador>exit
Se o teste correu bem, vá até o template “4Linux – S.O. Windows 2003” e crie um novo
“item” conforme abaixo.
Figura 4.90: item para monitorar serviços Windows
Nenhuma grande novidade aqui, apenas atente para a key e para o campo “New
application”. Outro ponto importante é o uso do “Value map Windows service state”.
Figura 4.91: Estado do serviço Telnet no Overview

Verifique que no “Overview” o serviço esta aparecendo e funcionando.
4.8.5. Restabelecendo serviços offline via Zabbix
Um aviso de cautela logo no início. Permitir que o agente execute comandos remotos
no host monitorado pode causar falhas de segurança se não houver cuidado triplicado.
Somente use este recurso se você realmente precisar e tiver absoluta certeza do que
esta fazendo.
Um recurso poderoso é a capacidade do agente do Zabbix de executar comandos

remotos a pedido do servidor. Isso possibilita que sejamos capazes de restaurar um serviço que
caiu, ou reiniciar um que está com problemas no atendimento de requisições.
Obviamente o agente por padrão não executa nada, tampouco é capaz de executar
comandos administrativos arbitrariamente. Isso se deve a dois fatos: os “defaults” dos arquivos de
configuração e a execução do daemon do Zabbix como usuário não privilegiado.
Nossa primeira prioridade é justamente liberar o agente para executar os comandos. O
arquivo “/etc/zabbix/agent.d/remote_command.conf” contém as configurações para tal
procedimento. Eleja uma das máquinas virtuais Gnu/Linux e comece a realizar os procedimentos
a seguir.
# vim /etc/zabbix/agent.d/remote_commands.conf
1 # Este é o arquivo de configuração do agente do Zabbix para comandos
2 # remotos.
3
4 #
========================================================================
5 # Liga/Desliga o recurso de comandos remotos do agente.
6 #
7 # Este tipo de feature vem desligada por padrão devido ao risco de segurança
8 # que ela pode apresentar se mal configurada.
9 #
10 # Note que o usuário do Zabbix tem que ter direitos de execução do comando em
11 # questão enviado pelo servidor. Para isso ou ele é executado como root
12 # (desaconselhável) ou chama executáveis com suid (desaconselhável) ou utiliza
13 # sudo para rodar os comandos. Este último é a opção mais segura das três, mas
14 # requer configurações extras no arquivo sudoers.
15 #
16 EnableRemoteCommands=1
17
18 #
========================================================================
19 # No caso de habilitada a execução de comandos remotos, é aconselhável deixar
20 # esta opção ativada para auditoria do sistema. Ela vai registrar no arquivo
21 # de logs do agente quando e qual comando foi executado (ou no mínimo foi
22 # tentado).
23 #
24 LogRemoteCommands=1
é preciso mudar para 1 ambos “EnableRemoteCommands” e “LogRemoteCommands”.

Seus nomes são bem subjetivos, e apesar de não haver necessidade de ativar o segundo para
que a coisa toda funcione é extremamente aconselhável fazêlo.
Já estamos ampliando bastante a confiança do agente no servidor, vamos ser

cautelosos e ao menos colocar as tentativas de execução de comandos nos logs para
auditoria.
É recomendável que você desabilite o arquivo de log também e faça o agente gravar no
syslog, dessa forma ele não terá direito de escrita nos arquivos usados para armazenar
suas mensagens.
Agora a segunda parte: como usuário “zabbix”, o agente não será capaz de iniciar
nenhum serviço do Gnu/Linux, somente o “root” pode fazêlo. Então vamos apelar ao “sudo”
novamente para execução do comando (instale o “sudo” se necessário).
Configure o sudo para permitir que o agente execute sem senha o “script” de
reinicialização do ssh.
# visudo
…
zabbix ALL = NOPASSWD: /usr/init.d/ssh restart
Seja metódico e defina exatamente quais são os parâmetros permitidos dentro do sudo,
principalmente para “scripts” de sistema. Não queremos ninguém dando “stop” no ssh
pelo Zabbix, acidentalmente ou não!
Crie uma “action” para conter o comando remoto.
Figura 4.92: Action para parada do SSH (1/3)
As configurações padrões são bem apropriadas, apenas acrescente o adendo na

mensagem que o serviços esta sendo reiniciado manualmente.
Nas condições, é importante notar que há três delas. Uma indica que o status do “trigger”
deve ser “PROBLEM”.
Você não quer que o serviço seja reiniciado quando o gatilho voltar a OK, certo?
As outras duas possibilidades são o “trigger” de processo ou de checagem local de portas
serem ativados. Qualquer um deles que apresentar “PROBLEM” dispara esta ação.
Uma mensagem para os envolvidos com esse host deve ser enviada. E por fim o
comando remoto, ativado a partir do quadro “Action operations”.
Figura 4.95: Comando remoto para o action de parada do serviço de SSH

1) Operation type: escolha “Remote command” ao invés do valor para envio de
mensagens. Note que o campo abaixo vai mudar.
2) Remote command: você precisa colocar o comando com a sintaxe “Host:command”,
onde host é o local onde o comando será executado (onde você habilitou o comando
remoto no agente) e “command” é o comando propriamente dito. No nosso caso
usaremos “Database:sudo /etc/init.d/ssh restart”.
Você pode usar macros nos comandos e pode invocar quantos comandos você quiser,
em quaisquer servidores, em qualquer sequência.
Agora vamos ao teste: vá até o host no qual você configurou o agente para aceitar
comandos remotos e pare o serviço de SSH, em seguida abra o log e aguarde.
# tail /var/log/zabbix/zabbix_agentd.log f
…
7287:20110215:192625.462 Executing command 'sudo /etc/init.d/ssh restart'
Starting OpenBSD Secure Shell server: sshd.
Se você voltar à tela de eventos verá que há dois deles, um de queda e outro de volta.
4.8.6. Exercícios
1) Crie o mesmo esquema de monitoramento feito para o SSH para o Apache dentro do
“application”. Gere um template a parte para o Apache para conter os “items” e
configurações. Também crie uma “action” capaz de reiniciar o serviço se for detectado
que nenhum “daemon” do apache esta rodando.
2) Crie um “trigger” para avaliar se um serviço do Windows não esta rodando e uma
“action” para alertar o administrador Windows. No corpo da mensagem coloque o
estado em que o estado se encontrava no momento do alerta. Use a mesma tática de
checagem de portas e múltiplos gatilhos.
4.9. Medindo a “saúde” de sua rede
Até o momento nossos esforços foram dirigidos a checagem de dados que indicam
apenas se um dado host (ou serviço) está operacional ou não. Vamos começar a abordar outros
tópicos, que embora, indiretamente relacionados com os serviços podem afetar seu
funcionamento.
Este tópico aborda a parte de “networking” e mostra como monitorar o quão saudável sua
rede está.
4.9.1. Latência de rede
O primeiro ponto que vamos analisar são as causas de indisponibilidade por excesso de
trafego na rede. Note que medir a banda pode ajudar a identificar gargalos de rede, mas a métrica
mais indicada para medir lentidão é a latência de rede, que pode estar baixa mesmo quando não
há trafego! Como sempre vamos começar com a criação do item dentro do template “4Linux –
ICMP”.
A chave “icmppingsec” também faz um “ping” como a “icmpping”, mas diferente desta ela
retorna o número de segundos que o pacote levou para ir e voltar (na verdade a média de três
pacotes).
Figura 4.96: Item para latência de rede
Neste item, atente para o campo “Units” que contém o valor “s” (segundos). Ele irá
formatar o valor recebido pelo item para uma forma legível por seres humanos. E mais importante,
desta vez “Type of Information” esta como “Numeric (float)”, porque o retorno da key
“icmppingsec” é em segundos, mas normalmente os tempos de respostas são quebrados em três
casas decimais (milissegundos).
4.9.2. Macro para o limiar da latência de rede
Um ponto muito importante é definir o que é uma latência ruim. Isso é muito variável de
um ambiente para outro, se você estiver medindo a latência em uma rede local então, é provável
que uma latência acima de 10 milissegundos seja alta. No caso de medir a latência de um
equipamento com link via satélite, podemos encontrar latências de alguns segundos como padrão
dependendo da tecnologia.
Para deixar nossos templates flexíveis o suficiente para se adequarem a quaisquer

ambientes podemos usar um recurso muito interessante do Zabbix chamado “macros de
usuários”.
Existem três tipos de escopo de macro: global (definido em Administration → General)
que vale para todos os templates e hosts; macros de templates, cujo alcance vale para todos os
hosts associados a um dado template e macros de host, que vale só para aquele host. Se você
redefinir (como vamos fazer) uma macro num ambiente mais restrito, o que irá valer será este
último.
O Zabbix tem várias macros internas e já tivemos contato com algumas quando criamos
nossos “triggers”. {HOSTNAME}, que é a mais comum, armazena o nome do host definido dentro
do “front end”. Quando definirmos uma macro de usuário é importante que em sua sintaxe um
sinal de cifrão ($) seja colocado antes do nome e dentro das chaves.
Por exemplo, vamos definir uma macro para latência de rede com o nome “LATENCIA”,
logo sua sintaxe será “{$LATENCIA}”. Evite o uso de outros caracteres no nome da macro exceto
por “underline” (_). Também não comece o nome da macro por números. É uma boa prática
manter os nomes em caixa alta.
No caso de nosso cenário iremos definir um padrão de “0.01” segundos (10

milissegundos) para nossa macro, ela vai ser uma macro de template, mais especificamente o
template “4Linux – ICMP”. Abra as configurações do mesmo clicando no nome dele em
Configuration → Templates. No canto direito do quadro principal você vai achar a área de
definição de macros.
Figura 4.97: Macro para latência de rede
Acrescente os valores conforme a Figura 4.97 e salve o template. Ela já estará valendo

para todos os hosts associados a ele. Vamos agora usála no gatilho para verificação de latência
alta de rede. Crie o “trigger” no template conforme a seguir.
Figura 4.98: Trigger para latência de rede usando a macro
A grande diferença deste template para os anteriores é o uso da macro. Preste atenção
no campo Expression, seu valor indica a fórmula “{HOST:ITEM.avg(60)}>{$LATENCIA}”.
Podemos inserir quantas macros quisermos na expressão do gatilho.
A partir de agora se reutilizarmos estes templates em outros ambientes, podemos

adequar a latência de rede globalmente alterando o valor da macro no template. No caso de um
dos hosts em nosso sistema ter um limiar diferente de latência, podemos ainda redefinir a macro
dentro do próprio host, alterando assim o comportamento de seu “trigger” pontualmente.
4.9.3. Nosso primeiro gráfico
Vamos agora criar um gráfico que irá usar este “trigger” para exibir o limiar de teste na
tela. O resultado será similar ao da Figura 4.99.
Figura 4.99: Gráfico para medir a latência de rede
Vá até a tela de criação de gráficos e clique em “Create Graph”. Siga as instrução abaixo
para construir um gráfico como demonstrado acima.
Figura 4.100: Criando um gráfico de latência de rede

1) Name: nome do gráfico. A partir da versão 1.8.4 do Zabbix é possível usar macros
aqui.
2) Width e Height: tamanho padrão do gráfico para algumas telas. Na maioria dos casos
o “front end” ajusta o gráfico ao tamanho corrente da tela do Browser.
3) Graph type: o tipo de gráfico, aqui vamos criar um “Normal” mas podemos construir
gráficos “Stacked” (empilhados), “Pie” (Pizza) e “Exploded” (pizza com valores
destacados para fora da área do gráfico. Nosso exemplo usa “Simple”.
4) Show working time: se ativo, mostra uma sombra nos horários fora do “Working time”
definido em Administration → General → Working time.
5) Show triggers: exibe uma linha pontilhada como demonstrada anteriormente no
limitar do “trigger”. Deixe ele ativo.
6) Y axis MIN/MAX value: valores mínimo e máximo do gráfico. Útil para definir uma
escala de visualização. No nosso caso vamos colocar apenas o valor mínimo de 0
(assim o “chão” de nosso gráfico sempre se manterá em 0) e o máximo em
“Calculated”, pois não temos como saber onde esta o topo para cada ambiente. Em
alguns casos, como em porcentagens, normalmente o máximo é um valor fixo, em
outros ele pode ser o valor de um item.
7) Items: aqui podemos definir quais são os campos que desejamos incluir no gráfico.
Procure sempre usar o mínimo possível de informação neste caso. Para acrescentar
um Item clique em “Add”. A janela de novo item para o gráfico se abrirá como a seguir.
Figura 4.101: Adicionando métricas ao gráfico

1) Parameter: qual key cadastrada no template este elemento representará.
2) Type: se este item é “Simple” ou “Agregated”. Campos agregados agrupam várias

contagem em um único valor. São úteis para visualização de variação com menor
granularidade num dado espaço de tempo. Por exemplo, se você quiser apenas a
média, de hora em hora, ao invés de usar o intervalo de coleta.
3) Function: qual valor deve ser mostrado se houver a existência de mais de um valor
por pixel no eixo “x”. As funções são “avg” (média, o mais comum), “max” (máximo),
“min” (mínimo) ou “all” (todos os três). Em variações muito baixas, “all” pode não
exibir nada significante.
4) Draw style: Como a linha será desenhada. Os valores possíveis são: “Line” (linha

simples), “Filled region” (área preenchida), “Bold line” (linha mais espessa), “Dot”
(pontos), “Dashed line” (tracejado) e “Gradient” (área com gradiente da cor
gradativamente indo para transparente). Este gráfico usa “alpha blender”.
5) Colour: obviamente a cor.
6) Y axis side: Se os valores deste item serão exibidos do lado esquerdo ou direito do
gráfico.
7) Sort order: um número indicando a ordem de desenho no gráfico, vai de 0 a 100.
Você pode ordenar os elementos dos gráficos como desejar na tela de construção do
gráfico depois de acrescentar todos eles.
Clique em “Save” em ambas as telas e o gráfico estará pronto para exibição em
Monitoring → Graphs.
O botão de “Preview” que existe na tela de construção dos gráficos não será capaz de
exibir os gráficos se você estiver acrescentando ele a um template como estamos
fazendo. Ele só funciona no caso de um gráfico ser criado direto em um host.
4.9.4. Personalizando o mapa para exibição de informações
O mapa do Zabbix é extremamente personalizável, e permite que visualizemos
praticamente qualquer valor que coletamos e processamos, desde “items” até “triggers”. Vamos
aproveitar que coletamos várias métricas importantes e associálas ao mapa. O resultado final
deve ficar como na Figura .
Figura 4.102: Mapa com labels personalizadas exibindo dados
Para definir estes valores é bastante simples: edite a o item de host clicando sobre ele e
preencha, linha a linha, os valores do campo “Label”. No exemplo que vimos, vários hosts exibem
o “Uptime” obtido de “{Host:system.uptime.last(0)}” e de latência de rede, obtido de
“{Host:icmppingsec.avg(60)}”. Atenção especial ao segundo, pois usamos a função “avg” e não
“last”, isso é totalmente permitido.
Na Figura 4.103 temos um exemplo com o host “Presentation”. Após editar o valor clique
em “Apply”.
Figura 4.103: Exemplo de labels com valores de métricas

Não esqueça de salvar o mapa constantemente no botão “Save”.
4.9.5. Exercícios
1) Assim como o “icmppingsec” esta para o “icmpping”, várias keys com sufixo “_perf”

estão para os equivalentes das “simple checks” de portas TCP. Por exemplo,
“ssh_perf” é a medição de latência para o servidor de conexões remotas segura. Crie
os “items” e gráficos (veja o exemplo abaixo) para os outros serviços que você já criou
anteriormente de disponibilidade. Cadastre macros para medir o limiar e finalize com
os “triggers” dos mesmos.
Em sala de aula, crie pelo menos um deles, os outros podem ser feitos em casa.
Figura 4.104: Exemplo de gráfico de latência de serviços para exercícios
4.10. Espaço disponível em disco
A latência de rede pode medir o nível de resposta final das aplicações disponibilizadas via
TCP. Mas um item extremamente crítico, pois pode causar paradas de serviços abruptamente, é o
espaço disponível em disco.
Vários daemons simplesmente saem de funcionamento porque não são capazes de
escrever em partições de logs, e bancos de dados e pastas de usuários sempre podem exceder
as estimativas previstas. Por isso é importante que verifiquemos ambas as partições de sistema e
de dados dentro de um servidor.
Como exemplo iremos criar uma verificação da raiz nos Gnu/Linux. Depois estenderemos
o mesmo princípio ao Windows. Outro ponto é que nos servidores sempre existem várias
partições (ao menos nos bem instalados), e por isso temos que ter múltiplos “items” para cobrir
todos os casos e deixar margem, através de macros, para partições com nomes personalizados
pelo administrador.
Por fim, desta vez teremos que coletar várias métricas (ao menos três) para criação dos
gráficos e “triggers”. Espaço total, usado e livre.
Existem outras métricas como porcentagem utilizada e livre do disco (“pfree” e

“pused”), além de “items” baseados em “inodes”. Consulte o manual do Zabbix para
mais detalhes.
Antes de começar a criar “items” vamos definir um valor limite para nossos “triggers” como
fizemos na latência de rede. A utilização dos espaços em disco pode variar muito entre os
servidores. Todas as nossas ações serão dentro do template “4Linux – S.O. Linux”. Comece
criando a macro conforme abaixo.
Figura 4.105: Macro para limite de espaço em disco utilizado
O valor padrão usado para nosso cenário será “80” (80% da partição cheia), todo servidor
que exceder este limite deverá disparar um alerta para os administradores.
Vamos criar os item agora, a key “vfs.fs.size[mount_point, mode]”, diferente das anteriores
exige parâmetros para funcionar. O primeiro é obrigatório e indica qual das partições devem ser
analisada. O segundo é opcional e diz qual parâmetro deve ser coletado. Os valores possíveis
são: “total” (bytes totais da partição. É o tipo padrão), “used” (bytes utilizados), “free” (bytes livres),
“pused” (porcentagem utilizada) e “pfree” (porcentagem livre). Vamos usar apenas os três
primeiros, começando pelo total, conforme a seguir.
O agente não verifica se o diretório colocado no parâmetro é a raiz de um ponto de
montagem. No caso de não ser, ele continuará obtendo o valor do espaço da partição
como um todo (pense nele como um “df” ao invés de um comando “du”.
Figura 4.106: Primeiro item de espaço em disco

1) Description: aqui temos uma novidade: uma vez que estamos usando parâmetros na
key, podemos capturálos e inserilos no “description” usando a notificação “$n”, onde
“n” é o número do parâmetro começando por 1. Em nosso exemplo usaremos “$1”
para pegar o ponto de montagem da partição. Isso alivia bastante a digitação, pois os
outros “items” que iremos clonar não precisam ter “descriptions” muito diferentes.
2) Key: a chave de espaço conforme explicado anteriormente. Para o total sua sintaxe
final é “vfs.fs.size[/,total]”.
3) Units: “b” representa valores em “bytes”. O Zabbix é inteligente o suficiente para fazer
as conversões para “kilo”, “mega”, “giga”, “tera”, etc. Usando múltiplos de 1024.
Salve o item e ao invés de criar o próximo item “no braço”, vamos usar um recurso de
clonagem de valores do Zabbix. Várias telas permitem que usemos o recurso de clonagem. Neste
caso vamos clonar o total para usado e livre, conforme o esquema na Figura 4.107.
Figura 4.107: Items a serem clonados para espaço em disco
Edite o item de “Espaço total” e clique no botão “Clone”.
Figura 4.108: Botão para clonar items
Você verá que os dados se repetirão. Altere apenas a key (que deve ser única) e o
“description”. Repita para o outro item e você terá outras duas métricas prontas e coletando em
tempo recorde! Confira no “Overview” se os dados estão sendo coletados adequadamente
(atentando para que eles estejam em notação abreviada, Mb, Gb, etc).
4.10.1. Gráficos para espaço em disco
Vamos criar dois gráficos para visualização de espaço em disco: o primeiro é um gráfico
de pizza (também chamados de torta, mas o nome oficial é gráfico circular) para mostrar o atual
volume de uso do disco. Apesar de parecer inútil, este tipo de gráfico tem uma vantagem grande
sobre o de linha: ele exibe de maneira visual o estado atual com proporções facilmente
reconhecíveis por olhos humanos. Veja a Figura 4.109, que ilustra o gráfico que vamos criar daqui
a pouco, facilmente conseguimos ver que esta partição esta com mais de 50% ocupada somente
olhando para o gráfico.
Novamente, como usamos o campo “Unit” igual a “b”, os valores já aparecerão

convertidos e abreviados para facilitar leitura humana.
Figura 4.109: Gráfico de pizza para exibição de espaço

livre e ocupado
Para gerar um gráfico como esse siga os passos a seguir.
Figura 4.110: Criando um gráfico de pizza
Não há muitos segredos nesta tela, ao selecionar “Pie” em “Graph Type” menos campos
irão aparecer no formulário. Vamos deixar a legenda ativa. Podese fazer gráficos em 3D se
desejado, mas não há grandes vantagens neles em relação aos normais em termos de
visualização, é apenas estética.
Note que vamos utilizar dois “items” ao mesmo tempo: espaço utilizado e livre.
Foi usado vermelho para o espaço utilizado por um bom motivo, as cores quentes
tendem a atrair o olho humano quando em contraste com cores frias ou mais claras.
Isso faz com que inconscientemente o administrador ou suporte, fixe no espaço
utilizado o que é o crítico neste caso.
Enquanto o gráfico circular é indicado para mostrar o último status de vários “items”
relacionados, proporcionalmente ele oculta o histórico do espaço ocupado. Por isso precisamos
criar, também, um gráfico simples. O procedimento é similar ao anterior e resultará no gráfico da
Figura 4.111.
Seu diferencial é que vamos usar um limite superior ao invés de um limite calculado. Para
indicar o topo do gráfico vamos apontar para o espaço total da partição obtido através de um item.
Figura 4.111: Gráfico de histórico de espaço em disco
Crie um gráfico como antes, mas atente para o detalhes em destaque abaixo.
Figura 4.112: Criando o gráfico de histórico de uso de disco

Após acrescentar o item de espaço utilizado, no campo “Y axis MAX value” escolha
“Item” e selecione o item de espaço total. Isso vai limitar o topo do gráfico e dar uma visualização
mais precisa do espaço que está sendo utilizado em relação ao total. Se você não o fizer e tiver
por exemplo pouco espaço usado o gráfico ficará ajustado ao tamanho máximo atingido o que
pode levar um observador desavisado a interpretar como disco cheio!
4.10.2. Gatilhos para alertas de espaço em disco
Agora vamos usar a macro que definimos anteriormente para calcular o volume de disco
usado. Para isso vamos usar uma fórmula para, a partir do total, saber qual é a porcentagem em
“bytes” que a partição terá de limiar. A expressão lógicomatemática seria.
ESPAÇO_USADO > (ESPAÇO_TOTAL * LIMITE / 100)
Sendo que:
• ESPAÇO_USADO: é a média da janela de tempo do espaço utilizado na partição.
• ESPAÇO_TOTAL: é o último valor coletado do espaço total da partição.
• LIMITE: o valor definido em nossa macro, representando a porcentagem de limite

(padrão 80%) para averiguação de estouro de uso de disco.
Note que, você poderia usar o “pused” para pegar a porcentagem utilizada ao invés
desta fórmula, mas isso acrescenta mais um item no monitoramento. Além do mais
este é um exemplo bem didático para expressões mais complexas.
No caso de nosso cenário a expressão completa é apresentada na Figura 4.113 e calcula
exatamente quantos porcentos de uso da partição apresenta.
Figura 4.113: Trigger para cálculo de espaço em disco
Note ainda que, como sempre, colocamos uma dependência ao “Agent Ping” para evitar
testes com valores inexistente que resultam em “UNKNOWN”.
Verifique se alguma máquina excedeu o espaço e acionou o “trigger”. Neste caso você
deve aumentar o valor da macro para aquele host somente. Isso é um caso atípico no nosso
cenário então o trataremos como uma exceção.
Para testar o “trigger” use o seguinte comando em uma das máquinas Gnu/Linux:
# dd if=/dev/zero of=/tmp/lixo bs=1k count=$(( 200 * 1024 ))
Isso vai gerar um arquivo de 200 Mb no “/tmp”. Mude o tamanho do arquivo conforme
achar necessário para fazer o teste. Deixe ele lá até o “trigger” alarmar e depois apagueo para
liberar o espaço e forçar a troca de estado para “OK”.
4.10.3. Exercícios
1) Clone os “items” criados para a partição “/” alterando para as partições “/usr”, “/var”,
“/tmp”, “/boot” e “/home” (as normalmente criadas numa instalação). Replique também
as macros, os gráficos e os “triggers”.
Deixe todas estas métricas e gatilhos como “disabled” por padrão! Elas dependem da
instalação de Gnu/Linux. Em sala replique ao menos uma, as outras podem ser feitas
em casa.
2) Crie as mesmas métricas para o Windows, mas com as partições de “C:” até “G:”. Em
sala crie ao menos uma, as outras podem ser feitas em casa.
3) Desafio: crie métricas que checam partições personalizadas pelo administrador,
usando macros para definir os pontos de montagem.
4.11. Scripts externos
Fizemos várias checagens até o momento usando os recursos do Zabbix. Mas nem
sempre teremos tudo a mão. Este trecho do curso ensina a estender o agente de tal forma a criar
novas keys através da chamada de scripts externos.
Além disso algumas métricas do Windows só podem ser obtidas pelo sistema de
“performance counters” que é um tipo de registro de coleta de performance padrão do Windows.
Veremos como utilizar ambos para adicionar mais poder de fogo ao nosso arsenal de
monitoramento.
4.11.1. Checando a disponibilidade do PostgreSQL
O Zabbix não tem suporte a todos os protocolos TCP da face da Terra. De fato isso seria
um feito impressionante para um aplicativo de monitoramento. O protocolo do PostgreSQl esta
entre os não suportados, e embora tenhamos utilizado keys como “tcp” e “tcp_perf” para medir
sua disponibilidade podem ocorrer situações onde o banco aceite conexões mas não responda
nada, ou o faça muito lentamente.
Nestes casos iremos criar uma extensão do agente apta a realizar uma única consulta
(SELECT 1) e verificar se ele retornou o valor correto. Esta extensão vai chamar um script criado
em “bash” que aciona localmente o servidor, faz a consulta e determina o resultado. Prepare os
conhecimentos de “shell script”, respire fundo e vamos começar acessando o host “Database”.
O primeiro passo é permitir que o usuário zabbix se conecte ao banco sem a necessidade
de senhas. Isso é necessário porque o comando será executado automaticamente sem a
intervenção manual de um administrador.
Como vamos usar o “psql”, cliente padrão via console do PostgreSQL, podemos usar um
artifício interessante com o arquivo “.pgpass”. Este arquivo deve ficar dentro do diretório home do
zabbix e deve conter uma “string” com os parâmetros de acesso. Cada permissão de acesso do
usuário zabbix deve estar em uma linha (assim podemos acessar múltiplos bancos de dados).
O formato das linhas deste arquivo seguem a sintaxe:
hostname:porta:basededados:usuário:senha
E no nosso caso vamos acessar o banco principal do sistema “postgres”, logo o valor final
será “localhost:5432:postgres:zabbix:zabbixdb”. Os seguintes comandos criam o arquivo, ajustam
sua permissão e fazem o teste local.
# su zabbix
$ echo "localhost:5432:postgres:zabbix:zabbixpwd" > .pgpass
$ chmod 0400 .pgpass
$ psql h localhost U zabbix postgres c “SELECT 1;”
1
$ logout
A permissão do arquivo “.pgpass” deve ser 0600 ou 0400 e o dono do arquivo deve ser
o usuário zabbix.
Ainda temos que criar o usuário “zabbix” dentro do banco com a senha “zabbixpwd”.
# su – postgres
$ psql postgres
postgres# CREATE ROLE zabbix LOGIN;
postgres# \passwd zabbix
Digite nova senha: zabbixpwd
Digitea novamente: zabbixpwd
postgres# \q
Agora vamos criar um arquivo para conter as configurações do script. Ele vai conter
apenas uma variável por enquanto. Mais a frente vamos colocar outros valores aqui para o
conjunto de scripts do PostgreSQL.
# vim /etc/zabbix/pgaccess.conf
1 HOST=localhost
Enfim chegamos ao script. Basicamente ele executa o comando “psql” com o SQL de
testes e verifica se tudo ocorreu bem. Mas há algumas partes do script que merecem um
destaque.
# vim /etc/zabbix/externalscripts/pgsql_ping.sh
1 #!/bin/bash
2
3 BASE="/etc/zabbix"
4 CONF=$BASE/pgaccess.conf
5 QUERY_PING="SELECT 1;"
6 ERROR_LOG=/var/log/zabbix/pgsql_ping.error
7
8 function showerror {
9 echo e "PostgreSQL ping error:\n$(cat $ERROR_LOG)" 1>&2
10 }
11
12 if [ r $CONF ]; then
13 . $CONF
14 fi
15
16 PING_OK=1
17 PING_FAIL=0
18 PING=$(psql h $HOST c "$QUERY_PING" postgres tA 2> $ERROR_LOG) 
19 RETURN=$? 
20
21 if [[ $RESULT ne 0 ]]; then 
22 showerror
23 exit 1
24 else
25 if [[ $PING eq 1 ]]; then 
26 echo $PING_OK
27 else
28 showerror 
29 echo $PING_FAIL
30 fi
31 fi
32
33 exit 0
1) O primeiro destaque do script é justamente o comando que faz o “SELECT 1” e

armazena seu conteúdo em uma variável chamada “$PING”. Note que o “psql” está
usando os parâmetros “t” e “A” para que o comando retorne apenas um valor 1. No
caso de algum erro o valor de “$PING” será diferente de 1.
2) O retorno do comando é verificado e no caso de erros, uma mensagem é gravada na
saída de erros e o script para com retorno 1. O Zabbix trata isto enviando a saída para
o “zabbix_agentd.log”.
3) No caso do SELECT ser bem sucedido, o valor retornado será 1 (definido no
cabeçalho do script).
4) Caso contrário o script retorna 0 e grava uma mensagem no log indicando porque.
Note que o comportamento, de 1 significa sucesso e 0 para falha, replica o padrão das
keys de disponibilidade que vimos anteriormente. Isso ajuda a manter o padrão e permite o uso do
“value maps” que criamos.
Todo script de comando externo deve retornar um, e apenas um valor! Repita isso
consigo mesmo! Não há como pegar valores compostos no Zabbix e trabalhar com eles
individualmente depois. Cada item armazena um “single content”.
Agora vamos criar uma nova key “pgsql.ping”, dentro do agente. Para isso usamos o
“UserParameter”, dentro de um dos arquivos de configuração do agente. A sintaxe desta linha é:
UserParamente=key,comando arg1 arg2 ...
No caso de nossa necessidade ficará como a seguir.
# cat /etc/zabbix/agent.d/pgsql_checks.conf
1 UserParameter=pgsql.ping,/etc/zabbix/externalscripts/pgsql_ping.sh
Temos que acertar as permissões dos arquivos e reiniciar o agente.
# chown root.zabbix /etc/zabbix/pgaccess.conf /etc/zabbix/agent.d/pgsql_checks.conf
/etc/zabbix/externalscripts/pgsql_ping.sh
# chmod 0640 /etc/zabbix/pgaccess.conf /etc/zabbix/agent.d/pgsql_checks.conf
# chmod 0750 /etc/zabbix/externalscripts/pgsql_ping.sh
Já podemos fazer o teste local, o script deve retornar o valor 1.
# su zabbix c “/etc/zabbix/externalscripts/pgsql_ping.sh”
1
A partir do Zabbix server teste o acesso a nova chave. O resultado também deve ser 1.
# zabbix_get s database k 'pgsql.ping'
1 ←
Se todos os testes foram resolvidos é o momento de voltar ao “front end”. Crie um novo
template “4Linux – PostgreSQL 8.4 on Linux”, ele deve depender do “template 4Linux – S.O.
Linux”. Depois entre no host “Database”, remova o template “4Linux – S.O. Linux” pelo botão
“Unlink” (conservando assim os dados coletados) e adicione o novo modelo conforme a Figura
4.114.
Figura 4.114: Trocando o template do host database para o PostgreSQL
Verifique se no “Overview” os dados estão sendo recebidos.
Figura 4.115: Disponibilidade do PostgreSQL ativa no database
Com isso já poderíamos criar “triggers” e fazer o mesmo escalonamento de gatilhos para
averiguar qual tipo de erro pode acontecer.
4.11.2. Medindo a disponibilidade de um link Internet
Agora faremos um abordagem diferente: vamos medir a latência do link de Internet a partir
do host “Presentation” (assim podemos obter um valor puro entre o host de borda e o “gateway”
da operadora).
Este script, um pouco mais complexo que o anterior, permite que coletemos a média de
latência entre um conjunto de sites.
# vim /etc/zabbix/externalscripts/internet_perf.sh
1 #!/bin/bash
2
3 BASE=/etc/zabbix
4 CONF=$BASE/internet_perf.links
5 BC=$(which bc)
6
7 function showerror {
8 echo e "Check link error: $1" 1>&2
9 }
10
11 if [[ ! x $BC ]]; then
12 showerror "aplicativo bc não instalado"
13 exit 1
14 fi
15
16 if [[ ! r $CONF ]]; then
17 showerror "arquivo $CONF não existe ou não esta acessível para leitura"
18 exit 1
19 fi
20
21 NTESTS=$(wc l $CONF | cut f1 d" ")
22 SUM_AVG=0
23 for destination in $(cat $CONF); do 
24 PING=$(ping n c 1 w 1 W 1 $destination 2>&1)
25 if [[ $? eq 0 ]]; then
26 AVG=$(echo $PING | cut f34 d" " | cut f2 d"/")
27 SUM_AVG=$(echo "scale=3; $AVG + $SUM_AVG;" | bc)
28 else
29 NTESTS=$(( $NTESTS 1 ))
30 showerror "ping para $destination falhou com erro: $PING"
31 fi
32 done
33
34 if [[ $NTESTS eq 0 ]]; then
35 showerror "Todos os testes falharam"
36 exit 1
37 fi
38
39 echo "scale=3; $SUM_AVG / $NTESTS / 1000;" | bc 
40
41 exit 0
1) Este trecho é o corpo principal do script, ele pega o arquivo de links (abaixo) e realiza
um “ping” em cada um dos endereços lá dentro. Para cada coleta bem sucedida ele
soma a média que o comando retorna (em milissegundos).
2) No segundo trecho a partir do resultado da soma e da quantidade de testes é obtida a
média final e convertida para segundos (assim podemos usar o “Unit” “s” para
formatar a saída).
O arquivo de links pode conter tantas entradas o quanto quisermos, mas não é
recomendável que haja mais do que 5, que é o tempo limite que o Zabbix espera por um script
executar antes de desistir e retornar nulo.
# vim /etc/zabbix/internet_perf.links
1 www.google.com
2 www.uol.com.br
Como fizemos anteriormente, criaremos uma nova key “Internet.perf” que aponta para o
nosso script.
# vim /etc/zabbix/agent.d/internet_perf.conf
1 UserParameter=internet.perf,/etc/zabbix/externalscripts/internet_perf.sh
Finalmente acerte as permissões dos arquivos.
# chown root.zabbix /etc/zabbix R
# chmod 0640 /etc/zabbix/internet_perf.links /etc/zabbix/agent.d/internet_perf.conf
# chmod 0750 /etc/zabbix/externalscripts/internet_perf.sh
Já podemos fazer os testes locais e os remotos conforme mostrado no tópico anterior.
Também já podemos criar as macros, “items”, “triggers” e gráficos seguindo a mesma filosofia.
Somente mude o seguinte: para o item e gatilho deixeos desabilitados no template “4Linux – S.O.
Linux” e habilite somente no host “Presentation”.
Para concluirmos com outra novidade vamos colocar no “label” do link de Internet o valor
médio dos últimos 60 segundos de coleta (Figura 4.116).
Figura 4.116: Latência sendo

exibida no label do link
Abra o link e edite os valores de seus campos como a seguir.
Figura 4.117: Latência de rede e trigger associados ao link com a Internet no mapa
1) Label: coloque o valor “Latência: {Presentation:internet_perf.avg(60)}”.
2) Adicione o “trigger” da latência que você acabou de criar.
Não esqueça de salvar antes de sair do mapa. Para testar, diminua o valor da macro de
limite para um valor bem baixo.
Figura 4.118: Link no mapa

identificando status do trigger
Note como o link mudou de cor (Figura 4.118) quando o host acusou alta latência de
Internet.
4.11.3. Exercícios
1) Desafio: Crie um script externo capaz de ler a temperatura dos processadores e
armazenálos no Zabbix. O script deve receber um parâmetro indicando de qual core
deve ser coletado a temperatura (0 – primeiro, 1 – segundo, e assim por diante). Crie
ao menos um gráfico para visualizar o valor coletado dos cores.
- 228
REFERÊNCIAS
BIBLIOGRÁFICAS
- 229
OLUPS, RIHARDS. Zabbix 1.8 Network Monitoring. Packet Publishing. Abril
de 2010.
Homepage oficial da documentação do Zabbix, website:

http://www.zabbix.com/documentation/. Acesso em 16 de Fevereiro de 2011.
- 230
Anexo I
Performance do Sistema Operacional
Introdução
Aqui vamos passar as dicas e métricas que podem ser usadas para monitorar as quatro
principais características de desempenho. Uso de CPU, memória, “throughput” de rede e I/O de
disco. Este capítulo utiliza o template completo do Gnu/Linux para coleta de todas as informações.
Processamento
Esta é primeira métrica de performance que, geralmente, é observada quando o sistema
fica lento. Algumas considerações devem ser feitas quando se busca monitorar o processamento
para identificar gargalos:
1) 100% de processamento não quer dizer nada!
1.1) Picos de processamentos são mais corriqueiros do que imaginamos, eles
acontecem frequentemente, mas são tão momentâneos que nem os
percebemos mesmo em gráficos com curtos intervalos de coleta. Sempre que
procurar por eles, concentrese apenas nos de longa duração.
- 231
1.2) Se você criar gatilhos de verificação de CPU, façaos com uma janela de tempo
razoável. O aconselhado é que ela seja em torno dos 15 minutos, se o
processamento ficou muito alto, por tanto tempo assim, provavelmente há
alguma coisa errada na sua aplicação ou seu hardware está mal dimensionado.
2) Quando coletar informações de CPU você pode se deparar com muitas opções, aqui
vão algumas dicas sobre o que fazer para decidir o que coletar.
2.1) Antes de olhar a porcentagem da CPU, olhe para o “system load” (key
“system.cpu.load”). Ela indica o enfileiramento de processos, o que pode ser
bem pior do que simplesmente ter CPU alta o tempo todo.
2.2) Mantenha ao menos uma coleta geral de baixo nível. O consumo de CPU é
dividido em vários tipos, os mais relevantes são “user” (consumo realizado
pelos processos), “system” (consumo realizado pelo kernel) e “wait” (consumo
realizado por espera de I/O, geralmente de disco). Existem outros menos
relevantes, portanto consulte a documentação do Zabbix sobre a key
“system.cpu.util” para obter mais detalhes.
2.3) Ao monitorar múltiplos cores individualmente, colete apenas o “idle” de cada um
deles. Raramente você precisará de coletas detalhadas por núcleo.
2.4) Monitore também o “context switch” pela key “system.cpu.switches” para
verificar o número de vezes que os processos nascem, dormem, acordam e
morrem nos “cores”, além de indicar a migração de “threads”.
Métricas de memória
O segundo ponto mais importante de se monitorar num S.O. É a memória, incluindo aqui
a área de troca (swap).
1) Consumo de memória pode ser bem complicado de se monitorar se você não prestar
atenção nos tipos de memória que existem. No Gnu/Linux, por exemplo, temos a
memória de processos, a de “buffer” e a de cache. Por padrão a key “vm.memory.size”
não é capaz de capturar a memória dos processos (que é a importante). Para fazer
isso você tem que criar um item calculado que subtrai a memória “available” (e não a
“free”) do total.
- 232
2) Monitore a memória de “swap” com “system.swap.size” para determinar o consumo, e
mais importante, com “system.swap.in” e “system.swap.out” que mostram a leitura e
escrita na mesma. A área de troca é diretamente ligada ao I/O de disco (abaixo).
Throughput e banda de rede
Banda pode ser um item importante se você não tem um “link” suficientemente grande
para comportar suas necessidades, mas é o “throughput” o que realmente deve ser observado.
1) Grande largura de banda com baixo “throughput” e alta latência de rede indicam,
problemas de rede (provavelmente físicos). A key “net.if.in” e “net.if.out” são as
indicadas para isso.
2) Lembrese que o Zabbix, o sistema operacional e seus aplicativos medem o consumo
de rede em “bytes” e não em “bits”. No entanto todos os equipamentos de rede e links
de Internet são comprados pelo segundo. Prefira exibir mesmo assim os dados em
“bytes”. Se você realmente tiver que exibir em “bits” terá que criar um campo calculado
que lê e multiplica o valor do item em “bytes”.
3) Cuidado ao estipular valores de topo dos gráficos de banda para redes internas.
Enquanto nos links de Internet isso é uma prática recomendável, para consumos de
servidores em redes de 100 ou 1000 Mbps os valores vão ficar tão próximos do eixo x
que a impressão será de tráfego zero.
Performance de Disco
Para bancos de dados, analise a performance de disco. O template da 4Linux faz uso de
um script externo que coleta dados de baixo nível, o padrão do Zabbix ainda não é capaz de
coletar estes dados.
1) Não se atenha a “throughput” de disco em “bytes”, eles variam tanto de um hardware
para outro que é difícil de estabelecer um padrão. Use métricas como número de
operações, tempo gasto em escrita/leitura e enfileiramento de operações, eles são
muito mais significativos.
2) Procure por pontos de incidência de operações irregulares, se o tempo todo seu disco
fica numa média de operações e de repente ele muda, avalie o que pode ter ocorrido
neste período, mesmo que seja para menos carga (o que pode indicar “delays” de
operação).
- 233
Anexo II
Performance de serviços
Introdução
Performance de serviços é um assunto extenso e demandaria vários cursos a parte para
poder cobrir sua toda a sua extensão. De fato, uma parte dos cursos avançados da 4Linux
detalham este tipo de estudo. Aqui vamos apenas arranhar a ponta do iceberg.
Os templates completos do final do curso contém muito mais detalhes dos que os
discutidos aqui.
PostgreSQL
O banco de dados do PostgreSQL possui um sistema de tabelas chamadas catálogos.
Estas tabelas armazenam diversas operações importantes.
1) Não perca tempo olhando estatísticas de nível muito baixo. Comece por dados como
número de conexões e de operações no banco. Não aumente as conexões do banco
arbitrariamente, essa é uma prática ruim!
- 234
2) Procure distinguir o comportamento de sua aplicação. Muitas operações de escrita e
pouca leitura, ou viceversa, ou ainda ambas! Isso torna as coisas mais fáceis para
dimensionar “tunnings”.
3) Monitore a instância como um todo e depois desça para bancos específicos, seguido
de tabelas e por último índices e sequências. Assim você ganha uma visão global do
sistema antes de depurar qual tabela você precisa separar, particionar, etc.
JBoss
O servidor de aplicações JBoss tem todos aqueles “MBeans” que o Zapcat dissecou para
nós. Vamos comentar os mais importantes.
1) Aplicações java não usam “fork”. Eles sempre trabalham em “threads”, por isso
monitorar “threads” (principalmente os HTTP e AJP) vão mostrar o uso da JVM para
conexões.
2) O JBoss usa “datasources”, que possuem “poolings” de conexões. Monitorar as
conexões destes “pools” também é uma boa métrica. Via de regra uma boa aplicação,
mesmo muito ocupada, não deve usar mais do que algumas poucas dezenas de
conexões.
3) Consumo de memória “heap” pode indicar “garbage collectors” fazendo muitas
operações (nunca coloque muita memória de “heap” para as JVMs, pois o GC pode
derrubar as JVMs). Vazamentos “Leaks” de memórias também podem ser
detectados com este tipo de monitoramento.
4) Monitorar a área de “perm gen” normalmente não é necessário, mas pode indicar
quando “redeploys” acabam consumindo toda a memória destinada a “byte codes”.
Apache
O template do Apache precisa do “mod_status” ativado para coleta de informações.
1) Normalmente a métrica mais significativa é o número de conexões e uso de

processos.
2) Verificar os processos em “idle” pode indicar que a configuração pode ser ajustada
para menos, para consumir menos recursos.

4linux-Zabbix PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4linux-Zabbix PDF

Uploaded by

Copyright:

Available Formats

Soluções de Monitoramento com

Valter Douglas Lisbôa Júnior

2.10. Instalando o servidor Zabbix via pacote.......................................................................57

3.8. Ativando um host............................................................................................................123

4.9.3. Nosso primeiro gráfico.........................................................................................................205

Figura 3.6: Media Types.........................................................................................................83

Figura 3.45: Editando as propriedades do novo link...........................................................112

Figura 4.7: Nova entrada de menu com o script criado......................................................137

Figura 4.46: Simple check para o SSH................................................................................161

Figura 4.85: Ativando o serviço de telnet............................................................................191

As comunidades também mantém uma série de fóruns em

• Executar deploy do agente Zapcat no JBoss para monitoramento do servidor de

Figura 2.1: Configuração do evolution (1/10)

Figura 2.2: Configuração do evolution (2/10)

Figura 2.3: Configuração do evolution (3/10)

Começaremos a configurar as contas de usuários dentro do sistema de LDAP que o

Figura 2.4: Configuração do evolution (4/10)

Figura 2.5: Configuração do evolution (5/10)

Figura 2.6: Configuração do evolution (6/10)

Figura 2.7: Configuração do evolution (7/10)

Figura 2.8: Configuração do evolution (8/10)

Figura 2.9: Configuração do evolution (9/10)

Figura 2.10: Configuração do evolution (10/10)

Agora que o Evolution esta é funcionamento, acesse o menu Editar → Preferências e

Vamos então configurar o Pidgin, um cliente de IM simples e eficiente para receber os

Figura 2.11: Tela de boas vindas do Pidgin

Figura 2.12: Configurando uma conta Jabber no Pidgin

Figura 2.13: Definindo o uso de criptografia

2.3. Obtendo os fontes do Zabbix

Se você estiver usando a versão 9.0 do PostgreSQL é importante lembrar que o

Esta sessão toda é dedicada ao processo de criar os binários, cobrindo quais

Opção do configure Descrição

Opção do configure Descrição

Opção do configure Descrição

zabbix_sender Utilitário para envio de “traps” para o

Diretório ou arquivo Descrição

Diretório ou arquivo Descrição

Copie o arquivo compactado do DVD (confs/config­server.tar.bz2 e confs/config­

Figura 2.14: Baixando o agente do Zabbix no Windows

Primeiro é preciso baixar os executáveis pelo endereço

Figura 2.15: Instalando os executáveis no Windows

O arquivo zabbix_agentd.conf deve ficar na raiz da pasta conf, assim como os

Figura 2.16: Diretório de configuração do Zabbix no Windows

Edite o arquivo c:\Zabbix\conf\agent\checkings.conf e mude os parâmetros Server e

Figura 2.17: Configurando o agente no Windows

Figura 2.18: Desbloqueando o agente no Windows

Figura 2.19: O agente do Zabbix sendo executado como serviço automático.

2.8. Instalação do agente Zapcat para JBoss

Reinicie o JBoss e teste o acesso ao Zapcat pelo endereço

Figura 2.20: Tela de entrada do Zapcat

O último comando dá permissões de escrita na pasta “conf” ao servidor, isso é

Reinicie o Apache, abra a porta 80 do firewall e teste acessando a URL

Figura 2.21: Configuração do front end (1/10)

Figura 2.22: Configuração do front end (2/10)

Figura 2.23: Configuração do front end (3/10)

Procure com o apoio da tabela abaixo e da tela de configuração todas as opções

Parâmetro do PHP Significado

Figura 2.24: Configuração do front end (4/10)

Se todos os pré­requisitos foram supridos clique em “Next”. Senão refaça os passos

Figura 2.25: Configuração do front end (5/10)

Figura 2.26: Configuração do front end (6/10)

Figura 2.27: Configuração do front end (7/10)

1) O servidor de Zabbix esta em localhost, mas atenção para ambientes de produção

Copie o arquivo compactado do DVD (confs/configserver.tar.bz2 e confs/config

Se todos os prérequisitos foram supridos clique em “Next”. Senão refaça os passos

Em produção não desligue o “autologout” de nenhum usuário a menos que seja