Monitoramento Com o Zabbix

234
Soluções de Monitoramento com Zabbix Valter Douglas Lisbôa Júnior www.4linux.com.br

Transcript of Monitoramento Com o Zabbix

Page 1: Monitoramento Com o Zabbix

Soluções de Monitoramento com Zabbix

Valter Douglas Lisbôa Júnior

www.4linux.com.br

Page 2: Monitoramento Com o Zabbix

- 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

Page 3: Monitoramento Com o Zabbix

- 3

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

2.11. Preparando o servidor web............................................................................................58

2.11.1. Instalação do Apache e PHP5...............................................................................................58

2.11.2. Configuração do Virtual Host...............................................................................................58

2.11.3. Configurando o front end......................................................................................................61

2.12. Exercícios de revisão.....................................................................................................72

Capítulo 3

Criando uma Infraestrutura de Monitoramento - Parte 2, Front end.......................................74

3.1. Introdução........................................................................................................................75

3.1.1. Organização do front end.......................................................................................................75

3.2. Gerenciamento de usuários.............................................................................................77

3.2.1. Cadastrando os usuários do LDAP no Zabbix........................................................................81

3.3. Meios de alertas...............................................................................................................83

3.3.1. Correio eletrônico...................................................................................................................84

3.3.2. Mensagens instantâneas.........................................................................................................84

3.3.3. Apontando os alertas aos usuários.........................................................................................85

3.3.4. Boas práticas com Media types..............................................................................................87

3.4. Hosts, host groups e templates.......................................................................................87

3.4.1. Templates para o caso de estudo............................................................................................88

3.4.2. Vínculo entre templates..........................................................................................................90

3.4.3. Backup dos templates.............................................................................................................91

3.4.4. Hosts........................................................................................................................................91

3.4.5. Gerenciando os Host Groups..................................................................................................92

3.4.6. Criando um novo host.............................................................................................................93

3.4.7. Fazendo backup dos hosts......................................................................................................95

3.4.8. Configurando uma permissão de acesso................................................................................95

3.4.9. Exercícios sobre usuários, hosts, grupos e permissões.........................................................97

3.5. Mapas...............................................................................................................................98

3.5.1. Importando imagens para o mapa..........................................................................................98

3.5.2. Criando um mapa..................................................................................................................100

3.5.3. Adicionando um elemento.....................................................................................................103

3.5.4. Editando um elemento do mapa...........................................................................................104

3.5.5. Salvando o mapa...................................................................................................................106

3.5.6. Adicionando os outros elementos.........................................................................................106

3.5.7. Criando e editando links.......................................................................................................110

3.5.8. Prática Dirigida.....................................................................................................................111

3.5.9. Exercícios sobre Mapas........................................................................................................113

3.6. Templates, applications e items....................................................................................114

3.6.1. Criando um Application e um Item dentro de um template................................................115

3.6.2. Interdependência de templates............................................................................................118

3.7. Associando os templates aos hosts................................................................................120

Page 4: Monitoramento Com o Zabbix

- 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

Page 5: Monitoramento Com o Zabbix

- 5

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

4.9.4. Personalizando o mapa para exibição de informações........................................................208

4.9.5. Exercícios..............................................................................................................................210

4.10. Espaço disponível em disco.........................................................................................210

4.10.1. Gráficos para espaço em disco...........................................................................................213

4.10.2. Gatilhos para alertas de espaço em disco..........................................................................216

4.10.3. Exercícios............................................................................................................................217

4.11. Scripts externos...........................................................................................................218

4.11.1. Checando a disponibilidade do PostgreSQL......................................................................218

4.11.2. Medindo a disponibilidade de um link Internet.................................................................223

4.11.3. Exercícios............................................................................................................................227

REFERÊNCIAS

BIBLIOGRÁFICAS......................................................................................................................228

Anexo I

Performance do Sistema Operacional..................................................................................230

Introdução.......................................................................................................................................230

Processamento.................................................................................................................................230

Métricas de memória......................................................................................................................231

Throughput e banda de rede...........................................................................................................232

Performance de Disco.....................................................................................................................232

Anexo II

Performance de serviços.......................................................................................................233

Introdução.......................................................................................................................................233

PostgreSQL......................................................................................................................................233

JBoss................................................................................................................................................234

Apache.............................................................................................................................................234

Índice de tabelasTabela 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

Page 6: Monitoramento Com o Zabbix

- 6

Índice de FigurasFigura 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

Page 7: Monitoramento Com o Zabbix

- 7

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

Figura 3.7: Configurando o Zabbix para enviar e-mails........................................................84

Figura 3.8: Configurando o Zabbix para enviar mensagens instantâneas...........................84

Figura 3.9: Media Types de um usuário sem apontamentos.................................................85

Figura 3.10: Adicionando o Media Type Email a um usuário................................................85

Figura 3.11: Adicionando um media type Jabber a um usuário............................................86

Figura 3.12: Media Types de um usuário após o cadastro....................................................86

Figura 3.13: Selecionando todos os templates pré cadastrados...........................................88

Figura 3.14: Excluindo os templates selecionados................................................................89

Figura 3.15: Criando um novo template.................................................................................89

Figura 3.16: Cadastrando um novo template.........................................................................89

Figura 3.17: Vinculando um template a outro.......................................................................90

Figura 3.18: Exportando um template...................................................................................91

Figura 3.19: Layout dos hosts a serem monitorados.............................................................92

Figura 3.20: Como criar um novo grupo de hosts.................................................................93

Figura 3.21: Novo host group.................................................................................................93

Figura 3.22: Host pré-cadastrado no front end na tela de Hosts..........................................93

Figura 3.23: Botão para criar um host...................................................................................93

Figura 3.24: Todos os hosts do cenário cadastrados.............................................................95

Figura 3.25: Concedendo permissões de acesso (1/4)...........................................................95

Figura 3.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

Page 8: Monitoramento Com o Zabbix

- 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.....................................................................................127

Figura 4.1: Menu de Ferramentas acessado pelo mapa......................................................130

Figura 4.2: Saída de um comando ping................................................................................130

Figura 4.3: Saída de um comando que falhou do traceroute..............................................131

Figura 4.4: Saída do traceroute adequando a nova necessidade .......................................135

Figura 4.5: Criando um novo script para testar portas SSH (1/2)......................................136

Figura 4.6: Criando um novo script para testar portas SSH (2/2)......................................136

Page 9: Monitoramento Com o Zabbix

- 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

Page 10: Monitoramento Com o Zabbix

- 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................................................180

Figura 4.74: Item para verificação de número de processos..............................................183

Figura 4.75: Overview refletindo o número de processos...................................................183

Figura 4.76: Trigger para queda do daemon.......................................................................184

Figura 4.77: Teste de queda do sshd....................................................................................185

Figura 4.78: Reflexo da queda do daemon SSH no overview..............................................185

Figura 4.79: Item para verificação da porta local...............................................................186

Figura 4.80: Fluxograma da dependência entre triggers para análise de serviços...........187

Figura 4.81: Trigger para verificação da porta local...........................................................189

Figura 4.82: Trigger para verificação de porta remota.......................................................189

Figura 4.83: Serviço telnet do Windows..............................................................................190

Figura 4.84: Habilitando o serviço de telnet do Windows...................................................191

Page 11: Monitoramento Com o Zabbix

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

Page 12: Monitoramento Com o Zabbix

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.

Page 13: Monitoramento Com o Zabbix

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.

Page 14: Monitoramento Com o Zabbix

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.

Page 15: Monitoramento Com o Zabbix

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, mostrando como gerenciar os elementos mais básicos da ferramenta: usuários, 

hosts, templates, grupos de hosts e mapas.

2.2. Configurando os componentes de recebimento de alertas

Por padrão o Zabbix possui quatro formas de alertas embutidos dentro de seu sistema: e­

mails, cliente jabber, SMS via modem GSM e SMS via serviço de torpedos. De todos, o último não 

é muito útil aqui no Brasil, devido seguir os padrões das operadoras no Canadá e Estados Unidos.

Dos restantes vamos ver o funcionamento do sistema de correios e de jabber dentro da 

sala de aula, devido a natureza do hardware, a emulação das máquinas virtuais do cenário e 

custos de mensagem não abordamos o uso dentro do nosso cenário com SMS. No entanto temos 

um apêndice que cobre o sistema de SMS com throubleshooting e dicas de configuração.

Receber mensagens por cliente de 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.

Page 16: Monitoramento Com o Zabbix

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)

Page 17: Monitoramento Com o Zabbix

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)

Page 18: Monitoramento Com o Zabbix

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: [email protected].

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

Page 19: Monitoramento Com o Zabbix

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)

Page 20: Monitoramento Com o Zabbix

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)

Page 21: Monitoramento Com o Zabbix

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)

Page 22: Monitoramento Com o Zabbix

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)

Page 23: Monitoramento Com o Zabbix

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)

Page 24: Monitoramento Com o Zabbix

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)

Page 25: Monitoramento Com o Zabbix

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

Page 26: Monitoramento Com o Zabbix

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

Page 27: Monitoramento Com o Zabbix

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 mostrou mais adequada aos tipos de dados que o Zabbix manipula. 

Embora não pareça a princípio, o banco de dados do Zabbix é de extrema valia para a 

empresa, pois ele contém todo o histórico de funcionamento de sua infraestrutura e através dele 

podemos coletar SLAs e informações de “capacity plan”.

É recomendado também que seu banco de dados possua um plano de backups regular 

via PITR – Point in Time Recovery.

Page 28: Monitoramento Com o Zabbix

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=# 

Page 29: Monitoramento Com o Zabbix

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)

Page 30: Monitoramento Com o Zabbix

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

Page 31: Monitoramento Com o Zabbix

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 

Page 32: Monitoramento Com o Zabbix

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 manuais serão colocados em /usr/local como padrão. No entanto para manter a instalação organizada e facilitar atualizações de versões do Zabbix nós o colocaremos em /opt/zabbix-1.8.4.

--mandir=/usr/share/man Aponta a localização correta das páginas de manual, assim podemos usar o comando man para acessar as opções dos binários do Zabbix.

--enable-static Ativa a geração de binários em forma estática (sem shared libraries). É recomendado deixar esta opção desligada.

--enable-server Ativa a compilação do servidor. No caso presente iremos ativar esta opção, quando formos compilar apenas o agente iremos desabilitá-la.

--enable-proxy Compila os binários para sistemas distribuídos. Como neste curso não abordaremos o sistema de proxy do Zabbix vamos deixar esta opção sempre desabilitada.

--enable-agent Compila os binários para os agentes. É uma excelente ideia sempre deixar esta opção ativada. Mesmo em servidores dedicados do Zabbix é uma boa prática monitorar a própria máquina.

Page 33: Monitoramento Com o Zabbix

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.

Page 34: Monitoramento Com o Zabbix

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

Page 35: Monitoramento Com o Zabbix

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

Page 36: Monitoramento Com o Zabbix

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

Page 37: Monitoramento Com o 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

Page 38: Monitoramento Com o Zabbix

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.

Page 39: Monitoramento Com o Zabbix

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.

Page 40: Monitoramento Com o Zabbix

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

Page 41: Monitoramento Com o Zabbix

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 scripts no 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. 

Page 42: Monitoramento Com o Zabbix

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 #

Page 43: Monitoramento Com o Zabbix

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

Page 44: Monitoramento Com o Zabbix

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.

Page 45: Monitoramento Com o Zabbix

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 

Page 46: Monitoramento Com o Zabbix

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 agente a partir de 

agora.

2.6.3. Exercício sobre instalação de agente em Linux

 1)  Instale   o   agente   do   Zabbix   via   compilação   nas   máquinas   virtuais  Application  e Database conforme mostrado neste capítulo.

2.7. Instalando o agente em ambientes Windows

Um dos objetivos do curso é  demonstrar como o Zabbix é  capaz de monitorar  redes 

heterogêneas com vários sistemas operacionais e ativos de rede. Esta sessão cuida de instalar o 

agente do Zabbix em um Windows 2003.

Page 47: Monitoramento Com o Zabbix

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

Page 48: Monitoramento Com o Zabbix

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

Page 49: Monitoramento Com o Zabbix

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

Page 50: Monitoramento Com o Zabbix

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

Page 51: Monitoramento Com o Zabbix

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.

Page 52: Monitoramento Com o Zabbix

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/. 

Page 53: Monitoramento Com o Zabbix

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”

Page 54: Monitoramento Com o Zabbix

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

Page 55: Monitoramento Com o Zabbix

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

Page 56: Monitoramento Com o Zabbix

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   .

Page 57: Monitoramento Com o Zabbix

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.

Page 58: Monitoramento Com o Zabbix

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

Page 59: Monitoramento Com o Zabbix

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 59

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

necessário apenas inicialmente e será removido depois do termino da configuração do  

“front end”.

Agora   vamos   criar   o   arquivo   de   “virtual   host”.   Note   que   o   diretório   criado   acima   é 

apontado como raiz e os arquivos de logs são separados do padrão para facilitar a depuração de 

erros.

# cd /etc/apache2/sites­available

# vim zabbix­front end.conf

1 <VirtualHost *:80>

2         ServerAdmin [email protected]

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 

Page 60: Monitoramento Com o Zabbix

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.

Page 61: Monitoramento Com o Zabbix

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)

Page 62: Monitoramento Com o Zabbix

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)

Page 63: Monitoramento Com o Zabbix

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)

Page 64: Monitoramento Com o Zabbix

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.

Page 65: Monitoramento Com o Zabbix

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)

Page 66: Monitoramento Com o Zabbix

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)

Page 67: Monitoramento Com o Zabbix

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)

Page 68: Monitoramento Com o Zabbix

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)

Page 69: Monitoramento Com o Zabbix

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)

Page 70: Monitoramento Com o Zabbix

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 root www­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)

Page 71: Monitoramento Com o Zabbix

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

Page 72: Monitoramento Com o Zabbix

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: _________________________________________

Page 73: Monitoramento Com o Zabbix

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.

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

________________________________________________________________________

Page 74: Monitoramento Com o Zabbix

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.

Page 75: Monitoramento Com o Zabbix

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.

Page 76: Monitoramento Com o Zabbix

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ção de cenários de teste de serviços web.

• Actions Gerenciamento de ações que os triggers devem tomar ao alertarem algum   comportamento   (exemplo:   enviar   um   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.

Page 77: Monitoramento Com o Zabbix

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.

Page 78: Monitoramento Com o Zabbix

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

Page 79: Monitoramento Com o 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

Page 80: Monitoramento Com o Zabbix

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

Page 81: Monitoramento Com o Zabbix

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

Page 82: Monitoramento Com o Zabbix

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

Page 83: Monitoramento Com o Zabbix

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 ao usuários.

Mais a frente iremos acrescentar direitos aos usuários e também mudaremos seus tipos 

conforme a necessidade.

3.3. Meios de alertas

Os “Media Types” os nomes que o Zabbix atribui aos meios de envio de alertas. Como já 

foi dito o Zabbix suporta correio eletrônico, SMS via modem, SMS via serviço de rede (EUA e 

Canada apenas), mensageiro instantâneo via Jabber e chamada de scripts externos. No nosso 

cenário de curso iremos aprender a trabalhar com estes recursos usando o sistema de 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

Page 84: Monitoramento Com o Zabbix

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

Page 85: Monitoramento Com o Zabbix

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: [email protected]). 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

Page 86: Monitoramento Com o Zabbix

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

Page 87: Monitoramento Com o Zabbix

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.

Page 88: Monitoramento Com o Zabbix

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, enquanto não são 

obrigatórios,   pois   podemos   acrescentar   métricas   de   monitoramentos   direto   a   um   host,   eles 

ajudam a gerenciar de maneira efetiva os diversos tipos de monitoramentos possíveis e replicá­los 

a tantos hosts quanto quisermos (ou o quanto nossos sistemas aguentarem, o que vier primeiro).  

Os templates agregam métricas de monitoramento chamados items, macros e outros valores que 

são importantes para construir uma solução de monitoramento. A maior parte do seu trabalho no 

curso será em cima dos templates.

3.4.1. Templates para o caso de estudo

O primeiro passo é limpar todos os templates preexistentes no Zabbix. Apesar de parecer 

um tanto agressivo excluir todos os modelos pré criados, parte do intuito do curso é construir os 

seus templates de maneira adequada a sua necessidade. Em produção você pode conservá­los 

se  desejar,  mas   isso   não   é   um   requerimento   a   menos  que   você   tenha  garantidamente  um 

equipamento para o qual um dos modelos tenha sido construído. Outra opção é fazer backup dos 

originais (veja a próxima sessão). 

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

Page 89: Monitoramento Com o Zabbix

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

Page 90: Monitoramento Com o Zabbix

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

Page 91: Monitoramento Com o Zabbix

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

Page 92: Monitoramento Com o Zabbix

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

Page 93: Monitoramento Com o Zabbix

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

Page 94: Monitoramento Com o Zabbix

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 seja necessário monitorar estações de usuários ou servidores que estejam em ambientes com IP dinâmico (via DHCP) e neste caso somente via DNS é possível encontrar o host .

 7)  Qual a porta TCP do agente. Vamos mudar isto para monitorar o  “Zapcat”, mas em todos os outros casos deixaremos ela no padrão 10050.

 8)  Não monitoraremos este host via proxy.

 9)  No  Status  deixe   como  “Not   monitored”  por   enquanto,   quando   associarmos   os templates iremos ativar este host.

Page 95: Monitoramento Com o Zabbix

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

Page 96: Monitoramento Com o Zabbix

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)

Page 97: Monitoramento Com o Zabbix

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)

Page 98: Monitoramento Com o Zabbix

Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 98

Usuário Applica-tion

Databa-se

JBoss AS Presen-tation

Switch Windows2003

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.

Page 99: Monitoramento Com o Zabbix

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

Page 100: Monitoramento Com o Zabbix

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

Page 101: Monitoramento Com o Zabbix

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

Page 102: Monitoramento Com o Zabbix

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 possuir  um “trigger”  que  teve seu estado mudado  recentemente,  uma borda será desenha em volta do ícone.

 7)  No caso de haver um incidente com um item em particular, e ele for único (é somente um problema para  aquele   item em particular)  podemos deixar  o  campo  “Expand single problem” ligado para que a descrição do problema seja apresentado no mapa (evitando ter que clicar no item para 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.

Page 103: Monitoramento Com o Zabbix

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

Page 104: Monitoramento Com o Zabbix

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

Page 105: Monitoramento Com o Zabbix

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

Page 106: Monitoramento Com o Zabbix

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.

Page 107: Monitoramento Com o Zabbix

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

Page 108: Monitoramento Com o Zabbix

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

Page 109: Monitoramento Com o Zabbix

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

Page 110: Monitoramento Com o Zabbix

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

Page 111: Monitoramento Com o Zabbix

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

Page 112: Monitoramento Com o Zabbix

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

Page 113: Monitoramento Com o Zabbix

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

Page 114: Monitoramento Com o Zabbix

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

Page 115: Monitoramento Com o Zabbix

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)

Page 116: Monitoramento Com o Zabbix

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)

Page 117: Monitoramento Com o Zabbix

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   criar   um   “item”   que   faz   um   “ping”   via   ICMP  no   host,   logo  a   chave   será “icmpping”.  Clicar em “Select”  abre uma janela com infindáveis “keys” e você  pode selecioná­las por essa janela, se desejar.

Figura 3.54: Criando seu primeiro item (2/3)

Page 118: Monitoramento Com o Zabbix

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)

Page 119: Monitoramento Com o Zabbix

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

Page 120: Monitoramento Com o Zabbix

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)

Page 121: Monitoramento Com o Zabbix

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)

Page 122: Monitoramento Com o Zabbix

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)

Page 123: Monitoramento Com o Zabbix

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 hosts do cenário

Page 124: Monitoramento Com o Zabbix

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

Page 125: Monitoramento Com o Zabbix

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

Page 126: Monitoramento Com o Zabbix

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 

Page 127: Monitoramento Com o Zabbix

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

Page 128: Monitoramento Com o Zabbix

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.

Page 129: Monitoramento Com o Zabbix

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.

Page 130: Monitoramento Com o Zabbix

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

Page 131: Monitoramento Com o Zabbix

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

Page 132: Monitoramento Com o Zabbix

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.

Page 133: Monitoramento Com o Zabbix

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

Page 134: Monitoramento Com o Zabbix

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.

Page 135: Monitoramento Com o Zabbix

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

Page 136: Monitoramento Com o Zabbix

Capítulo 4 Monitoramento voltado 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)

Page 137: Monitoramento Com o Zabbix

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

Page 138: Monitoramento Com o Zabbix

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). 

Page 139: Monitoramento Com o Zabbix

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

Page 140: Monitoramento Com o Zabbix

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

Page 141: Monitoramento Com o Zabbix

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 todas as opções que possuem o valor 1 estão com a string “OK”. Isso 

facilita e muito a visualização dos valores e sempre que possível iremos criar ou usar “Values 

Maps” prontos para melhorar a apresentação de dados.

4.3.3. Criando um gatilho de parada de host

Embora já saibamos qual host esta OK, ainda não pedimos ao servidor para nos alertar 

via 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

Page 142: Monitoramento Com o Zabbix

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

Page 143: Monitoramento Com o Zabbix

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)

Page 144: Monitoramento Com o Zabbix

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)

Page 145: Monitoramento Com o Zabbix

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)

Page 146: Monitoramento Com o Zabbix

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

Page 147: Monitoramento Com o Zabbix

Capítulo 4 Monitoramento voltado para disponibilidade - 147

O Mapa também deve estar mostrando o status do “trigger” no host “Database”. Vá até 

Monitoring   → Maps e perceba como o Zabbix colocou um círculo vermelho no fundo do host. O 

nome do gatilho também esta aparecendo abaixo do label de nome.

Figura 4.28: Overview com indicação dos items com alerta

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

Page 148: Monitoramento Com o Zabbix

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

Page 149: Monitoramento Com o Zabbix

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

Page 150: Monitoramento Com o Zabbix

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)

Page 151: Monitoramento Com o Zabbix

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)

Page 152: Monitoramento Com o Zabbix

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)

Page 153: Monitoramento Com o Zabbix

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

Page 154: Monitoramento Com o Zabbix

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 percebido que o evento foi acionado pelo “reboot” 

da máquina virtual. Este tipo de comportamento é esperado, afinal a resposta do “ping”  deixou de 

ser   enviado   ao   servidor.   No   entanto   a   máquina   não   caiu,   e   uma   simples   reinicialização 

providencial em um servidor ou serviço, não deve ser acusada como queda de host. Ambos são 

situações diferentes.

Por  isso devemos sempre ter em mente que nossos “triggers” não devem se limitar a 

verificar um único valor de mudança de estado. É preciso de uma lógica mais bem trabalhada e 

fazer uso de um recurso chamado “janela de tempo”. A Figura 4.45 ilustra como a janela de tempo 

funciona.

Figura 4.44: Reiniciando o host Database

Page 155: Monitoramento Com o Zabbix

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

Page 156: Monitoramento Com o Zabbix

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.

Page 157: Monitoramento Com o Zabbix

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.

Page 158: Monitoramento Com o Zabbix

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/tcp closed snet­sensor­mgmt

Page 159: Monitoramento Com o Zabbix

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”. 

Page 160: Monitoramento Com o Zabbix

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).

Page 161: Monitoramento Com o Zabbix

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

Page 162: Monitoramento Com o Zabbix

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

Page 163: Monitoramento Com o Zabbix

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 

Page 164: Monitoramento Com o Zabbix

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.

Clique sobre “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)

Page 165: Monitoramento Com o Zabbix

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)

Page 166: Monitoramento Com o Zabbix

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)

Page 167: Monitoramento Com o Zabbix

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

Page 168: Monitoramento Com o Zabbix

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

Page 169: Monitoramento Com o Zabbix

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.

Page 170: Monitoramento Com o Zabbix

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

Page 171: Monitoramento Com o Zabbix

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)

Page 172: Monitoramento Com o Zabbix

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)

Page 173: Monitoramento Com o Zabbix

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)

Page 174: Monitoramento Com o Zabbix

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

Page 175: Monitoramento Com o Zabbix

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.

Page 176: Monitoramento Com o Zabbix

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 de segundos (que ele 

chama de “timeticks”).

Não se incomode com a saída em texto de vários desses comandos, o Zabbix lida com 

os números destacados em negrito apenas.

Toda   essa   diferença   requer   um   tratamento   no   momento   da   coleta,   ou   seja,   na 

Page 177: Monitoramento Com o Zabbix

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

Page 178: Monitoramento Com o Zabbix

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

Page 179: Monitoramento Com o Zabbix

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

Page 180: Monitoramento Com o Zabbix

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

Page 181: Monitoramento Com o Zabbix

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.

Page 182: Monitoramento Com o Zabbix

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 nossa prática atual,  o único parâmetro relevante é  o primeiro, pois vamos buscar 

apenas um processo bem definido dentro da memória (o “daemon” do SSH). Para descobrir qual 

o processo usaremos o comando “ps”. Entre no console do servidor do “Zabbixsrv”.

# ps uax | grep ssh ­i

root      1161  0.0  0.3   5496   988 ?        Ss   14:09   0:00 /usr/sbin/sshd

root      3594  0.2  1.1   8304  2868 ?        Ss   14:40   0:00 sshd: root@pts/0 

root      3674  0.0  0.3   3316   836 pts/0    S+   14:41   0:00 grep ­­color ssh

O primeiro processo é  o   “daemon”,  o segundo é  uma conexão ssh acontecendo e o 

terceiro é  o próprio “grep” na memória que usamos na linha de comando e portanto pode ser 

ignorado. Note que o nome do processo é “sshd” e não simplesmente ssh. Com isso em mãos, 

podemos ser mais pontuais com o “ps”, a opção “­C” pouco conhecida e usada, lista apenas os 

processos com o nome indicado. Ela é incompatível com as opções “a” e “x”, por isso à usaremos 

em combinação com a “u”, apenas.

# ps u ­C sshd

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

root      1161  0.0  0.2   5496   624 ?        Ss   14:09   0:00 /usr/sbin/sshd

root      3594  0.0  0.8   8304  2204 ?        Ss   14:40   0:00 sshd: root@pts/0

Guarde esta opção do “ps”, você vai precisar dela no futuro.

Vamos usar o “zabbix_get” para coletar a informação da chave agora.

# zabbix_get ­s localhost ­k "proc.num[sshd]"

2   ←

A chave retornou “2”, que é exatamente o número de processos que contamos com o ps. 

Com o teste concluído vamos à criação do “item” e “trigger”. Use o template “4Linux – S.O. Linux”.

Page 183: Monitoramento Com o Zabbix

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

Page 184: Monitoramento Com o Zabbix

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

Page 185: Monitoramento Com o Zabbix

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

Page 186: Monitoramento Com o Zabbix

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

Page 187: Monitoramento Com o Zabbix

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

Page 188: Monitoramento Com o Zabbix

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 vamos continuar com nossa prática dirigida e criar os dois “triggers” que faltam, pois 

o primeiro já esta pronto desde o tópico anterior. 

Page 189: Monitoramento Com o Zabbix

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

Page 190: Monitoramento Com o Zabbix

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

Page 191: Monitoramento Com o Zabbix

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

Page 192: Monitoramento Com o Zabbix

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

Page 193: Monitoramento Com o Zabbix

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]'

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.

Page 194: Monitoramento Com o Zabbix

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)

Page 195: Monitoramento Com o Zabbix

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)

Page 196: Monitoramento Com o Zabbix

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.

Page 197: Monitoramento Com o Zabbix

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

Page 198: Monitoramento Com o Zabbix

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

Page 199: Monitoramento Com o Zabbix

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.

Page 200: Monitoramento Com o Zabbix

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)

Page 201: Monitoramento Com o Zabbix

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)

Page 202: Monitoramento Com o Zabbix

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”.

Page 203: Monitoramento Com o Zabbix

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

Page 204: Monitoramento Com o Zabbix

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   “macros   de 

usuários”.

Existem três tipos de escopo de macro: global (definido em Administration   → General) 

que vale para todos os templates e hosts; macros de templates, cujo alcance vale para todos os 

hosts associados a um dado template e macros de host, que vale só para aquele host. Se você 

redefinir (como vamos fazer) uma macro num ambiente mais restrito, o que irá valer será este 

último.

O Zabbix tem várias macros internas e já tivemos contato com algumas quando criamos 

nossos “triggers”. {HOSTNAME}, que é a mais comum, armazena o nome do host definido dentro 

do “front end”. Quando definirmos uma macro de usuário é importante que em sua sintaxe um 

sinal de cifrão ($) seja colocado antes do nome e dentro das chaves.

Por exemplo, vamos definir uma macro para latência de rede com o nome “LATENCIA”, 

logo sua sintaxe será “{$LATENCIA}”. Evite o uso de outros caracteres no nome da macro exceto 

por “underline”  (_). Também não comece o nome da macro por números. É  uma boa prática 

manter os nomes em caixa alta.

No   caso   de   nosso   cenário   iremos   definir   um   padrão   de  “0.01”  segundos   (10 

milissegundos) para nossa macro, ela vai ser uma macro de template, mais especificamente o 

template  “4Linux   –   ICMP”.   Abra   as   configurações   do   mesmo   clicando   no   nome   dele   em 

Configuration   → Templates.  No canto direito  do quadro principal  você  vai  achar  a área  de 

definição de macros.

Page 205: Monitoramento Com o Zabbix

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

Page 206: Monitoramento Com o Zabbix

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

Page 207: Monitoramento Com o Zabbix

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

Page 208: Monitoramento Com o Zabbix

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 .

Page 209: Monitoramento Com o Zabbix

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

Page 210: Monitoramento Com o Zabbix

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   “simple   checks”   de   portas   TCP.   Por   exemplo, “ssh_perf” é a medição de latência para o servidor de conexões remotas segura. Crie os “items” e gráficos (veja o exemplo abaixo) para os outros serviços que você já criou anteriormente de disponibilidade. Cadastre macros para medir o limiar e finalize com os “triggers” dos mesmos.

Em sala de aula, crie pelo menos um deles, os outros podem ser feitos em casa.

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

Page 211: Monitoramento Com o Zabbix

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

Page 212: Monitoramento Com o Zabbix

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

Page 213: Monitoramento Com o Zabbix

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

Page 214: Monitoramento Com o Zabbix

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

Page 215: Monitoramento Com o Zabbix

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

Page 216: Monitoramento Com o Zabbix

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áfico ficará ajustado ao tamanho máximo atingido o que 

pode levar um observador desavisado a interpretar como disco cheio!

4.10.2. Gatilhos para alertas de espaço em disco

Agora vamos usar a macro que definimos anteriormente para calcular o volume de disco 

usado. Para isso vamos usar uma fórmula para, a partir do total, saber qual é a porcentagem em 

“bytes” que a partição terá de limiar. A expressão ló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.

Page 217: Monitoramento Com o Zabbix

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

Page 218: Monitoramento Com o Zabbix

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 

Page 219: Monitoramento Com o Zabbix

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

Page 220: Monitoramento Com o Zabbix

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

Page 221: Monitoramento Com o Zabbix

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

Page 222: Monitoramento Com o Zabbix

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

Page 223: Monitoramento Com o Zabbix

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

Page 224: Monitoramento Com o Zabbix

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

Page 225: Monitoramento Com o Zabbix

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).

Page 226: Monitoramento Com o Zabbix

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

Page 227: Monitoramento Com o Zabbix

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.

Page 228: Monitoramento Com o Zabbix

- 228

REFERÊNCIAS BIBLIOGRÁFICAS

Page 229: Monitoramento Com o Zabbix

- 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.

Page 230: Monitoramento Com o Zabbix

- 230

Anexo I

Performance do Sistema Operacional

Introdução

Aqui vamos passar as dicas e métricas que podem ser usadas para monitorar as quatro 

principais características de desempenho. Uso de CPU, memória, “throughput” de rede e I/O de 

disco. Este capítulo utiliza o template completo do Gnu/Linux para coleta de todas as informações.

Processamento

Esta é primeira métrica de performance que, geralmente, é observada quando o sistema 

fica lento. Algumas considerações devem ser feitas quando se busca monitorar o processamento 

para identificar gargalos:

 1)  100% de processamento não quer dizer nada!

 1.1)  Picos   de   processamentos   são   mais   corriqueiros   do   que   imaginamos,   eles acontecem   frequentemente,   mas   são   tão   momentâneos   que   nem   os percebemos mesmo em gráficos com curtos intervalos de coleta. Sempre que procurar por eles, concentre­se apenas nos de longa duração.

Page 231: Monitoramento Com o Zabbix

- 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.

Page 232: Monitoramento Com o Zabbix

- 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).

Page 233: Monitoramento Com o Zabbix

- 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!

Page 234: Monitoramento Com o Zabbix

- 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.