131444591 97430634-apostila-468-zabbix

Soluções de Monitoramento com Zabbix

Valter Douglas Lisbôa Júnior

www.4linux.com.br

- 2

Sumário

Capítulo 1

Conhecendo o Zabbix..................................................................................................................12

1.1. Objetivos...........................................................................................................................12

1.2. Conhecendo a ferramenta................................................................................................12

1.3. Comunidades e forums....................................................................................................13

Capítulo 2

Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema..........................................14

2.1. Objetivos...........................................................................................................................14

2.2. Introdução........................................................................................................................15

2.3. Configurando os componentes de recebimento de alertas............................................15

2.3.1. Configurando o cliente de correio eletrônico........................................................................16

2.3.2. Mensagens instantâneas.........................................................................................................24

2.4. Obtendo os fontes do Zabbix...........................................................................................26

2.5. Preparando o banco de dados.........................................................................................27

2.5.1. Instalação................................................................................................................................27

2.5.2. Criando o usuário e o banco...................................................................................................28

2.5.3. Carga inicial............................................................................................................................29

2.5.4. Concedendo as permissões necessárias ao usuário...............................................................30

2.6. Instalação do servidor Zabbix via código fonte..............................................................31

2.6.1. Dependências de compilação..................................................................................................33

2.6.2. Compilando e instalando.........................................................................................................34

2.6.3. Serviços de rede......................................................................................................................36

2.6.4. Arquivos de configuração.......................................................................................................36

2.6.5. Testando sua instalação..........................................................................................................38

2.6.6. Scripts de boot........................................................................................................................39

2.7. Instalação do agente Zabbix via compilação..................................................................40

2.7.1. Exercício: compile e instale o agente nas VM com Linux......................................................40

2.7.2. Acesso ao agente pelo servidor..............................................................................................40

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

2.8. Instalando o agente em ambientes Windows..................................................................44

2.8.1. Executando o agente como serviço........................................................................................48

2.9. Instalação do agente Zapcat para JBoss.........................................................................49

2.9.1. Obtenção do binário................................................................................................................50

2.9.2. Deployment..............................................................................................................................50

2.9.3. Opções de inicialização do JBoss............................................................................................51

2.9.4. Liberando o firewall para acesso ao Zapcat...........................................................................52

- 3

2.10. Testando o acesso via SNMP.........................................................................................52

2.10.1. Conceitos de SNMP..............................................................................................................53

2.11. Instalando o servidor Zabbix via pacote.......................................................................55

2.12. Preparando o servidor web............................................................................................55

2.12.1. Instalação do Apache e PHP5...............................................................................................55

2.12.2. Configuração do Virtual Host...............................................................................................55

2.12.3. Configurando o front end......................................................................................................58

2.13. Exercícios de revisão.....................................................................................................69

Capítulo 3

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

3.1. Objetivos...........................................................................................................................71

3.2. Introdução........................................................................................................................71

3.2.1. Organização do front end.......................................................................................................72

3.3. Gerenciamento de usuários.............................................................................................74

3.3.1. Cadastrando os usuários do LDAP no Zabbix........................................................................77

3.4. Meios de alertas...............................................................................................................80

3.4.1. Correio eletrônico...................................................................................................................80

3.4.2. Mensagens instantâneas.........................................................................................................81

3.4.3. Apontando os alertas aos usuários.........................................................................................81

3.4.4. Boas práticas com Media types..............................................................................................83

3.5. Hosts, host groups e templates.......................................................................................84

3.5.1. Templates para o caso de estudo............................................................................................85

3.5.2. Vínculo entre templates..........................................................................................................86

3.5.3. Backup dos templates.............................................................................................................87

3.5.4. Hosts........................................................................................................................................88

3.5.5. Gerenciando os Host Groups..................................................................................................88

3.5.6. Criando um novo host.............................................................................................................89

3.5.7. Fazendo backup dos hosts......................................................................................................91

3.5.8. Configurando uma permissão de acesso................................................................................91

3.5.9. Exercícios sobre usuários, hosts, grupos e permissões.........................................................93

3.6. Mapas...............................................................................................................................94

3.6.1. Importando imagens para o mapa..........................................................................................94

3.6.2. Criando um mapa....................................................................................................................95

3.6.3. Adicionando um elemento.......................................................................................................98

3.6.4. Editando um elemento do mapa.............................................................................................99

3.6.5. Salvando o mapa...................................................................................................................101

3.6.6. Adicionando os outros elementos.........................................................................................101

3.6.7. Criando e editando links.......................................................................................................105

3.6.8. Exercícios sobre ...................................................................................................................106

3.6.9. Exercícios sobre Mapas........................................................................................................108

- 4

3.7. Templates, applications e items.....................................................................................109

3.7.1. Criando um Application e um Item dentro de um template................................................110

3.7.2. Interdependência de templates............................................................................................113

3.8. Associando os templates aos hosts................................................................................114

3.9. Ativando um host............................................................................................................118

3.9.1. Throubleshooting para items com problemas......................................................................119

Capítulo 4

Monitoramento voltado para disponibilidade..........................................................................123

4.1. Objetivos.........................................................................................................................123

4.2. Introdução......................................................................................................................124

4.3. Checagens manual via front end...................................................................................124

4.3.1. Adequando o script de traceroute........................................................................................127

4.3.2. Criando novos comandos para o menu.................................................................................129

4.3.3. Exercícios..............................................................................................................................132

4.4. Checando disponibilidade via protocolo ICMP.............................................................133

4.4.1. Como funciona o ping ICMP.................................................................................................133

4.4.2. Visualizando o ping ICMP no Front end...............................................................................134

4.4.3. Criando um gatilho de parada de host.................................................................................136

4.4.4. Lidando com os eventos........................................................................................................141

4.4.5. Criando uma action para envio de alerta.............................................................................145

4.4.6. Exercícios..............................................................................................................................148

4.4.7. Boas práticas com triggers...................................................................................................149

4.5. Checagem genérica de portas e serviços......................................................................151

4.5.1. Conexões TCP e handshakes................................................................................................152

4.5.2. Criando um teste de serviço via varredura de portas.........................................................154

4.5.3. Exercício sobre checagem de portas....................................................................................156

4.6. Validação de páginas WEB.............................................................................................157

4.6.1. Disponibilidade do site..........................................................................................................157

4.6.2. Exercícios..............................................................................................................................162

4.7. Checando disponibilidade via agentes..........................................................................163

4.7.1. Checando se o agente esta operacional...............................................................................163

4.7.2. Criando um trigger com a função nodata()..........................................................................165

4.7.3. Exercícios..............................................................................................................................169

4.8. Tempo on-line e última inicialização do S.O..................................................................169

4.8.1. Trigger para alerta de reinicialização..................................................................................175

4.8.2. Exercícios..............................................................................................................................177

4.9. Checando serviços pelo agente.....................................................................................177

4.9.1. Verificando os processos ativos na memória........................................................................178

4.9.2. Checagem de portas e serviços localmente via agente.......................................................184

4.9.3. Exercícios..............................................................................................................................189

- 5

4.9.4. Verificando serviços no Windows.........................................................................................189

4.9.5. Restabelecendo serviços offline via Zabbix.........................................................................203

4.9.6. Exercícios..............................................................................................................................207

4.10. Medindo a “saúde” de sua rede...................................................................................207

4.10.1. Latência de rede..................................................................................................................207

4.10.2. Macro para o limiar da latência de rede............................................................................208

4.10.3. Nosso primeiro gráfico.......................................................................................................212

4.10.4. Personalizando o mapa para exibição de informações......................................................216

4.10.5. Exercícios............................................................................................................................218

4.11. Espaço disponível em disco.........................................................................................218

4.11.1. Gráficos para espaço em disco...........................................................................................221

4.11.2. Gatilhos para alertas de espaço em disco..........................................................................224

4.11.3. Exercícios............................................................................................................................225

4.12. Scripts externos...........................................................................................................225

4.12.1. Checando a disponibilidade do PostgreSQL......................................................................226

4.12.2. Medindo a disponibilidade de um link Internet.................................................................230

4.12.3. Exercícios............................................................................................................................233

REFERÊNCIAS

BIBLIOGRÁFICAS......................................................................................................................234

Anexo I

Performance do Sistema Operacional..................................................................................236

Introdução.......................................................................................................................................236

Processamento.................................................................................................................................236

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

Throughput e banda de rede...........................................................................................................238

Performance de Disco.....................................................................................................................238

Anexo II

Performance de serviços.......................................................................................................239

Introdução.......................................................................................................................................239

PostgreSQL......................................................................................................................................239

JBoss................................................................................................................................................240

Apache.............................................................................................................................................240

Índice de tabelasTabela 2.1: Opções de compilação do Zabbix........................................................................33

Tabela 2.2: Binários de uma instalação de servidor e agente do Zabbix..............................35

Tabela 2.3: Arquivos e diretórios de configuração................................................................37

Table 3.1: Usuários do cenário do curso................................................................................78

Table 4.1: Valores da key service_state................................................................................196

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

Figura 2.15: Instalando os executáveis no Windows.............................................................46

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

Figura 2.17: Configurando o agente no Windows..................................................................47

Figura 2.18: Desbloqueando o agente no Windows...............................................................48

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

Figura 2.20: Tela de entrada do Zapcat.................................................................................52

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









Figura 2.30: Configuração do front end (10/10)....................................................................68

Figura 2.31: Tela inicial do Zabbix após o primeiro login.....................................................68

Figura 3.1: Gerenciamento de usuários do Zabbix................................................................75

Figura 3.2: Editando o Admin.................................................................................................76

Figura 3.3: Configurando a autenticação LDAP....................................................................77

Figura 3.4: Novo Grupo JBoss Administrators.......................................................................78

Figura 3.5: Novo usuário Sysadmin.......................................................................................79

Figura 3.6: Media Types.........................................................................................................80

- 7

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

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

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

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

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

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

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

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

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

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

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

Figura 3.18: Exportando um template...................................................................................87

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

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

Figura 3.21: Novo host group.................................................................................................89

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

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

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

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




Figura 3.29: Tela inicial das imagens.....................................................................................94

Figura 3.30: Importando uma nova imagem..........................................................................95

Figura 3.31: Imagem do primeiro mapa a ser criado............................................................96

Figura 3.32: Mapas pré-cadastrados......................................................................................96

Figura 3.33: Novo mapa..........................................................................................................97

Figura 3.34: Barra de ferramentas para edição de mapas....................................................98

Figura 3.35: Criando um novo elemento................................................................................99

Figura 3.36: Posicionando um novo elemento com o mouse.................................................99

Figura 3.37: Editando um elemento na tela.........................................................................100

Figura 3.38: Botão Save do mapa.........................................................................................101

Figura 3.39: Dialogo de salvar mapa....................................................................................101

Figura 3.40: Outros elementos gráficos a serem adicionados............................................102

Figura 3.41: Editando o elemento que representa o host Presentation.............................103

Figura 3.42: Detalhes do host switch dentro do mapa........................................................104

Figura 3.43: Hosts acrescentados no mapa.........................................................................105

Figura 3.44: Criando um novo link entre o host Presentation e a imagem Internet..........106

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

- 8

Figura 3.46: Link entre o host Presentation e o Switch......................................................108

Figura 3.47: Mapa final.........................................................................................................109

Figura 3.48: Templates e seus elementos............................................................................109

Figura 3.49: Criando um application (1/4)...........................................................................110




Figura 3.53: Criando seu primeiro item (1/3)......................................................................111



Figura 3.56: Campo para associação de templates.............................................................113

Figura 3.57: Tela para escolha de templates.......................................................................113

Figura 3.58: Template associado..........................................................................................113

Figura 3.59: Template associado na lista de templates.......................................................114

Figura 3.60: Inter-relação dos templates base....................................................................114

Figura 3.61: Associando o template do JBoss ao host JBoss AS (1/6).................................114




Figura 3.65: Associando templates a hosts (5/11)...............................................................115


Figura 3.67: Templates para Windows e SNMP associados aos seus respectivos hosts. . .115

Figura 3.68: Associando um template a múltiplos hosts simultaneamente (1/4)..............117




Figura 3.72: Todos os templates associados aos hosts do cenário....................................118

Figura 3.73: Host presentation não monitorado..................................................................119

Figura 3.74: Dialogo de confirmação de ativação...............................................................119

Figura 3.75: Host presentation monitorado.........................................................................119

Figura 3.76: Item não suportado..........................................................................................120

Figura 3.77: Item suportado e ativo.....................................................................................122

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

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

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

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

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

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

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

- 9

Figura 4.8: Resultado do comando ativado no host.............................................................132

Figura 4.9: Diagrama de comportamento do echo ICMP....................................................133

Figura 4.10: Hosts ativos com ping ICMP em funcionamento............................................134

Figura 4.11: Um value maps de estado de serviços............................................................134

Figura 4.12: Editando o value map para nossa necessidade...............................................135

Figura 4.13: Value map editado e pronto para uso..............................................................135

Figura 4.14: Selecionando um value map no trigger..........................................................135

Figura 4.15: Values maps no overview.................................................................................136

Figura 4.16: Pausando o host Database...............................................................................137

Figura 4.17: Host database parado no overview.................................................................137

Figura 4.18: Criando um trigger para a parada do host (1/9).............................................138









Figura 4.27: Indicação de problemas no Dashboard...........................................................141

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

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

Figura 4.30: Mapa indicando o host Database como down.................................................143

Figura 4.31: Tela de Events, indicando a queda e o retorno dos hosts..............................143

Figura 4.32: Tela de acknowledgement...............................................................................144

Figura 4.33: Acknowledge (confirmação) aplicado..............................................................144

Figura 4.34: Criando um action para enviar o alerta (1/9).................................................145









Figura 4.43: Mensagens de alerta recebidas no Evolution.................................................148

Figura 4.44: Reiniciando o host Database...........................................................................149

Figura 4.45: Lógica de um gatilho com tempo de segurança.............................................150

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

- 10

Figura 4.47: Overview exibindo os serviços de SSH...........................................................156

Figura 4.48: Criando um cenário para disponibilidade Web (1/6)......................................158






Figura 4.54: Visualizando a checagem Web.........................................................................161

Figura 4.55: Detalhes do monitoramento Web....................................................................161

Figura 4.56: Gráfico de velocidade de download para o cenário Web................................162

Figura 4.57: Gráfico de tempo de resposta para o cenário Web.........................................162

Figura 4.58: Novo item para monitorar o agente................................................................164

Figura 4.59: Copiando o item de ping de agente para o template do JBoss (1/2)..............164

Figura 4.60: Copiando o item de ping de agente para o template do JBoss (2/2)..............165

Figura 4.61: Criando um trigger para o agent.ping (1/5)....................................................166





Figura 4.66: Trigger para o agent ping criado e ativo........................................................168

Figura 4.67: Trigger de agente ativado...............................................................................168

Figura 4.68: Dependência entre triggers evitando que o gatilho filho seja ativado..........168

Figura 4.69: Item para tempo de uptime.............................................................................172

Figura 4.70: Uptime via Zapcat............................................................................................173

Figura 4.71: Uptime via SNMP.............................................................................................173

Figura 4.72: Overview exibindo os uptimes a partir do agente padrão, Zapcat e SNMP..174

Figura 4.73: Um trigger para a reinicialização de um host................................................177

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

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

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

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

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

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

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

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

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

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

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

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

- 11

Figura 4.86: Processo do telnet na memória.......................................................................195

Figura 4.87: Liberando o telnet no firewall do Windows (1/3)............................................198



Figura 4.90: item para monitorar serviços Windows...........................................................202

Figura 4.91: Estado do serviço Telnet no Overview............................................................203

Figura 4.92: Action para parada do SSH (1/3).....................................................................205



Figura 4.95: Comando remoto para o action de parada do serviço de SSH.......................206

Figura 4.96: Item para latência de rede...............................................................................208

Figura 4.97: Macro para latência de rede............................................................................209

Figura 4.98: Trigger para latência de rede usando a macro...............................................212

Figura 4.99: Gráfico para medir a latência de rede............................................................213

Figura 4.100: Criando um gráfico de latência de rede........................................................214

Figura 4.101: Adicionando métricas ao gráfico...................................................................215

Figura 4.102: Mapa com labels personalizadas exibindo dados.........................................217

Figura 4.103: Exemplo de labels com valores de métricas.................................................217

Figura 4.104: Exemplo de gráfico de latência de serviços para exercícios........................218

Figura 4.105: Macro para limite de espaço em disco utilizado...........................................219

Figura 4.106: Primeiro item de espaço em disco.................................................................220

Figura 4.107: Items a serem clonados para espaço em disco.............................................221

Figura 4.108: Botão para clonar items.................................................................................221

Figura 4.109: Gráfico de pizza para exibição de espaço livre e ocupado...........................222

Figura 4.110: Criando um gráfico de pizza..........................................................................222

Figura 4.111: Gráfico de histórico de espaço em disco.......................................................223

Figura 4.112: Criando o gráfico de histórico de uso de disco.............................................223

Figura 4.113: Trigger para cálculo de espaço em disco......................................................224

Figura 4.114: Trocando o template do host database para o PostgreSQL.........................229

Figura 4.115: Disponibilidade do PostgreSQL ativa no database.......................................230

Figura 4.116: Latência sendo exibida no label do link........................................................232

Figura 4.117: Latência de rede e trigger associados ao link com a Internet no mapa......233

Figura 4.118: Link no mapa identificando status do trigger...............................................233

Capítulo 1 Conhecendo o Zabbix - 12

Capítulo 1

Conhecendo o Zabbix

1.1. Objetivos 1) Apresentar a ferramento ao aluno.

1.1) Como front end organiza os componentes dentro do Zabbix.

1.2) Componentes visuais de monitoramento.

1.3) Alertas de incidentes.

1.4) Reinicialização de serviços

2) Mostrar ao aluno onde obter informações.

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

Capítulo 1 Conhecendo o Zabbix - 13

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

http://www.zabbix.com/documentation/

http://www.zabbix.com/forum/

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

Capítulo 2

Criando uma Infraestrutura de

Monitoramento – Parte 1, Sistema

2.1. Objetivos 3) Preparar o ambiente de recebimento de alertas:

3.1) Configurar o Evolution para receber e-mails de alertas;

3.2) Configurar o Pidgin para receber mensagens instantâneas de alertas.

4) Preparar o ambiente para instalar o servidor do Zabbix:

4.1) Obter os fontes da ferramenta;

4.2) Preparar o PostgreSQL para servir de back end.

5) Instalar o servidor e agente:

5.1) Compilar o servidor e agente na máquina destinada a ser o monitorador;

5.2) Compilar e instalar o agente nas outras máquinas Linux;

5.3) Instalação dos binários dentro do Windows 2003 (com inicialização do agente como serviço);

5.4) Executar deploy do agente Zapcat no JBoss para monitoramento do


servidor de aplicações.

5.5) Testar o acesso ao SNMP de um switch a partir do monitorador.

6) Configuração de um virtual host dentro do Apache para o front end, incluindo modificação dos parâmetros do PHP.

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

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


Não há nada para ser restaurado, clique novamente em Avançar.



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

que o cenário possui. Preencha os campos como abaixo para configurar a primeira

conta e, em seguida, clique em Avançar.



1) Nome Completo: System administrator

2) Endereço de e-mail: [email protected].

1) Tipo de Servidor: devemos escolher POP, que é o recurso implantado para recepção de e-mails no cenário.

2) Servidor: é o endereço externo do servidor de e-mail.

3) Nome do usuário: O primeiro usuário que usaremos é o sysadmin.

4) Lembrar senha: para comodidade dos testes em curso ative o recurso de armazenamento de senha.

Esta opção não é segura para ser usada em produção! Mas como no

curso os usuários são fictícios e possuem a senha 123456 isso não vai nos

impactar.



Nesta tela, configure o recebimento automático a cada 1 minuto, assim não

precisamos ficar esperando e-mails chegarem e, também não precisamos ficar

clicando em Enviar/Receber a todo momento.



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.



1) Nome: Por final, configure um nome para esta conta. Isto é usado apenas para exibição no Evolution.



Esta é apenas uma tela de finalização, clique em Aplicar.

Torne o Evolution o seu cliente de e-mail padrão.




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 nenhum 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.3.2. Mensagens instantâneasReceber 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.



Na tela de boas vindas clique em Adicionar.

1) O protocolo Jabber usa a opção XMPP.

2) No nome do usuário use sysadmin.

Figura 2.12: Configurando uma conta Jabber no Pidgin

Figura 2.11: Tela de boas vindas do Pidgin


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 Lembrar Senha opção 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.

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

Figura 2.13: Definindo o uso de criptografia


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.5. 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órios (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 robustes se mostrou mais

adequada aos tipos de dados que o Zabbix trabalha.

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.

2.5.1. InstalaçãoPara instalar a versão do repositório do PostgreSQL:

# aptitude install postgresql-8.4


# yum install postgresql84-server

2.5.2. Criando o usuário e o bancoCom 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 convensão acima.

Somente o superusuário do PostgreSQL postgres tem permissão de realizar a

criação dos objetos citados acima, para podermos acessar o terminal de console do

banco (psql) temos que entrar como usuário postgres no linux e então usar o

comando. Note que o prompt de comando irá se alterar indicando que estamos no

console do PostgreSQL.

# su – postgres

$ psql

psql (8.4.5)

Digite "help" para ajuda.

postgres=#

Agora que conseguimos o acesso como superusuário, vamos primeiro criar o

banco de dados. O comando create database irá cuidar desta tarefa, note que todos

os comandos digitados dentro do 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!

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)

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 nome SET

bytea_output=escape;” dentro do console do psql. Isso pode ser

configurado no usuário ou no postgresql.conf também.

2.5.3. Carga inicialAgora 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 em frente neste capítulo.

2.5.4. Concedendo as permissões necessárias ao usuárioAgora é 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 em

produção

$ psql zabbixdb

postgres=# \a

postgres=# \t

postgres=# \o /tmp/grantzabbix.sql

postgres=# SELECT 'GRANT SELECT,UPDATE,DELETE,INSERT ON ' || schemaname || '.' ||

tablename || ' TO zabbix ;' FROM pg_tables;

postgres=# \o

postgres=# \i /tmp/grantzabbix.sql

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.6. Instalação do servidor


Zabbix via código fonte

Em alguns casos a distribuição de 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 que seja necessário uma

versão mais recente (devido a recursos novos, etc.) na sua solução de

monitoramento. Para suprir esta necessidade é preciso compilar o Zabbix a partir de

seu código fonte.

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

dependências devem ser instaladas e como escolher os recursos a serem compilados.

Via de regra se algum tipo de recurso não se mostrar necessário a princípio não o

ative, isso gera binários mais leves (com menos código embutido) e alivia o consumo

de memória em servidores com altas cargas de métricas sendo monitoradas.

Para começar, vamos instalar os dois pacotes mais básicos para compilação de

fontes no Debian, o 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, 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 faciliar 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 distribuidos. Como neste curso não abordaremos o sistema de proxy do Zabbix vamos deixar esta opção sempre desabilitada.

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

--enable-ipv6 Compila com suporte a IPV6. Embora não seja absolutamente necessário, dado ao recente anúcio 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

--with-libcurl Ativa o suporte a biblioteca de HTTP CURL. É necessária para o monitoramento de serviços Web e autentiação via HTTP.



--with-iodbc Ativa o suporte ao back end do bando de dados via ODBC. Não é recomendado.

--with-unixodbc Como o anterior mas usa unixODBC ao invés de iODBC. Este pacote é mais encontrado do que o iODBC.

--with-net-snmp Ativa o suporte a monitoramento via SNMP usando a biblioteca net-snmp do unix. Vamos deixá-la ativada.

--with-ucd-snmp Mesmo que o anterior, mas usando a biblioteca ucd, menos comum. Vamos deixá-la desativada.

--with-ssh2 Ativa suporte a monitoramento via SSH e verificação de status de um serviço de conexão remota segura. Vamos deixá-lo ativado.

--with-openipmi Ativa suporte a comandos e monitoramento de hardware por IPMI. Só é relevante quando o hardware que você vai monitorar e o S.O. Instalado nele possuem esta especificação. Para este curso deixaremos ele desativado.

--with-ldap Ativa suporte a autenticação via LDAP e monitoramento do status de um serviço de diretórios remoto. Vamos deixá-la ativada.

Tabela 1: Opções de compilação do Zabbix

2.6.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 depedê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

configure: error: PostgreSQL library not found

Pacote postgresql-8.4-dev

checking for IKSEMEL... configure: error: Jabber library not found

Pacote libiksemel-dev e acrescentar --with-jabber=/usr

configure: error: Curl library not found Pacote libcurl4-dev


Erro Dependência

configure: error: Invalid NET-SNMP directory - unable to find net-snmp-config

Pacote libsnmp-dev

configure: error: SSH2 library not found Pacote libssh2-1-dev

configure: error: Invalid LDAP directory - unable to find ldap.h

Pacote libldap2-dev

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.6.2. Compilando e instalandoAgora que o configure chegou ao ponto final e todas as dependências foram

resolvidas é hora de executar a compilação com o comando make, de fato 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 o comando os comandos, no final o comando ln irá

criar um link simbólico para /opt/zabbix. Isso é uma boa prática a ajuda 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 no 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 um descritivo de cada um deles.

Binário Funcionalidade

zabbix_get Utilitário para realizar consultas nos agentes via linha de comando. Muito útil, 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 item especial do tipo Zabbix trap para lidar com estes envios. Útil para alertar incidentes instantâneamente 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 como root, por isso vamos

criar um grupo e usuário de nome zabbix para que o serviço entrem na memória

como usuários não privilegiados.

O nome do usuário que o Zabbix usa é hadcoded, ou seja, ele é programado

dentro do código fonte e não pode ser alterado via configuração. Desse

modo sempre temos que criar o usuário com o nome zabbix, já o nome do

grupo é totalmente opcional.


# groupadd zabbix

# useradd -g zabbix -m -s /bin/bash zabbix

Ambos os daemons do agente e do servidor precisam de dois diretórios para

armazenar os logs e o arquivo de PID. Com os comandos abaixo crie e dê as

permissões necessárias para ambos.

# mkdir /var/{log,run}/zabbix -p

# chown zabbix. /var/{run,log}/zabbix

2.6.3. Serviços de redeAcrescente 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.6.4. Arquivos de configuraçãoOs 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 agente (carregado pelo arquivo principal)


Diretório ou arquivo Descrição

/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 extençã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 qual a quantidade 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 ver apenas as mais relevantes, porém os arquivos tem extensos

comentários em português criados pelo autor deste material.

# 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

1 export PATH=”$PATH:/opt/zabbix/sbin:/opt/zabbix/bin”

# . /etc/profile

# zabbix_get --help

# zabbix_agentd --help

2.6.5. Testando sua instalaçãoUtilize 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 contéudo do arquivo de logs e use os comandos ps e netstat para ver

quais os processos ele iniciou e em quais portas eles se vincularam.

Depois do termino com o agente vamos configurar o servidor conforme a

seguir e realizar o mesmo procedimento de inicialização e pesquisa que no agente.

# vim /etc/zabbix/server.d/database.conf

DBHost=127.0.0.1

DBPort=5432

DBName=zabbixdb

DBUser=zabbix

DBPassword=zabbixdbpw

1) O endereço IP ou nome DNS do servidor que esta com o banco de dados. Como no nosso cenário o banco e o servidor Zabbix estão na mesma máquina virtual utilizamos o endereço de loopback;


2) A porta TCP de acesso do banco, esta é a porta padrão do PostgreSQL;

3) Nome do banco de dados que criamos no início do capítulo;

4) Nome do usuário que criamos e demos permissão;

5) Senha do usuário acima.

Agora execute os comandos de inicialização dos daemons conforme indicado

abaixo.

# zabbix_agentd

# zabbix_server

Verifique se as últimas linhas do log indicam se ambos iniciaram

corretamente, e também se todos os processos estão na memória.

# tail -n1 /var/log/zabbix/zabbix_server.log

1203:20110207:092633.044 server #1 started [DB Cache]

# tail -n1 /var/log/zabbix/zabbix_agentd.log

871:20110207:092607.522 zabbix_agentd collector started

# ps u -C zabbix_agentd

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

zabbix 863 0.0 0.1 4836 496 ? SN 09:25 0:00 /opt/zabbix/sbin/zabbix_agentd

…

# ps u -C zabbix_server

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

zabbix 1201 0.0 1.0 46696 2636 ? SN 09:26 0:03 /opt/zabbix/sbin/zabbix_server

…

Note que a saída do último comando é muito grande. Ao final dos testes mate

os processos com o comando killall.

# killall zabbix_server zabbix_agentd

2.6.6. Scripts de bootNo 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.7. Instalação do agente Zabbix via compilação

Agora chegou o momento de instalar o agente do Zabbix nas outras máquinas

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

2.7.1. Exercício: compile e instale o agente nas VM com LinuxCom 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.7.2. Acesso ao agente pelo servidorAgora 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

netstat vamos 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

5 # passivas do servidor.

6 #

7 ListenIP=172.27.0.1

8 ListenPort=10050

9

10 # ============================================================================

11 # IP o qual o agente do Zabbix irá usar para enviar dados, é opcional pois o

12 # sistema usa o IP o qual esta designado a enviar dados conforme a tabela de

13 # roteamento.

14 #

15 SourceIP=

1) Mudar para o IP interno do Presentation.

Agora reinicie o agente e confira novamente a qual IP ele esta vículado.

# /etc/init.d/zabbix-agent restart

Stopping Zabbix agent daemon: zabbix_agentd

Starting Zabbix agent daemon: zabbix_agentd

# netstat -lntp | grep zabbix


Se o serviço agora estiver vinculado ao IP correto repita estes passos em cada

VM.

Neste ponto é importante paramos para que possamos verificar uma possível

falha de conexão. Vamos forçar a VM zabbixsrv tentar 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

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



PORT STATE SERVICE

10050/tcp open unknown



Se o estado retornado for open, então o servidor é capaz de se conectar ao

agente no nível da camada TCP, mas ainda precisamos ter certeza absoluta que ele

esta permitindo conexões no nível de camada de aplicação. Vamos repetir o teste com

o zabbix_get e ver se o agente retorna o valor 1.


←

Note que ele não retorna nada! Apenas uma linha em branco aparece no

resultado do comando. Isso esta ocorrendo porque o agente precisa liberar a

consulta para o servidor, por padrão os arquivos de configuração apenas permitem

que ele seja acessado a partir do localhost. Para liberar o acesso temos que editar o

arquivo /etc/zabbix/agent.d/checkings.conf e mudar dois parâmetros.

O primeiro, obviamente é o Server que aceita uma lista separada por vírgula


(,) dos endereços que são permitidos fazer a consulta. O segundo é o Hostname

representando o nome da máquina com o qual o agente deve se apresentar ao

servidor. Este nome deve ser único e não necessariamente precisa ser igual ao

hostname real da máquina, de fato no nosso cenário iremos deixá-lo diferente.

# vim /etc/zabbix/agent.d/checkings.conf

1 # Este é o arquivo para configuração de checagens no agente. Há dois tipos de

2 # checagens, a passiva e a ativa.

3 #

4 # Checagens passivas são o padrão, o servidor faz o agendamento das métricas e

5 # manda uma requisição ao agente que aguarda passivamente (dai o nome), este

6 # então coleta o dado do sistema e envia de volta ao servidor.

7 #

8 # Uma checagem ativa permite que o agente receba uma lista de itens a serem

9 # monitorados do servidor e ao invés deste último cuidar do agendamento e

10 # requisições é o agente que toma para si esta tarefa.

11 #

12 # Checagens ativas são úteis quando o Firewall não permite que o servidor de

13 # monitoramento alcance o agente via rede ou quando se utiliza um sistema de

14 # monitoramento de logs onde o monitoramento ativo é obrigatório.

15 #

16

17 # ============================================================================

18 # Quais são os servidores para recebimento de requisições ou obtenção da lista

19 # de checagens ativas.

20 Server=172.27.0.10

21

22 # ============================================================================

23 # Como este host esta cadastrado dentro do Zabbix. Isto não precisa corrsponder

24 # ao hostname da máquina ele é uma string de identificação do agente para com o

25 # servidor do Zabbix.

26 #

27 Hostname=Presentation

…

1) Sempre temos que mudar este parâmetro para o endereço do servidor ou nome DNS do mesmo. Se houverem mais de um servidor, separe os endereços/nome por vírgula;

2) Este é o nome a ser cadastrado no front end do Zabbix e não o nome de DNS (apesar que podem ser os mesmos).

Reinicie o agente mais uma vez e faça o teste com zabbix_get a partir do

servidor.



1 ←

Se o comando resultante retornou 1 então o servidor poderá acessar o agente

a partir de agora.

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


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


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


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


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.8.1. Executando o agente como serviçoInstalar 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


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, evitando que se

a máquina for reiniciada ele pare. Teste no servidor do Zabbix se ele esta

conseguindo alcançar o agente.

# zabbix_get -s win2003 -k 'agent.ping'

1

Se ele retornar 1 como acima, então a instalação esta concluída.

2.9. Instalação do agente Zapcat para JBoss

O Zabbix possui alguns agentes programado 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.

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


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.9.1. Obtenção do binárioSiga 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.9.2. DeploymentPara instalar o Zapcat, simplesmente copie o binário para a pasta de deploy da

instância em execução do JBoss. No nosso caso esta pasta é

/opt/jboss/server/application/deploy/.

# cp 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 anteriormente.

# netstat -lntp | grep ':1005'


tcp 0 0 0.0.0.0:10052 0.0.0.0:* OUÇA 29181/java


Repare que, como ele é um aplicativo java, o netstat não vai informar o nome

dele (Zapcat) na saída com -p.

2.9.3. Opções de inicialização do JBossO 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

…

JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"

JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"

JAVA_OPTS="$JAVA_OPTS

-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl

"

JAVA_OPTS="$JAVA_OPTS -Dorg.kjkoster.zapcat.zabbix.port=10052”

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.

2.9.4. Liberando o firewall para acesso ao ZapcatNo filtro de pacotes libere o acesso à porta 10052/TCP com os comandos

abaixo.

# iptables -A INPUT -j ACCEPT -p tcp --dport 10052


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

Figura 2.20: Tela de entrada do Zapcat


# 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::ifDescr.1 = STRING: lo

IF-MIB::ifDescr.2 = STRING: eth0




IF-MIB::ifDescr.6 = STRING: switch0

…

IF-MIB::ifSpecific.1 = 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.10.1. Conceitos de SNMPO 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 e das 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 .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 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.11. 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.

2.12. Preparando o servidor web

Como visto anteriormente o Zabbix é um sistema componetizado, 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.12.1. Instalação do Apache e PHP5Para 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.12.2. Configuração do Virtual HostPara 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

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

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.

Para ativar esta configuração realize o seguinte procedimento. 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



O primeiro acesso do front end vai enviar o browse direto para o wizzard de

inicialização do site. Siga os passos como descrito a seguir para ativar a interface.

2.12.3. Configurando o front end


A primeira tela é apenas um bem vindo, clique em Next para começar.

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


Marque a opção I agree para concordar com a licença do Zabbix e clique em

Next.



Nesta tela muitos alertas de falha irão aparecer, isso porque o Zabbix requer

uma configuração muito além dos padrões do PHP. Neste ponto é preciso editar o

arquivo de configuração do PHP e modificar os valores necessários.

Note que o status de cada parâmetro pode ser um OK em verde (o servidor já

esta configurado para o recomendado ou superior), Ok em vermelho claro (o servidor

já esta configurado para o mínimo, mas não alcançou o ideal) ou Fail em vermelho

que indica que nem o mínimo foi atingido. O ideal é deixar tudo no Recommended,

porém é preciso avaliar se o servidor terá os recursos necessários para a execução

dessas configurações. Normalmente teremos servidores que são capazes de fornecer

memória o suficiente para tal.

Com o vim abra o arquivo conforme abaixo.

# vim /etc/php5/apache2/php.ini

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



opções relevantes e configure-as para atingir o Recommendado.

Parâmetro do PHP Significado

date.timezone Qual fuso horário o PHP deve usar, mesmo que o seu sistema esteja corretamente configurado é importante configurar este parâmetro para o seu fuso horário (usualmente America/Sao_Paulo).

max_execution_time Tempo máximo que um processo do PHP pode rodar antes de ser morto.

max_input_time Tempo máximo que um processo do PHP pode gastar interpretando dados.

memory_limit O quanto uma única instância de execução do PHP pode usar de memória.

post_max_size O máximo tamanho que uma requisição POST pode enviar ao servidor.

upload_max_filesize Tamanho máximo para upload de um arquivo.

Depois de alterar e salvar o arquivo, reinicie o apache.

# /etc/init.d/apache2 reload

Então clique no botão Retry. A tela que será recarregada irá ser similar a

abaixo.


Se todos os pré-requisitos foram supridos clique em Next, senão refaça os

passos acima até conseguir chegar aos valores recomendados.

O suporte a GD do PHP no Debian Squeeze não atinge o recomendado mas

funciona se problemas com o Zabbix.



A tela de conexão ao banco de dados precisa ser preenchida conforme

explicação abaixo e Figura 2.26.

1) Escolha o banco de dados, no nosso cenário é o PostgreSQL.

2) Coloque o nome ou IP do host do banco de dados, no nosso caso é localhost.

3) Coloque a porta TCP para o acesso, por padrão a do PostgreSQL é 5432.

4) Em Name coloque o nome do banco de dados, zabbixdb em nosso caso.

5) Em User coloque o nome do usuário que criamos anteriormente, zabbix.

6) Em Password coloque a senha do usuário acima.



Depois de preencher o formulário clique em test connection para se certificar

de que tudo correu bem. Se um Ok aparecer acima do botão, clique em Next.



Preencha o formulário com os dados do serviço de monitoramento,

1) O servidor de Zabbix esta em localhost, mas atenção para ambientes de produção onde o servidor do Zabbix esta em outra máquina, neste caso deve ser preenchido o endereço ou nome da máquina remota.

2) O campo Port corresponde a porta TCP em que o Zabbix esta escutando (Zabbix trapper), normalmente esta porta é a 10051.

3) O Name é um título do serviço de front end do Zabbix. Este título vai ficar estampando na barra do browser e somente ajuda a identificar o front end quando você tem várias barras de navegação.



Repasse as configurações nesta tela e clique em Next se tudo estiver OK.



Esta janela indica que o arquivo de configuração foi gravado com sucesso no

diretório conf que deixamos com permissões de escrita anteriormente, é hora de

revogar as permissões de escrita neste diretório.

# cd /var/lib/zabbix/frontend/

# ls -lhd conf

drwxrwx--- 2 root 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

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

2.13. Exercícios de revisão


Figura 2.31: Tela inicial do Zabbix após o primeiro login


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ê usária para pegar apenas uma métrica?

______________________________________________________________________________

______________________________________________________________________________

5) Realize uma breve pesquisa na Internet e relacione todos os agentes de Zabbix que você encontrar.

______________________________________________________________________________

______________________________________________________________________________

6) Com o zabbix_get, colete via terminal de console o valor das chaves abaixo dos hosts win2003 e application:

6.1) agent.version: _________________________________________

6.2) system.cpu.num: _________________________________________

6.3) vm.memory.size: _________________________________________

7) (Desafio) Se você tentar usar o zabbix_get para coletar dados do Zapcat verá que ele vai falhar retornando um valor não suportado. Você consegue descobrir como, via linha de comando poderíamos coletar os valores deste agente? Se sim crie um pequeno script para fazer a coleta passando para ele host, porta e chave.

______________________________________________________________________________


______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

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

Capítulo 3

Criando uma Infraestrutura de

Monitoramento - Parte 2, Front end

3.1. Objetivos 1) Conhecer a configuração do Zabbix via Front end.

2) Gerenciar os hosts e templates para o monitoramento.

2.1) Criar métricas de monitoramento.

2.2) Depurar itens não suportados.

3) Gerenciar acessos e permissões aos hosts monitorados através de usuários cadastrados numa base LDAP.

4) Configurar os meios de alerta.

5) Criar mapas.

6) Realizar backups das configurações.

3.2. 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.2.1. Organização do front endOK, 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 passei 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 4 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.

• 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


Menu Função

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 disponiblidade por hosts ou triggers.

• Most busy triggers Top 100

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.

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


Menu Função

• DM Configuração de monitoramento distribuido.

• 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 fronte 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.3. 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.


Dois usuários serão exibidos: o Admin, superusuário do front end 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


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.

Agora que o Admin teve a senha modificada, é o momento de configurar o

Figura 3.2: Editando o Admin


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.

3.3.1. Cadastrando os usuários do LDAP no ZabbixApesar 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

Figura 3.3: Configurando a autenticação LDAP


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, 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 vamos definir suas permissões mais adiante.

Salve e escolha Users no combobox ao lado do botão Create Group, isso vai

nos fazer voltar à tela de usuários onde editamos o Admin. Clique no botão Create

User e cadastre os usuários da Tabela 5 conforme a Figura 3.5.

Figura 3.4: Novo Grupo JBoss Administrators


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 i

botão add para acrescentar a quais grupos o usuário pertence.

Um campo que merece uma atenção especial é o User Type que permite dar

alguns privilégios iniciais à conta. No nosso caso iremos utilizar o tipo mais simples,

o Zabbix User, que permite apenas acesso ao menu de monitoramento.

Podemos ainda criar outros dois tipos de usuários, 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 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

Figura 3.5: Novo usuário Sysadmin


seus tipos conforme a necessidade.

3.4. Meios de alertas

Os Media Types é a nomenclatura 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 estes

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 (coluna Description), se você

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

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, 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 muito

comum no curso. Ela será repetida em muitos outros locais.

3.4.1. Correio eletrônicoAgora edite o item de e-mail, a tela da Figura 3.7 será exibida, preencha os

Figura 3.6: Media Types


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.4.2. Mensagens instantâneasAgora iremos editar o Jabber, clique sobre o nome dele e preencha os campos

conforme a Figura 3.8.

Os campos Jabber identifier e Password são os 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.4.3. Apontando os alertas aos usuáriosAgora vamos dizer quais usuários usam qual Media Type. Abra o usuário

sysadmin e note que no final da tela um campo Media esta com o valor No media

defined.

Figura 3.7: Configurando o Zabbix para enviar e-mails

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


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.

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.

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

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


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

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.

3.4.4. Boas práticas com Media typesHá algumas recomendações a serem feitas quando se trabalha com alertas de

sistemas monitorados.

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

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

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


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

10) 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.5. Hosts, host groups e templates

Nesta sessão iremos abordar os conceitos mais fundamentais de

monitoramento do Zabbix: hosts, host groups e templates.

Hosts são a representação de um servidor, serviço ou ativo de rede a ser

monitorado. Eles normalmente representam um sistema físico, mas isso não é

totalmente verdade, o agente do Zapcat por exemplo, será representado por um host

a parte e ele não é um hardware.

Host groups separam logicamente os hosts e permitem que sejam atribuídas

permissões de acessos dos usuários a um determinado host.

Templates (modelos) são os blocos de construção do monitoramento, enquanto

não são obrigatórios, pois podemos acrescentar métricas de monitoramentos direto a

um host, eles ajudam a gerenciar de maneira efetiva os diversos tipos de

monitoramentos possíveis e replicá-los a tantos hosts o 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.5.1. Templates para o caso de estudoO 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 requerido 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.

Depois escolha no combobox no final da tabela o valor Delete selected with

linked elements e pressione o botão Go.

Repare que o Zabbix indica quantos elementos serão afetados pela ação do

combobox no botão Go no número entre parênteses.

Esta operação pode demorar alguns minutos dependendo da CPU e do I/O

de disco que seu equipamento possui.

Agora é o momento de criar o primeiro template.

Figura 3.13: Selecionando todos os templates pré cadastrados

Figura 3.14: Excluindo os templates selecionados


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.

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

Figura 3.16: Cadastrando um novo template

Figura 3.15: Criando um novo template


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 cria mais um último template para usarmos na prática dirigida, 4Linux – SNMP

Base também vinculado ao 4Linux – ICMP.

3.5.3. Backup dos templatesUma 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ê deseja.

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.

Figura 3.18: Exportando um template

Figura 3.17: Vinculando um template a outro


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

Também devemos criar alguns grupos adicionais para separar logicamente

cada servidor, para isso vamos gerenciar os Host Groups.

3.5.5. Gerenciando os Host GroupsUm 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


A seguinte tela irá surgir.

1) No campo Group name coloque o nome do novo grupo (Network Devices no nosso caso).

3.5.6. Criando um novo hostAgora 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.21: Novo host group

Figura 3.23: Botão para criar um host


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.


Crie todos os hosts do cenário conforme indicado na Figura 3.24.

3.5.7. Fazendo backup dos hostsO processo de backup dos hosts segue o mesmo procedimento dos do

template. Selecione todos os hosts criados e faça o backup dos mesmos.

3.5.8. Configurando uma permissão de acessoCom 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.

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.25: Concedendo permissões de acesso (1/4)


Figura 3.24: Todos os hosts do cenário cadastrados


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.5.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, crie grupos de hosts e usuários, e atribua permissões conforme for necessário para chegar a este resultado. Note que há um novo usuário

Usuário Applica-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 pelo usuário suporte e Admin, todos os usuários devem ter

permissão de mudança de configuração dos hosts que eles tem direito de

escrita.

3.6. 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.6.1. Importando imagens para o mapaAntes 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 forum 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.

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 importe 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.29: Tela inicial das imagens

Figura 3.30: Importando uma nova imagem


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 está

completo.

3.6.2. Criando um mapaAgora 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.

Este mapa não tem todos os elementos a serem inseridos no mapa, mas vai

proporcionar um bom primeiro exemplo. Abra a tela de gerenciamento de mapas

acessando o menu Configuration → Maps, um mapa pré-cadastrado (Local network)

irá ser exibido, marque a caixa de checagem dele e exclua ele da lista.

Figura 3.31: Imagem do primeiro mapa a ser criado


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.

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 exibí-lo).

Figura 3.32: Mapas pré-cadastrados

Figura 3.33: Novo mapa


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 (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 de primeiro momento.

3.6.3. Adicionando um elementoDentro 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,

Figura 3.34: Barra de ferramentas para edição de mapas


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 e 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, primeiro 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.

O Zabbix versão 1.6.x não erá capaz de usar Drag & Drop. Tudo tinha que

ser feito com coordenadas manuais.

3.6.4. Editando um elemento do mapaUma 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.

Figura 3.35: Criando um novo elemento

Figura 3.36: Posicionando um novo elemento com o mouse


Quando o ícone representa um elemento dinâmico ele vai reagir a mudanças

dos estados de qualquer 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.

1) Clique sobre o objeto criado anteriormente, a tela a direita irá ser exibida e pode ser reposicionada na tela para que você poder 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 definida 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

Figura 3.37: Editando um elemento na tela


de seleção.

6) Por fim podemos configurar as coordenadas da posição do elemento dentro do mapa em pixels. Normalmente fazemos isso pelo

No término clique em Apply para aceitar as modificações, isso não vai fechar a

tela de edição, para isso ainda temos que clicar em Close.

3.6.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. 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.6.6. Adicionando os outros elementosAgora adicione mais dois elementos no mapa para representar o host

Presentation e Switch e posicione-os como na Figura 3.40.

Figura 3.38: Botão Save do

mapa.

Figura 3.39: Dialogo de salvar mapa


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


1) Neste campo vamos escolher o valor host agora, 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 são personalizadas para a nossa necessidade.

3) Neste campo, que aparece sempre que escolhemos Host em Type clique em Select e escolha o host desejado. Neste caso é o Presentation.

4) Troque o ícone para Server On, visualmente ele deve representar uma máquina.

5) Ao ativar Use advanced icons os campos do item 6 serão exibidos. Isso permite escolhermos um ícone diferente para cada estado. Como foi mencionado anteriormente isso é um tanto redundante com o sistema de highlighting do mapa, mas vamos ativar ambos para que você veja a

Figura 3.41: Editando o elemento que representa o host Presentation


diferença entre eles.

5.1) Nestes campos escolha os ícones conforme indicado, cada um dos estados irá exibir um ícone diferente. Repare que o exibido na tela ao clicar em Apply é o Server Disable.

O mesmo será feito para o elemento do host Switch, a Figura 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


3.6.7. Criando e editando linksCom os elementos de hosts e imagens no mapa ainda falta criar o link que

interligam um elemento a outro. Os links podem tanto ser um simples traço para

mostrar uma ligação entre dois elementos como também podem ser usados para

demonstrar estados de gatilhos com problemas.

3.6.8. Exercícios sobre

Figura 3.43: Hosts acrescentados no mapa


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


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


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.6.9. Exercícios sobre Mapas 1) Faça upload das figuras do DVD, 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


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

Figura 3.48: Templates e seus elementos

Figura 3.47: Mapa final


2) Os Items são provavelmente o objeto mais importante dentro de todo o Zabbix. Eles são as definições das métricas de coletas. Quase que 90% de todo o trabalho de monitoramento gira em torno de um Item.

3) Os Triggers (ou gatilhos) montam a lógica para gerar alertas baseado na informação coletada pelos Items. A parte mais complexa do Zabbix é montar as expressões booleanas dos gatilhos de maneira concisa e equilibrada, evitando falsos positivos ao mesmo tempo que gera alertas em um tempo hábil. Inciaremos o estudo deles no próximo capítulo.

4) Os Graphs são elementos que exibem gráficos. Também iniciaremos seu estudo no próximo capítulo.

Nesta sessão nos concentraremos apenas os Applications e Items.

3.7.1. Criando um Application e um Item dentro de um templateAinda 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, neste caso ela seá 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.49: Criando um application (1/4)




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.53: Criando seu

primeiro item (1/3)


1) No campo Description coloque um identificador (de preferência único, mas isso não é necessário). O nome dele será o exibido em gráficos, usado em triggers, etc. Escolha coerentemente.

2) O Type indica como este item vai fazer a coleta de uma métrica. Os diversos tipos que serão abordados neste curso serão explicados nos próximos capítulos, aqui vamos usar Simple check que significa usar checagens via protocolo de rede.

3) O Key é o campo mais importante de todos, ele deve ser único dentro de cada template e host. Sua função é definir qual métrica será coletada. Como dito anteriormente um item é a parte mais importante de um template e o seu key é a parte mais importante de um item. Saber qual usar em qual situação faz parte da competência de usar a ferramenta e de criar um monitoramento eficaz. No nosso caso vamos criar um item que faz um ping via ICMP no host, logo a chave será icmpping. Clicar em Select abre uma janela com infindáveis keys, você pode selecioná-las por lá se desejar.

4) Repita “Cada item do Zabbix é capaz de armazenar apenas um, e somente

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


um valor”. Não é possível armazenar objetos complexos dentro dos items, por isso precisamos definir qual o formato que o valor será armazenado. No caso da key icmpping ele retorna 1 se o ping foi bem sucedido e 0 senã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, no 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 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 de vez.

7) Escolha o application ICMP que criamos anteriormente. Se existirem mais de um application nesta lista, você pode pressionar CTRL para selecionar vários.

Clique em Save para finalizar.

O resultado final é mostrado na Figura 3.55.

3.7.2. Interdependência de templatesEm várias situações práticas seremos obrigados a criar uma lógica de

checagens entre os triggers que irão gerar alertas e usar applications que estão em

outros templates. Isso só pode ser feito se criarmos templates que são associados a

outros. No nosso cenário de exemplos teremos vários casos deste tipo.

Normalmente os templates mais próximos a raiz são aqueles que realizam os

Figura 3.55: Criando seu primeiro item (3/3)


testes mais primários, como o template de ICMP criado anteriormente, de fato ele

será a raiz da maioria dos outros templates em destaque 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 o quanto precisar nesta tela.

A Figura 3.58 mostra como a tela ficará, isto indica que o novo template é

vinculado ao 4Linux – ICMP. 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

dependender 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


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

No diálogo que surgir, escolha o template desejado (4Linux – JBoss Base) e

Figura 3.61: Associando o template do JBoss ao host JBoss AS (1/6)



Figura 3.60: Inter-relação dos templates base


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 do(s) templates(s) escolhidos aparecer 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 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


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)


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.9. 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.72: Todos os templates associados aos hosts do cenário


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.9.1. Throubleshooting para items com problemasTecnicamente os templates e instalação estiver 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, e 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 devidamente funcionando, o

lugar correto para descobrir o que acontece esta dentro dos items 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


A Figura 3.76 mostra como o item ICMP Ping deve estar com problemas, note

que o Statu 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 acontencendo é o log do

servidor. Entre no console do Zabbix server e liste o final do arquivo de log

conforme abaixo.

# tail /var/log/zabbix/zabbix_server.log

2518:20110201:202018.896 server #18 started [Escalator]

2519:20110201:202018.900 server #19 started [Proxy Poller]

2506:20110201:202020.097 server #6 started [Poller. SNMP:YES]

2511:20110201:202020.108 Deleted 0 records from history and trends



2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]



2509:20110201:202023.022 /usr/sbin/fping: [2] No such file or directory

A última linha mostra a mesma mensagem que no front end. Para remediar

esta situação devemos instalar o fping pelo gerenciador de pacotes da distro que

estamos. No caso do Debian:

# aptitude install fping

Note que mesmo depois de instalar o aplicativo o erro persiste! Novamente

consulte os logs (ou o front end).

# tail /var/log/zabbix/zabbix_server.log


2511:20110201:202020.108 Deleted 0 records from history and trends

Figura 3.76: Item não suportado




2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]






Mesmo após instalar o pacote, o erro persiste! Então provavelmente o Zabbix

deve estar procurando o executável no lugar errado. Vamos usar o comando which

(pode ser o whereis também) para indicar onde ele esta 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 Linux para outra. O que fazer neste caso?

Simples mudaremos a configuração do servidor para se adequar ao ambiente em que

ele foi instalado. Edite o arquivo /etc/zabbix/zabbix_server.conf e procure as linhas

com as opções indicadas abaixo.

# vim /etc/zabbix/zabbix_server.conf

…

# ============================================================================

# Localização do programa de ping (ipv4 e ipv6)

#

FpingLocation=/usr/bin/fping

Fping6Location=/usr/bin/fping6

…

1) FpingLocaltion: indica o caminho do fping para pacotes ICMP usando IPV4. Mude para /usr/bin/fping.

2) Fping6Localtion: como acima, mas para IPV6. Mude para /usr/bin/fping6.

Com as opções modificadas reinicie o servidor.

# /etc/init.d/zabbix-server restart

Stopping Zabbix server daemon: zabbix_server

Starting Zabbix server daemon: zabbix_server

Confira no s logs se alguma outra mensagem apareceu e acesso


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á reestabelecido. A imagem abaixo mostra como ele deve

ficar ao final da operação.

Figura 3.77: Item suportado e ativo

Capítulo 4 Monitoramento voltado para disponibilidade - 122

Capítulo 4

Monitoramento voltado para

disponibilidade

4.1. Objetivos 1) Utilizar o Zabbix como uma ferramenta para medir disponibilidade:

1.1) Medir a disponibilidade dos equipamentos via checagens simples e agente (incluindo aqui o Zapcat)

1.2) Alertar quedas de hosts, serviços e reinicializações.

2) Medir a saúde da infraestrutura:

2.1) Latência de rede e de serviços.

2.2) Espaço em disco nos servidores.

2.3) Serviços ativos.

3) Interface

3.1) Teste manual.

3.2) Uso de gráficos e mapas.

3.3) Comandos externos.


4.2. 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 será visto 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.3. 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 como personalizar estes 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.


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 e

clique 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.1: Menu de Ferramentas acessado pelo

mapa

Figura 4.2: Saída de um comando ping


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 apenas (saltos de

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

• Liberar no firewall uma regra permitindo que o servidor do Zabbix alcance os hosts por UDP;

• Modificar o comando para que ele realize traceroute baseado em ICMP que já esta liberado no Firewall.

Nesta caso vamos optar pelo segundo item para demonstrar como alterar as

configurações destes comandos (que o Zabbix chama de scripts). Mas dependendo de

seu caso real pode ser preciso liberar o Firewall para permitir a passagem de

determinados pacotes.

Sempre cabe ao administrador ou gerente de rede tomar estas decisões

com base na simplicidade, segurança e necessidade do ambiente.

Infelizmente estas são regras que sempre entram em conflito, pondere

bastante para não deixar falhas de segurança e verifique se o comando a

ser habilitado é mesmo necessário.

4.3.1. Adequando o script de traceroute

Figura 4.3: Saída de um comando que falhou do 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

zabbix (e grupos ao qual esta conta pertença).

Este usuário não deve ter permissões de superusuário (conforme criamos o

mesmo 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

root tem direitos de criar pacotes da camada de rede arbitrariamente. Programas

como ping, fping entre outros tem permissão SUID ativa para garantir que usuários

convencionais sejam capazes de executar estes programas.

Evite usar SUID para dar permissões de execuções aos usuários normais!

Isso pode causar falhas de segurança.

Felizmente existe uma alternativa n 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, nunca se sabe quando uma nova falha vai sair.


Instale o sudo a partir do repositório do Debian no host Zabbix server.

# aptitude install sudo

Agora use o comando visudo para adicionar a permissão do usuário zabbix de

executar o comando traceroute.

# visudo

1 # /etc/sudoers

2 #

3 # This file MUST be edited with the 'visudo' command as root.

4 #

5 # See the man page for details on how to write a sudoers file.

6 #

7

8 Defaults env_reset

9

10 # Host alias specification

11

12 # User alias specification

13

14 # Cmnd alias specification

15

16 # User privilege specification

17 root ALL=(ALL) ALL

18

19 # Allow members of group sudo to execute any command

20 # (Note that later entries override this, so you might need to move

21 # it further down)

22 %sudo ALL=(ALL) ALL

23 #

24 #includedir /etc/sudoers.d

25

26 zabbix ALL = NOPASSWD: /usr/bin/traceroute

Salve o arquivo e teste novamente o comando usando agora o sudo antes dele.

# su – zabbix

$ sudo traceroute -I win2003

traceroute to win2003 (172.28.0.10), 30 hops max, 60 byte packets

1 gateway.curso468.4linux.com.br (172.27.0.1) 0.980 ms 0.855 ms 0.926 ms

2 172.28.0.10 (172.28.0.10) 3.805 ms 4.292 ms 4.211 ms

Voilá! Seu usuário Zabbix já consegue usar o comando no sistema, vamos

voltar ao front end. Entre em Administration → Scripts e clique sobre o nome do


comando Traceroute. Uma tela de edição do script irá surgir.

No campo Command modifique o valor, colocando sudo seguido de espaço

antes do traceroute e clique em Save. Agora volte até o mapa (Monitoring → Maps)

e execute o comando em vários hosts.

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.3.2. Criando novos comandos para o menuQuando 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

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


de testes de portas de serviços TCP.

Para exemplificar este caso, vamos criar um script que chama um comand

nmap testando a porta 22/TCP (SSH) dos servidores Linux em nosso cenário. Voleta

em Administration → Scripts.

Clique sobre o botão Create script conforme a Figura 4.5 para cessar 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 -P0 -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 qure precisam executar alguns

comandos compensa criar um grupo de usuários só para isso e atribuir

quais usuário 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.

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)


4) Host groups: indica em quais grupos de hosts um comando pode ser executado. Em combinação com a opção anterior é possível criar regras bem complexas. Além disso não faz sentido testar um SSH em um Windows por exemplo. Escolha Linux servers.

5) Qual tipo de permissão o grupo do usuário deve ter no host groups para exibir o comando. Ao menos permissão de READ é requerido.

Depois de cadastrar os campos clique em Save e vá até o mapa para testar o

comando. Clique sobre um host Linux.

A Figura 4.7 demonstra como o popup deve ter ficado. 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

Figura 4.7: Nova entrada de menu com o script criado

Figura 4.8: Resultado do comando ativado no host


comando.

4.3.3. Exercícios 1) Faça com 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 Windows. Somente os usuário 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 o usuário 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 o usuário 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.4. 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 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.4.1. Como funciona o ping ICMPO ICMP (Internet Control Message Protocol) é um protocolo da camada de

rede do modelo TCP/IP responsável por trocar mensagens de controles entre os hosts


(por exemplo, falhas de rotas).

O utilitário ping, o 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





Note que para todos os pacotes echo request, um echo reply retorna do

destino.

4.4.2. Visualizando o ping ICMP no Front endPodemos visualizar o resultado dentro da tela de Overview do front end,

acesse Monitoring → Overview para exibí-la.

Figura 4.9: Diagrama de comportamento do echo ICMP


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 selecione Value Maps. Aproveite a deixa e apague todos eles

exceto pelo Service State e Windows Services, vamos sempre manter 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.

2) Mapping e New mapping: Estes campo permitem a edição dos valores que são mapeados. Clique sobre os valores de Up e Down e no botão Delete

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


Selected para removê-los e 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 comapo 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.4.3. Criando um gatilho de parada de hostEmbora já saibamos qual host esta em pé, 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 nossos hosts.

Primeiro pause uma das máquinas virtuais (o exemplo utiliza o Database),

pelo console do Virtual Box selecione o menu Machine → Pause (Ou use CTRL

Direito + P).

Figura 4.13: Value map editado e pronto para uso

Figura 4.14: Selecionando um value map no trigger

Figura 4.15: Values maps no overview


Depois de alguns segundos (dez para ser mais exato) o overview vai indicar

que o Database esta parado.

1) Caso deseje você pode 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 despause a máquina virtual, assim o trigger entrará desligado.

Um trigger (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 uma simples teste boleana como o que usaremos agora 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

Figura 4.16: Pausando o host Database

Figura 4.17: Host database parado no overview


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 alertas. Por isso o nome deles permitem que contenham macros. No exemplo desta prática dirigida usamos o valor Host {HOSTNAME} inalcançável. Onde {HOSTNAME} será substituído pelo nome do host que o trigger foi ativado.

2) Expression: é onde iremos escrever o teste do gatilho, sua expressão boleana. Clique em Toggle input method para mudar o modo de escrita do gatilho, por padrão teríamos que escrever a expressão na mão, mas como você ainda esta iniciando no Zabbix iremos usar o auxiliar de expressões.

Note que a tela vai mudar conforme a Figura 4.21, para criar nossa expressão

use o botão Edit. A tela Condition irá surgir para que possamos montar a opção do

teste.

Figura 4.18: Criando um trigger para a parada do host (1/9)





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 gatillho, 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 analisados, vamos selecionar 1 coleta (a última).

4) N: O valor de N na expressão da função escolhida no item 2. É 0 no 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 para trás. Não usaremos ele ainda.

Clique no botão Insert para retornar a tela anterior.

Veja que o construtor de expressão já escreveu para nós toda a fórmula. O

valor {4Linux – ICMP:icmpping.last(#1)}=0 é o resultado final das escolhas feitas na

tela anterior. Ela esta no formato {Template:item.função(parâmetros)}=valor, não se

preocupe tanto com isso por enquanto, mas você deve ser capaz de ler as expressões

e compará-las com o gerador automático pois no manual as referências são

mostradas como o nome de cada função e não pelos menus. Para acrescentá-la use o

botão Add.




É um erro muito comum dos iniciantes (e mesmo de alguns veteranos) que

esqueçamos de clicar em Add. No caso de você receber um erro ao salvar

dizendo que a expressão é inválida verifique se você deixou de adicionar a

fórmula.

Com a nova expressão ativada podemos nos ater a outros pontos do trigger.

O botão Test pode ajudar a resolver uma expressão mais complexa, mas

tenha em mente que a entrada de dados da expressão só pode ser obtida

manualmente (você vai digitá-las). Não é possível coletar os dados do item

para averiguar se você fez certo.

1) The trigger depends on: aqui podemos escolher se este trigger depende de outros de forma que ele não seja ativado se outro mais básico esta com status PROBLEM. Vamos ver dependências mais a frente, por hora deixe vazio.

2) Event generation: indica se o trigger vai gerar um evento apenas uma ou múltiplas vezes.

3) Severity: um dos campos mais importante de todos, indica o quão problemático pode ser a ocorrencia de um incidente.

4) Comments: um texto explicando o que este trigger representa e o que acarreta ele esta ligado. Útil para o pessoal de primeiro nível de suporte




que não tem conhecimento profundo do sistema.

Clique em Save para finalizar este passo.

O gatilho deve estar sendo exibido na lista de triggers.

4.4.4. Lidando com os eventosTodo 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 suar 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.27: Indicação de problemas no Dashboard


O Mapa também deve estar mostrando o status do trigger no host Database,

vá até Monitoring → Maps e repare 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.29: Overview com visualização dos triggers ativos

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


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.

Repare que a coluna Status tem duas linhas, uma para a ativação do trigger e

outra para a desativação. Este comportamento é desejado pois sabemos por quanto

Figura 4.30: Mapa indicando o host Database como down

Figura 4.31: Tela de Events, indicando a queda e o retorno dos hosts


tempo um determinado trigger ficou ativo (e por consequência, por quanto tempo o

incidente ocorreu na sua infra), consulte a coluna Duration para isso.

Na coluna Duration se um evento mudou de estado uma última vez, o valor

mostrado indica o tempo desde aquele ponto até o 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.

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.4.5. Criando uma action para envio de alerta

Figura 4.33: Acknowledge (confirmação) aplicado

Figura 4.32: Tela de acknowledgement


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.

1) Name: indica o nome da ação, 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.

Figura 4.34: Criando um action para enviar o alerta (1/9)



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 este

action será disparado. 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.

Agora precisamos escolher o que a action deve fazer. No qaudro 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.




Figura 4.39: Criando um action

para enviar o alerta (6/9)


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 eviada, podemos escolher grupos ou usuários em particular. Para o nosso caso, um aparada de ping deve ser enviada ao grupo Network administrattors.

3) Send only to: aqui escolhemos quais media types devemos usar, podendo 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.

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). Repare que os valores das macros foram substituídos pelo Zabbix.

4.4.6. Exercícios 1) Aproveite o momento que você tem com uma action plenamente funcional

e consulte o manual on-line do Zabbix para que você veja 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.43: Mensagens de alerta recebidas no Evolution


4.4.7. Boas práticas com triggersSe 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 de 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 ser

limitar a verificar um único valor de mudança de estado na maioria das vezes. É

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


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, apnas

uma reinicialização.

Note que ao 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

contraprodutivo isso reduz o risco de envio de mensagens de alerta a toa,

dependendo do tipo de mensagem, isso pode inclusive representar uma ecônomia

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

noeste 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, a melhor

Figura 4.45: Lógica de um gatilho com tempo de segurança


maneira de se planejar tudo isso é começar pequeno e cobrir novas

necessidades conforme ela aparece. “Receitas de bolo” como a ITIL são

excelentes passos para se decidir por onde e quando começar.

Vamos então criar um trigger com uma janela de tempo. Edite a condição do

nosso trigger criado anteriormente, acessando Configuration → Templates, clique

no valor triggers do template 4Linux – ICMP e depois abra a condição do gatilho.

Dois campos serão alerados 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 usaremos 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 laerta 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 sistema, 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 muito pequenas tendem a gerar falsos

positivos. Tente achar o equilíbrio.

4.5. Checagem genérica de portas e serviços

Como dito anteriormente ICMP requests podem ser barrados por Firewalls. Se

este for o seu caso, então você não pode depender deles para medir a sua


disponibilidade e deve recorrer a outros métodos, neste tópico veremos um muito

comum, a checagem de portas TCP.

4.5.1. Conexões TCP e handshakesComo se dá a verificação remota de um serviço rodando em um soquete TCP?

Vamos fazer uma pequena prática para a verificação do mesmo e entender o famoso

Three wy handshake do protocolo TCP.

Primeiro ative no host Application o seguinte comando:

# tshark -ni eth0 host 172.27.0.10 and port 8080


Capturing on eth0

O tshark é o comando de linhas de console do Wireshark, e é muito mais

poderoso que o tcpdump. No caso do comando acima pedimos que ele capture todo

o trafego da interface eth0 que vier do Zabbix server e usar a porta 8080.

Agora no servidor do Zabbix de nosso cenário, use o comando nmap para

varrer a porta 8080 do host Application.

# nmap -sT -P0 -p 8080 172.27.0.20


Interesting ports on application.curso468.4linux.com.br (172.27.0.20):

PORT STATE SERVICE

8080/tcp open http-proxy


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.



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

1 O SYN Scan é um método considerado furtivo antigamente. Ele fazia apenas metade dos passos para abertura de uma conexão.


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

Repare que 4 pacotes foram trocados. O primeiro é o SYN (syncronization)

que pede a abertura da conexão, o segundo que parte do servidor de destino como

resposta é o SYN/ACK (syncronization and acknowledgement) que confirma a

abertura de pacotes e o terceiro é o ACK apenas para concluir a abertura. O nmap

usar ainda um último pacote para resetar a conexão (RST, ACK) que não vem ao caso.

A troca destes pacotes nesta ordem é o esperado pelas funções de soquete do

sistema operacional, se ela for realizada dessa forma isso significa que a porta

remota esta em estado de escuta (listening) ou que esta aberta. Mas ai vem a

pergunta e uma porta fechada, o que retorna? Vamos seguir com a prática,

novamente no host application execute os seguintes comandos.




Capturing on eth0

O iptables libera no filtro de pacotes de entrada a porta 10000/TCP. Agora a

partir do servidor Zabbix varra a porta 10000.

# nmap -sT -P0 -p 10000 172.27.0.20



PORT STATE SERVICE

10000/tcp closed snet-sensor-mgmt


Note o estado closed da saída do nmap! Vá até o tshark do Application e veja

o trafego dos pacotes capturado pelo tshark.



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.5.2. Criando um teste de serviço via varredura de portasOK, com estes dados em mãos vamos criar uma situação onde haverá três

casos de portas: aberta, fechada e filtrada por firewall.

Não existe uma maneira confiável de se checar serviços que usam UDP sem

apelar para a camada de apresentação do modelo TCP/IP.

Primeiro pare o serviço de SSH no database.

# /etc/init.d/ssh stop

Depois remova a regras de permissão de acesso de SSH da Application.

# iptables -D INPUT -j ACCEPT -p tcp --dport 22

A partir do zabbixsrv faça a seguinte varredura de portas.

# nmap -p 22 application presentation database -P0



PORT STATE SERVICE

22/tcp filtered ssh

MAC Address: 08:00:27:4B:97:E3 (Cadmus Computer Systems)


PORT STATE SERVICE

22/tcp open ssh



Interesting ports on database.curso468.4linux.com.br (172.27.0.30):

PORT STATE SERVICE

22/tcp closed ssh

MAC Address: 08:00:27:A3:73:61 (Cadmus Computer Systems)

Nmap done: 3 IP addresses (3 hosts up) scanned in 0.48 seconds

Note que no Database que desligamos o SSH retornou closed e o firewall do

Application retornou filtered, somente o Presentation deu um open. Anote este

resultados pois iremos compará-los com o que o Zabbix retornar.

No template 4Linux – S.O. Linux crie um novo item de simple check com a key

ssh. Para que o servidor possa usá-la é preciso que ele esteja compilado com suporte

a libSSH (opção --enable-libssh).

1) Key: a chave ssh faz um teste na porta 22 dos servidores.Figura 4.46: Simple check para o SSH


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.

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

ICMP.

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


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.6. 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 em nível de 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.6.1. Disponibilidade do site.O Zabbix denomina um teste de um site como um scenario (cenário), dentro

deste cenário há vários elementos chamados de steps (passos) que correspondem a

uma requisição 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

(normalmente 200 OK). Mas estas checagens tem outros itens embutidos nela. O

servidor calcula automaticamente a latência de rede e a velocidade de download dos


dados na URL e já gera gráficos destas estatísticas. Um trigger também é criado

automaticamente para alertar códigos de retornos inesperados ou falta em uma

determinada string na página de resposta. Ele no entanto, não gera uma action

sozinho.

Muitas destas funcionalidades são encontradas em outras ferramentas como o

JMeter (que possui asserts capazes de realizar este tipo de verificação), porém uma

solução não substitui a outra, pois a intenção do Zabbix não é ser um validador de

aplicativos web e sim um verificador de funcionalidades pontuais de URL. Ele

também não deve ser usado como gerador de cargas para testes de performance. No

entanto o Zabbix consegue armazenar o histórico de resultados on-line e por um

longo tempo.

Para criar um novo cenário acesso 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)



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 moneto do monitoramento. O valor que colocamos é Teste de aplicação PHP no Apache.

3) Authetication: no caso da URL requerer algum tipo de autenticação HTTP, você pode escolhê-la aqui. Não há necessidade de autenticação no nosso exemplo.

4) Update inverval (in sec): mesmo que nos itens, 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 o qual ele vai se passar.

6) Status: Se ele esta ou ativo.

7) Variables: um conjunto de variáveis para serem enviadas ao servidor. Deixe em branco neste caso.

Note que em lugar algum foi definido qual a Url que este cenário vai acessar.

Isso porque é possível definir várias URLs dentro dele, cada uma é um step. Clique

no botão Add do campo Steps para criar um novo passo.



1) Name: O nome deste step, normalmente representa a URL a ser testada (por exemplo página principal, carrinho de compras, blog, etc.)

2) URL: a URL a ser acessada, pode incluir parâmetros de método GET se desejado. No nosso caso colocaremos phpapp.curso468.4linux.com.br.

3) Post: se a á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.


http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


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

clicnaod 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, 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.54: Visualizando a checagem Web




Como você pode ver, a criação de um cenário é simples, mas permite uma

flexibilidade muito grande. Vamos em seguida ver como realizar uma validação de

um formulário web.

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

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


esperada.

4.7. Checando disponibilidade via agentes

As duas simple checks icmpping e ssh que usamos e o cenário web criado não

utilizam o agente (são denomiadas 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, 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 simples e depois passaremos a checar métricas de sistema

operacional muito mais ricas.

4.7.1. Checando se o agente esta operacionalO 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 funionando 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) e requer um

tratamento especial para o caso. Vá até a tela de items 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.


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.58: Novo item para monitorar o agente

Figura 4.59: Copiando o item de ping de agente para o template do JBoss (1/2)


1) Target Type: esta parte 'um pouco confusa, pois antigamente o Zabbix não diferenciava hosts e templates (de fato ele ainda faz pouca dissociação entre eles algumas vezes). Você vai escolher Host neste campo para que logo abaixo possa escolher os templates.

2) Group: escolha o host group Templates.

3) Target: marque o template do JBoss como indicado.

Clique em Copy para finalizar a operação. O item agora faz parte de ambos

templates. Confira pelo Overview se todos os hosts Linux e Window, além do JBoss é

claro, estão com este item funcionando.

4.7.2. Criando um trigger com a função nodata()Agora vamos criar um trigger que opera com a função nodata() conforme

anteriormente citado. 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 também devido a herança entre eles.

Figura 4.60: Copiando o item de ping de agente para o template do JBoss (2/2)


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)



Adicione a expressão ao trigger.

Agora vamos adicionar uma dependência a este trigger, ele só deve ser

avaliado no caso do 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 mensagens), segundo permite que o Zabbix não perca tempo com

processamento de gatilhos que são desnecessários para a ocasião (que gastam tempo

de CPU no servidor de monitoramento). No nosso cenário se o host não estiver

respondendo à requisição ICMP é inútil testar o agente.

Note que isto pode não ser verdade no cenário de sua empresa! Avaliar a

dependência dos triggers é importante quando se está construindo uma

solução eficiente de monitoramento.

Clique no botão Add e selecione o trigger do ICMP.

Note que agora ele aparece na lista de dependências. Salve o novo gatilho.




Figura 4.66: Trigger para o agent ping criado e ativo


Repare que ambas a dependência e a nova função aparece 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.

Repare 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


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.7.3. Exercícios 1) Copie o trigger para o template do JBoss.

2) Crie os actions necessários 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.8. 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 Linux, Windows, switch e a

máquina virtual java na qual o JBoss é executado. Isso nos dá três casos de coleta:

pelo agente normal, pelo agente Zapcat e pelo SNMP.


Isso vai demonstrar como o sistema do Zabbix consegue lidar com ambiente

heterogêneos e vai demonstrar que depois da coleta o tratamento, armazenamento e

análise não muda.

O primeiro passo é analisar o retorno dos valores via console, isso é

importante para que tenhamos parâmetros de tipos de dados (inteiros, float); nome

correto das keys, OIDs, etc e acesso. O agente do Zabbix possui uma key chamada

system.uptime que retorna o tempo desde o último boot, de maneira equivalente o

JBoss tem um JMX java.lang:type=Runtime,Uptime que também saz 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.13, página 68 pode usar o seu script em

vez do segundo comando.

Cada comando retornou um valor inteiro, todos representando o uptime do

sistema. A grande diferença entre eles é a precisão de tempo utilizada, o agente do

Zabbix retorna o valor em segundos, o Zapcat em milissegundos e o agente SNMP

em centésimos de segundos (que ele chama de timeticks).

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

lida com os números destacados em negrito apenas.

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

configuração de cada item. Primeiro vamos coletar o dado do agente do Zabbix, no

template 4Linux – S.O. Base crie um novo item conforme a seguir.


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


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 os Mbeans estão disponíveis em um servidor com o

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 no curso 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 a usada, consulte o manual de seu fabricante. Esta

Figura 4.70: Uptime via Zapcat

Figura 4.71: Uptime via SNMP

http://javaapp.curso468.4linux.com.br/zapcat-1.2/mbeans.jsp


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.

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 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 o Zabbix sabe trabalhar.

Novamente, isso demonstrou a capacidade em coletar dados de ambiente

heterogêneos, desde que você tenha um agente suportado não há problemas. O

agente padrão do Zabbix é compatível com 9 sistemas operacionais do mercado, as

JVMs com Tomcat e/ou JBoss são suportadas pelo Zapcat e a maioria esmagadora de

ativos de redes (desde switches até impressoras, passando por no-breaks) suportam

Figura 4.72: Overview exibindo os uptimes a partir do agente padrão, Zapcat e SNMP


alguma versão de SNMP hoje em dia.

4.8.1. Trigger para alerta de reinicializaçãoAvaliar 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 1 hora como sendo menor do que 1800 (meia hora). Dois pontos importantes aqui: primeiro o tempo de janela da função last() deve ser sempre maior do que o valor comparado e segundo, o tempo de ativação deve ser maior do que o tempo de coleta.

2) Trigger depends on: coloque como dependência deste trigger o da verificação do agente. Não há sentido em tentar analisar uma métrica que não esta sendo recebida. Isso evita que ela apresente valores desconhecidos.

4.8.2. Exercícios

Figura 4.73: Um trigger para a reinicialização de um host


1) Crie as triggers para os templates do JBoss e do SNMP.

2) Cria 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 167 para detalhes).

4.9. 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 poder 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.9.1. Verificando os processos ativos na memóriaO 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 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 rodando um determinado processo ou conjunto de processos. O padrão é verificar de todos os processos.

• state: qual o estado do processo, podendo ser all (padrão), run, sleep, 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 portante

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ção 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 dele ainda.

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.


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

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

Figura 4.75: Overview refletindo o número de processos


processos. Note que o número de processos do host Zabbix Server esta com 2

porque há uma conexão ssh ocorrendo nele, nos outros apenas o daemon aguardando

a conexão está sendo executado.

Com os dados sendo coletado já podemos criar um trigger.

1) A condição do trigger é bem padrão em relação as nossas 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 do 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, ainda é classificado como erro e precisa de intervenção imeditada.

Salve o trigger e vá até o console do host Database e para o SSH.


Acesse a lista de eventos em Monitoring → Events para acompanhar a

Figura 4.76: Trigger para queda do daemon


ativação do 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.9.2. Checagem de portas e serviços localmente via agenteAlé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


Após a criação do item, verifique se a coleta esta sendo realizada. Se tudo

estiver ok é 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 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 estremo poder, e mesmo sem expressões

booleanas complexas dentro de cada trigger seremos capazes de determinar qual o

possível ocorrido 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


O primeiro trigger (cada um é representado pelo losango) é o que criamos

anteriormente para verificar se há ao menos um processo sshd no ar. No caso de não

haver nenhum ele deve alertar o administrador responsável pelo serviço. Note que,

se realmente não há nenhum tipo de processo do serviço sendo executado então não

há sentido em verificar portas, correto?

O segundo é a análise da porta localmente a partir do agente, se não há

processos escutando na porta a partir da própria máquina local então o processo

master da aplicação provavelmente caiu. Note que se você parar o ssh pelo serviço

de boot as conexões que estão em andamento não são interrompidas! Logo é possível

ter uma situação onde há processos sshd na memória que estão apenas atendendo a

conexões que foram estabelecidas anteriormente à queda do processo principal e só

vão morrer se estas conexões forem encerradas.

Esse tipo de comportamento é muito comum em serviços que são baseados em

forks, como o Apache, o próprio Zabbix, muitos daemons escritos em Perl, etc.

Programas que trabalham puramente com threads como as aplicações feitas

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


em java incluindo aqui o Tomcat e o JBoss tem um processo monolítico e não

seguem esta regra.

Pro fim, 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 estão 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 a menos que tudo esteja na mais perfeita ordem. Se um dos mais primários

falharem então os outros que são checados depois são pulados.

Obviamente podem 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, o primeiro já esta pronto desde o tópico anterior.


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


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.9.3. Exercícios 1) Agora teste os gatilhos realizando as seguintes tarefas:

1.1) Pare o daemon ssh de um Linux sem conexões abertas para ele (somente o primeiro gatilho deve disparar). Restaure o daemon.

1.2) Pare o daemon ssh de um 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 Linux, somente o terceiro gatilho deve disparar. Restaure a regra após o termino.

4.9.4. Verificando serviços no WindowsAssim como o Linux, o Windows tem seu sistema de gerenciamento do

serviços ativos na memória. Usamos ele no tópico 2.8.1. , página 48 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


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


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 é reforçado, no Windows inclua a extençã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


Note que o resultado foi zero. Isso porque zero significa rodando, esperimente

pausar o serviço no Windows e execute o comando novamente.

# zabbix_get -s win2003 -k 'service_state[TlntSvr]'

1

Agora retornou 1. Sim, parece contraprodutivo, 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.


Clique em Adicionar Porta... e preencha a janela que aparecer conforme

indicado a seguir.

1) Nome: O nome do serviço, apenas um label para o Firewall, coloque telnet.

Figura 4.87: Liberando o telnet no firewall do Windows (1/3)



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.

# nmap -P0 -p 23 win2003


Interesting ports on 172.28.0.10:

PORT STATE SERVICE

23/tcp open telnet


# telnet win2003

Trying 172.28.0.10...

Connected to win2003.curso468.4linux.com.br.



Escape character is '^]'.

Welcome to Microsoft Telnet Service

login: administrador

password:

*===============================================================

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.

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

Figura 4.90: item para monitorar serviços Windows


state.

Verifique que no Overview o serviços esta aparecendo e funcionando.

4.9.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, tão pouco é 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ção para tal procedimento. Eleja uma das máquinas virtuais 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.

Figura 4.91: Estado do serviço Telnet no Overview


3

4 # ============================================================================

5 # Liga/Desliga o recurso de comandos remotos do agente.

6 #

7 # Este tipo de feature vem desligada por padrão devido ao risco de segurança

8 # que ela pode apresentar se mal configurada.

9 #

10 # Note que o usuário do Zabbix tem que ter direitos de execução do comando em

11 # questão enviado pelo servidor. Para isso ou ele é executado como root

12 # (desaconselhável) ou chama executáveis com suid (desaconselhável) ou utiliza

13 # sudo para rodar os comandos. Este último é a opção mais segura das três, mas

14 # requer configurações extras no arquivo sudoers.

15 #

16 EnableRemoteCommands=1

17

18 # ============================================================================

19 # No caso de habilitada a execução de comandos remotos, é aconselhável deixar

20 # esta opção ativada para auditoria do sistema. Ela vai registrar no arquivo

21 # de logs do agente quando e qual comando foi executado (ou no mínimo foi

22 # tentado).

23 #

24 LogRemoteCommands=1


é preciso mudar para 1 ambos EnableRemoteCommands e

LogRemoteCommands. Seus nomes são bem subjetivos, e apesar de não haver

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

inicialização do ssh.


# visudo

…

zabbix ALL = NOPASSWD: /usr/init.d/ssh start

Seja metódico e só defina 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

Você não quer que o serviço seja reiniciado quando o gatilho voltar a OK,

certo?

As outras duas possibilidades é o trigger de processo ou de checagem local de

Figura 4.92: Action para parada do SSH (1/3)



portas forem os ativados. Qualquer um deles que apresentar PROBLEM dispara esta

ação.

Uma mensagem para os envolvidos do host deve ser remetida. 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. No nosso caso usamos Database:sudo /etc/init.d/ssh start.

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 que você configurou o agente para aceitar

comandos remotos e pare o serviço de SSH, em seguida abra o log e aguarde.


# tail /var/log/zabbix/zabbix_agentd.log -f

…

7287:20110215:192625.462 Executing command 'sudo /etc/init.d/ssh start'

Starting OpenBSD Secure Shell server: sshd.

Se você voltar à tela de eventos verá que há dois deles, um de queda e outro

Figura 4.95: Comando remoto para o action de parada do serviço de SSH



de volta.

4.9.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 um 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 um 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.10. 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.10.1. Latência de redeO primeiro ponto que vamos analisar é causas de indisponibilidade por

excesso de trafego na rede. Note que medir a banda pode ajudar a identificar

gargalos de rede, mas a métrica mais indicada para medir lentidão é a latência de

rede que pode estar baixa mesmo quando não há trafego! Como sempre vamos

começar com a criação do item dentro do template 4Linux – ICMP.

A chave icmppingsec também faz um ping como a icmpping, mas diferente

desta ela retorna o número de segundos que o pacote levou para ir e voltar (na

verdade a média de três pacotes).


Neste item, atente para o campo Units que contém o valor s (segundos). Ele

irá formatar o valor recebido pelo item para uma forma legível por seres humanos. E

mais importante, desta vez Type of Information esta como Numeric (float), porque

o retorno da key icmppingsec é em segundos, mas normalmente os tempos de

respostas são quebrados em três casas decimais (milissegundos).

4.10.2. Macro para o limiar da latência de redeUm 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

qualquer ambientes podemos usar um recurso muito interessante do Zabbix chamado

macros de usuários.

Figura 4.96: Item para latência de rede


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 valem só para aquele host. Se você redefinir (como vamos fazer) uma macro num

ambiente mais restrito, o irá valer será este último.

O Zabbix tem várias macros internas que já tivemos contatos quando criamos

nossos triggers, {HOSTNAME}, 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.

Acrescente os valores conforme a Figura 4.97 e salve o template. Ela já estará

valendo para todos os hosts associados a ele, vamos agora usá-la no gatilho para

verificação de latência alta de rede. Crie o trigger no template conforme a seguir.

Figura 4.97: Macro para latência de rede


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.10.3. Nosso primeiro gráficoVamos agora criar um gráfico que irá usar esta trigger para exibir o limiar de

teste na tela. O resultado será similar ao da Figura 4.99.

Figura 4.98: Trigger para latência de rede usando a macro


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.

3) Graph type: O tipo de gráfico, aqui vamos criar um Normal mas podemos

Figura 4.100: Criando um gráfico de latência de rede

Figura 4.99: Gráfico para medir a latência de rede


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: valor mínimo do gráfico e máximo. Ú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 é Simples ou Agregated. Campos agregados agrupam várias contagem em um único valor. São úteis para visualização de variação com menor granulidade 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 ser exibido significativamente.

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

Figura 4.101: Adicionando métricas ao gráfico


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 direiro 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 num template

como estamos fazendo. Ele só funciona no caso de um gráfico ser criado

direto num host.

4.10.4. Personalizando o mapa para exibição de informaçõesO 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 .


Para colocar estes valores é bastante simples, edite a o item de host clicando

sobre ele e preencha (linha-a-alinha, 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.102: Mapa com labels personalizadas exibindo dados

Figura 4.103: Exemplo de labels com valores de métricas


Não esqueça de salvar o mapa constantemente no botão Save.

4.10.5. Exercícios

1) Assim como o icmppingsec esta para o icmpping, várias keys com sufixo “_perf” estão para os equivamentes 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.11. 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 é espaço disponível em disco.

Vários daemons simplesmente saem de funcionamento porque não são

Figura 4.104: Exemplo de gráfico de latência de serviços para exercícios


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 Linux, depois você

terá que estender 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 de limiar para nossos

triggers como fizemos na latência de rede. O espaço utilizado em um sistema de

arquivos de um servidor pode ser bem diferente do de outro. 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 diz qual o parâmetro deve ser

coletado, os valores possíveis são total (bytes totais da partição, é o padrão se

omitido), used (bytes utilizados), free (bytes livres), pused (porcentagem utilizada) e

pfree (porcentagem livre). Vamos usar apenas os três primeiros, começando pelo

total conforme a seguir.

Figura 4.105: Macro para limite de espaço em disco utilizado


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 usamos $1 para pegar o ponto de montagem da partição. Isso alivia bastante a digitação, pois os outros items que iremos clonar não precisam ter descriptions muito diferentes.

2) Key: a chave de espaço conforme explicado anteriormente. Para o total sua sintaxe final é vfs.fs.size[/,total].

3) Units: b representa valores em bytes. O Zabbix é inteligente o suficiente para fazer as conversões para kilo, mega, giga, tera, etc. Usando múltiplos de 1024.

Salve o item, agora ao invés de criar o próximo item “no braço” vamos usar

Figura 4.106: Primeiro item de espaço em disco


um recurso de clonagem de valores do Zabbix. Várias telas permitem que usemos o

recurso de clone. No 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 que eles estão em notação abreviada, Mb, Gb, etc).

4.11.1. Gráficos para espaço em discoVamos 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úteis,

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.109: Gráfico de pizza para exibição de espaço livre e ocupado

Figura 4.108: Botão para clonar items


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 apenas (Sim, você

pode fazer gráficos em 3D se quiser, mas não há grandes vantagens neles em relação

aos normal 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 que é o crítico neste caso.

Enquanto o gráfico circular é indicado para mostrar o último status de vários

items relacionados proporcionalmente ele oculta o histórico do espaço ocupado. Por

isso precisamos criar um gráfico simples ainda. 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 calculado.

Para indicar o topo do gráfico vamos apontar para o espaço total da partição obtido

através de um item.

Figura 4.110: Criando um gráfico de pizza


Crie um gráfico como antes, mas atente para o detalhes em destaque abaixo.

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.11.2. Gatilhos para alertas de espaço em discoAgora vamos usar a macro que definimos anteriormente para calcular o

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


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.

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

Figura 4.113: Trigger para cálculo de espaço em disco


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 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.11.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 Linux. Em sala replique ao menos uma, as outras podem ser feitas em casa.

2) Crie as mesmas métricas para o Windows, mas com as partições de C: até G:. Em sala crie ao menos uma, as outras podem ser feitas em casa.

3) (Desafio) crie métricas que checam partições personalizadas pelo administrador usando macros para definir os pontos de montagem.

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

pelos performance counters. 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.12.1. Checando a disponibilidade do PostgreSQLO Zabbix não tem suporte a todos os protocolos TCP da face da Terra, de fato

isso seria um feito impressionante para um aplicativo de monitoramento. O protocolo

do PostgreSQl esta entre os não suportados, e embora tenhamos utilizado keys como


tcp e tcp_perf para medir sua disponibilidade podem ocorrer situações onde o banco

aceite conexões mas não responda nada, ou o faça muito lentamente.

Nestes casos iremos criar uma extensão do agente apta a realizar uma única

consulta (SELECT 1) e verificar se ele retornou o valor correto. Esta extensão vai

chamar um script criado em bash que aciona localmente o servidor, faz a consulta e

determina o resultado. Prepare os conhecimentos de shell script, respire fundo e

vamos começar acessando o host Database.

O primeiro passo é permitir que o usuário zabbix se conecte ao banco sem a

necessidade de senhas. Isso é necessário porque o comando será executado

automaticamente sem a intervenção manual de um administrador.

Como vamos usar o psql, cliente padrão via console do PostgreSQL, podemos

usar um artifício interessante com o arquivo .pgpass. Este arquivo deve ficar dentro

do diretório home do zabbix e deve conter uma string com os parâmetros de acesso.

Cada permissão de acesso do usuário zabbix deve estar em uma linha (assim

podemos acessar múltiplos bancos de dados).

O formato das linhas deste arquivo seguem a sintaxe:

hostname:porta:basededados:usuário:senha

E no nosso caso vão 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 .pgpass deve ser 0600 ou 0400, 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

Enfim chegamos ao script, basicamente ele executa o comando psql com o

SQL de testes e verifica se tudo ocorreu bem. Mas há algumas partes do script que

merecem um destaque.

# vim /etc/zabbix/externalscripts/pgsql_ping.sh

1 #!/bin/bash

2

3 BASE="/etc/zabbix"

4 CONF=$BASE/pgaccess.conf

5 QUERY_PING="SELECT 1;"

6 ERROR_LOG=/var/log/zabbix/pgsql_ping.error

7

8 function showerror {

9 echo -e "PostgreSQL ping error:\n$(cat $ERROR_LOG)" 1>&2

10 }

11

12 if [ -r $CONF ]; then

13 . $CONF

14 fi

15

16 PING_OK=1

17 PING_FAIL=0

18 PING=$(psql -h $HOST -c "$QUERY_PING" postgres -tA 2> $ERROR_LOG)

19 RETURN=$?

20

21 if [[ $RESULT -ne 0 ]]; then

22 showerror

23 exit 1

24 else


25 if [[ $PING -eq 1 ]]; then

26 echo $PING_OK

27 else

28 showerror

29 echo $PING_FAIL

30 fi

31 fi

32

33 exit 0

1) O primeiro destaque do script é justamente o comando que faz o SELECT 1 e armazena seu conteúdo em uma varíavel chamada $PING. Note que o psql esta usando os parâmetros -t e -A para que o comando retorne apenas um valor (1). No caso de algum erro o valor do PING será diferente de 1.

2) O retorno do comando é verificado 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 um valor 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 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 1, e apenas um valor!

Repita isso consigo mesmo! Não há como pegar valores compostos no

Zabbix e trabalhar com eles individualmente depois. Cada item armazena

um single content.

Agora vamos criar uma nova key pgsql.ping, dentro do agente. Para isso

usamos o UserParameter, dentro de um dos arquivos de configuração do agente. A

sintaxe desta linha é:

UserParamente=key,comando arg1 arg2 ...

No caso de nossa necessidade ficará como a seguir.

# cat /etc/zabbix/agent.d/pgsql_checks.conf

1 UserParameter=pgsql.ping,/etc/zabbix/externalscripts/pgsql_ping.sh


Temos que acertar as permissões dos arquivos e reiniciar o agente.

# chown root.zabbix /etc/zabbix/pgaccess.conf

/etc/zabbix/agent.d/pgsql_checks.conf /etc/zabbix/externalscripts/pgsql_ping.sh

# chmod 0640 /etc/zabbix/pgaccess.conf /etc/zabbix/agent.d/pgsql_checks.conf

# chmod 0750 /etc/zabbix/externalscripts/pgsql_ping.sh


Já podemos fazer o teste local, o script deve retornar o valor 1.

# su zabbix -c “/etc/zabbix/externalscripts/pgsql_ping.sh”

1

A partir do Zabbix server teste o acesso a nova chave, o resultado também

deve ser 1.

# zabbix_get -s database -k 'pgsql.ping'

1 ←

Se todos os testes foram resolvidos é o momento de voltar ao front end. Crie u

m novo template 4Linux – PostgreSQL 8.4 on Linux, ele deve depender o 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


Com isso já poderíamos criar triggers e fazer o mesmo escalonamento de

gatilhos para averiguar qual tipo de erro pode acontecer.

4.12.2. Medindo a disponibilidade de um link InternetAgora faremos um aproach diferente, vamos medir a latência do link de

Internet a partir do host Presentation (assim podemos obter um valor puro dentre o

host de borda e o gateway da operadora).

Este script, um pouco mais complexo que o anterior, permite que coletemos a

média de latência entre um conjunto de sites.

# vim /etc/zabbix/externalscripts/internet_perf.sh

1 #!/bin/bash

2

3 BASE=/etc/zabbix

4 CONF=$BASE/internet_perf.links

5 BC=$(which bc)

6

7 function showerror {

8 echo -e "Check link error: $1" 1>&2

9 }

10

11 if [[ ! -x $BC ]]; then

12 showerror "aplicativo bc não instalado"

13 exit 1

14 fi

Figura 4.115: Disponibilidade do PostgreSQL ativa no database


15

16 if [[ ! -r $CONF ]]; then

17 showerror "arquivo $CONF não existe ou não esta acessível para leitura"

18 exit 1

19 fi

20

21 NTESTS=$(wc -l $CONF | cut -f1 -d" ")

22 SUM_AVG=0

23 for destination in $(cat $CONF); do

24 PING=$(ping -n -c 1 -w 1 -W 1 $destination 2>&1)

25 if [[ $? -eq 0 ]]; then

26 AVG=$(echo $PING | cut -f34 -d" " | cut -f2 -d"/")

27 SUM_AVG=$(echo "scale=3; $AVG + $SUM_AVG;" | bc)

28 else

29 NTESTS=$(( $NTESTS - 1 ))

30 showerror "ping para $destination falhou com erro: $PING"

31 fi

32 done

33

34 if [[ $NTESTS -eq 0 ]]; then

35 showerror "Todos os testes falharam"

36 exit 1

37 fi

38

39 echo "scale=3; $SUM_AVG / $NTESTS / 1000;" | bc

40

41 exit 0

1) Este trecho é o corpo principal do script, ele pega o arquivo de links (abaixo) e realiza um ping em cada um dos endereços lá dentro. Para cada coleta bem sucedida ele soma a média que o comando retorna (em milissegundos).

2) No segundo trecho a partir do resultado da soma e da quantidade de testes é obtida a média final e convertida para segundos (assim podemos usar o Unit s para formatar a saída).

O arquivo de links pode conter tantas entradas o quanto quisermos, mas não

recomenda-se 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 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

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

Abra o link e edite os valores de seus campos como a seguir.

Figura 4.116: Latência sendo exibida no label do link


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.

Note como o link mudou de cor (Figura 4.118) quando o host acusou alta

latência de Internet.

4.12.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, 2 – segundo, e assim por diante). Crie ao menos um gráfico para visualizar o valor coletado dos cores.

Figura 4.118: Link no mapa identificando status do trigger

Figura 4.117: Latência de rede e trigger associados ao link com a Internet no mapa

- 217

REFERÊNCIAS BIBLIOGRÁFICAS

- 218

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.

- 219

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 Linux

para coleta de todas as informações.

Processamento

A primeira métrica de performance que geralmente paramos para ver o que

esta acontecendo quando o sistema fica lento. Há algumas coisas a se ter em mente

sobre processamento e sobre o que monitorar para achar gargalos de

processamento.

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

2.1) Picos de processamentos são mais corriqueiros do que imaginamos, eles acontecem frequentemente mas são tão momentâneos que nem percebemos eles mesmo em gráficos com curtos tempos de coletas.

- 220

Sempre que procurar por eles, concentre-se apenas nos de longa duração.

2.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 por tanto tempo assim o processamento ficou muito alto provavelmente há alguma coisa errada na sua aplicação ou seu hardware está mal dimensionado.

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

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

3.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, consulte a documentação do Zabbix sobre a key system.cpu.util para mais detalhes.

3.3) Ao monitorar múltiplos cores individualmente, colete apenas o idle de cada um deles. Raramente você precisará de coletas detalhadas por núcleo.

3.4) Monitore tambem 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 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.

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

- 221

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 uma largura

suficientemente grande para comportar suas necessidades, mas é o throughput que

realmente deve ser observado.

1) Alta 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 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, análise de 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).

- 223

Anexo II

Performance de serviços

Introdução

Performance de serviços é um assunto extenso e demandam de 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!

- 224

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

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

3) Consumo de memória heap podem indicar garbage collectors fazendo muitas operações (nunca coloque muita memória de heap para as JVMs o GC pode derrubar as JVMs quando ele). 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 idles pode indicar que a configuração pode ser diminuída para consumir menos recursos.

131444591 97430634-apostila-468-zabbix

Technology