Monitoramento Com Zabbix

Prévia do material em texto

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, grupose 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..........................................................................2164.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.2: Configuração do evolution (2/10)........................................................................17
Figura 2.3: Configuração do evolution (3/10)........................................................................18
Figura 2.4: Configuração do evolution (4/10)........................................................................19
Figura 2.5: Configuração do evolution (5/10)........................................................................20
Figura 2.6: Configuração do evolution (6/10)........................................................................21
Figura 2.7: Configuração do evolution (7/10)........................................................................22
Figura 2.8: Configuração do evolution (8/10)........................................................................23
Figura 2.9: Configuração do evolution (9/10)........................................................................23
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.22: Configuração do front end (2/10)......................................................................62
Figura 2.23: Configuração do front end (3/10)......................................................................63
Figura 2.24: Configuração do front end (4/10)......................................................................65
Figura 2.25: Configuração do front end (5/10)......................................................................66
Figura 2.26: Configuração do front end (6/10)......................................................................67
Figura 2.27: Configuração do front end (7/10)......................................................................68
Figura 2.28: Configuração do front end (8/10)......................................................................69
Figura 2.29: Configuração do front end (9/10)......................................................................70
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.........................................................................................................83Figura 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.26: Concedendo permissões de acesso (2/4)...........................................................96
Figura 3.27: Concedendo permissões de acesso (3/4)...........................................................96
Figura 3.28: Concedendo permissões de acesso (4/4)...........................................................97
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.50: Criando um application (2/4)...........................................................................115
Figura 3.51: Criando um application (3/4)...........................................................................115
Figura 3.52: Criando um application (4/4)...........................................................................116
Figura 3.53: Criando seu primeiro item (1/3)......................................................................116
Figura 3.54: Criando seu primeiro item (2/3)......................................................................117
Figura 3.55: Criando seu primeiro item (3/3)......................................................................118
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.62: Associando o template do JBoss ao host JBoss AS (2/6).................................120
Figura 3.63: Associando o template do JBoss ao host JBoss AS (3/6).................................120
Figura 3.64: Associando o template do JBoss ao host JBoss AS (4/6).................................121
Figura 3.65: Associando templates a hosts (5/11)...............................................................121
Figura 3.66: Associando o template do JBoss ao host JBoss AS (6/6).................................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.69: Associando um template a múltiplos hosts simultaneamente (2/4)..............122
Figura 3.70: Associando um template a múltiplos hosts simultaneamente (3/4)..............123
Figura 3.71: Associando um template a múltiplos hosts simultaneamente (4/4)..............123
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.....................................................................................127Figura 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.19: Criando um trigger para a parada do host (2/9).............................................143
Figura 4.20: Criando um trigger para a parada do host (3/9).............................................143
Figura 4.21: Criando um trigger para a parada do host (4/9).............................................143
Figura 4.22: Criando um trigger para a parada do host (5/9).............................................144
Figura 4.23: Criando um trigger para a parada do host (6/9).............................................144
Figura 4.24: Criando um trigger para a parada do host (7/9).............................................145
Figura 4.25: Criando um trigger para a parada do host (8/9).............................................145
Figura 4.26: Criando um trigger para a parada do host (9/9).............................................146
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.35: Criando uma action para enviar o alerta (2/9)................................................150
Figura 4.36: Criando uma action para enviar o alerta (3/9)................................................151
Figura 4.37: Criando uma action para enviar o alerta (4/9)................................................151
Figura 4.38: Criando uma action para enviar o alerta (5/9)................................................151
Figura 4.39: Criando uma action para enviar o alerta (6/9)................................................152
Figura 4.40: Criando uma action para enviar o alerta (7/9)................................................152
Figura 4.41: Criando uma action para enviar o alerta (8/9)................................................152
Figura 4.42: Criando uma action para enviar o alerta (9/9)................................................153
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.49: Criando um cenário para disponibilidade Web (2/6)......................................164
Figura 4.50: Criando um cenário para disponibilidade Web (3/6)......................................165
Figura 4.51: Criando um cenário para disponibilidade Web (4/6)......................................166
Figura 4.52: Criando um cenário para disponibilidade Web (5/6)......................................167
Figura 4.53: Criando um cenário para disponibilidade Web (6/6)......................................167
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.62: Criando um trigger para o agent.ping (2/5)....................................................172
Figura 4.63: Criando um trigger para o agent.ping (3/5)....................................................173
Figura 4.64: Criando um trigger para o agent.ping (4/5)....................................................173
Figura 4.65: Criando um trigger para o agent.ping (5/5)....................................................173
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................................................180Figura 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.88: Liberando o telnet no firewall do Windows (2/3)............................................194
Figura 4.89: Liberando o telnet no firewall do Windows (3/3)............................................195
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.93: Action para parada do SSH (2/3).....................................................................200
Figura 4.94: Action para parada do SSH (3/3).....................................................................201
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 - 12
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.
Capítulo 1 Conhecendo o Zabbix - 13
1.1. Conhecendo a ferramenta
Siga os passos indicados pelo professor para acesso ao exemplo pronto na máquina dele. 
Você   vai   fazer   um  passo­a­passo   conhecendo   a   ferramenta   como  um  usuário   comum  (não 
superusuário).
1.2. Comunidades e forums
O Zabbix tem uma documentação on­line 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 e­mails 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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 15
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, mostrandocomo 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 e­mail é  a maneira mais tradicional de todas. Para 
caso de estudos precisamos configurar o Evolution, cliente de e­mail padrão do Gnome. Abra o 
Evolution pelo menu principal do Gnome e siga os passos descritos a seguir.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 16
2.2.1. Configurando o cliente de correio eletrônico
Esta é apenas um tela de boas vindas, clique em Avançar.
Figura 2.1: Configuração do evolution (1/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 17
Não há nada para ser restaurado, clique novamente em Avançar.
Figura 2.2: Configuração do evolution (2/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 18
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 e­mail: sysadmin@curso468.4linux.com.br.
Figura 2.3: Configuração do evolution (3/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 19
 3)  Tipo de Servidor: devemos escolher POP, que é o recurso implantado para recepção 
de e­mails no cenário.
 4)  Servidor: é o endereço externo do servidor de e­mail.
 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.
Figura 2.4: Configuração do evolution (4/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 20
Nesta tela, configure o recebimento automático a cada 1 minuto, assim não precisamos 
ficar esperando e­mails chegarem e, também não precisamos ficar clicando em Enviar/Receber a 
todo momento.
Figura 2.5: Configuração do evolution (5/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 21
Apesar de não utilizar o envio de e­mail sob o ponto de vista do usuário, é interessante 
configurar o SMTP para averiguar se os e­mails estão caminhando dentro do cenário. 
 1)  No Tipo de Servidor escolha SMTP.
 2)  No Servidor coloque o mesmo endereço de e­mail que colocamos no POP3.
Não reproduza este comportamento de aceite de e­mails 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 e­mail.
Figura 2.6: Configuração do evolution (6/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 22
 1)  Nome:  Por  final,   configure  um nome para  esta  conta.   Isto  é  usado  apenas  para 
exibição no Evolution.
Figura 2.7: Configuração do evolution (7/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 23
Esta é apenas uma tela de finalização, clique em Aplicar.
Torne o Evolution o seu cliente de e­mail padrão.
Figura 2.9: Configuração do evolution (9/10)
Figura 2.8: Configuração do evolution (8/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 24
Na primeira vez que você  entrar ele  irá  pedir a senha (123456) do usuário, digite­a e 
verifique se não houve nenhum erro. Não há nenhum e­mail 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.10: Configuração do evolution (10/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 25
Na tela de boas vindas clique em Adicionar.
Figura 2.12: Configurando uma conta Jabber no Pidgin
Figura 2.11: Tela de boas vindas do Pidgin
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 26
 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.
 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.
Figura 2.13: Definindo o uso de criptografia
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 27
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/zabbix­1.8.4.tar.gz 
# tar xf zabbix­1.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 mostroumais 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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 28
2.4.1. Instalação
Para instalar a versão do repositório do PostgreSQL:
# aptitude install postgresql­8.4
# yum install postgresql84­server
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=# 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 29
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 ponto­e­ví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
Digite­a 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: DHE­RSA­AES256­SHA, bits: 256)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 30
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/zabbix­1.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
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 31
$ 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 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 32
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  build­essential  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 build­essential make
# cd /usr/src/zabbix­1.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 manuaisserã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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 33
Opção do configure Descrição
--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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 34
Opção do configure Descrição
--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/zabbix­1.8.4 –mandir=/usr/share/man ­­enable­server ­­disable­static 
­­disable­proxy ­­enable­agent ­­enable­ipv6 ­­with­pgsql ­­with­jabber ­­with­libcurl ­­with­net­
snmp ­­with­ssh2 ­­without­openipmi ­­with­ldap
Erro Dependência
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 35
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 ­fomit­frame­pointer.  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/zabbix­1.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 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 36
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/zabbix­1.8.4/sbin/zabbix_agent
# rm /usr/share/man/man1/zabbix_agent.1*
# strip ­­strip­all /opt/zabbix­1.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
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 37
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
…
zabbix­agent     10050/tcp Zabbix Agent
zabbix­agent     10050/udp Zabbix Agent
zabbix­trapper   10051/tcp Zabbix Trapper
zabbix­trapper   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 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 38
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/config­server.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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 39
# cd /
# tar xf /tmp/config­server.tar.bz2 
# tar xf /tmp/config­agent.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/zabbix­path.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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 40
# 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
…
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 41
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/server­bootscripts.tar.bz2”  e   “boot/debian/agent­bootscripts.tar.bz2”  para  o  “/tmp”  e 
descompacte­os na raiz.
# cd /
# tar xvf /tmp/server­bootscripts.tar.bz2 
# tar xvf /tmp/agent­bootscripts.tar.bz2
Teste a instalação dos scripts.
# /etc/init.d/zabbix­server start
# /etc/init.d/zabbix­agent start
Por fim, coloque os scriptsno boot da máquina virtual.
# update­rc.d zabbix­agent defaults
# update­rc.d zabbix­server 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 “­­enable­server” 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. 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 42
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 #
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 43
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/zabbix­agent restart
Stopping Zabbix agent daemon: zabbix_agentd
Starting Zabbix agent daemon: zabbix_agentd
# netstat ­lntp | grep zabbix
tcp  0 0 172.27.0.1:10050  0.0.0.0:*  OUÇA  654/zabbix_agentd
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 2011­01­30 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
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 44
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
# iptables­save > /etc/iptables/rules
Repetindo o “nmap” a partir do servidor do Zabbix:
# nmap ­P0 ­p 10050 gateway
Starting Nmap 5.00 ( http://nmap.org ) at 2011­01­30 02:34 BRST
Interesting ports on gateway.curso468.4linux.com.br (172.27.0.1):
PORT      STATE SERVICE
10050/tcp open  unknown
MAC Address: 08:00:27:BD:55:12 (Cadmus Computer Systems)
Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds
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.
# zabbix_get ­s gateway ­k 'agent.ping'
   ←
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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 45
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 
…
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 46
 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.
# zabbix_get ­s gateway ­k 'agent.ping'
1   ←
Se o comando resultante retornou 1 então o servidor poderá acessar o agentea 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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 47
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.14: Baixando o agente do Zabbix no Windows
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 48
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/agent­win­
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.
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.15: Instalando os executáveis no Windows
Figura 2.16: Diretório de configuração do Zabbix no Windows
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 49
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.17: Configurando o agente no Windows
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 50
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.18: Desbloqueando o agente no Windows
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 51
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”).
Certifique­se 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.
Figura 2.19: O agente do Zabbix sendo executado como serviço automático.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 52
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/zapcat­1.2/zapcat­1.2.zip  
# unzip zapcat­1.2.zip
# cd zapcat­1.2
# ls
bin  build.xml  COPYING  lib  openfire  README  samples  src  templates  webapp  zapcat­
1.2.jar  zapcat­1.2.war  zapcat­openfire­1.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/. 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 53
# cp zapcat­1.2.war /opt/jboss/server/application/deploy/
# tail /opt/jboss/server/application/log/server.log
…
2011­01­30 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
2011­01­30 06:10:25,679 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, 
ctxPath=/zapcat­1.2, warUrl=.../tmp/deploy/tmp3690979215130123277zapcat­1.2­exp.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 172.27.0.20:10050  0.0.0.0:*  OUÇA 28751/zabbix_agentd
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”
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 54
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/zapcat­1.2/, a tela abaixo deve aparecer.
No próximo capítulo voltaremos a este acesso. Por hora já basta verificar se o Zapcat esta 
funcionando.
Figura 2.20: Tela de entrada do Zapcat
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 55
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
# iptables­save > /etc/iptables/rules
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 snmp­mibs­downloader
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
IF­MIB::ifIndex.1 = INTEGER: 1
IF­MIB::ifIndex.2 = INTEGER: 2
IF­MIB::ifIndex.3 = INTEGER: 3
IF­MIB::ifIndex.4 = INTEGER: 4
IF­MIB::ifIndex.5 = INTEGER: 5
IF­MIB::ifIndex.6 = INTEGER: 6
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 56
IF­MIB::ifDescr.1 = STRING: lo
IF­MIB::ifDescr.2 = STRING: eth0
IF­MIB::ifDescr.3 = STRING: eth1
IF­MIB::ifDescr.4 = STRING: eth2
IF­MIB::ifDescr.5 = STRING: eth3
IF­MIB::ifDescr.6 = STRING: switch0
…
IF­MIB::ifSpecific.1 = OID: SNMPv2­SMI::zeroDotZero
IF­MIB::ifSpecific.2 = OID: SNMPv2­SMI::zeroDotZero
IF­MIB::ifSpecific.3 = OID: SNMPv2­SMI::zeroDotZero
IF­MIB::ifSpecific.4 = OID: SNMPv2­SMI::zeroDotZero
IF­MIB::ifSpecific.5 = OID: SNMPv2­SMI::zeroDotZero
IF­MIB::ifSpecific.6 = OID: SNMPv2­SMI::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 copie­o 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  DISMAN­EVENT­MIB::sysUpTimeInstance   ou   por   uma   representação   numérica   como   .
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 57
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 passou­se 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 zabbix­server­pgsql
# aptitude install zabbix­agent
O CentOS não tem pacotes no seu repositório.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 58
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 libapache2­mod­php5 php5­gd php5­pgsql php5­ldap
No centOS, use o seguinte comando. 
# yum install php http php­gd php­pgsql php­ldap
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/zabbix­1.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.www­data frontend ­R
# chmod 0770 frontend/conf
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 59
O  último   comandodá   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/sites­available
# vim zabbix­front 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}/error­zabbix­frontend.log 
18 
19         # Possible values include: debug, info, notice, warn, error, crit,
20         # alert, emerg.
21         LogLevel warn
22 
23         CustomLog ${APACHE_LOG_DIR}/access­zabbix­frontend.log combined 
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 60
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/sites­enabled
# rm 000­default
# ln ­sv ../sites­available/zabbix­front end 000­zabbix­front 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
# iptables ­A INPUT ­j ACCEPT ­p tcp ­­dport 80
# iptables­save > /etc/iptables/rules
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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 61
2.11.3. Configurando o front end
A primeira tela é apenas uma mensagem de boas vindas. Clique em “Next” para começar.
Figura 2.21: Configuração do front end (1/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 62
Marque a opção “I agree” para concordar com a licença do Zabbix e clique em “Next”.
Figura 2.22: Configuração do front end (2/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 63
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
Figura 2.23: Configuração do front end (3/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 64
Procure   com  o   apoio   da   tabela   abaixo   e   da   tela   de   configuração   todas   as   opções 
relevantes e configure­as 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.
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 65
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. 
Figura 2.24: Configuração do front end (4/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 66
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.
Figura 2.25: Configuração do front end (5/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 67
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”.
Figura 2.26: Configuração do front end (6/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 68
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.
Figura 2.27: Configuração do front end (7/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 69
Repasse as configurações nesta tela e clique em “Next” se tudo estiver OK.
Figura 2.28: Configuração do front end (8/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 70
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 rootwww­data 4,0K Jan 27 22:58 conf
# chmod 0750 conf
# ls ­lh conf
total 28K
…
­rw­r­­r­­ 1 www­data www­data  440 Jan 27 22:58 zabbix.conf.php
…
# chown root.www­data conf/zabbix.conf.php
# chmod 0640 conf/zabbix.conf.php
Figura 2.29: Configuração do front end (9/10)
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 71
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.30: Configuração do front end (10/10)
Figura 2.31: Tela inicial do Zabbix após o primeiro login
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 72
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: _________________________________________
Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 73
 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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 75
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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 76
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 
Top 100
Os 100 triggers mais ativos no sistema.
• 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çãode 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   e­mail   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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 77
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 (e­mails, SMS, etc.)
• Scripts Gerenciamento de scripts para testes on­line 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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 78
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 on­line no “front end”. 
Para editar o Admin clique sobre o link com o nome dele. Uma nova tela ira aparecer.
Figura 3.1: Gerenciamento de usuários do Zabbix
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 79
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 “Auto­logout”. Depois de terminar clique no botão 
“Save”. Isso é apenas um salva­guarda 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  “auto­logout”  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.
Figura 3.2: Editando o Admin
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 80
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.
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.
Figura 3.3: Configurando a autenticação LDAP
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 81
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 
sistemas UNIX
Network Administrators, UNIX 
Administrators, Web Administrators
winadmin Administrador de 
sistemas Windows
Network Administrators, Windows 
Administrators
javaeng Administrador do 
JBoss AS
JBoss Administratros
dba Administrador do 
banco de dados
Database Administrators
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
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 82
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. 
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.
Figura 3.5: Novo usuário Sysadmin
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 83
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 aousuá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 e­mail 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 e­mail 
para ajudar na redundância do serviço de alerta ou dedicar determinados tipos de e­mails para 
diferentes servidores.
Figura 3.6: Media Types
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 84
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 e­mail,  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 e­mails (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 e­mail é o endereço de 
remetente que o Zabbix usará para enviar a mensagem.
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.7: Configurando o Zabbix para enviar e-mails
Figura 3.8: Configurando o Zabbix para enviar mensagens instantâneas
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 85
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”. 
Clique em “Add” para adicionar um novo meio de alerta ao usuário. Vamos começar pelo 
e­mail.
Coloque o e­mail 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. 
Figura 3.9: Media Types de um usuário sem apontamentos
Figura 3.10: Adicionando o Media Type Email a um usuário
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 86
A sintaxe do “When Active” usa 1 como segunda e 7 como domingo, definir por exemplo 
segunda a sexta ficaria “1­5”. Uma vírgula separa o dia do horário, segunda a sexta das 09:00 até 
as 18:00 ficaria “1­5,09:00­18:00”. Podemos ainda usar o ponto­e­ví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 “1­5,09:00­
18:00;6,09:00­13: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.
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á.
Salve e repita para todos os usuários agora.
Figura 3.11: Adicionando um media type Jabber a um 
usuário
Figura 3.12: Media Types de um usuário após o cadastro
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 87
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 e­mail,  dois modems 
SMS, etc.)  ou melhor,  fazendo com que ele seja enviado por várias mídias (SMS, 
Jabber e e­mail, 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 on­line do sistema de mensagens instantâneas. Também 
não adianta enviar um e­mail de desastre as três da madrugada quando ninguém esta 
olhando e­mails.
 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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 88
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, enquantonã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). 
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.13: Selecionando todos os templates pré 
cadastrados
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 89
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. 
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.
 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.
Figura 3.14: Excluindo os templates selecionados
Figura 3.16: Cadastrando um novo template
Figura 3.15: Criando um novo 
template
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 90
 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”. 
 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”.
Figura 3.17: Vinculando um template a outro
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 91
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.
 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 salve­o. 
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.18: Exportando um template
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 92
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.19: Layout dos hosts a serem monitorados
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 93
A seguinte tela irá surgir.
 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.
Para  criar  um novo host  para  o   “host  Presentation”  da   infraestrutura  clique  no  botão 
“Create Host” (Figura 3.23). 
E preencha os dados conforme a figura a seguir.
Figura 3.22: Host pré-cadastrado no front end na tela de Hosts
Figura 3.20: Como criar um novo grupo 
de hosts
Figura 3.23: Botão para criar um host
Figura 3.21: Novo host group
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 94
 1)  O campo Name coloque o nome do host (Presentation no nosso caso).
 2)  No  Groups  escolha quais grupos este host  deve pertencer.  Lembre­se 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 sejanecessá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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 95
Crie todos os hosts do cenário conforme indicado na Figura 3.24.
 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.
 1)  Selecione “User groups” se já não estiver nesta opção.
 2)  Clique no nome do grupo “Unix administrators”.
Figura 3.25: Concedendo permissões de acesso (1/4)
Figura 3.24: Todos os hosts do cenário cadastrados
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 96
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 “Read­Write”.
Figura 3.26: Concedendo permissões de acesso (2/4)
Figura 3.27: Concedendo permissões de acesso (3/4)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 97
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. 
Figura 3.28: Concedendo permissões de acesso (4/4)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 98
Usuário Applica-
tion
Databa-
se 
JBoss AS Presen-
tation
Switch Windows
2003
Zabbix 
server
suporte read only read only read only read only read only read only read only
sysadmin read-
write
read-
write
read only read-
write
read-
write
read only read-
write
winadmin read only read only read only read only read-
write
read-
write
read only
dba read only read-
write
read only read only read only read only read only
javaeng read only read only read-
write
read only read only read only read only
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.   Acesse­o   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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 99
Acesse o menu Administration   → General, e escolha na caixa de opções a esquerda. A 
opção “Images”.
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.
 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.
Figura 3.30: Importando uma nova imagem
Figura 3.29: Tela inicial das imagens
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 100
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
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 101
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.
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.
 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.
Figura 3.32: Mapas pré-cadastrados
Figura 3.33: Novo mapa
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 102
 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 possuirum “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 exibi­lo).
 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.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 103
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.
 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. 
Arraste­o até a parte da tela que você desejar para posicioná­lo.
Figura 3.34: Barra de ferramentas para edição de mapas
Figura 3.35: Criando um novo 
elemento
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 104
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.36: Posicionando um novo elemento com o mouse
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 105
 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”. 
Figura 3.37: Editando um elemento na tela
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 106
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).
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.
3.5.6. Adicionando os outros elementos
Agora adicione mais dois elementos no mapa para representar os hosts “Presentation” e 
“Switch” e posicione­os como na Figura 3.40.
Figura 3.39: Dialogo de salvar mapa
Figura 3.38: 
Botão Save do 
mapa.
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 107
Clique no elemento do meio para editá­lo conforme abaixo, ele servirá de representação 
para o host “Presentation” agora.
Figura 3.40: Outros elementos 
gráficos a serem adicionados
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 108
 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.
Figura 3.41: Editando o elemento que representa o host Presentation
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 109
 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.
Como resultado final uma imagem parecida com a Figura 3.43 deve estar no meio de sua 
área de mapa.
Figura 3.42: Detalhes do host switch dentro do mapa
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 110
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.
Figura 3.43: Hosts 
acrescentados no mapa
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 111
3.5.8. Prática Dirigida
 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.44: Criando um novo link entre o host Presentation e a imagem Internet
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 112
 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.45: Editando as propriedades do novo link
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 113
.
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 exportando­o 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.46: Link entre o host Presentation e o Switch
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 114
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.
 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”.
Figura 3.47: Mapa final
Figura 3.48: Templates e seus elementos
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 115
 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. 
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”.
Figura 3.50: Criando um application (2/4)
Figura 3.51: Criando um application (3/4)
Figura 3.49: Criando um application (1/4)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 116
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).
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.52: Criando um application (4/4)
Figura 3.53: 
Criando seu 
primeiro item 
(1/3)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 117
 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   criarum   “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.
Figura 3.54: Criando seu primeiro item (2/3)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 118
 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 “ipses­literis” 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.
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.
Figura 3.55: Criando seu primeiro item (3/3)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 119
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”.
Clique no botão “Add” para abrir a tela de templates.
Na janela de dialogo que aparecer selecione “4Linux – ICMP” e clique em “Select”. Você 
pode escolher tantos templates quanto precisar nesta tela.
A Figura 3.58 mostra como a tela ficará. Ela indica que o novo template é vinculado ao 
“4Linux – ICMP”. Finalmente salve o template.
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 associe­os 
conforme a estrutura de árvore indicada:
Figura 3.56: Campo para associação de 
templates
Figura 3.57: Tela para escolha de templates
Figura 3.58: Template associado
Figura 3.59: Template associado na lista de templates
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 120
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.
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.61: Associando o template do JBoss ao host JBoss AS (1/6)
Figura 3.62: Associando o template do JBoss ao host JBoss AS (2/6)
Figura 3.60: Inter-relação dos templates base
Figura 3.63: Associando o template do JBoss ao host JBoss AS 
(3/6)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 121
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.
Para finalizar clique em “Save”.
Note que o template escolhido e suas dependências, entre parênteses, serão exibidas na 
Lista de templates.
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.65: Associando templates a hosts 
(5/11)
Figura 3.67: Templates para Windows e SNMP associados aos seus respectivos hosts
Figura 3.64: Associando o template do JBoss ao host JBoss AS (4/6)
Figura 3.66: Associando o template do JBoss ao host JBoss AS (6/6)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 122
 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.
 1)  Marque a opção “Link addictional templates”;
 2)  Clique em “Add”. Nossa velha tela de templates irá surgir.
Figura 3.68: Associando um 
template a múltiplos hosts 
simultaneamente (1/4)
Figura 3.69: Associando um template a múltiplos 
hosts simultaneamente (2/4)
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 123
Marque “4Linux – S.O. Linux” e clique em “Select”.
Note que o template  ficará   logo acima dos botões de adicionar e remover. Clique em 
“Save” para finalizar.
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.70: Associando um template a múltiplos hosts 
simultaneamente (3/4)
Figura 3.71: Associando um template a múltiplos hosts simultaneamente (4/4)
Figura 3.72: Todos os templates associados aos hostsdo cenário
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 124
Vá em Configuration   Hosts→  e clique sobre o link “Not monitored” conforme a Figura 
3.73 indica.
Um dialogo irá surgir perguntando se o host deve ser mesmo ativado. Confirme clicando 
em “OK”.
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.73: Host presentation não monitorado
Figura 3.74: Dialogo de confirmação de ativação
Figura 3.75: Host presentation monitorado
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 125
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
  2504:20110201:202020.147 server #4 started [Poller. SNMP:YES]
  2502:20110201:202020.150 server #2 started [Poller. SNMP:YES]
  2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]
  2503:20110201:202020.242 server #3 started [Poller. SNMP:YES]
  2505:20110201:202020.293 server #5 started [Poller. 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”).
Figura 3.76: Item não suportado
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 126
# tail /var/log/zabbix/zabbix_server.log 
  2506:20110201:202020.097 server #6 started [Poller. SNMP:YES]
  2511:20110201:202020.108 Deleted 0 records from history and trends
  2504:20110201:202020.147 server #4 started [Poller. SNMP:YES]
  2502:20110201:202020.150 server #2 started [Poller. SNMP:YES]
  2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]
  2503:20110201:202020.242 server #3 started [Poller. SNMP:YES]
  2505:20110201:202020.293 server #5 started [Poller. SNMP:YES]
  2509:20110201:202023.022 /usr/sbin/fping: [2] No such file or directory
  2509:20110201:202923.237 /usr/sbin/fping: [2] No such file or directory
  2509:20110201:203002.281 /usr/sbin/fping: [2] No such file or directory
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 
Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 127
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/zabbix­server 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.
Capítulo 4 Monitoramento voltado para disponibilidade - 129
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 130
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”.
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.2: Saída de um comando ping
Figura 4.1: Menu de 
Ferramentas acessado pelo 
mapa
Capítulo 4 Monitoramento voltado para disponibilidade - 131
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.
Figura 4.3: Saída de um comando que falhou do traceroute
Capítulo 4 Monitoramento voltado para disponibilidade - 132
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 133
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
Capítulo 4 Monitoramento voltado para disponibilidade - 134
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 135
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.4: Saída do traceroute adequando a nova necessidade 
Capítulo 4 Monitoramentovoltado para disponibilidade - 136
Clique sobre o botão “Create script” conforme a Figura 4.5 para acessar a tela de criação 
de comandos.
 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”.
Figura 4.5: Criando um novo script para testar portas SSH (1/2)
Figura 4.6: Criando um novo script para testar portas SSH (2/2)
Capítulo 4 Monitoramento voltado para disponibilidade - 137
 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.
A Figura 4.7 demonstra como o “popup” será mostrado. Clique sobre o novo scipt “SSH” 
para executá­lo.
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.
Figura 4.8: Resultado do comando ativado no host
Figura 4.7: Nova entrada de 
menu com o script criado
Capítulo 4 Monitoramento voltado para disponibilidade - 138
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). 
Capítulo 4 Monitoramento voltado para disponibilidade - 139
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).
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
  1.000731  172.27.0.10 ­> 172.27.0.1   ICMP Echo (ping) request
  1.001954   172.27.0.1 ­> 172.27.0.10  ICMP Echo (ping) reply
  2.000778  172.27.0.10 ­> 172.27.0.1   ICMP Echo (ping) request
  2.001882   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 exibi­la.
Figura 4.9: Diagrama de comportamento do echo 
ICMP
Capítulo 4 Monitoramento voltado para disponibilidade - 140
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.
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”.
 1)  Name:  Aqui  é  definido o nome do novo conjunto de valores, vamos mudá­lo para 
“Estado”. 
Figura 4.10: Hosts ativos com ping ICMP em funcionamento
Figura 4.11: Um value maps de 
estado de serviços
Figura 4.12: Editando o value map para nossa necessidade
Capítulo 4 Monitoramento voltado para disponibilidade - 141
 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.
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”.
Procure o comando “Show value” conforme indicado na Figura  4.14 e escolha a opção 
“Estado”. Salve o item e volte ao “Overview”.
Note que agora todasas 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 e­mail/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 
Figura 4.13: Value map editado e 
pronto para uso
Figura 4.15: Values maps no overview
Figura 4.14: Selecionando um value map no trigger
Capítulo 4 Monitoramento voltado para disponibilidade - 142
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).
Depois de alguns segundos (dez para ser mais exato) o “Overview” vai  indicar que o 
“Database” esta parado.
 1)  Caso deseje pode­se 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.
Figura 4.16: Pausando o host Database
Figura 4.17: Host database parado no overview
Capítulo 4 Monitoramento voltado para disponibilidade - 143
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”.
Edite os “triggers” do template conforme mostrado na Figura 4.18 .
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  e­mails,  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.
Figura 4.18: Criando um trigger para a parada do host (1/9)
Figura 4.19: Criando um trigger para a parada do host 
(2/9)
Figura 4.20: Criando um trigger para a parada do host (3/9)
Figura 4.21: Criando um trigger para a parada do host (4/9)
Capítulo 4 Monitoramento voltado para disponibilidade - 144
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”.
Figura 4.22: Criando um trigger para a parada do host (5/9)
Figura 4.23: Criando um trigger para a parada do host (6/9)
Capítulo 4 Monitoramento voltado para disponibilidade - 145
É   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.
Figura 4.24: Criando um trigger para a parada do host (7/9)
Figura 4.25: Criando um trigger para a parada do host (8/9)
Capítulo 4 Monitoramento voltado para disponibilidade - 146
 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. 
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.26: Criando um trigger para a parada do host (9/9)
Figura 4.27: Indicação de problemas no Dashboard
Capítulo 4 Monitoramento voltado para disponibilidade - 147
O Mapa também deve estar mostrando o statusdo “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.28: Overview com indicação dos items com 
alerta
Figura 4.29: Overview com visualização dos triggers 
ativos
Capítulo 4 Monitoramento voltado para disponibilidade - 148
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.
 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.
Figura 4.30: Mapa indicando o host Database como down
Figura 4.31: Tela de Events, indicando a queda e o retorno dos hosts
Capítulo 4 Monitoramento voltado para disponibilidade - 149
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”.
Na tela que surgir preencha o quadro de texto e clique em “Acknowledge & Return”. 
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. 
Figura 4.32: Tela de acknowledgement
Figura 4.33: Acknowledge (confirmação) aplicado
Capítulo 4 Monitoramento voltado para disponibilidade - 150
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.
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.34: Criando uma action para enviar o alerta 
(1/9)
Figura 4.35: Criando uma action para enviar o alerta (2/9)
Capítulo 4 Monitoramento voltado para disponibilidade - 151
 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   e­mail   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, deixe­os 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.36: Criando uma action para enviar o alerta (3/9)
Figura 4.37: Criando uma action para enviar o alerta (4/9)
Figura 4.38: Criando uma action para enviar o alerta (5/9)
Capítulo 4 Monitoramento voltado para disponibilidade - 152
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. Pode­se 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.
Após isso clique em “Save”  no quadro principal.
Figura 4.40: Criando uma action para enviar o alerta (7/9)
Figura 4.41: Criando uma action para enviar o alerta 
(8/9)
Figura 4.39: 
Criando uma 
action para enviar 
o alerta (6/9)
Capítulo 4 Monitoramento voltado para disponibilidade - 153
Chegou   o  momento   de   testar   nossa   “action”.   Pause   por   alguns  minutos   a  máquina 
“Database”   e   volte   ela   ao   normal.  Nesse   ínterim,   consulte   os   e­mails   no   “Evolution”  e   as 
mensagens no “Pidgin”.
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 on­line 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.42: Criando uma action para enviar o alerta (9/9)
Figura 4.43: Mensagens de alerta recebidas no Evolution
Capítulo 4 Monitoramento voltado para disponibilidade - 154
4.3.7. Boas práticas com triggers
Se você fez o último exercício, deve ter percebidoque 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.44: Reiniciando o host Database
Capítulo 4 Monitoramento voltado para disponibilidade - 155
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.
Figura 4.45: Lógica de um gatilho com tempo de segurança
Capítulo 4 Monitoramento voltado para disponibilidade - 156
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 157
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
Running as user "root" and group "root". This could be dangerous.
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
Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­09 17:08 BRST
Interesting ports on application.curso468.4linux.com.br (172.27.0.20):
PORT     STATE SERVICE
8080/tcp open  http­proxy
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
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”.
# tshark ­ni eth0 host 172.27.0.10 and port 8080
Running as user "root" and group "root". This could be dangerous.
1 O SYN Scan é um método considerado furtivo antigamente. Ele fazia apenas metade dos passos para abertura 
de uma conexão.
Capítulo 4 Monitoramento voltado para disponibilidade - 158
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.
# iptables ­A INPUT ­j ACCEPT ­p tcp ­­dport 10000
# tshark ­ni eth0 host 172.27.0.10 and port 10000
Running as user "root" and group "root". This could be dangerous.
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
Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­09 17:13 BRST
Interesting ports on application.curso468.4linux.com.br (172.27.0.20):
PORT      STATE  SERVICE
10000/tcpclosed snet­sensor­mgmt
Capítulo 4 Monitoramento voltado para disponibilidade - 159
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
Note o estado “closed” da saída do “nmap”! Vá até o “tshark” do “Application” e veja o 
trafego dos pacotes capturado.
# tshark ­ni eth0 host 172.27.0.10 and port 10000
Running as user "root" and group "root". This could be dangerous.
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”. 
Capítulo 4 Monitoramento voltado para disponibilidade - 160
# 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 
Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­09 14:04 BRST
Interesting ports on application.curso468.4linux.com.br (172.27.0.20):
PORT   STATE    SERVICE
22/tcp filtered ssh
MAC Address: 08:00:27:4B:97:E3 (Cadmus Computer Systems)
Interesting ports on gateway.curso468.4linux.com.br (172.27.0.1):
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 08:00:27:BD:55:12 (Cadmus Computer Systems)
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 
­­enable­libssh).
Capítulo 4 Monitoramento voltado para disponibilidade - 161
 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.46: Simple check para o SSH
Capítulo 4 Monitoramento voltado para disponibilidade - 162
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.
Figura 4.47: Overview exibindo os serviços de SSH
Capítulo 4 Monitoramento voltado para disponibilidade - 163
Serviços Porta Host Template Key
OpenSSH 22/TCP Todos os Linux S.O. Linux ssh
Varnish (HTTP 
cacher)
80/TCP Presentation Varnish http
Apache (proxy) 8080/TCP Presentation Apache http
JBoss 
(Aplicativo)
8009/TCP (AJP) Application JBoss base tcp,8009
8080/TCP 
(HTTP)
http,8080
Apache 
(Aplicativo)
80/TCP Application Apache http
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 (­­enable­curl).
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 
Capítulo 4 Monitoramento voltado para disponibilidade - 164
“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 on­line 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:
 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.
Cliquesobre “Create scenario”, uma nova janela de cadastro irá surgir.
Figura 4.48: Criando um cenário para disponibilidade 
Web (1/6)
Figura 4.49: Criando um cenário para disponibilidade 
Web (2/6)
Capítulo 4 Monitoramento voltado para disponibilidade - 165
 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 
defini­la 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.
Figura 4.50: Criando um cenário para disponibilidade Web (3/6)
Capítulo 4 Monitoramento voltado para disponibilidade - 166
 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. 
Figura 4.51: Criando um cenário para disponibilidade Web (4/6)
Capítulo 4 Monitoramento voltado para disponibilidade - 167
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.
Clique sobre o nome do cenário e note que ele esta sendo organizado pela “application” 
escolhida quando o cadastramos.
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.55: Detalhes do monitoramento Web
Figura 4.53: Criando um cenário para disponibilidade Web (6/6)
Figura 4.52: Criando um cenário para disponibilidade Web (5/6)
Figura 4.54: Visualizando a checagem Web
Capítulo 4 Monitoramento voltado para disponibilidade - 168
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.
Figura 4.57: Gráfico de tempo de resposta para o cenário Web
Figura 4.56: Gráfico de velocidade de download para o cenário Web
Capítulo 4 Monitoramento voltado para disponibilidade - 169
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 170
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.
 1)  Selecione o item dentro da lista
 2)  Escolha “Copy selected to...” na caixa de ações.
 3)  Clique em “Go” (1).
Figura 4.59: Copiando o item de ping de agente para o template do JBoss 
(1/2)
Figura 4.58: Novo item para monitorar o agente
Capítulo 4 Monitoramento voltado para disponibilidade - 171
 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.60: Copiando o item de ping de agente para o template do JBoss (2/2)
Capítulo 4 Monitoramento voltado para disponibilidade - 172
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.
Figura 4.61: Criando um trigger para o agent.ping (1/5)
Figura 4.62: Criando um trigger para o agent.ping (2/5)
Capítulo 4 Monitoramento voltado para disponibilidade - 173
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.63: Criando um trigger para o agent.ping (3/5)
Figura 4.65: Criando um trigger para o agent.ping (5/5)
Figura 4.66: Trigger para o agent ping criado e ativo
Figura 4.64: Criando um trigger para o agent.ping (4/5)
Capítulo 4 Monitoramento voltado para disponibilidade - 174
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/zabbix­agent stop
Vá  até  o “Overview”, selecione “triggers”  no campo  “Type”  e aguarde o ativamento do 
mesmo.
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”.
Perceba   como  ambos   os   “triggers”   de   agente   ficaram   cinzas   enquanto   os   de   ICMP 
alertaram uma queda.
Figura 4.67: Trigger de agente ativado
Figura 4.68: Dependência entre triggers evitando que o gatilho filho 
seja ativado
Capítulo 4 Monitoramento voltado para disponibilidade - 175
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 on­line 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.
Capítulo 4 Monitoramento voltado para disponibilidade - 176
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 “DISMAN­EVENT­MIB::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 DISMAN­EVENT­MIB::sysUpTimeInstance
DISMAN­EVENT­MIB::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 desegundos (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 
Capítulo 4 Monitoramento voltado para disponibilidade - 177
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.
 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.69: Item para tempo de uptime
Capítulo 4 Monitoramento voltado para disponibilidade - 178
 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.
 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 “net­snmp” (­­enable­snmp). Note que os campos abaixo se 
alteram conforme você escolhe outros tipos de valores.
Figura 4.70: Uptime via Zapcat
Figura 4.71: Uptime via SNMP
Capítulo 4 Monitoramento voltado para disponibilidade - 179
 2)  SNMP   OID:   coloque   a   “object   identifier”  da   métrica   desejada   conforme   sua 
necessidade, no nosso caso é “DISMAN­EVENT­MIB::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”.
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é 
Figura 4.72: Overview exibindo os uptimes a partir do agente padrão, Zapcat e SNMP
Capítulo 4 Monitoramento voltado para disponibilidade - 180
impressoras, passando por no­breaks) 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.
 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.
Figura 4.73: Um trigger para a reinicialização de um host
Capítulo 4 Monitoramento voltado para disponibilidade - 181
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, certifique­se 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.
Capítulo 4 Monitoramento voltado para disponibilidade - 182
• 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 nossaprá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”.
Capítulo 4 Monitoramento voltado para disponibilidade - 183
A Figura 4.74 ilustra como o item para contagem de processo deve ser criado, ele é bem 
trivial. 
No “Overview”, já podemos rastrear o funcionamento da contagem de processos. Note 
Figura 4.74: Item para verificação de número de processos
Figura 4.75: Overview refletindo o número de processos
Capítulo 4 Monitoramento voltado para disponibilidade - 184
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”. 
 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.
# /etc/init.d/ssh stop
Acesse a  lista de eventos em  Monitoring   → Events  para acompanhar a ativação do 
Figura 4.76: Trigger para queda do daemon
Capítulo 4 Monitoramento voltado para disponibilidade - 185
“trigger”.
Também olhe no “Overview” como o “trigger” ficou exibido.
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.77: Teste de queda do sshd
Figura 4.78: Reflexo da queda do daemon SSH no overview
Capítulo 4 Monitoramento voltado para disponibilidade - 186
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.79: Item para verificação da porta local
Capítulo 4 Monitoramento voltado para disponibilidade - 187
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. 
Figura 4.80: Fluxograma da dependência entre triggers para 
análise de serviços
Capítulo 4 Monitoramento voltado para disponibilidade - 188
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 vamoscontinuar com nossa prática dirigida e criar os dois “triggers” que faltam, pois 
o primeiro já esta pronto desde o tópico anterior. 
Capítulo 4 Monitoramento voltado para disponibilidade - 189
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.81: Trigger para verificação da porta local
Figura 4.82: Trigger para verificação de porta remota
Capítulo 4 Monitoramento voltado para disponibilidade - 190
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.
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.83: Serviço telnet do Windows
Capítulo 4 Monitoramento voltado para disponibilidade - 191
 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.
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.84: Habilitando o serviço de telnet do Windows
Figura 4.85: Ativando o serviço de telnet
Capítulo 4 Monitoramento voltado para disponibilidade - 192
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, deve­se 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
Figura 4.86: Processo do telnet na memória
Capítulo 4 Monitoramento voltado para disponibilidade - 193
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 194
Clique em “Adicionar  Porta...”  e preencha a  janela que aparecer conforme  indicado a 
seguir.
Figura 4.87: Liberando o telnet no firewall do Windows (1/3)
Figura 4.88: Liberando o telnet no firewall do Windows 
(2/3)
Capítulo 4 Monitoramento voltado para disponibilidade - 195
 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.
Por fim, clique em “OK” novamente. Para averiguar se tudo esta correto faça um teste a 
partir do console do host “Zabbix server”.
Figura 4.89: Liberando o telnet no firewall do Windows (3/3)
Capítulo 4 Monitoramento voltado para disponibilidade - 196
# nmap ­P0 ­p 23 win2003
Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­15 18:39 BRST
Interesting ports on 172.28.0.10:
PORT   STATE SERVICE
23/tcp open  telnet
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
# 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: 
*===============================================================
Bem­vindo 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.
Capítulo 4 Monitoramento voltado para disponibilidade - 197
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.90: item para monitorar serviços Windows
Figura 4.91: Estado do serviço Telnet no Overview
Capítulo 4 Monitoramento voltado para disponibilidade - 198
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
Capítulo 4 Monitoramento voltado para disponibilidade - 199
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
# /etc/init.d/zabbix­agent restart
é  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.
Capítulo 4 Monitoramento voltado para disponibilidade - 200
# 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.
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”. 
Figura 4.92: Action para parada do SSH (1/3)
Figura 4.93: Action para parada do SSH (2/3)
Capítulo 4 Monitoramento voltado para disponibilidade - 201
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”.
 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.
Figura 4.95: Comando remoto para o action de parada do serviço de SSH
Figura 4.94: Action para parada do SSH (3/3)
Capítulo 4 Monitoramento voltado para disponibilidade - 202
# /etc/init.d/ssh stop
# 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”.
Capítulo 4 Monitoramento voltado para disponibilidade - 203
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). 
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).
Figura 4.96: Item para latência de rede
Capítulo 4 Monitoramento voltado para disponibilidade - 204
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   “macrosde 
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.
Capítulo 4 Monitoramento voltado para disponibilidade - 205
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.
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.97: Macro para latência de rede
Figura 4.98: Trigger para latência de rede usando a macro
Capítulo 4 Monitoramento voltado para disponibilidade - 206
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.
 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.
Figura 4.99: Gráfico para medir a latência de rede
Figura 4.100: Criando um gráfico de latência de rede
Capítulo 4 Monitoramento voltado para disponibilidade - 207
 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.
 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.
Figura 4.101: Adicionando métricas ao gráfico
Capítulo 4 Monitoramento voltado para disponibilidade - 208
 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 .
Capítulo 4 Monitoramento voltado para disponibilidade - 209
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
Figura 4.102: Mapa com labels personalizadas exibindo dados
Capítulo 4 Monitoramento voltado para disponibilidade - 210
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   “simplechecks”   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.
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. 
Figura 4.104: Exemplo de gráfico de latência de serviços para exercícios
Capítulo 4 Monitoramento voltado para disponibilidade - 211
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.
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), 
Figura 4.105: Macro para limite de espaço em disco utilizado
Capítulo 4 Monitoramento voltado para disponibilidade - 212
“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”.
 1)  Description: aqui temos uma novidade: uma vez que estamos usando parâmetros na 
key, podemos capturá­los e inseri­los 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.
Figura 4.106: Primeiro item de espaço em disco
Capítulo 4 Monitoramento voltado para disponibilidade - 213
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.
Edite o item de “Espaço total” e clique no botão “Clone”. 
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.107: Items a serem clonados para espaço em disco
Figura 4.108: Botão para clonar items
Capítulo 4 Monitoramento voltado para disponibilidade - 214
Para gerar um gráfico como esse siga os passos a seguir.
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. Pode­se  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.
Figura 4.109: Gráfico de pizza para exibição de espaço 
livre e ocupado
Figura 4.110: Criando um gráfico de pizza
Capítulo 4 Monitoramento voltado para disponibilidade - 215
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.
Crie um gráfico como antes, mas atente para o detalhes em destaque abaixo.
Figura 4.111: Gráfico de histórico de espaço em disco
Figura 4.112: Criando o gráfico de histórico de uso de disco
Capítulo 4 Monitoramento voltado para disponibilidade - 216
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áficoficará 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ógico­matemá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.
Capítulo 4 Monitoramento voltado para disponibilidade - 217
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 apague­o 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.
Figura 4.113: Trigger para cálculo de espaço em disco
Capítulo 4 Monitoramento voltado para disponibilidade - 218
 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 
Capítulo 4 Monitoramento voltado para disponibilidade - 219
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
Digite­a 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
Capítulo 4 Monitoramento voltado para disponibilidade - 220
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
Capítulo 4 Monitoramento voltado para disponibilidade - 221
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
Capítulo 4 Monitoramento voltado para disponibilidade - 222
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
# /etc/init.d/zabbix­agent restart
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. 
Verifique se no “Overview” os dados estão sendo recebidos.
Figura 4.114: Trocando o template do host database para o PostgreSQL
Capítulo 4 Monitoramento voltado para disponibilidade - 223
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 }
Figura 4.115: Disponibilidade do PostgreSQL ativa no database
Capítulo 4 Monitoramento voltado para disponibilidade - 224
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
Capítulo 4 Monitoramento voltado para disponibilidade - 225
 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 deixe­os 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).
Capítulo 4 Monitoramento voltado para disponibilidade - 226
Abra o link e edite os valores de seus campos como a seguir.
 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
Figura 4.116: Latência sendo 
exibida no label do link
Figura 4.117: Latência de rede e trigger associados ao link com a Internet no mapa
Capítulo 4 Monitoramento voltado para disponibilidade - 227
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 processamentonã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, concentre­se apenas nos de longa duração.
 - 231
 1.2)  Se você criar gatilhos de verificação de CPU, faça­os 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)  Lembre­se 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 vice­versa, 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.
	Capítulo 1 
Conhecendo o Zabbix
	1.1. Conhecendo a ferramenta
	1.2. Comunidades e forums
	Capítulo 2 
Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema
	2.1. Introdução
	2.2. Configurando os componentes de recebimento de alertas
	2.2.1. Configurando o cliente de correio eletrônico
	2.2.2. Mensagens instantâneas
	2.3. Obtendo os fontes do Zabbix
	2.4. Preparando o banco de dados
	2.4.1. Instalação
	2.4.2. Criando o usuário e o banco
	2.4.3. Carga inicial
	2.4.4. Concedendoas permissões necessárias ao usuário
	2.5. Instalação do servidor Zabbix via código fonte
	2.5.1. Dependências de compilação.
	2.5.2. Compilando e instalando
	2.5.3. Serviços de rede
	2.5.4. Arquivos de configuração
	2.5.5. Testando sua instalação
	2.5.6. Scripts de boot
	2.6. Instalação do agente Zabbix via compilação
	2.6.1. Exercício: compile e instale o agente nas VM com Gnu/Linux
	2.6.2. Acesso ao agente pelo servidor
	2.6.3. Exercício sobre instalação de agente em Linux
	2.7. Instalando o agente em ambientes Windows
	2.7.1. Executando o agente como serviço
	2.8. Instalação do agente Zapcat para JBoss
	2.8.1. Obtenção do binário
	2.8.2. Deployment
	2.8.3. Opções de inicialização do JBoss
	2.8.4. Liberando o firewall para acesso ao Zapcat
	2.9. Testando o acesso via SNMP
	2.9.1. Conceitos de SNMP
	2.10. Instalando o servidor Zabbix via pacote
	2.11. Preparando o servidor web
	2.11.1. Instalação do Apache e PHP5
	2.11.2. Configuração do Virtual Host
	2.11.3. Configurando o front end
	2.12. Exercícios de revisão
	Capítulo 3 
Criando uma Infraestrutura de Monitoramento - Parte 2, Front end
	3.1. Introdução
	3.1.1. Organização do front end
	3.2. Gerenciamento de usuários
	3.2.1. Cadastrando os usuários do LDAP no Zabbix
	3.3. Meios de alertas
	3.3.1. Correio eletrônico
	3.3.2. Mensagens instantâneas
	3.3.3. Apontando os alertas aos usuários
	3.3.4. Boas práticas com Media types
	3.4. Hosts, host groups e templates
	3.4.1. Templates para o caso de estudo
	3.4.2. Vínculo entre templates
	3.4.3. Backup dos templates
	3.4.4. Hosts
	3.4.5. Gerenciando os Host Groups
	3.4.6. Criando um novo host
	3.4.7. Fazendo backup dos hosts
	3.4.8. Configurando uma permissão de acesso
	3.4.9. Exercícios sobre usuários, hosts, grupos e permissões.
	3.5. Mapas
	3.5.1. Importando imagens para o mapa
	3.5.2. Criando um mapa
	3.5.3. Adicionando um elemento
	3.5.4. Editando um elemento do mapa
	3.5.5. Salvando o mapa
	3.5.6. Adicionando os outros elementos
	3.5.7. Criando e editando links
	3.5.8. Prática Dirigida
	3.5.9. Exercícios sobre Mapas
	3.6. Templates, applications e items
	3.6.1. Criando um Application e um Item dentro de um template
	3.6.2. Interdependência de templates
	3.7. Associando os templates aos hosts
	3.8. Ativando um host
	3.8.1. Throubleshooting para itens com problemas
	Capítulo 4 
Monitoramento voltado para disponibilidade
	4.1. Introdução
	4.2. Checagens manual via front end
	4.2.1. Adequando o script de traceroute
	4.2.2. Criando novos comandos para o menu
	4.2.3. Exercícios
	4.3. Checando disponibilidade via protocolo ICMP
	4.3.1. Como funciona o ping ICMP
	4.3.2. Visualizando o ping ICMP no Front end
	4.3.3. Criando um gatilho de parada de host
	4.3.4. Lidando com os eventos
	4.3.5. Criando uma action para envio de alerta
	4.3.6. Exercícios
	4.3.7. Boas práticas com triggers
	4.4. Checagem genérica de portas e serviços
	4.4.1. Conexões TCP e handshakes
	4.4.2. Criando um teste de serviço via varredura de portas
	4.4.3. Exercício sobre checagem de portas
	4.5. Validação de páginas WEB
	4.5.1. Disponibilidade do site.
	4.5.2. Exercícios
	4.6. Checando disponibilidade via agentes
	4.6.1. Checando se o agente esta operacional
	4.6.2. Criando um trigger com a função nodata()
	4.6.3. Exercícios
	4.7. Tempo on-line e última inicialização do S.O.
	4.7.1. Trigger para alerta de reinicialização
	4.7.2. Exercícios
	4.8. Checando serviços pelo agente
	4.8.1. Verificando os processos ativos na memória
	4.8.2. Checagem de portas e serviços localmente via agente
	4.8.3. Exercícios
	4.8.4. Verificando serviços no Windows
	4.8.5. Restabelecendo serviços offline via Zabbix
	4.8.6. Exercícios
	4.9. Medindo a “saúde” de sua rede
	4.9.1. Latência de rede
	4.9.2. Macro para o limiar da latência de rede
	4.9.3. Nosso primeiro gráfico
	4.9.4. Personalizando o mapa para exibição de informações
	4.9.5. Exercícios
	4.10. Espaço disponível em disco
	4.10.1. Gráficos para espaço em disco
	4.10.2. Gatilhos para alertas de espaço em disco
	4.10.3. Exercícios
	4.11. Scripts externos
	4.11.1. Checando a disponibilidade do PostgreSQL
	4.11.2. Medindo a disponibilidade de um link Internet
	4.11.3. Exercícios
	REFERÊNCIAS 
BIBLIOGRÁFICAS
	Anexo I
Performance do Sistema Operacional
	Introdução
	Processamento
	Métricas de memória
	Throughput e banda de rede
	Performance de Disco
	Anexo II
Performance de serviços
	Introdução
	PostgreSQL
	JBoss
	Apache