Monitoramento Com o 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. Conhecendo a ferramenta................................................................................................13 1.2. Comunidades e forums....................................................................................................13 Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema..........................................14 2.1. Introdução........................................................................................................................15 2.2. Configurando os componentes de recebimento de alertas............................................15 2.2.1. Configurando o cliente de correio eletrônico........................................................................16 2.2.2. Mensagens instantâneas.........................................................................................................24

2.3. Obtendo os fontes do Zabbix...........................................................................................27 2.4. Preparando o banco de dados.........................................................................................27 2.4.1. Instalação................................................................................................................................28 2.4.2. Criando o usuário e o banco...................................................................................................28 2.4.3. Carga inicial............................................................................................................................30 2.4.4. Concedendo as permissões necessárias ao usuário...............................................................30

2.5. Instalação do servidor Zabbix via código fonte..............................................................31 2.5.1. Dependências de compilação..................................................................................................34 2.5.2. Compilando e instalando.........................................................................................................35 2.5.3. Serviços de rede......................................................................................................................37 2.5.4. Arquivos de configuração.......................................................................................................37 2.5.5. Testando sua instalação..........................................................................................................39 2.5.6. Scripts de boot........................................................................................................................41

2.6. Instalação do agente Zabbix via compilação..................................................................41 2.6.1. Exercício: compile e instale o agente nas VM com Gnu/Linux..............................................42 2.6.2. Acesso ao agente pelo servidor..............................................................................................42 2.6.3. Exercício sobre instalação de agente em Linux.....................................................................46

2.7. Instalando o agente em ambientes Windows..................................................................46 2.7.1. Executando o agente como serviço........................................................................................50

2.8. Instalação do agente Zapcat para JBoss.........................................................................52 2.8.1. Obtenção do binário................................................................................................................52 2.8.2. Deployment.............................................................................................................................52 2.8.3. Opções de inicialização do JBoss............................................................................................53 2.8.4. Liberando o firewall para acesso ao Zapcat...........................................................................55

2.9. Testando o acesso via SNMP...........................................................................................55 2.9.1. Conceitos de SNMP.................................................................................................................56

-3 2.10. Instalando o servidor Zabbix via pacote.......................................................................57 2.11. Preparando o servidor web............................................................................................58 2.11.1. Instalação do Apache e PHP5...............................................................................................58 2.11.2. Configuração do Virtual Host...............................................................................................58 2.11.3. Configurando o front end......................................................................................................61

2.12. Exercícios de revisão.....................................................................................................72 Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end.......................................74 3.1. Introdução........................................................................................................................75 3.1.1. Organização do front end.......................................................................................................75

3.2. Gerenciamento de usuários.............................................................................................77 3.2.1. Cadastrando os usuários do LDAP no Zabbix........................................................................81

3.3. Meios de alertas...............................................................................................................83 3.3.1. Correio eletrônico...................................................................................................................84 3.3.2. Mensagens instantâneas.........................................................................................................84 3.3.3. Apontando os alertas aos usuários.........................................................................................85 3.3.4. Boas práticas com Media types..............................................................................................87

3.4. Hosts, host groups e templates.......................................................................................87 3.4.1. Templates para o caso de estudo............................................................................................88 3.4.2. Vínculo entre templates..........................................................................................................90 3.4.3. Backup dos templates.............................................................................................................91 3.4.4. Hosts........................................................................................................................................91 3.4.5. Gerenciando os Host Groups..................................................................................................92 3.4.6. Criando um novo host.............................................................................................................93 3.4.7. Fazendo backup dos hosts......................................................................................................95 3.4.8. Configurando uma permissão de acesso................................................................................95 3.4.9. Exercícios sobre usuários, hosts, grupos e permissões.........................................................97

3.5. Mapas...............................................................................................................................98 3.5.1. Importando imagens para o mapa..........................................................................................98 3.5.2. Criando um mapa..................................................................................................................100 3.5.3. Adicionando um elemento.....................................................................................................103 3.5.4. Editando um elemento do mapa...........................................................................................104 3.5.5. Salvando o mapa...................................................................................................................106 3.5.6. Adicionando os outros elementos.........................................................................................106 3.5.7. Criando e editando links.......................................................................................................110 3.5.8. Prática Dirigida.....................................................................................................................111 3.5.9. Exercícios sobre Mapas........................................................................................................113

3.6. Templates, applications e items....................................................................................114 3.6.1. Criando um Application e um Item dentro de um template................................................115 3.6.2. Interdependência de templates............................................................................................118

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

-4 3.8. Ativando um host............................................................................................................123 3.8.1. Throubleshooting para itens com problemas.......................................................................124

Capítulo 4 Monitoramento voltado para disponibilidade..........................................................................128 4.1. Introdução......................................................................................................................129 4.2. Checagens manual via front end...................................................................................129 4.2.1. Adequando o script de traceroute........................................................................................132 4.2.2. Criando novos comandos para o menu.................................................................................135 4.2.3. Exercícios..............................................................................................................................138

4.3. Checando disponibilidade via protocolo ICMP.............................................................138 4.3.1. Como funciona o ping ICMP.................................................................................................138 4.3.2. Visualizando o ping ICMP no Front end...............................................................................139 4.3.3. Criando um gatilho de parada de host.................................................................................141 4.3.4. Lidando com os eventos........................................................................................................146 4.3.5. Criando uma action para envio de alerta.............................................................................150 4.3.6. Exercícios..............................................................................................................................153 4.3.7. Boas práticas com triggers...................................................................................................154

4.4. Checagem genérica de portas e serviços......................................................................156 4.4.1. Conexões TCP e handshakes................................................................................................157 4.4.2. Criando um teste de serviço via varredura de portas.........................................................159 4.4.3. Exercício sobre checagem de portas....................................................................................162

4.5. Validação de páginas WEB.............................................................................................163 4.5.1. Disponibilidade do site..........................................................................................................163 4.5.2. Exercícios..............................................................................................................................168

4.6. Checando disponibilidade via agentes..........................................................................169 4.6.1. Checando se o agente esta operacional...............................................................................169 4.6.2. Criando um trigger com a função nodata()..........................................................................171 4.6.3. Exercícios..............................................................................................................................175

4.7. Tempo on-line e última inicialização do S.O..................................................................175 4.7.1. Trigger para alerta de reinicialização..................................................................................180 4.7.2. Exercícios..............................................................................................................................181

4.8. Checando serviços pelo agente.....................................................................................181 4.8.1. Verificando os processos ativos na memória........................................................................181 4.8.2. Checagem de portas e serviços localmente via agente.......................................................185 4.8.3. Exercícios..............................................................................................................................190 4.8.4. Verificando serviços no Windows.........................................................................................190 4.8.5. Restabelecendo serviços offline via Zabbix.........................................................................198 4.8.6. Exercícios..............................................................................................................................202

4.9. Medindo a “saúde” de sua rede.....................................................................................202 4.9.1. Latência de rede....................................................................................................................202 4.9.2. Macro para o limiar da latência de rede..............................................................................204

-5 4.9.3. Nosso primeiro gráfico.........................................................................................................205 4.9.4. Personalizando o mapa para exibição de informações........................................................208 4.9.5. Exercícios..............................................................................................................................210

4.10. Espaço disponível em disco.........................................................................................210 4.10.1. Gráficos para espaço em disco...........................................................................................213 4.10.2. Gatilhos para alertas de espaço em disco..........................................................................216 4.10.3. Exercícios............................................................................................................................217

4.11. Scripts externos...........................................................................................................218 4.11.1. Checando a disponibilidade do PostgreSQL......................................................................218 4.11.2. Medindo a disponibilidade de um link Internet.................................................................223 4.11.3. Exercícios............................................................................................................................227

REFERÊNCIAS BIBLIOGRÁFICAS......................................................................................................................228 Anexo I Performance do Sistema Operacional..................................................................................230 Introdução.......................................................................................................................................230 Processamento.................................................................................................................................230 Métricas de memória......................................................................................................................231 Throughput e banda de rede...........................................................................................................232 Performance de Disco.....................................................................................................................232

Anexo II Performance de serviços.......................................................................................................233 Introdução.......................................................................................................................................233 PostgreSQL......................................................................................................................................233 JBoss................................................................................................................................................234 Apache.............................................................................................................................................234

Índice de tabelas Tabela 1: Opções de compilação do Zabbix............................................................................34 Tabela 2: Binários de uma instalação de servidor e agente do Zabbix.................................36 Tabela 3: Arquivos e diretórios de configuração....................................................................38 Tabela 4: Função dos menus no front end..............................................................................77 Table 5: Usuários do cenário do curso...................................................................................81 Tabela 6: Relação de permissões entre hosts e usuários.......................................................98 Tabela 7: Lista de imagens iniciais para o mapa.................................................................100 Tabela 8: Serviços do cenário do curso................................................................................163 Tabela 9: Responsáveis de cada host...................................................................................175 Table 10: Valores da key service_state.................................................................................193

-6

Índice de Figuras Figura 2.1: Configuração do evolution (1/10)........................................................................16 Figura 2.2: Configuração do evolution (2/10)........................................................................17 Figura 2.3: Configuração do evolution (3/10)........................................................................18 Figura 2.4: Configuração do evolution (4/10)........................................................................19 Figura 2.5: Configuração do evolution (5/10)........................................................................20 Figura 2.6: Configuração do evolution (6/10)........................................................................21 Figura 2.7: Configuração do evolution (7/10)........................................................................22 Figura 2.8: Configuração do evolution (8/10)........................................................................23 Figura 2.9: Configuração do evolution (9/10)........................................................................23 Figura 2.10: Configuração do evolution (10/10)....................................................................24 Figura 2.11: Tela de boas vindas do Pidgin............................................................................25 Figura 2.12: Configurando uma conta Jabber no Pidgin.......................................................25 Figura 2.13: Definindo o uso de criptografia.........................................................................26 Figura 2.14: Baixando o agente do Zabbix no Windows........................................................47 Figura 2.15: Instalando os executáveis no Windows.............................................................48 Figura 2.16: Diretório de configuração do Zabbix no Windows............................................48 Figura 2.17: Configurando o agente no Windows..................................................................49 Figura 2.18: Desbloqueando o agente no Windows...............................................................50 Figura 2.19: O agente do Zabbix sendo executado como serviço automático......................51 Figura 2.20: Tela de entrada do Zapcat.................................................................................54 Figura 2.21: Configuração do front end (1/10)......................................................................61 Figura 2.22: Configuração do front end (2/10)......................................................................62 Figura 2.23: Configuração do front end (3/10)......................................................................63 Figura 2.24: Configuração do front end (4/10)......................................................................65 Figura 2.25: Configuração do front end (5/10)......................................................................66 Figura 2.26: Configuração do front end (6/10)......................................................................67 Figura 2.27: Configuração do front end (7/10)......................................................................68 Figura 2.28: Configuração do front end (8/10)......................................................................69 Figura 2.29: Configuração do front end (9/10)......................................................................70 Figura 2.30: Configuração do front end (10/10)....................................................................71 Figura 2.31: Tela inicial do Zabbix após o primeiro login.....................................................71 Figura 3.1: Gerenciamento de usuários do Zabbix................................................................78 Figura 3.2: Editando o Admin.................................................................................................79 Figura 3.3: Configurando a autenticação LDAP....................................................................80 Figura 3.4: Novo Grupo JBoss Administrators.......................................................................81 Figura 3.5: Novo usuário Sysadmin.......................................................................................82

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

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

-9 Figura 4.7: Nova entrada de menu com o script criado......................................................137 Figura 4.8: Resultado do comando ativado no host.............................................................137 Figura 4.9: Diagrama de comportamento do echo ICMP....................................................139 Figura 4.10: Hosts ativos com ping ICMP em funcionamento............................................140 Figura 4.11: Um value maps de estado de serviços............................................................140 Figura 4.12: Editando o value map para nossa necessidade...............................................140 Figura 4.13: Value map editado e pronto para uso..............................................................141 Figura 4.14: Selecionando um value map no trigger..........................................................141 Figura 4.15: Values maps no overview.................................................................................141 Figura 4.16: Pausando o host Database...............................................................................142 Figura 4.17: Host database parado no overview.................................................................142 Figura 4.18: Criando um trigger para a parada do host (1/9).............................................143 Figura 4.19: Criando um trigger para a parada do host (2/9).............................................143 Figura 4.20: Criando um trigger para a parada do host (3/9).............................................143 Figura 4.21: Criando um trigger para a parada do host (4/9).............................................143 Figura 4.22: Criando um trigger para a parada do host (5/9).............................................144 Figura 4.23: Criando um trigger para a parada do host (6/9).............................................144 Figura 4.24: Criando um trigger para a parada do host (7/9).............................................145 Figura 4.25: Criando um trigger para a parada do host (8/9).............................................145 Figura 4.26: Criando um trigger para a parada do host (9/9).............................................146 Figura 4.27: Indicação de problemas no Dashboard...........................................................146 Figura 4.28: Overview com indicação dos items com alerta...............................................147 Figura 4.29: Overview com visualização dos triggers ativos..............................................147 Figura 4.30: Mapa indicando o host Database como down.................................................148 Figura 4.31: Tela de Events, indicando a queda e o retorno dos hosts..............................148 Figura 4.32: Tela de acknowledgement...............................................................................149 Figura 4.33: Acknowledge (confirmação) aplicado..............................................................149 Figura 4.34: Criando uma action para enviar o alerta (1/9)................................................150 Figura 4.35: Criando uma action para enviar o alerta (2/9)................................................150 Figura 4.36: Criando uma action para enviar o alerta (3/9)................................................151 Figura 4.37: Criando uma action para enviar o alerta (4/9)................................................151 Figura 4.38: Criando uma action para enviar o alerta (5/9)................................................151 Figura 4.39: Criando uma action para enviar o alerta (6/9)................................................152 Figura 4.40: Criando uma action para enviar o alerta (7/9)................................................152 Figura 4.41: Criando uma action para enviar o alerta (8/9)................................................152 Figura 4.42: Criando uma action para enviar o alerta (9/9)................................................153 Figura 4.43: Mensagens de alerta recebidas no Evolution.................................................153 Figura 4.44: Reiniciando o host Database...........................................................................154 Figura 4.45: Lógica de um gatilho com tempo de segurança.............................................155

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

Capítulo 1 Conhecendo o Zabbix - 11 Figura 4.85: Ativando o serviço de telnet............................................................................191 Figura 4.86: Processo do telnet na memória.......................................................................192 Figura 4.87: Liberando o telnet no firewall do Windows (1/3)............................................194 Figura 4.88: Liberando o telnet no firewall do Windows (2/3)............................................194 Figura 4.89: Liberando o telnet no firewall do Windows (3/3)............................................195 Figura 4.90: item para monitorar serviços Windows...........................................................197 Figura 4.91: Estado do serviço Telnet no Overview............................................................197 Figura 4.92: Action para parada do SSH (1/3).....................................................................200 Figura 4.93: Action para parada do SSH (2/3).....................................................................200 Figura 4.94: Action para parada do SSH (3/3).....................................................................201 Figura 4.95: Comando remoto para o action de parada do serviço de SSH.......................201 Figura 4.96: Item para latência de rede...............................................................................203 Figura 4.97: Macro para latência de rede............................................................................205 Figura 4.98: Trigger para latência de rede usando a macro...............................................205 Figura 4.99: Gráfico para medir a latência de rede............................................................206 Figura 4.100: Criando um gráfico de latência de rede........................................................206 Figura 4.101: Adicionando métricas ao gráfico...................................................................207 Figura 4.102: Mapa com labels personalizadas exibindo dados.........................................209 Figura 4.103: Exemplo de labels com valores de métricas.................................................209 Figura 4.104: Exemplo de gráfico de latência de serviços para exercícios........................210 Figura 4.105: Macro para limite de espaço em disco utilizado...........................................211 Figura 4.106: Primeiro item de espaço em disco.................................................................212 Figura 4.107: Items a serem clonados para espaço em disco.............................................213 Figura 4.108: Botão para clonar items.................................................................................213 Figura 4.109: Gráfico de pizza para exibição de espaço livre e ocupado...........................214 Figura 4.110: Criando um gráfico de pizza..........................................................................214 Figura 4.111: Gráfico de histórico de espaço em disco.......................................................215 Figura 4.112: Criando o gráfico de histórico de uso de disco.............................................215 Figura 4.113: Trigger para cálculo de espaço em disco......................................................217 Figura 4.114: Trocando o template do host database para o PostgreSQL.........................222 Figura 4.115: Disponibilidade do PostgreSQL ativa no database.......................................223 Figura 4.116: Latência sendo exibida no label do link........................................................226 Figura 4.117: Latência de rede e trigger associados ao link com a Internet no mapa......226 Figura 4.118: Link no mapa identificando status do trigger...............................................226

Capítulo 1 Conhecendo o Zabbix - 12

Capítulo 1  Conhecendo o Zabbix

OBJETIVOS • Apresentar a ferramento ao aluno. • Como o “front end” organiza os componentes dentro do Zabbix. • Componentes visuais de monitoramento. • Alertas de incidentes. • Reinicialização de serviços. • Mostrar ao aluno onde obter informações.

Capítulo 1 Conhecendo o Zabbix - 13

1.1. Conhecendo a ferramenta Siga os passos indicados pelo professor para acesso ao exemplo pronto na máquina dele.  Você   vai   fazer   um   passo­a­passo   conhecendo   a   ferramenta   como   um   usuário   comum   (não  superusuário).

1.2. Comunidades e forums O Zabbix tem uma documentação on­line que será usada durante o curso para consultas.  O link de acesso é http://www.zabbix.com/documentation/.  As   comunidades   também   mantém   uma   série   de   fóruns   em  http://www.zabbix.com/forum/. Em destaque os seguinte: • Zabbix announcements: anúncios e novas versões • Zabbix help: fórum principal de ajuda • Zabbix cookbook: várias configurações prontas postadas e comentadas. Muito útil. • Zabbix throubleshooting: se um problema persiste, este  é o local para postar erros e  soluções. • Zabbix em português y em espanhol: fórum em português e espanhol, útil quando você  não lê inglês muito bem.

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

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

OBJETIVOS • Preparar o ambiente de recebimento de alertas: • Configurar o Evolution para receber e­mails de alertas; • Configurar o Pidgin para receber mensagens instantâneas de alertas. • Preparar o ambiente para instalar o servidor do Zabbix: • Obter os fontes da ferramenta; • Preparar o PostgreSQL para servir de back end. • Instalar o servidor e agente: • Compilar o servidor e agente na máquina destinada a ser o monitorador e nas demais; • Instalação dos binários dentro do Windows 2003 (com inicialização do agente como  serviço); • Executar   deploy   do   agente   Zapcat   no   JBoss   para   monitoramento   do   servidor   de  aplicações • Configuração de um virtual host dentro do Apache para o  front end, incluindo modificação  dos parâmetros do PHP.

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

2.1. Introdução Este capítulo apresenta todas as tarefas relacionadas a criação da base de sua solução  de monitoramento. Aqui é onde será abordado a maior parte do conhecimento técnico de console  Linux,   deploying   em   JBoss,   serviços   de   Windows   e   acesso   à   SNMP,   visando   incutir   as  competências necessárias para que, sozinho, você seja capaz de reproduzir estes passos em um  ambiente de produção. Além disso, serão vistos os primeiros passos na utilização e familiarização com a interface  web do Zabbix, mostrando como gerenciar os elementos mais básicos da ferramenta: usuários,  hosts, templates, grupos de hosts e mapas.

2.2. Configurando os componentes de recebimento de alertas Por padrão o Zabbix possui quatro formas de alertas embutidos dentro de seu sistema: e­ mails, cliente jabber, SMS via modem GSM e SMS via serviço de torpedos. De todos, o último não  é muito útil aqui no Brasil, devido seguir os padrões das operadoras no Canadá e Estados Unidos. Dos restantes vamos ver o funcionamento do sistema de correios e de jabber dentro da  sala de aula, devido a natureza do hardware, a emulação das máquinas virtuais do cenário e  custos de mensagem não abordamos o uso dentro do nosso cenário com SMS. No entanto temos  um apêndice que cobre o sistema de SMS com throubleshooting e dicas de configuração. Receber mensagens por cliente de e­mail  é a maneira mais tradicional de todas. Para  caso de estudos precisamos configurar o Evolution, cliente de e­mail padrão do Gnome. Abra o  Evolution pelo menu principal do Gnome e siga os passos descritos a seguir.

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

2.2.1. Configurando o cliente de correio eletrônico

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

Esta é apenas um tela de boas vindas, clique em Avançar.

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

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

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

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

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

Começaremos   a   configurar   as   contas   de   usuários   dentro   do   sistema   de   LDAP   que   o  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].

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

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

 3)  Tipo de Servidor: devemos escolher POP, que é o recurso implantado para recepção  de e­mails no cenário.  4)  Servidor: é o endereço externo do servidor de e­mail.  5)  Nome do usuário: o primeiro usuário que usaremos é o sysadmin.  6)  Lembrar   senha:  para   comodidade   dos   testes   em   curso   ative   o   recurso   de  armazenamento de senha. Esta opção não é segura para ser usada em produção!  Mas como no curso os  usuários são fictícios e possuem a senha 123456 isso não vai nos impactar.

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

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

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

Na primeira vez que você entrar ele irá pedir a senha (123456) do usuário, digite­a e  verifique se não houve nenhum erro. Não há nenhum e­mail na caixa de mensagens do sysadmin,  logo nenhuma mensagem vai aparecer. Agora que o  Evolution  esta é funcionamento, acesse o menu  Editar  →  Preferências  e  clique no ícone  Contas de Correio  a esquerda. Através do botão  Adicionar  cadastre mais três  contas seguindo os mesmos passos que anteriormente, mudando apenas os nomes e usuários.  As contas a serem acrescentadas são Windows Administrator (winadmin), Java Engineer  (javaeng) e DBA (dba). Após o término, escolha duas contas e teste o envio de mensagens entre  elas.

2.2.2. Mensagens instantâneas Receber mensagens de alertas via Instant Messaging é útil em empresas que possuem  um sistema interno de IM e os funcionários estão logados constantemente. O Zabbix suporta o  envio destas mensagens via protocolo Jabber e o cenário já possui este tipo de serviço através de  um servidor OpenFire instalado na máquina mestra do Zabbix. Vamos então configurar o  Pidgin,  um cliente de IM simples e eficiente para receber os  alertas   enviados   via   protocolo   Jabber   pelo   servidor   do   Zabbix.   Abra   o   aplicativo   pelo   menu  principal do Gnome e siga os passos a seguir.

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

Figura 2.11: Tela de boas vindas do Pidgin

Na tela de boas vindas clique em Adicionar.

Figura 2.12: Configurando uma conta Jabber no Pidgin

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

 1)  O protocolo Jabber usa a opção XMPP.  2)  No nome do usuário use sysadmin.  3)  No domínio, você deve  apontar o nome da máquina cadastrada para IM e não o  domínio.  4)  Na senha coloque 123456.  5)  Ative o Lembrar Senha. Não   ative   a   opção   “Lembrar  Senha”   em  produção!   Isso   seria   uma   terrível   falha   de  segurança. Ela só esta sendo ativada para comodidade do curso.

Figura 2.13: Definindo o uso de criptografia

 1)  Clique na aba Avançado.  2)  Escolha para usar criptografia apenas se estiver disponível. Clique em Adicionar e ative a conta na interface do Pidgin.

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

2.3. Obtendo os fontes do Zabbix Antes de começar a trabalhar com as diversas partes básicas da instalação, precisamos  baixar   o   código   fonte   do   Zabbix.   Você   sempre   pode   fazê­lo   através   da   URL  http://www.zabbix.com/download.php, mas o comando abaixo já vai colocar o pacote de fontes no  local apropriado dentro da máquina virtual “zabbixsrv”. # cd /usr/src # wget http://ufpr.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest %20Stable/1.8.4/zabbix­1.8.4.tar.gz  # tar xf zabbix­1.8.4.tar.gz Você também pode escolher outros mirrors e trocar o endereço acima se desejar.

2.4. Preparando o banco de dados O   Zabbix   não   utiliza   recursos   como   o   RRDTools   para   armazenar   dados,   ele   faz   uso  apenas de um SGBD ou de um banco de dados mais simplório (como o sqlite) para armazenar  configurações, hosts, templates, histórico, etc. Por isso precisamos selecionar um dos bancos nativos ou usar ODBC (este último não é  recomendado).   No   caso   deste   curso   elegemos   o   PostgreSQL,   um   SGBD   livre   e   de   alta  performance   capaz   de   manipular   uma   grande   quantidade   de   dados.   Apesar   da   maioria   das  instalações de Zabbix estar em MySQL recomendamos fortemente que seja usado o PostgreSQL  pois sua robustez se mostrou mais adequada aos tipos de dados que o Zabbix manipula.  Embora não pareça a princípio, o banco de dados do Zabbix é de extrema valia para a  empresa, pois ele contém todo o histórico de funcionamento de sua infraestrutura e através dele  podemos coletar SLAs e informações de “capacity plan”. É recomendado também que seu banco de dados possua um plano de backups regular  via PITR – Point in Time Recovery.

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

2.4.1. Instalação Para instalar a versão do repositório do PostgreSQL: # aptitude install postgresql­8.4

# yum install postgresql84­server

2.4.2. Criando o usuário e o banco Com o banco de dados instalado devemos criar uma base de dados e um usuário com as  devidas   permissões   de   acesso   ao   mesmo.   O   nome   de   ambos   elementos   são   totalmente  opcionais, mas neste material vamos convencionar que o banco de dados se chamará zabbixdb e  o usuário será zabbix. Muitas documentações e até o próprio arquivo padrão de configuração do zabbix server  utiliza o nome do banco como zabbix, mas isso pode causar algumas confusões entre  ele e o nome do usuário, foi por isso que optamos pela convenção acima. Somente o superusuário do PostgreSQL, chamado postgres tem permissão de realizar a  criação dos objetos citados acima, logo, para podermos acessar o terminal de console do banco  (psql) temos que entrar como usuário  postgres  no Gnu/Linux e então usar o comando correto.  Note que o prompt de comando irá se alterar indicando que estamos no console do PostgreSQL. # su – postgres $ psql psql (8.4.5) Digite "help" para ajuda. postgres=# 

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

Agora que conseguimos o acesso como superusuário, vamos primeiro criar o banco de  dados.   O   comando   “create   database”  irá   cuidar   desta   tarefa.   Note   que   todos   os   comandos  digitados dentro deste console terminam com ponto­e­vírgula (;). postgres=# CREATE DATABASE zabbixdb; Com o banco de dados criado com sucesso vamos criar o usuário e definir sua senha.  Para   propósito   de   organização   deste   material   a   senha   do   banco   de   dados   do   zabbix   será  zabbixdbpw. Ao digitar a senha note que ela não aparece como no quadro de comando abaixo!  Este é apenas um demonstrativo didático. postgres=# CREATE ROLE zabbix LOGIN; postgres=# \password zabbix Digite nova senha: zabbixdbpw Digite­a novamente: zabbixdbpw  É interessante definir a senha por \password pois assim ela não fica armazenada no   histórico de comandos do usuário. Agora precisamos liberar a conexão do servidor ao banco de dados do zabbix, para isso  edite o arquivo “pg_hba.conf” conforme abaixo e acrescente a linha em destaque. postgres=# \q $ logout # vim /etc/postgresql/8.4/main/pg_hba.conf  … host    zabbixdb    zabbix      127.0.0.1/32            md5 Reinicie o banco de dados e realize o teste de conexão. # /etc/init.d/postgresql restart # psql ­h localhost ­U zabbix zabbixdb psql (8.4.5) conexão SSL (cifra: DHE­RSA­AES256­SHA, bits: 256)

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 30 Digite "help" para ajuda. zabbixdb=> \q # Se   você   estiver   usando   a   versão   9.0   do  PostgreSQL  é   importante   lembrar   que   o   suporte   a   imagens   do   Zabbix   assume   que   o   banco   utiliza   a   forma   antiga   de   armazenamento   bytea   (escape   em   vez   de   hex).   Para   configurar   o   comportamento   antigo   use   o   comando   “ALTER   DATABASE   nomedabase 

SET 

bytea_output=escape;”   dentro   do   console   do  psql.   Isso   pode   ser   configurado   no   usuário ou no “postgresql.conf” também.

2.4.3. Carga inicial Agora vamos fazer a carga inicial do banco carregando os esquemas, os dados mais   básicos. # su ­ postgres $ cd /usr/src/zabbix­1.8.4/create/schema $ cat postgresql.sql | psql zabbixdb $ cd ../data $ cat data.sql | psql zabbixdb Não   faça   a   carga   do   arquivos   de   imagens,   iremos   abordar   como   colocar   figuras   personalizadas e de melhor definição mais a frente, neste capítulo.

2.4.4. Concedendo as permissões necessárias ao usuário Agora é o momento de conceder as permissões de acesso nas tabelas. O usuário Zabbix  precisa de permissões de SELECT, INSERT, UPDATE e DELETE apenas. Com a sequência de  comandos abaixo você conseguirá ativar todas as permissões necessárias. Embora este processo seja mais complicado do que fazer deixar o usuário zabbix como   dono do banco ele é muito mais seguro e deve ser utilizado assim em produção

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 31 $ psql zabbixdb 1

postgres=# \t 

2

postgres=# \a 

3

postgres=# \o /tmp/grantzabbix.sql 

4

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

|| tablename || ' TO zabbix ;' FROM pg_tables;   5

postgres=# \o

6

postgres=# \i /tmp/grantzabbix.sql 

7

postgres=# \q

$ logout  1)  O comando \a remove o alinhamento dos elementos na tabela;  2)  O \t mostra apenas tuplas, eliminando cabeçalhos e rodapés;  3)  O comando \o grava o “output” no arquivo definido (/tmp/grantzabbix.sql). Note que é  preciso de outro \o sem o nome do arquivo para encerrar o “output”;  4)  Este comando em SQL seleciona todas as tabelas do banco de dados e monta uma  “string”   com  o   comando   de   permissão   (GRANT),  você   pode   ver  o   conteúdo   deste  comando no arquivo “/tmp/grantzabbix.sql”;  5)  O comando \i carrega e executa o conteúdo do arquivo gerado acima.

2.5. Instalação do servidor Zabbix via código fonte Em   alguns   casos   a   distribuição   Gnu/Linux   que   você   escolher   pode   possuir   em   seu  repositório uma versão satisfatória do Zabbix disponível. Se for este o caso, ótimo! Simplesmente  instale o pacote e comece a configurar. No entanto isso nem sempre é verdade e pode ser necessário uma versão mais recente  (devido a recursos novos, etc.) na sua solução de monitoramento. Para suprir esta necessidade é  preciso compilar o Zabbix a partir de seu código fonte.  Esta   sessão   toda   é   dedicada   ao   processo   de   criar   os   binários,   cobrindo   quais  dependências devem ser instaladas e como escolher os recursos a serem compilados. Via de  regra   se   algum   tipo   de   recurso   não   se   mostrar  necessário   a   princípio   não   o   ative,  isso   gera  binários mais leves (com menos código embutido) e alivia o consumo de memória em servidores 

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 32 com altas cargas de métricas sendo monitoradas. Para começar, vamos instalar os dois pacotes mais básicos para compilação de fontes no  Debian,  o  build­essential  e   o  make.  O  primeiro   é   um  meta   pacote  que   irá   instalar  todos os  pacotes mínimos de compilação de fontes (compilador, linkeditor, cabeçalhos do kernel e da libc,  etc.) e o segundo é um automatizador de compilação. No terminal do zabbixsrv rode os seguintes  comandos. # aptitude install build­essential make # cd /usr/src/zabbix­1.8.4 # ./configure ­­help | less O configure é um script gerado a partir do “autotools”, que é um conjunto de ferramentas  para facilitar a compilação de fontes em C. A opção ­­help fornecida acima irá listar todas as  opções que podemos ativar ou não para compilar o Zabbix. Note que o configure não compila  nada ele apenas “prepara a cama” para realizar a compilação com o “make”. Na tabela a seguir estão as opções relevantes do configure para a nossa tarefa. Opção do configure --prefix=diretório

Descrição Define onde o Zabbix será instalado. É importante lembrar que se nada for configurado nesta opção os binários e manuais serão colocados em /usr/local como padrão. No entanto para manter a instalação organizada e facilitar atualizações de versões do Zabbix nós o colocaremos em /opt/zabbix-1.8.4.

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

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

--enable-server

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

--enable-proxy

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

--enable-agent

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

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 33 Opção do configure

Descrição

--enable-ipv6

Compila com suporte a IPV6. Embora não seja absolutamente necessário, dado ao recente anúncio do esgotamento de endereços IP da IANA o IPV6 logo será necessário em muitos ambiente.

--with-ibm-db2

Ativa o suporte ao “back end” do bando de dados IBM DB2. Vamos deixá-lo desabilitado uma vez que usaremos o PostgreSQL. Você pode escolher apenas um “back end”.

--with-mysql

Ativa o suporte ao “back end” do bando de dados MySQL. Vamos deixá-lo desabilitado uma vez que usaremos o PostgreSQL. Você pode escolher apenas um “back end”.

--with-oracle

Ativa o suporte ao “back end” do bando de dados Oracle. Vamos deixá-lo desabilitado uma vez que usaremos o PostgreSQL. Você pode escolher apenas um “back end”.

--with-pgsql

Ativa o suporte ao “back end” do bando de dados PostgreSQL, vamos deixá-lo habilitado. Você pode escolher apenas um “back end”.

--with-sqlite3

Ativa o suporte ao “back end” do bando de dados sqlite versão 3. Vamos deixá-lo desabilitado uma vez que usaremos o PostgreSQL. Você pode escolher apenas um “back end”.

--with-jabber

Ativa o suporte do servidor de contato com servidores Jabber permitindo que o Zabbix envie alertas taravés deste serviço de mensagens instantâneas. Vamos ativar essa opção.

--with-libcurl

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

--with-iodbc

Ativa o suporte ao “back end” do bando de dados via ODBC. Não é recomendado.

--with-unixodbc

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

--with-net-snmp

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

--with-ucd-snmp

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

--with-ssh2

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

--with-openipmi

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

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 34 Opção do configure --with-ldap

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

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

2.5.1. Dependências de compilação. Ao   executar   o   comando   abaixo,   colete   cada   erro   que   aparecer   e   aponte   na   tabela   o  pacote que deve ser instalado para resolver a dependência. Isto vai servir de referência para você  em futuras instalações e também tem como intenção ensinar a lidar com erros de dependências  de compilação. Use o comando “aptitude” para encontrar os pacotes corretos. ./configure ­­prefix=/opt/zabbix­1.8.4 –mandir=/usr/share/man ­­enable­server ­­disable­static  ­­disable­proxy ­­enable­agent ­­enable­ipv6 ­­with­pgsql ­­with­jabber ­­with­libcurl ­­with­net­ snmp ­­with­ssh2 ­­without­openipmi ­­with­ldap Erro

Dependência

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 35 Você pode otimizar os binários tornando o Zabbix mais rápido mas dependente de uma   CPU compatível se você exportar as variáveis de ambiente  CFLAGS e  CXXFLAGS   com o seguinte valor “­O2 ­pipe ­march=native”, antes de executar o configure. Se você   estiver usando um sistema de 32 bits acrescente ainda ­fomit­frame­pointer.  Cuidado   com outros flags de compilação! Você pode acabar com um binário defeituoso!

2.5.2. Compilando e instalando Agora que o “configure” chegou ao ponto final e todas as dependências foram resolvidas é  hora   de   executar   a   compilação   com   o   comando   “make”.  Na   verdade   o   “make”   não   é   um  compilador, ele apenas chama os comandos necessários para construir os binário através de um  arquivo Makefile que foi gerado pelo “configure”.  Execute   conforme   abaixo,   os   comandos.   No   final   o   comando   “ln”  irá   criar   um   link  simbólico para /opt/zabbix. Isso  é uma boa prática para ajudar a trocar as versões do Zabbix  durante uma migração, apontando o link para a pasta com os novos binários, enquanto mantemos  os anteriores para o caso de um “downgrade” emergencial. Você pode substituir o ­j2 por outro número para acelerar a sua compilação se você   tiver múltiplos cores. Uma regra geral é 2xCores+1. # make ­j2 # make install # ln ­svf /opt/zabbix­1.8.4 /opt/zabbix # tree /opt/zabbix O comando “tree” vai mostrar a hierarquia de diretórios e arquivos abaixo do caminho da  instalação. A tabela abaixo tem o descritivo de cada um deles. Binário

Funcionalidade

zabbix_get

Utilitário para realizar consultas nos agentes via linha de comando. Muito útil e nós o utilizaremos extensamente durante o curso.

zabbix_sender

Utilitário para envio de “traps” para o servidor do Zabbix. É necessário criar um

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 36 Binário

Funcionalidade item especial do tipo “Zabbix trap” para lidar com estes envios. Útil para alertar incidentes instantaneamente para o servidor como o início, termino ou erro de um backup.

zabbix_agent

Agente para ser usado com o “super daemon xinetd” ou similar. Não é necessário na grande maioria dos casos e será removido do diretório.

zabbix_agentd

O daemon do agente do Zabbix que fica na memória a espera das requisições do servidor.

zabbix_server

O daemon do servidor do Zabbix. Este é o componente principal de toda a infraestrutura.

Tabela 2: Binários de uma instalação de servidor e agente do Zabbix É preciso remover o “zabbix_agent” e sua página de manual, uma vez que iremos usar  apenas   o   “daemon   zabbix_agentd”.   Também   é   uma   boa   prática   não   manter   os   símbolos   de  depuração nos binários de produção. O comando “strip” irá retirar estes símbolos e o executável  final será ligeiramente menor em tamanho (o que ajuda a consumir menos memória também). # rm /opt/zabbix­1.8.4/sbin/zabbix_agent # rm /usr/share/man/man1/zabbix_agent.1* # strip ­­strip­all /opt/zabbix­1.8.4/*/* Não é aconselhável executar daemons de sistema com o usuário root, por isso vamos  criar um grupo e usuário de nome zabbix para que o serviço entre na memória como usuário não  privilegiado. O nome do usuário que o Zabbix usa é hadcoded, ou seja, ele é programado dentro do   código fonte e não pode ser alterado via configuração. Desse modo sempre temos que   criar o usuário com o nome zabbix, já o nome do grupo é totalmente opcional. # groupadd zabbix # useradd ­g zabbix ­m ­s /bin/bash zabbix

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 37 Ambos os daemons, do agente e do servidor, precisam de dois diretórios para armazenar  os logs e o arquivo de PID. Com os comandos abaixo crie e dê as permissões necessárias para  ambos. # mkdir /var/{log,run}/zabbix ­p # chown zabbix. /var/{run,log}/zabbix

2.5.3. Serviços de rede Acrescente   ao   “/etc/services”   o   mapeamento   de   portas   do   “Zabbix   Agent”   e   “Zabbix  Trapper”. # vim /etc/services … zabbix­agent     10050/tcp Zabbix Agent zabbix­agent     10050/udp Zabbix Agent zabbix­trapper   10051/tcp Zabbix Trapper zabbix­trapper   10051/udp Zabbix Trapper Estas   entradas   permitem   que   programas   como   “wireshark”   e   “netstat”   reconheçam   as  portas do Zabbix.

2.5.4. Arquivos de configuração Os   arquivos   de   configuração   do   Zabbix   acompanham   os   seus   fontes,   mas   a   4Linux  preparou um conjunto de arquivos para uso em produção com uma organização melhorada. Ao  invés de simplesmente colocar todas as configurações em um único arquivo, os parâmetros foram  distribuídos em grupos lógicos separados em vários arquivos e diretórios. O Zabbix por padrão procura pelos seus arquivos em /etc/zabbix, a partir dos arquivos  principais (zabbix_server.conf e zabbix_agentd.conf) outros arquivos foram chamados e inseridos  na   configuração.   A   tabela   abaixo   demonstra   como   ficaram   organizados   os   diretórios   e   seu  conteúdo.

Diretório ou arquivo /etc/zabbix/agent.d

Descrição Diretório para configurações extras do

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 38 Diretório ou arquivo

Descrição agente principal)

(carregado

pelo

arquivo

/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 comandos remotos no agente.

/etc/zabbix/alert.d

Diretório externos

/etc/zabbix/externalscripts

Diretório para scripts de extensão do agente do Zabbix.

/etc/zabbix/server.d

Diretório para configurações extras do servidor (carregado pelo arquivo principal)

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

Configuração do “back end” de banco de dados do servidor.

/etc/zabbix/server.d/logs.conf

Configuração de logs (local, nível de debug, etc.) do servidor.

/etc/zabbix/server.d/network.conf

Configurações de rede do servidor.

/etc/zabbix/server.d/process.conf

Configurações de quais daemons devem iniciar e quantos de cada um deles, além de consumo de memória do servidor.

/etc/zabbix/server.d/proxy.conf

Configuração de monitoramento distribuído do servidor.

/etc/zabbix/zabbix_agentd.conf

Arquivo principal de configuração do agente

/etc/zabbix/zabbix_server.conf

Arquivo principal de configuração do servidor

para

scripts

de

de

alertas

Tabela 3: Arquivos e diretórios de configuração Copie   o   arquivo   compactado   do   DVD   (confs/config­server.tar.bz2   e   confs/config­ agent.tar.bz2) para dentro do /tmp da máquina virtual. Este arquivos tem vários valores padrões  razoáveis para começar e necessitam de pouca configuração. Não é de intenção deste material  dissecar   cada   uma   das   opções   de   configuração,   vamos   abordar   apenas   as   mais   relevantes,  porém os arquivos tem extensos comentários em português criados pelo autor deste material.

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 39 # cd / # tar xf /tmp/config­server.tar.bz2  # tar xf /tmp/config­agent.tar.bz2 # chown root.zabbix /etc/zabbix ­R  # find /etc/zabbix ­type d ­exec chmod 0750 {} \;  # find /etc/zabbix ­type f ­exec chmod 0640 {} \;   1)  Note que o grupo dos diretórios e seus arquivos foram apontados para “zabbix”. O  dono continuou a ser o root;  2)  Todos os diretórios tiveram a permissão de acesso global revogada, nenhum usuário  do   sistema   tem   que   acessar   esta   pasta   exceto   o   do   Zabbix   (existem   informações  sensíveis como senhas em text/plain nestes arquivos). Também, apenas o root tem  direitos de gravação nessas pastas o grupo zabbix tem apenas acesso de leitura.  3)  Os arquivos seguem a mesma lógica que os diretórios.

Não deixe de fazer o procedimento das permissões, ele vai tornar a sua instalação do   Zabbix muito mais segura. Para finalizar vamos configurar o sistema para apontar o PATH para o link simbólico de  instalação. Isso vai facilitar o acesso aos comandos. # vim /etc/profile.d/zabbix­path.sh 8

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

# . /etc/profile # zabbix_get ­­help # zabbix_agentd ­­help

2.5.5. Testando sua instalação Utilize o manual do “zabbix_agentd” para descobrir como listar as métricas suportadas  pelo ambiente e como testar um delas individualmente. Depois inicie o agente, veja o conteúdo do  arquivo de logs e use os comandos “ps” e “netstat” para ver quais os processos que ele iniciou e  em quais portas eles se vincularam. Depois do término com o agente vamos configurar o servidor conforme os passos a seguir  e realizar o mesmo procedimento de inicialização e pesquisa que no agente.

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 40 # vim /etc/zabbix/server.d/database.conf DBHost=127.0.0.1  DBPort=5432  DBName=zabbixdb  DBUser=zabbix  DBPassword=zabbixdbpw   1)  O endereço IP ou nome DNS do servidor que esta com o banco de dados. Como no  nosso cenário o banco e o servidor Zabbix estão na mesma máquina virtual utilizamos  o endereço de “loopback”;  2)  A porta TCP de acesso do banco. Esta é a porta padrão do PostgreSQL;  3)  Nome do banco de dados que criamos no início do capítulo;  4)  Nome do usuário que criamos e demos permissão;  5)  Senha do usuário acima. Agora execute os comandos de inicialização dos daemons conforme indicado abaixo. # zabbix_agentd # zabbix_server Verifique se as últimas linhas do log indicam se ambos iniciaram corretamente e também  se todos os processos estão na memória. # tail ­n1 /var/log/zabbix/zabbix_server.log   1203:20110207:092633.044 server #1 started [DB Cache] # tail ­n1 /var/log/zabbix/zabbix_agentd.log    871:20110207:092607.522 zabbix_agentd collector started # ps u ­C zabbix_agentd SER    PID %CPU %MEM VSZ  RSS TTY STAT START   TIME COMMAND zabbix 863 0.0  0.1  4836 496 ?   SN   09:25   0:00 /opt/zabbix/sbin/zabbix_agentd … # ps u ­C zabbix_server USER   PID  %CPU %MEM  VSZ   RSS TTY STAT START   TIME COMMAND zabbix 1201 0.0  1.0   46696 2636 ?  SN   09:26   0:03 /opt/zabbix/sbin/zabbix_server …

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

Note   que   a   saída   do   último   comando   é   muito   grande.   Ao   final   dos   testes   mate   os  processos com o comando “killall”: # killall zabbix_server zabbix_agentd

2.5.6. Scripts de boot No   CD   temos   alguns   scripts   de   boot   prontos   para   uso   no   Debian,   copie   os   arquivos   “boot/debian/server­bootscripts.tar.bz2”   e   “boot/debian/agent­bootscripts.tar.bz2”   para   o   “/tmp”   e  descompacte­os na raiz. # cd / # tar xvf /tmp/server­bootscripts.tar.bz2  # tar xvf /tmp/agent­bootscripts.tar.bz2 Teste a instalação dos scripts. # /etc/init.d/zabbix­server start # /etc/init.d/zabbix­agent start Por fim, coloque os scripts no boot da máquina virtual. # update­rc.d zabbix­agent defaults # update­rc.d zabbix­server defaults

2.6. Instalação do agente Zabbix via compilação Agora chegou o momento de instalar o agente do Zabbix nas outras máquinas virtuais  com Gnu/Linux. O procedimento de instalação é similar ao do servidor, mas não iremos habilitar a  opção “­­enable­server” no “configure”. Também não são necessários todos as opções de “with”  usadas acima. O agente é certamente mais simples que o servidor em termos de funcionamento e  só precisa do suporte a LDAP. 

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

2.6.1. Exercício: compile e instale o agente nas VM com Gnu/Linux Com as informações acima em mãos realize os procedimentos de instalação dos agentes  na máquina virtual  Presentation. Não se esqueça também de colocar os scripts de boot e os  arquivos de configuração nela e iniciar o processo na memória.

2.6.2. Acesso ao agente pelo servidor Agora que o agente esta instalado e rodando  é preciso realizar algumas configurações  básicas para que ele permita o acesso vindo do servidor. Primeiro vamos verificar se suas configurações de porta e rede estão de acordo, usando o  comando “netstat” para listar as portas que ele esta escutando. # netstat ­lntp | grep zabbix tcp  0 0 127.0.0.1:10050 0.0.0.0:* OUÇA 592/zabbix_agentd A saída do comando mostra que o daemon esta apenas vinculado ao endereço localhost  da máquina, vamos modificar seu arquivo de configuração e reiniciá­lo. Identifique qual o IP local  da   máquina   que   pertence   a   DMZ  (rede  172.27.0.0/24)  e  substitua   127.0.0.1   por  ele   dentro   do  arquivo /etc/zabbix/agent.d/networks.conf no parâmetro ListenIP. # vim /etc/zabbix/agent.d/network.conf 1

# Este é o arquivo de configuração de rede do agente do Zabbix.

2 3

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

4

# Qual porta  e IP que o agente vai se vincular para receber checagens passivas do servidor.

5

#

6

ListenIP=172.27.0.1 

7

ListenPort=10050

8 9

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

10

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

o qual esta designado a enviar dados conforme a tabela de oteamento. 11

#

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

SourceIP=  1)  Mudar para o IP interno do Presentation. Agora reinicie o agente e confira novamente a qual IP ele esta vinculado.

# /etc/init.d/zabbix­agent restart Stopping Zabbix agent daemon: zabbix_agentd Starting Zabbix agent daemon: zabbix_agentd # netstat ­lntp | grep zabbix tcp  0 0 172.27.0.1:10050  0.0.0.0:*  OUÇA  654/zabbix_agentd Se o serviço agora estiver vinculado ao IP correto repita estes passos em cada VM. Neste ponto é importante paramos para verificar uma possível falha de conexão. Vamos  forçar a VM “zabbixsrv” a se comunicar com o gateway (presentation) via “zabbix_get”. Vamos   usar a “key agent.ping” como exemplo. # zabbix_get ­s gateway ­k 'agent.ping' zabbix_get [6646]: Get value error: *** Cannot connect to [gateway]:10050 [Connection timed  out] Note a mensagem 'Connection timed out' no final da linha de erro, também repare que  levou algum tempo para que o comando retornasse a mensagem. Isso acontece porque o filtro de  pacotes   da   máquina   esta   bloqueando   conexões,   podemos   averiguar   isto   com   mais   precisão  usando a ferramenta “nmap” conforme abaixo: # nmap ­P0 ­p 10050 gateway

Starting Nmap 5.00 ( http://nmap.org ) at 2011­01­30 02:17 BRST Interesting ports on gateway.curso468.4linux.com.br (172.27.0.1): PORT      STATE    SERVICE 10050/tcp filtered unknown MAC Address: 08:00:27:BD:55:12 (Cadmus Computer Systems) Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds

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

O estado da porta que o nmap retornou é “filtered”, ou seja, não há retorno de pacotes do  sistema. Para  podermos  liberar o  acesso   use   o  procedimento  abaixo  no  terminal  da  máquina  “presentation”. # iptables ­A INPUT ­j ACCEPT ­p tcp ­­dport 10050 ­s 172.27.0.10 # iptables­save > /etc/iptables/rules Repetindo o “nmap” a partir do servidor do Zabbix: # nmap ­P0 ­p 10050 gateway Starting Nmap 5.00 ( http://nmap.org ) at 2011­01­30 02:34 BRST Interesting ports on gateway.curso468.4linux.com.br (172.27.0.1): PORT      STATE SERVICE 10050/tcp open  unknown MAC Address: 08:00:27:BD:55:12 (Cadmus Computer Systems) Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds Se o estado retornado for “open”, então o servidor é capaz de se conectar ao agente no  nível   da   camada   TCP,   mas   ainda   precisamos   ter   certeza   absoluta   que   ele   esta   permitindo   conexões no nível de camada de aplicação. Vamos repetir o teste com o zabbix_get  e ver se o  agente retorna o valor 1. # zabbix_get ­s gateway ­k 'agent.ping'  ←  Note que ele não retorna nada! Apenas uma linha em branco aparece no resultado do  comando. Isso esta ocorrendo porque o agente precisa liberar a consulta para o servidor, por  padrão os arquivos de configuração apenas permitem que ele seja acessado a partir do localhost.  Para liberar o acesso temos que editar o arquivo “/etc/zabbix/agent.d/checkings.conf” e mudar  dois parâmetros.

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 45 O primeiro, obviamente é o “Server”  que aceita uma lista separada por vírgula (,) dos  endereços que são permitidos fazer a consulta. O segundo  é o “Hostname”  representando o  nome da máquina com o qual o agente deve se apresentar ao servidor. Este nome deve ser único  e não necessariamente precisa ser igual ao hostname real da máquina, de fato no nosso cenário  iremos deixá­lo diferente. # vim /etc/zabbix/agent.d/checkings.conf 1

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

passiva e a ativa. 2

#

3

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

uma requisição ao agente que aguarda passivamente (dai o nome), este então coleta o dado  do sistema e envia de volta ao servidor. 4

#

5

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

do servidor e ao invés deste último cuidar do agendamento e requisições é o agente que toma  para si esta tarefa. 6

#

7

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

alcance o agente via rede ou quando se utiliza um sistema de monitoramento de logs onde o  monitoramento ativo é obrigatório. 8

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

9

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

checagens ativas. 10

Server=172.27.0.10 

11 12

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

13

# Como este host esta cadastrado dentro do Zabbix isto não precisa corrsponder ao 

hostname da máquina ele é uma string de identificação do agente para com o servidor do  Zabbix. 14

#

15

Hostname=Presentation 

…

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

 1)  Sempre temos que mudar este parâmetro para o endereço do servidor ou nome DNS  do mesmo. Se houverem mais de um servidor, separe os endereços/nome por vírgula;  2)  Este é o nome a ser cadastrado no “front end” do Zabbix e não o nome de DNS  (apesar de poderem ser os mesmos).  Reinicie o agente mais uma vez e faça o teste com “zabbix_get” a partir do servidor. # zabbix_get ­s gateway ­k 'agent.ping' 1 ←  Se o comando resultante retornou 1 então o servidor poderá acessar o agente a partir de  agora.

2.6.3. Exercício sobre instalação de agente em Linux  1)  Instale   o   agente   do   Zabbix   via   compilação   nas   máquinas   virtuais  Application  e  Database conforme mostrado neste capítulo.

2.7. Instalando o agente em ambientes Windows Um  dos   objetivos  do   curso   é   demonstrar  como   o   Zabbix   é   capaz  de   monitorar  redes  heterogêneas com vários sistemas operacionais e ativos de rede. Esta sessão cuida de instalar o  agente do Zabbix em um Windows 2003.

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

Figura 2.14: Baixando o agente do Zabbix no Windows

Primeiro

 

é

 

preciso

 

baixar

 

os

 

executáveis

 

pelo

 

endereço 

http://www.zabbix.com/downloads.php, localize o link de binários para Windows como na Figura  2.14. Clique no link de download e escolha um local para colocar o arquivo compactado, no  exemplo da apostila ele foi colocado em C:\Downloads. Abra a pasta em que o arquivo foi salvo e  descompacte o arquivo. Dentro dele você encontrará outras duas pastas para arquiteturas de 32 e  64 bits. No nosso caso iremos usar os de 32 bits.

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

Figura 2.15: Instalando os executáveis no Windows

Volte   a   raiz   e   crie   um   diretório   chamado   Zabbix   e   dentro   dele   ainda   crie   mais   três  diretórios: conf, log e bin e copie os executáveis descompactados dentro deste último.  Obtenha os arquivos do DVD com a configuração do agente do Windows  (conf/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.

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

Edite   o   arquivo   c:\Zabbix\conf\agent\checkings.conf   e   mude   os   parâmetros  Server  e  HostName  conforme   a   Figura  2.17,   para   permitir   o   acesso   do   servidor   e   o   arquivo  c:\Zabbix\conf\agent\network.conf para vinculá­lo ao endereço IP da placa de rede.

Use   o   Wordpad   para   alterar   estes   arquivos,   o   Notepad   tem   vários   problemas   com   codificação e finais de linha. 

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

Figura 2.17: Configurando o agente no Windows

Agora vamos testar a instalação, abra dois prompts de comando, no primeiro acesse o  diretório dos binários e execute o comando conforme abaixo. cd C:\Zabbix\bin zabbix_agentd ­c ..\zabbix_agentd.conf Note que uma mensagem dizendo que ele foi iniciado pelo console irá aparecer na tela. É  porque o Windows não é capaz de executar o agente como um daemon da maneira que o Linux  faz, mais a frente veremos como iniciá­lo como serviço do Windows que é maneira correta de se  fazer. Outra mensagem, desta vez via caixa de dialogo, também vai aparecer na tela. É o serviço  de   segurança   do   Windows   que   esta   perguntado   se   deve   bloquear   ou   não   esta   aplicação.  Obviamente devemos clicar em Desbloquear.

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

Figura 2.18: Desbloqueando o agente no Windows

Agora   no   segundo   prompt   de   comando,   use   o   comando   “netstat”   como   abaixo   para  verificar se ele esta escutando no endereço correto. netstat ­an

2.7.1. Executando o agente como serviço Instalar o agente do Zabbix como serviço é muito simples. No prompt de comando onde  você   o   testou   pressione   “CTRL+C”   para   cancelar   a   execução   do   programa   (demora   alguns  segundos). Quando o prompt retornar digite: zabbix_agentd.exe ­c c:\Zabbix\conf\zabbix_agentd.conf ­­install Duas mensagens irão aparecer indicando a instalação do agente como “Service” e “Event  Source”. Para conferir se o agente esta mesmo no ar abra o Painel de Controle  →  Ferramentas  Administrativas → Serviços e procure pelo serviço chamado “Zabbix Agent”.

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

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

Nesta tela é também possível parar, reiniciar, etc. o agente através da barra de ícones na  parte superior da janela. Como o serviço inicia parado devemos clicar sobre ele e no ícone Iniciar   o Serviço (representado pelo símbolo de “play”). Certifique­se que ele esta para ser iniciado automaticamente, assim quando o sistema for  reiniciado o serviço também será. Teste no servidor do Zabbix se ele esta conseguindo alcançar o  agente. # zabbix_get ­s win2003 ­k 'agent.ping' 1 Se ele retornar 1 como acima, então a instalação esta concluída.

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

2.8. Instalação do agente Zapcat para JBoss O   Zabbix   possui   alguns   agentes   programados   por   terceiros   além   do   nativo   que  acompanha os fontes padrão. Um destes agentes é o Zapcat, que é capaz de monitorar através  de   um  “deploy”,  servidores   JBoss   e   Tomcat.   No   nosso   cenário   temos   um   servidor   JBoss   na  máquina virtual Application que será monitorado pelo Zapcat. O resto desta sessão é dedicado à  instalação e configuração deste agente. O   Zapcat   é   na   verdade   um   JMX   Bridge,   ele   é   capaz   de   coletar   os   MBeans   JMX   do  servidor e expô­lo para o Zabbix via Zabbix API. Diferente do agente, ele escuta na porta 10051  (mas isso é configurável) e requer que outro “host” a parte seja criado dentro da interface do  Zabbix (veremos isso mais adiante).

2.8.1. Obtenção do binário Siga o procedimento abaixo para obter o binário do zapcat. Você irá baixá­lo do Source  Forge. # cd /var/tmp # wget http://ufpr.dl.sourceforge.net/project/zapcat/zapcat/zapcat­1.2/zapcat­1.2.zip   # unzip zapcat­1.2.zip # cd zapcat­1.2 # ls bin  build.xml  COPYING  lib  openfire  README  samples  src  templates  webapp  zapcat­ 1.2.jar  zapcat­1.2.war  zapcat­openfire­1.2.jar Note que o zapcat vem na forma de um .war (aplicação web java) e .jar (applicativo java).  Vamos nos ater apenas ao modo web.

2.8.2. Deployment Para instalar o Zapcat, simplesmente copie o binário para a pasta de “deploy” da instância  em execução do JBoss. No nosso caso esta pasta é /opt/jboss/server/application/deploy/. 

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

# cp zapcat­1.2.war /opt/jboss/server/application/deploy/ # tail /opt/jboss/server/application/log/server.log … 2011­01­30 06:08:10,616 INFO  [org.jboss.system.server.Server] JBoss (MX MicroKernel)  [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)] Started in 27s:81ms 2011­01­30 06:10:25,679 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy,  ctxPath=/zapcat­1.2, warUrl=.../tmp/deploy/tmp3690979215130123277zapcat­1.2­exp.war/ A última mensagem do log indica que o pacote foi instalado com sucesso (deployed). Ele  já   esta   funcionando   e   podemos   averiguar   isso   com   o   comando   “netstat”   como   fizemos  anteriormente. # netstat ­lntp | grep ':1005' tcp  0  0 172.27.0.20:10050  0.0.0.0:*  OUÇA 28751/zabbix_agentd tcp  0  0 0.0.0.0:10052     0.0.0.0:*  OUÇA 29181/java Repare   que,  como   ele   é  um  aplicativo  java,  o   “netstat” não  vai  informar  o   nome   dele  (Zapcat) na saída com ­p.

2.8.3. Opções de inicialização do JBoss O   JBoss   precisa   de   três   opções   para   permitir   que   o   Zapcat   possa   ler  todos   os   seus  MBeans  (  O  Tomcat   só  precisa   da   primeira).  Edite   o   arquivo  de   configurações  do   JBoss  e  e  acrescente ao final dele o seguinte conteúdo. # vim /opt/jboss/bin/run.conf … 1

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

2

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

3

JAVA_OPTS="$JAVA_OPTS 

­Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImp l" 4

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

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

JAVA_OPTS="$JAVA_OPTS ­Dorg.kjkoster.zapcat.zabbix.address=0.0.0.0”  1)  O “JMX remote” ativa o sistema de consultas via JMX no JBoss e Tomcat. No caso do  segundo apenas este parâmetro é necessário;  2)  O “Mbean server” é a implementação do JBoss para acesso aos JMX via servidor;  3)  Indica   a   classe   que   deve   ser   usada   para   manipular   os   Mbeans   internamente   no  JBoss;  4)  Esta opção define a porta do Zapcat. Ela é opcional e por padrão o Zapcat escuta na  porta 10052;  5)  Esta opção define a qual IP o zapcat deve se vincular. Ela é opcional e por padrão ele  se vincula a todos os endereços disponíveis do host (0.0.0.0). Reinicie   o   JBoss   e   teste   o   acesso   ao   Zapcat   pelo   endereço 

http://javaapp.curso468.4linux.com.br/zapcat­1.2/, a tela abaixo deve aparecer.

Figura 2.20: Tela de entrada do Zapcat

No próximo capítulo voltaremos a este acesso. Por hora já basta verificar se o Zapcat esta  funcionando.

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

2.8.4. Liberando o firewall para acesso ao Zapcat No filtro de pacotes libere o acesso à porta 10052/TCP com os comandos abaixo. # iptables ­A INPUT ­j ACCEPT ­p tcp ­­dport 10052 # iptables­save > /etc/iptables/rules

2.9. Testando o acesso via SNMP Uma das máquinas virtuais representa um ativo de rede, um “switch” para ser mais exato.  Nele nenhum agente pode ser instalado e vamos usar o SNMP para realizar o monitoramento.  Para testar se o acesso ao SNMP esta OK, instale as ferramentas de “snmp” no Debian. # aptitude install snmp snmp­mibs­downloader Libere o acesso a todas as MIBs do seu sistema. # vim /etc/snmp/snmp.conf 1

#

2

# As the snmp packages come without MIB files due to license reasons, loading

3

# of MIBs is disabled by default. If you added the MIBs you can reenable

4

# loaging them by commenting out the following line.

5

#mibs : Agora   utilize   o   comando  snmpwalk  para   verificar   se   o   switch   retorna   os   dados   de 

interfaces de rede.  # snmpwalk ­c public ­v2c 172.27.0.135 if IF­MIB::ifIndex.1 = INTEGER: 1 IF­MIB::ifIndex.2 = INTEGER: 2 IF­MIB::ifIndex.3 = INTEGER: 3 IF­MIB::ifIndex.4 = INTEGER: 4 IF­MIB::ifIndex.5 = INTEGER: 5 IF­MIB::ifIndex.6 = INTEGER: 6

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 56 IF­MIB::ifDescr.1 = STRING: lo IF­MIB::ifDescr.2 = STRING: eth0 IF­MIB::ifDescr.3 = STRING: eth1 IF­MIB::ifDescr.4 = STRING: eth2 IF­MIB::ifDescr.5 = STRING: eth3 IF­MIB::ifDescr.6 = STRING: switch0 … IF­MIB::ifSpecific.1 = OID: SNMPv2­SMI::zeroDotZero IF­MIB::ifSpecific.2 = OID: SNMPv2­SMI::zeroDotZero IF­MIB::ifSpecific.3 = OID: SNMPv2­SMI::zeroDotZero IF­MIB::ifSpecific.4 = OID: SNMPv2­SMI::zeroDotZero IF­MIB::ifSpecific.5 = OID: SNMPv2­SMI::zeroDotZero IF­MIB::ifSpecific.6 = OID: SNMPv2­SMI::zeroDotZero Se o comando retornou a lista acima (que foi truncada pelo tamanho) então seu sistema já  consegue ler o SNMP do “switch”. Se  você estiver usando um hardware com uma MIB proprietária, localize e  baixe  o   arquivo na Internet e copie­o no diretório /usr/share/snmp/mibs/

2.9.1. Conceitos de SNMP O   SNMP   é   um   protocolo   de   monitoramento   bem   difundido,   principalmente   entre  equipamentos de rede. A grande maioria do hardware embarcado para rede suporta algum tipo de  versão do mesmo. A mais comum é a versão 2, mas a versão 1 (considerada obsoleta) e a versão  3 (a mais segura) tem uma incidência regular. Se você tiver que optar por uma delas, sempre  tente escolher a mais recente possível. Apesar de adicionar uma certa complexidade, a versão 3  ajuda em muito na segurança pois trabalha com ACLs por autenticação e criptografia. No curso  veremos   a   versão   2   que   é   mais   comum   de   se   encontrar   nos   equipamentos   (opção   ­v2c   no  comando   usado   anteriormente),   mas   a   diferença   de   trabalho   entre   elas   é   bem   pequena  (praticamente alguns campos a mais na versão 3). Todas   as   três   versões   trabalham   com   MIBS,   arquivos   texto   com   definições   de   como  coletar as OIDS, as strings de acesso das métricas. Uma OID pode ser representada por um texto  como   DISMAN­EVENT­MIB::sysUpTimeInstance   ou   por   uma   representação   numérica   como   .

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 57 1.3.6.1.2.1.1.3.0.  Se você possuir a MIB de um equipamento monitorado pelo Zabbix e quiser utilizar a  forma textual mostrada acima em vez da numérica, terá que copiar o arquivo de texto dela dentro  do diretório de sua distribuição Gnu/Linux onde o servidor estiver instalado.  Normalmente este diretório esta em /usr/share/snmp/mibs/, mas é recomendado que  você confirme se isto vale para a distro que você esta usando. Por fim, a partir da versão 2 do protocolo SNMP passou­se a trabalhar com uma “string”  de comunidade (community). Por padrão esta “string” tem o valor “public” armazenado dentro dela  (parâmetro ­c do comando snmpwalk). Este valor tem como objetivo permitir apenas que quem  conheça a “community” seja capaz de acessar o SNMP. Francamente, colocar a segurança de um sistema em cima de um valor em texto plano  que   viaja   sem   criptografia   na   rede   não   é   nada   seguro.   Se   você   realmente   quiser  segurança deve usar a versão 3. Também proteja ao máximo o acesso a porta 161 (ou  a   qual   você   definiu)   de   acessos   indevidos,   o   ideal   é   permitir   apenas   acesso   dos  endereços dos servidores de monitoramento.  Apenas se lembre que ainda assim,  nada é inviolável e o SNMP não é exceção.

2.10. Instalando o servidor Zabbix via pacote No caso do repositório de uma versão de Debian possuir uma versão do Zabbix que é  adequado a suas necessidades então ao invés de compilar é recomendado que você o utilize. No  presente momento da escrita deste material esse não era o caso. # aptitude install zabbix­server­pgsql # aptitude install zabbix­agent

O CentOS não tem pacotes no seu repositório.

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

2.11. Preparando o servidor web Como visto anteriormente o Zabbix é um sistema componentizado e sua interface web  roda dentro de um servidor com suporte a PHP. Esta sessão descreve como instalar e configurar  um servidor Apache 2.2 para tal intento.

2.11.1. Instalação do Apache e PHP5 Para instalar um novo pacote apache com suporte a PHP siga os passos abaixo. O Zabbix  precisa ainda do suporte a GD (uma biblioteca gráfica) para geração de imagens e acesso ao  PostgreSQL. # aptitude install apache2 libapache2­mod­php5 php5­gd php5­pgsql php5­ldap No centOS, use o seguinte comando.  # yum install php http php­gd php­pgsql php­ldap

2.11.2. Configuração do Virtual Host Para criar uma configuração de “host” virtual no Apache para o Zabbix, vamos primeiro  criar um diretório e copiar o conteúdo da pasta “front ends” do seu diretório de fontes. # mkdir ­p /var/lib/zabbix/frontend # cd /usr/src/zabbix­1.8.4/frontends/php/ # cp * /var/lib/zabbix/frontend/ ­a Para assegurar que o apache tenha acesso apenas de leitura a pasta e seus arquivos  execute o procedimento abaixo.  # cd /var/lib/zabbix/ # find frontend ­type d ­exec chmod 0750 {} \; # find frontend ­type f ­exec chmod 0640 {} \; # chown root.www­data frontend ­R # chmod 0770 frontend/conf

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

O   último   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



2

        ServerAdmin [email protected]

3 4

        DocumentRoot /var/lib/zabbix/frontend 

5 6

        

7

                Options FollowSymLinks

8

                AllowOverride None

9

        

10

        

11

                Options Indexes FollowSymLinks MultiViews

12

                AllowOverride None

13

                Order allow,deny

14

                allow from all

15

        

16 17

        ErrorLog ${APACHE_LOG_DIR}/error­zabbix­frontend.log 

18 19

        # Possible values include: debug, info, notice, warn, error, crit,

20

        # alert, emerg.

21

        LogLevel warn

22 23

        CustomLog ${APACHE_LOG_DIR}/access­zabbix­frontend.log combined 

Capítulo 2 Criando uma Infraestrutura de Monitoramento – Parte 1, Sistema - 60 24 25



 1)  DocumentRoot precisa apontar para o diretório onde instalamos o “front end”.  2)  Em  ErrorLog, vamos direcionar os logs de erros para um arquivo específico deste  “virtual host”.  3)  O mesmo deve ser feito com o CustomLog, apontando para um arquivo específico de  acessos. Este passo esta substituindo o site padrão pelo do Zabbix. Se houverem outros hosts  virtuais na mesma máquina  não  é  necessário  removê­los, apenas  ajuste  as configurações do  arquivo acima para receber conexões apenas de uma URL em particular. # cd /etc/apache2/sites­enabled # rm 000­default # ln ­sv ../sites­available/zabbix­front end 000­zabbix­front end Reinicie   o   Apache,   abra   a   porta   80   do   firewall   e   teste   acessando   a   URL  http://zabbix.curso468.4linux.com.br/. # /etc/init.d/apache2 restart # iptables ­A INPUT ­j ACCEPT ­p tcp ­­dport 80 # iptables­save > /etc/iptables/rules O   primeiro   acesso   ao   “front   end”   vai   enviar   o   browser   direto   para   o   “wizzard”   de  inicialização do site. Siga os passos como descrito a seguir para ativar a interface.

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

2.11.3. Configurando o front end

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

A primeira tela é apenas uma mensagem de boas vindas. Clique em “Next” para começar.

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

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

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

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

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

Nesta   tela   muitos   alertas   de   falha   irão   aparecer,   isso   porque   o   Zabbix   requer   uma  configuração   muito   além   dos   padrões   do   PHP.   Neste   ponto   é   preciso   editar   o   arquivo   de  configuração do PHP e modificar os valores necessários.  Note   que   o   status   de   cada   parâmetro   pode   ser  um   OK   em  verde   (o   servidor  já   esta  configurado   para   o   recomendado   ou   superior),   Ok   em   vermelho   claro   (o   servidor   já   esta  configurado para o mínimo, mas não alcançou o ideal) ou “Fail” em vermelho que indica que nem  o mínimo foi atingido. O ideal  é deixar tudo no “Recommended”, porém é preciso avaliar se o  servidor   terá   os   recursos   necessários   para   a   execução   dessas   configurações.   Normalmente  teremos servidores que são capazes de fornecer recursos o suficiente para tal. Com o “vim” abra o arquivo conforme abaixo. # vim /etc/php5/apache2/php.ini

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

Procure   com   o   apoio   da   tabela   abaixo   e   da   tela   de   configuração   todas   as   opções  relevantes e configure­as para atingir o “Recommended”.  Parâmetro do PHP

Significado

date.timezone

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

max_execution_time

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

max_input_time

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

memory_limit

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

post_max_size

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

upload_max_filesize

Tamanho máximo para “upload” de um arquivo.

Depois de alterar e salvar o arquivo, reinicie o apache. # /etc/init.d/apache2 reload Então clique no botão “Retry”. A tela que será recarregada irá ser similar a abaixo.

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

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

Se   todos   os   pré­requisitos   foram   supridos   clique   em   “Next”.  Senão   refaça   os   passos  acima até conseguir chegar aos valores recomendados.  O suporte a GD do PHP no Debian Squeeze não atinge o recomendado mas funciona  sem problemas com o Zabbix. 

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

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

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.

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

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

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

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

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

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.

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

Figura 2.28: Configuração do front end (8/10)

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

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

Figura 2.29: Configuração do front end (9/10)

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

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

Agora pressione “Next” para ir para a próxima tela.

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

Clique em “Finish”. O “front end” irá abrir uma tela de login, você pode acessar usando o  usuário Admin (com o A em maiúscula) e a senha zabbix. A tela a seguir será a mostrada para  você.

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

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

2.12. Exercícios de revisão  1)  É possível colocar o agente do Zabbix para ser executado no Windows como serviço?  Como? ________________________________________________________________________ ________________________________________________________________________  2)  Quais os possíveis backends de bancos de dados que o servidor do Zabbix suporta? ________________________________________________________________________ ________________________________________________________________________  3)  É possível instalar a Interface do “front end” em qualquer servidor que suporte PHP? ________________________________________________________________________ ________________________________________________________________________  4)  Com o “snmpwalk” podemos listar várias partes  ou mesmo todas as métricas SNMP.  Qual o comando você usaria para pegar apenas uma métrica? ________________________________________________________________________ ________________________________________________________________________  5)  Realize uma breve pesquisa na Internet e relacione todos os agentes de Zabbix que  você encontrar. ________________________________________________________________________ ________________________________________________________________________  6)  Com o “zabbix_get”, colete via terminal de console o valor das chaves abaixo dos  hosts “win2003” e “application”:  6.1)  agent.version: 

_________________________________________

 6.2)  system.cpu.num:

_________________________________________

 6.3)  vm.memory.size:

_________________________________________

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

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

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

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

OBJETIVOS • Conhecer a configuração do Zabbix via Front end. • Gerenciar os hosts e templates para o monitoramento. • Criar métricas de monitoramento. • Depurar itens não suportados. • Gerenciar   acessos   e   permissões   aos   hosts   monitorados   através   de   usuários  cadastrados numa base LDAP. • Configurar os meios de alerta. • Criar mapas. • Realizar backups das configurações.

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

3.1. Introdução A partir deste ponto a interação administrativa via console vai diminuir consideravelmente,  pois vamos começar a trabalhar com a interface web do Zabbix. Quase 100% de todas as tarefas   com a ferramenta é executada através dessa interface. Nesta sessão e nas próximas serão apresentadas dicas de uso, organização, todas as  configurações do núcleo do “front end” e criação dos elementos mais básicos de monitoramento  (hosts, templates, grupos, etc.).

3.1.1. Organização do front end OK, você colocou no ar toda a infraestrutura da solução de monitoramento, agora um web  site com alguns menus esta diante de você. E agora?  Bom, o primeiro passo  é entender como os menus do Zabbix trabalham e aprender a  encontrar as opções que você deseja trabalhar. Esta interface é extremamente poderosa e ao  mesmo   tempo   simples   de   se   operar.   No   início   é   provável   que   haja   uma   certa   confusão   na  distribuição das janelas e funções, mas acredite, ela foi desenvolvida para ser fácil de usar após  aprender os entremeios dos menus. Aproveite   e   passeie   com   o   mouse   nos   menus.   Note   que   não   é   necessário   clicar   em  nenhum   dos   menus   superiores,   somente   a   passagem   do   ponteiro   já   exibirá   as   opções   dos  submenus. Nestes sim é necessário clicar para abrir a tela desejada! Na Tabela abaixo há uma  descrição superficial do que cada item de menu faz. Menu Monitoring

Função Menu para acesso ao monitoramento, depois que o Zabbix estiver  completamente configurado este é o menu mais acessado de todos.

•

Dashboard

Tela de centralização das informações de monitoramento.

•

Overview

Permite   a   visualização   global   ou   por   grupos   das   métricas  monitoradas e dos alarmes.

•

Web

Visualização do monitoramento dos serviços de web (não confundir  com monitoramento do servidor web).

•

Latest data

Mostra   os   últimos   dados   (e   quando   eles   foram   coletados)   do  monitoramento de um host.

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

Função

•

Triggers

Mostra o status dos últimos triggers (gatilhos) e permite interação  com   eles   (como   por   exemplo   dar   um   Acknowledge   a   um  determinado gatilho)

•

Events

Mostra   os   últimos   eventos   causados   pelos   triggers   ou   pelo  autodiscovery.

•

Graphs

Visualização individual dos gráficos cadastrados nos hosts.

•

Screens

Visualização   dos   screens.   Telas   que   agrupam   elementos  monitorados (como mapas, gráficos e widgets).

•

Maps

Visualização dos mapas.

•

Discovery

Hosts   e   elementos   que   foram   descobertos   pelo   sistema   de   auto  detecção de hosts.

•

IT Services

Visualização  de  SLA  baseada  no  monitoramento de hosts, ativos  e/ou serviços.

Inventory •

Hosts

Report

Inventário de hosts Hosts que fazem parte do inventário. Menu de relatório.

•

Status do Zabbix

Uma tela de resumo (que também é mostrada no Dashboard) para  avalização da performance do servidor Zabbix.

•

Avaliability Report

Relatórios de disponibilidade por hosts ou triggers.

•

Most   busy   triggers  Os 100 triggers mais ativos no sistema. Top 100

•

Bar Report

Configuration

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

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

Função

•

IT Services

Gerenciamento dos serviços para cálculo de SLA

•

Discovery

Gerenciamento do “auto discovery”.

Administration

Menu para acesso às opções de administração do front end.

•

General

Opções globais do front end.

•

DM

Configuração de monitoramento distribuído.

•

Authentication

Métodos de autenticação.

•

Users

Gerenciamento de usuários para acesso ao “front end”.

•

Media Types

Gerenciamento de formas de alertas (e­mails, SMS, etc.)

•

Scripts

Gerenciamento de scripts para testes on­line pelo “front end”.

•

Audit

Logs   de   auditoria   de   ações   dos   usuários   e   de   eventos   gerados  pelas Actions.

•

Queue

Fila de alertas a serem “acknowledged”.

•

Notifications

Notificações enviadas por usuário/tempo.

•

Locales

Personalização   das   strings   de   exibição   para   tradução   (português  brasileiro já esta pronto, portanto não precisamos mexer aqui).

•

Instalation

Telas de instalação (as mesmas que passamos agora a pouco para  configurar o “front end”).

Tabela 4: Função dos menus no front end Não é intenção do curso detalhar todos os itens de todas as telas (isso provavelmente  seria tarefa de um livro bem grande). Embora simples a interface do Zabbix tem uma magnitude   de opções bem grande e vamos nos concentrar nelas aos poucos conforme a necessidade e   escopo do curso.

3.2. Gerenciamento de usuários O ponto mais lógico para começar é administrar quem pode acessar o “front end” e definir  uma senha ao usuário Admin. Vamos entrar no menu Administration  →  Users. No canto direito  da tela que vai aparecer, você verá um “combobox” ao lado do botão “Create User” clique sobre  ele e selecione “Users”. A Figura 3.1 mostra a tela que irá ser exibida.

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

Figura 3.1: Gerenciamento de usuários do Zabbix

Dois usuários serão exibidos:  Admin, superusuário do “front end”, com o qual estamos  logados e guest, usado para acesso sem autenticação.  Não   tente   apagar   o   usuário   “guest”.   Ele   é   necessário   para   a   tela   de   login   quando   entramos na interface. Esta   tela   mostra   várias   informações   interessantes,   como   por   exemplo,   quando   foi  realizado o ultimo login e quem esta on­line no “front end”.  Para editar o Admin clique sobre o link com o nome dele. Uma nova tela ira aparecer.

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

Figura 3.2: Editando o Admin

Clique em “Change password” e coloque a senha a sua escolha, não esqueça essa senha  ou vai ser necessário reiniciá­la no banco de dados. Para evitar que o Zabbix fique desligando  nossa sessão a todo momento desligue a opção “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.

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

Agora que o Admin teve a senha modificada, é o momento de configurar o Zabbix para  autenticar no diretório LDAP instalado no servidor. Entre em  Administration  →  Authetication,  selecione em “Default Authetication” a opção LDAP e preencha os campos conforme abaixo.

Figura 3.3: Configurando a autenticação LDAP

Os dados aqui preenchidos variam de um ambiente para outro, no caso de estudo do  curso estamos dizendo ao Zabbix onde está o servidor (LDAP Host  e  Port), qual  é a raiz do  domínio (Base DN), qual o atributo usado em busca (por profundidade), não foi fornecido usuário  e senha de acesso ao LDAP, ou seja, ele é “read only guest based” (Bind DN e Bind Password) e  ativamos a autenticação (LDAP Authentication Enabled). É possível e recomendado que a senha do usuário Admin cadastrada dentro do LDAP  seja testada, preencha a senha e clique no botão “Test”. O Zabbix vai dizer se foi bem sucedido  ou não. Para salvar também é obrigatório que a senha seja digitada corretamente. Normalmente teremos um usuário e senha com “read only” para acesso do LDAP em   produção. Permitir acesso “read only guest based” não é a forma mais segura de se   fazer acesso a base de diretórios.

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

3.2.1. Cadastrando os usuários do LDAP no Zabbix Apesar do Zabbix estar apontando para o LDAP e o Admin estar funcionando  é preciso  mapear quais usuários da árvore de diretórios para dentro do “front end”. Se você não o fizer, não  será capaz de logar com um determinado usuário. No cenário que estamos usando temos alguns usuários descritos na Tabela  que devem  ser adicionados e alguns novos grupos de usuários que irão organizar alguns deles. Usuário

Descrição

Grupos

sysadmin

Administrador sistemas UNIX

de Network Administrators, UNIX Administrators, Web Administrators

winadmin

Administrador de Network Administrators, sistemas Windows Administrators

javaeng

Administrador JBoss AS

do JBoss Administratros

dba

Administrador banco de dados

do Database Administrators

Windows

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

Figura 3.4: Novo Grupo JBoss Administrators

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

Salve e escolha Users no combobox ao lado do botão “Create Group”, isso vai nos fazer  voltar à tela de usuários onde editamos o Admin. Clique no botão “Create User”  e cadastre os  usuários da Tabela 5 conforme a Figura 3.5. 

Figura 3.5: Novo usuário Sysadmin

O “Alias” é o campo com o nome do usuário e deve estar 100% igual ao dentro do LDAP.  “Name” e “Surname” são apenas “labels” para exibição e no quadro “Groups” use o botão “add”  para acrescentar a quais grupos o usuário pertence. Um campo que merece uma atenção especial é o  “User Type”  que permite dar alguns  privilégios iniciais à conta. No nosso caso iremos utilizar o tipo mais simples, o “Zabbix User”, que  permite apenas acesso ao menu de monitoramento.

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

Podemos ainda   criar  outros  dois  tipos  de  usuários, como   o  “Zabbix  Admin”  que  pode  acessar o monitoramento e a configuração de hosts. Este caso é útil quando alguém deve ter  permissões de verificação e também direito de cadastrar e modificar hosts monitorados assim  como seus “templates” e grupos. Por fim temos o “Zabbix Super Admin” que é o caso do nosso  usuário Admin. Este último pode fazer tudo, inclusive adicionar e remover direitos ao usuários. Mais a frente iremos acrescentar direitos aos usuários e também mudaremos seus tipos  conforme a necessidade.

3.3. Meios de alertas Os “Media Types” os nomes que o Zabbix atribui aos meios de envio de alertas. Como já  foi dito o Zabbix suporta correio eletrônico, SMS via modem, SMS via serviço de rede (EUA e  Canada apenas), mensageiro instantâneo via Jabber e chamada de scripts externos. No nosso  cenário de curso iremos aprender a trabalhar com estes recursos usando o sistema de e­mail e  jabber  (os  quais configuramos os  clientes no  início   do  capítulo).  Entre   em  Administration  →  Media   Types  a   tela   da   Figura  3.6  será   exibida   com   os   três   meios   de   comunicação   pré  configurados no servidor. Para editar qualquer um deles clique no nome da coluna  Description.   Para criar um novo, clique em “Create Media Type”. É possível ter múltiplos meios do mesmo tipo, por exemplo, ter vários servidores de e­mail  para ajudar na redundância do serviço de alerta ou dedicar determinados tipos de e­mails para   diferentes servidores.

Figura 3.6: Media Types

Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 84 Também é aconselhável limpar os  “Media Types”  não usados, como no nosso caso de  uso, não usa SMS, marque no “checkbox” a frente de seu nome, e em seguida selecione “Delete   selected” na caixa de ações ao fim da tabela e clique em Go (1). Confirme a exclusão. Ambas, a operação de limpeza e o modo de fazê­la, são bem triviais e serão muito  comuns no curso. Ela será repetida em muitos outros locais.

3.3.1. Correio eletrônico Agora  edite  o item de  e­mail, a  tela  da  Figura  3.7  será  exibida.  Preencha  os campos  conforme a mesma. Description é um campo descritivo apenas e não tem efeitos na configuração  a  não   ser  identificar  este   “Media   type”  na   interface;  SMTP  Server  aponta  para   o  nome/IP  do  servidor de e­mails (porta TCP/25); SMTP helo é usado na mensagem inicial trocada entre Zabbix  e servidores, é aconselhável colocar o domínio da própria empresa; SMTP e­mail é o endereço de  remetente que o Zabbix usará para enviar a mensagem.

Figura 3.7: Configurando o Zabbix para enviar e-mails

Clique em “Save” quando terminar.

3.3.2. Mensagens instantâneas Agora iremos editar o Jabber, clique sobre o nome dele e preencha os campos conforme   a Figura 3.8.

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

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

Os   campos   “Jabber   identifier”  e   “Password”  são   o   usuário   e   senha   de   uma   conta  cadastrada no IM destinada exclusivamente ao Zabbix, a senha no curso   é 123456. Salve os  dados. Sempre que utilizar um identificador de usuário no Jabber você deve incluir o nome do   servidor completo após o @ e não apenas o domínio.

3.3.3. Apontando os alertas aos usuários Agora vamos dizer quais usuários usam qual “Media Type”. Edite o usuário “sysadmin” e  note que no final da tela um campo “Media” esta com o valor “No media defined”. 

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

Clique em “Add” para adicionar um novo meio de alerta ao usuário. Vamos começar pelo  e­mail.

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

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. 

Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 86 A sintaxe do “When Active” usa 1 como segunda e 7 como domingo, definir por exemplo  segunda a sexta ficaria “1­5”. Uma vírgula separa o dia do horário, segunda a sexta das 09:00 até  as 18:00 ficaria “1­5,09:00­18:00”. Podemos ainda usar o ponto­e­vírgula para definir outras faixas,  por exemplo segunda a sexta, das 09:00 às 18:00 e sábado das 09:00 às 13:00 ficaria “1­5,09:00­ 18:00;6,09:00­13:00”. O “Use if severity “filtra os tipos de severidade de um campo. Eles são importantes para  que meios de alertas com custo (SMS) não sejam usados para alertas de pouca importância.  Também são usados para não causar avalanches de alertas em um meio os quais eles mais  incomodariam do que ajudariam, imagine ser alertado todo minuto por mensagem instantânea  que um serviço foi reiniciado! Seria totalmente improdutivo. Por fim, “Status” controla se este “Media Type” estará ou não ativo. Isso é particularmente  útil quando o funcionário responsável estiver de folga, afastado ou de férias. Clique em “Add” para salvar e adicione outro “Media Type” para o Jabber.

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

No nosso exemplo deixe o Jabber apenas com severidade “High” e “Disaster”. O nome do  usuário em “Send to” é o mesmo que o Alias. Salve e veja na Figura 3.12 como o campo “Media”  ficará.

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

Salve e repita para todos os usuários agora.

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

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

3.4. Hosts, host groups e templates Nesta   sessão   iremos   abordar   os   conceitos   mais   fundamentais   de   monitoramento   do  Zabbix: hosts, host groups e templates.

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

Hosts são a representação de um servidor, serviço ou ativo de rede a ser monitorado.  Eles normalmente representam um sistema físico, mas isso não é totalmente verdade, o agente  do Zapcat por exemplo, será representado por um host a parte e ele não é um hardware. Host groups separam logicamente os hosts e permitem que sejam atribuídas permissões  de acessos dos usuários a um determinado host. Templates (modelos) são os blocos de construção do monitoramento, enquanto não são  obrigatórios,   pois   podemos   acrescentar   métricas   de   monitoramentos   direto   a   um   host,   eles  ajudam a gerenciar de maneira efetiva os diversos tipos de monitoramentos possíveis e replicá­los  a tantos hosts quanto quisermos (ou o quanto nossos sistemas aguentarem, o que vier primeiro).   Os templates agregam métricas de monitoramento chamados items, macros e outros valores que  são importantes para construir uma solução de monitoramento. A maior parte do seu trabalho no  curso será em cima dos templates.

3.4.1. Templates para o caso de estudo O primeiro passo é limpar todos os templates preexistentes no Zabbix. Apesar de parecer  um tanto agressivo excluir todos os modelos pré criados, parte do intuito do curso é construir os  seus templates de maneira adequada a sua necessidade. Em produção você pode conservá­los  se   desejar,   mas   isso   não   é   um   requerimento   a   menos   que   você   tenha   garantidamente   um  equipamento para o qual um dos modelos tenha sido construído. Outra opção é fazer backup dos  originais (veja a próxima sessão). 

Figura 3.13: Selecionando todos os templates pré cadastrados

Para selecionar todos os templates, entre em  Configuration  →  Templates  e  clique no  “checkbox” do topo da tabela conforme indicado a Figura 3.13.

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

Figura 3.14: Excluindo os templates selecionados

Depois   escolha   no   “combobox”   no   final   da   tabela   o   valor  “Delete   selected   with   linked   elements” e pressione o botão “Go”. Perceba   que   o   Zabbix   indica   quantos   elementos   serão   afetados   pela   ação   do  “combobox” no botão “Go” no número entre parênteses.

Esta operação pode demorar alguns minutos dependendo da CPU e do I/O de disco  que seu equipamento possui. Agora é o momento de criar o primeiro template. 

Figura 3.15: Criando um novo template

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

Figura 3.16: Cadastrando um novo template

 1)  No campo Name será colocado o nome do novo template. Que será “4Linux – ICMP   base”. Este template conterá as métricas mais básicas de testes por ICMP.

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

 2)  No campo  Groups, quadro  “In Groups”  o grupo  Templates  deve ficar selecionado.  Note que os grupos para hosts são misturados com os grupos de templates. Você pode criar um novo grupo usando o campo “New group” sem a necessidade de   fazê­lo na tela de grupos de hosts.

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

Figura 3.17: Vinculando um template a outro

 1)  Na  parte   inferior da   tela  você  verá   um   botão  “Add”  ao   lado   do   campo  “Link   with  template”  2)  Escolha o template relacionado (4Linux – ICMP no nosso caso).   3)  Salve o template. Agora se associarmos um host com o template “4Linux – S.O. Base” ele automaticamente  vai   receber   todos   os   objetos   definidos   no   “4Linux   –   ICMP”.   Aproveite   e   crie   mais   um   último  template para usarmos na prática dirigida, “4Linux – SNMP Base” também vinculado ao “4Linux –   ICMP”.

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

3.4.3. Backup dos templates Uma ação importante em todo sistema é criar um backup das configurações. A partir de  agora toda modificação que fizermos nos mapas, templates, grupos e hosts deverá ser seguida de  um backup. A operação de backup, chamada “Export”  é bastante padronizada, todas as telas  pertinentes a fazer backup utilizam o mesmo procedimento explicado abaixo. O resultado  é um  arquivo XML contendo os dados de configuração.

Figura 3.18: Exportando um template

 1)  Selecione todos os templates que você desejar.  2)  Selecione “Export Selected” na caixa de opções do final da tabela.  3)  Clique no botão “Go”. Uma tela de download irá ser exibida, escolha o nome e local do arquivo e salve­o.  Mantenha estes dados em um local seguro e sempre realize esta operação após algum   tipo de alteração.

3.4.4. Hosts Agora que um template foi definido vamos criar um host e associá­lo a este modelo. Na  Figura 3.19 esta uma representação de como as máquinas virtuais estão dispostas em termos de  “layout” de rede. Em nossa prática dirigida iremos cadastrar os hosts “Presentation“ e “Switch”,  além de modificar o “Zabbix Server“ que é criado automaticamente no momento do importe de  dados do PostgreSQL.

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

Figura 3.19: Layout dos hosts a serem monitorados

Também devemos criar alguns grupos adicionais para separar logicamente cada servidor,  para isso vamos gerenciar os “Host Groups”.

3.4.5. Gerenciando os Host Groups Um “Host group“ tem duas funções dentro do Zabbix: a primeira e mais óbvia é manter  os hosts organizados de tal forma que seja mais fácil localizar ou exibir um grupo de servidores  com serviços correlacionados. A segunda é o sistema de permissionamento de acesso aos hosts  que será trabalhado ao longo do curso. Para   exemplificar   a   criação   dos   hosts   vamos   criar   apenas   um   deles,   que   conterá   os  equipamentos   de   rede.   Clique   no   menu  Configuration  →  Host   Groups,   e   clique   no   botão  “Create Group” conforme a Figura . 

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

Figura 3.20: Como criar um novo grupo de hosts

A seguinte tela irá surgir.

Figura 3.21: Novo host group

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

3.4.6. Criando um novo host Agora   que   geramos  um  “host   group”,   vamos   criar  os  hosts,   acesse  Configuration  →  Hosts, algo similar a Figura 3.22 irá aparecer.  Como dito anteriormente a lista de hosts já possui o  próprio servidor do Zabbix pré­cadastrado.

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

Para   criar   um   novo   host   para   o   “host   Presentation”   da   infraestrutura   clique   no   botão  “Create Host” (Figura 3.23). 

Figura 3.23: Botão para criar um host

E preencha os dados conforme a figura a seguir.

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

 1)  O campo Name coloque o nome do host (Presentation no nosso caso).  2)  No  Groups  escolha   quais   grupos   este   host   deve   pertencer.   Lembre­se   que   estes  grupos vão indicar quem pode ou não acessar este host pelo “front end”.  3)  Se houver um novo grupo não cadastrado acima é possível criá­lo aqui.  4)  Qual o nome DNS da máquina.  5)  Qual o endereço da máquina.  6)  O campo “Connect to” permite que seja escolhido o acesso pelo endereço IP ou pelo  nome de DNS. O clássico é usar o endereço (evitando consultas DNS excessivas no  lado do servidor), mas é possível que seja necessário monitorar estações de usuários  ou servidores que estejam em ambientes com IP dinâmico (via DHCP) e neste caso  somente via DNS é possível encontrar o host .  7)  Qual a porta TCP do agente. Vamos mudar isto para monitorar o  “Zapcat”, mas em  todos os outros casos deixaremos ela no padrão 10050.  8)  Não monitoraremos este host via proxy.  9)  No  Status  deixe   como  “Not   monitored”  por   enquanto,   quando   associarmos   os  templates iremos ativar este host.

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

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

Figura 3.24: Todos os hosts do cenário cadastrados

 10) 

3.4.7. Fazendo backup dos hosts O processo de backup dos hosts segue o mesmo procedimento do template. Selecione  todos os hosts criados e faça o backup dos mesmos.

3.4.8. Configurando uma permissão de acesso Com os usuários, grupos, máquinas e modelos definidos, vamos ver como dar o acesso  ao   monitoramento   de   determinadas   porções   do   Zabbix   para   a   conta   “sysadmin”.   Isso   é   feito  através dos grupos de usuários e grupo de hosts. Acesse Administration → Users.

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

 1)  Selecione “User groups” se já não estiver nesta opção.  2)  Clique no nome do grupo “Unix administrators”.

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

Figura 3.26: Concedendo permissões de acesso (2/4)

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

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

No dialogo que aparecer selecione o grupo de hosts “Linux Servers” e clique em “select”.

Figura 3.28: Concedendo permissões de acesso (4/4)

Ao retornar você verá o grupo na caixa. Clique em  “Save”  e pronto, quem pertencer ao  grupo “Unix administrators” vai poder ler e gravar nos hosts dentro de “Linux servers”. Os   direitos   de   “deny”   tem   precedência   aos   de   “read   only”,   que   por   sua   vez   tem  precedência sobre os de “read write”.

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

 1)  O cenário do curso precisa de um conjunto de permissões conforme a Tabela abaixo.  Crie grupos de hosts e usuários, e atribua permissões conforme for necessário para  chegar a este resultado. Note que há um novo usuário. 

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

Usuário Applica- Databa- JBoss AS Presention se tation suporte

Switch

Windows 2003

Zabbix server

read only read only read only read only read only read only read only

sysadmin readwrite

readwrite

read only readwrite

readwrite

winadmin read only read only read only read only readwrite dba

read only readwrite

javaeng

read only read only readwrite

read only readwrite readwrite

read only

read only read only read only read only read only read only read only read only read only

Tabela 6: Relação de permissões entre hosts e usuários Exceto pelos usuários “suporte” e “Admin”, todos os usuários devem ter permissão de  mudança de configuração dos hosts no qual eles tem direito de escrita.

3.5. Mapas Os mapas são elementos visuais úteis para determinar onde foi o ponto de falha dentro de  uma infraestrutura. Eles são de extrema valia para equipes que avaliam a saúde das máquinas  constantemente e precisam reagir rapidamente diante de um incidente. O Mapa também pode ajudar a diagramar estruturas físicas de rede e ajudam a mostrar  como   os   equipamentos   se   relacionam,   embora   o   “front   end”   não   seja   uma   ferramenta   de  desenhos de diagramas propriamente dita.

3.5.1. Importando imagens para o mapa Antes de  criar um mapa   é  preciso  definir as figurar que  farão  parte   de  seu  desenho.  Anteriormente nós pulamos o “dump” das figuras padrão do Zabbix, isso foi proposital pois iremos  inserir figuras de melhor qualidade dentro do “front end”.  O conjunto de figuras que utilizaremos esta dentro do fórum do Zabbix através do link  http://www.zabbix.com/wiki/_media/contrib/zabbix_icons_set_generic.zip.   Acesse­o   e   baixe   o  arquivo para uma pasta em se computador (não é necessário enviá­las à máquina destinada ao  servidor,  todo  o  procedimento  de   inserção   será  feito pelo   “front   end”). Depois descompacte  o  arquivo para ter acesso ás imagens.

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

Acesse o menu Administration  → General, e escolha na caixa de opções a esquerda. A  opção “Images”.

Figura 3.29: Tela inicial das imagens

Nesta tela clique no botão “Create Image” para abrir o diálogo de importação de uma nova  imagem. Conforme as instruções abaixo importe a primeira imagem.

Figura 3.30: Importando uma nova imagem

 1)  Nome   da   imagem   a   ser   inserido,   este   nome   precisa   ser   único.   No   primeiro   caso  coloque o valor “Server On”.  2)  Podemos enviar ícones (Icons) ou fundo de telas (Background) ao “front end”. Ícones  são usados nos elementos como hosts, triggers e imagens estáticas, telas de fundo  obviamente são usadas como um fundo para o mapa.  3)  No campo  Upload, clique no botão  “Browse...”  e escolha o local onde a imagem se  encontra, no caso do curso a imagem utilizada é o ícone de tamanho 48x48 e nome  “48_g_srv_tower_on.png”. Realize o mesmo procedimento para outras imagens conforme a tabela abaixo.

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

Nome da imagem

Ícone

Link

48_g_network_on.png

Server Disable

48_g_srv_tower_disable.png

Server Off

48_g_srv_tower_off.png

Server Unknown

48_g_srv_tower_unknown.png

Switch Disable

48_g_switch_disable.png

Switch Off

48_g_switch_off.png

Switch On

48_g_switch_on.png

Switch Unknown

48_g_switch_unknown.png

Tabela 7: Lista de imagens iniciais para o mapa Com isso todas as imagens necessárias para o primeiro estágio do mapa foram criadas.

3.5.2. Criando um mapa Agora que todos os ícones estão dentro do “front end” vamos criar o primeiro protótipo de  mapa. A imagem final dele esta representado na Figura 3.31.

Figura 3.31: Imagem do primeiro mapa a ser criado

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

Este mapa não tem todos os elementos a serem inseridos no mapa, mas vai proporcionar  um   bom   primeiro   exemplo.   Abra   a   tela   de   gerenciamento   de   mapas   acessando   o   menu  Configuration  → Maps, um mapa pré­cadastrado (Local network) irá ser exibido, marque a caixa  de checagem dele e exclua ele da lista.

Figura 3.32: Mapas pré-cadastrados

Depois de apagar o mapa existente crie outro novo clicando no botão  “Create Map”  no  canto direito da tela. Uma tela como na Figura 3.33 irá surgir e é preciso cadastrar os dados do  novo mapa conforme a seguir.

Figura 3.33: Novo mapa

 1)  O campo Name indica o nome do novo mapa, no caso desta prática dirigida coloque  “Infraestrutura Curso 468”.   2)  A largura em pixels do mapa, “600” é um bom tamanho para o nosso caso.  3)  A altura do mapa, “500” é um bom tamanho para o nosso curso.  4)  No campo  “Background Image”  podemos escolher uma figura de fundo para este  mapa. Vamos deixar o mapa sem figura de fundo.

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

 5)  A opção “Icon highlighting” serve para pedir ao Zabbix desenhar fundos  nos ícones  para representar estados, ela é um tanto redundante em relação a múltiplas figuras de  ícones como vamos ver mais a frente, porém iremos deixá­las ligadas mesmo assim.  6)  Se   o   ícone   possuir   um   “trigger”   que   teve   seu   estado   mudado   recentemente,   uma  borda será desenha em volta do ícone.  7)  No caso de haver um incidente com um item em particular, e ele for único (é somente  um   problema   para   aquele   item   em   particular)   podemos   deixar   o   campo   “Expand  single problem” ligado para que a descrição do problema seja apresentado no mapa  (evitando ter que clicar no item para exibi­lo).  8)  Qual o tipo de mensagem que será adicionada ao nome do item na tela quando um  “trigger”  for exibido. Os valores possíveis são:  “Label”, o default indicando que deve  exibir o nome do rótulo;  “IP Address”, mostra o endereço de rede do host;  “Element   name”,  o  nome  do  elemento  que  esta   apresentando   problemas;  “Status only”,  que  indica o status do “trigger” (OK ou PROBLEM); “Nothing”, nada é mostrado.  9)  Localização padrão dos labels.  10) 

No campo “Problem display” podemos escolher se desejamos mostrar todos 

os   problemas   em   uma   única   linha   (All),   duas   linhas   com   os   problemas   com  “acknowlegment”   e   outro   sem   (Separated),   ou   ainda   somente   os   problemas   sem  “acknowlegment “ chamados de “Unacknowledged”. Depois clique no botão “Save”. Você irá retornar a tela anterior. Agora para criar o mapa  visual clique sobre o nome do mapa.

Não se preocupe em decorar e testar todas as opções de mapas, iremos detalhar a  maior parte delas durante o curso.

Decidir o tamanho da área de mapas é uma arte, ela depende de vários fatores como  por exemplo o tamanho do monitor onde ele será exibido. Não se acanhe de retornar a  edição de configurações do mapa se o tamanho da área não ficar a seu gosto em um  primeiro momento.

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

3.5.3. Adicionando um elemento Dentro da tela de mapas, uma área em branco dividida por linhas de alinhamento será  exibida. Seu tamanho é o definido na tela de cadastro de mapas. Na parte superior da tela você  pode ver uma barra de ferramentas como na Figura 3.34, a explicação que segue define o uso de  cada botão.

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

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

Figura 3.35: Criando um novo elemento

Arraste­o até a parte da tela que você desejar para posicioná­lo.

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

Figura 3.36: Posicionando um novo elemento com o mouse

Versões anteriores do Zabbix não eram capazes de usar Drag & Drop. Tudo tinha que   ser feito com coordenadas manuais.

3.5.4. Editando um elemento do mapa Uma vez que o ícone esteja posicionado, é possível editar os seus atributos conforme os  passos descritos a seguir. Um elemento na tela pode ser de vários tipos, ele pode por exemplo  representar uma imagem estática, um host ou um gatilho.  Quando o ícone representa um elemento dinâmico ele vai reagir a mudanças dos estados  de   qualquer   um   dos   “triggers”   associados   visualmente.   Como   já   foi   dito   antes   isso   é  extremamente importante para acompanhamentos visuais, especialmente se for utilizado telões  ou monitores numa sala de acompanhamento de incidentes.

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

Figura 3.37: Editando um elemento na tela

 1)  Clique sobre o objeto criado anteriormente. A tela a direita irá ser exibida e pode ser  reposicionada na tela permitindo enxergar um determinado trecho do mapa na tela.  2)  O campo “Type” indica o tipo de objeto mencionado anteriormente, no primeiro caso  iremos escolher  “Image”  porque o link não representa nenhum elemento monitorado  (apesar   que   posteriormente   vamos   monitorar   o   estado   do   link).   Conforme   o  andamento do curso veremos muitos outros tipos.  3)  No   campo  “Label”  digite   o   texto   a   ser   exibido   como   rótulo   do   ícone.   Aqui   como  veremos mais tarde é possível colocar variáveis especiais chamadas de “Macros” que  o servidor associa a valores dinâmicos.  4)  A localização deste rótulo pode ser escolhida em “Label location”. Por padrão ela fica  como foi definido no padrão da criação do Mapa.  5)  Qual a imagem do ícone a ser exibida? Neste caso vamos deixar como esta, mas  todas as imagens que fizemos “upload” estão sendo exibidas nesta caixa de seleção.  6)  Por fim podemos configurar as coordenadas da posição do elemento dentro do mapa  em “pixels”. Normalmente fazemos isso pelo sistema “Drag and Drop”. No término clique em “Apply” para aceitar as modificações. Isso não vai fechar a tela de  edição, para isso ainda temos que clicar em “Close”. 

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

3.5.5. Salvando o mapa É importante que salvemos constantemente o mapa, pois se você clicar em outro link de  menu do “front end” irá perder todas as alterações feitas até esse momento. Para salvar o mapa  clique no botão “Save” (Figura 3.38).

Figura 3.38: Botão Save do mapa.

Um diálogo sempre aparecerá ao salvar um mapa. Ele não esta confirmando se você quer  salvar, e sim perguntando se deve retornar a tela anterior ou continuar no mapa. “Cancel” é usado  para continuar no mapa e “OK” para voltar a tela de gerenciamento de mapas.

Figura 3.39: Dialogo de salvar mapa

3.5.6. Adicionando os outros elementos Agora adicione mais dois elementos no mapa para representar os hosts “Presentation” e  “Switch” e posicione­os como na Figura 3.40.

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

Figura 3.40: Outros elementos gráficos a serem adicionados

Clique no elemento do meio para editá­lo conforme abaixo, ele servirá de representação  para o host “Presentation” agora.

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

Figura 3.41: Editando o elemento que representa o host Presentation

 1)  Neste   campo   vamos   escolher   o   valor   “host”.  Visto   que   vamos   utilizar   um   dos  previamente cadastrados, você verá que por ele estar desativado, quando clicar em  “Apply”, o “label” DISABLED será mostrado em vermelho.  2)  Neste   campo   o   valor   da   macro  {HOSTNAME}  será   substituído   pelo   nome   que  cadastramos o host no gerenciamento dos mesmos. Esta macro é interna do Zabbix e  não   precisa   ser   definida   pelo   usuário.   Durante   o   curso   aprenderemos   outras   e  definiremos várias que serão personalizadas para a nossa necessidade.  3)  Neste   campo,   que   aparece   sempre   que   escolhemos  Host  em  “Type”  clique   em  “Select” e escolha o host desejado. Neste caso é o “Presentation”.  4)  Troque o ícone para “Server On”, visualmente ele deve representar uma máquina.

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

 5)  Ao ativar  “Use advanced icons”  os campos do item 6 serão exibidos. Isso permite  escolhermos   um   ícone   diferente   para   cada   estado.   Como   foi   mencionado  anteriormente isso é um tanto redundante com o sistema de  “highlighting”  do mapa,  mas vamos ativar ambos para que você veja a diferença entre eles.  5.1)  Nestes campos escolha os ícones conforme indicado. Cada um dos estados irá  exibir um ícone diferente. Perceba que o exibido na tela ao clicar em “Apply” é o  “Server Disable”. O mesmo será feito para o elemento do host “Switch”, a Figura 3.42 mostra quais são os  valores utilizados.

Figura 3.42: Detalhes do host switch dentro do mapa

Como resultado final uma imagem parecida com a Figura 3.43 deve estar no meio de sua  área de mapa.

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

Figura 3.43: Hosts acrescentados no mapa

3.5.7. Criando e editando links Com os elementos de hosts e imagens no mapa ainda falta criar os links que interligam  um elemento a outro. Os links podem tanto ser um simples traço para mostrar uma ligação entre  dois   elementos   como   também   podem   ser   usados   para   demonstrar   estados   de   gatilhos   com  problemas.

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

3.5.8. Prática Dirigida

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

 1)  Primeiro selecione o ícone da Internet.  2)  Pressione “CTRL” e clique no ícone do host “Presentation”. A tela à direita de edição  vai representar uma mescla dos dois itens.  3)  Clique no botão de adicionar link. Uma nova parte da janela intitulada “Connectors”  irá surgir.   4)  Dentro dela um link chamado “Link_1” vai estar cadastrado e irá indicar quais são os  elementos que ele interliga. Clique sobre o nome dele para exibir suas propriedades  na aba “Connect Editor”.

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

Figura 3.45: Editando as propriedades do novo link

 1)  No campo “Label” podemos colocar uma identificação deste link. Assim como o rótulo  dos elementos com imagens ela também aceita macros.  2)  Nos dois campos de “Elements” os itens que estão vinculados podem ser alterados.  3)  Em   “Link   indicators“   vamos,   mais   a   frente,   associar   um   link   com   gatilhos.   No  momento deixe o valor como esta.  4)  Em “Type (OK)” escolha “Bold line”  para poder visualizar o link com mais facilidade.  Este campo é usado quando um ou mais gatilhos ao qual o link esta associado não  estejão ativos.  5)  Por fim em “Colour (OK)” podemos escolher uma cor para o link.

Clique em  “Apply”  e salve o mapa. Agora só é preciso adicionar mais um link entre o  “Presentation” e o “Switch”. A figura 3.46 mostra como este último vinculo deve ser cadastrado

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

.

Figura 3.46: Link entre o host Presentation e o Switch

Agora você já tem o mapa final desta prática dirigida. Salve e confirme o retorno para a  tela  de  gerenciamento de  mapas. Não  esqueça  de  fazer o  backup do  mapa  exportando­o  do  mesmo modo que fez com os templates e hosts.

3.5.9. Exercícios sobre Mapas

 1)  Faça upload das figuras do DVD contidas na pasta “Imagens Mapas”. São imagens do  logotipo  do  servidor Jboss. Os nomes no  “front  end” devem corresponder aos das  imagens.  2)  Construa o mapa final conforme a Figura 3.47.

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

Figura 3.47: Mapa final

3.6. Templates, applications e items Dentro dos tempĺates temos diversos elementos usados para realizar a coleta e análise das métricas. Considere um modelo como o coração de seu gerenciamento de monitoramento. A Figura 3.48 mostra quais são estes elementos. Acesse Configuration → Templates para chegar esta tela.

Figura 3.48: Templates e seus elementos

 1)  Applications  são pequenos grupos para organizar o próximo tipo de elemento (os  Items) dentro de um template. Eles são significativos na tela de “Latest data”.  2)  Os “Items” são provavelmente o objeto mais importante dentro de todo o Zabbix. Eles  são as definições das métricas de coletas. Quase que 90% de todo o trabalho de  monitoramento gira em torno de um “Item”.

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

 3)  Os “Triggers”, ou gatilhos, montam a lógica para gerar alertas baseado na informação  coletada pelos “Items”. A parte mais complexa do Zabbix  é montar as expressões  booleanas dos gatilhos de maneira concisa e equilibrada, evitando falsos positivos ao   mesmo tempo que gera alertas em um tempo hábil. Inciaremos o estudo deles no  próximo capítulo.  4)  Os “Graphs” são elementos que exibem gráficos. Também iniciaremos seu estudo no  próximo capítulo. Nesta sessão nos concentraremos apenas nos “Applications” e “Items”.

3.6.1. Criando um Application e um Item dentro de um template Ainda em Configuration  →  Templates, clique no link “Applications” (0) como indicado na  Figura 3.49. 

Figura 3.49: Criando um application (1/4)

Uma nova tela surgirá. Localize no canto superior direito dela o botão “Create application”  como na Figura 3.50 e clique sobre ele.

Figura 3.50: Criando um application (2/4)

A tela de “New application” surgirá conforme abaixo.

Figura 3.51: Criando um application (3/4)

 1)  Coloque o nome da “application” aqui, que neste caso ela será “ICMP”.  2)  Podemos   opcionalmente   escolher   outro   template   ou   host   para   associar   este  “application”. Pouco provável que venhamos a alterar este tipo de opção nesta tela. Clique em “Save” para concluir e retornar a tela que lista todas as “applications”.

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

Figura 3.52: Criando um application (4/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).

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

Na tela de “items”, clique no botão “Create Item”  para exibir a tela a seguir. Ainda não  será explicado campo a campo do cadastro de um novo item. Isso será feito no decorrer do curso.

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

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

 1)  No campo “Description” coloque um identificador (de preferência único, mas isso não  é   necessário).   O   nome   dele   será   o   exibido   em   gráficos,   usado   em   triggers,   etc.  Escolha coerentemente.  2)  O “Type” indica como este item vai fazer a coleta de uma métrica. Os diversos tipos  que   serão   abordados   neste   curso   serão   explicados   nos   próximos   capítulos,   aqui  vamos usar “Simple check” que significa usar checagens via protocolo de rede.  3)  O  “Key”  é o  campo  mais importante  de  todos, ele deve ser  único  dentro  de  cada  template   e   host.   Sua   função   é   definir   qual   métrica   será   coletada.   Como   dito  anteriormente um “item” é a parte mais importante de um template e o seu “key” é a  parte mais importante de um “item”. Saber qual usar em qual situação, faz parte da  competência de usar a ferramenta e de criar um monitoramento eficaz. No nosso caso   vamos   criar   um   “item”   que   faz   um   “ping”   via   ICMP   no   host,   logo   a   chave   será  “icmpping”. Clicar em “Select”  abre uma janela com infindáveis “keys” e você pode  selecioná­las por essa janela, se desejar.

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

 4)  Repetindo: “Cada item do Zabbix é capaz de armazenar apenas um, e somente um  valor”.   Não   é   possível   armazenar   objetos   complexos   dentro   dos   “items”,   por   isso  precisamos definir qual o formato do valor que será armazenado. No caso da “key  icmpping” ele retorna 1 se o “ping” foi bem sucedido e 0 se não. Valores inteiros sem  sinal como estes são “Numeric (Unsigned)”.  5)  O “Update interval”, é o tempo entre uma coleta e outra, em segundos. Por padrão o  Zabbix usa 30 segundos. Em nosso cenário usaremos 10, mas tenha em mente que  estes não são bons valores. Enquanto podemos nos sentir tentados a usar intervalos  curtos para termos uma granulidade de dados bem alta (e mais próxima da realidade)  ele impacta pesadamente em duas coisas: espaço em disco, que aparentemente  é  pequeno  mas começa   a  tomar grandes  proporções  em  ambiente  com milhares  de  métricas e o enfileiramento de métricas a serem processadas pelo servidor. A última  em   particular   é   muito   ruim,   pois   causará   todo   tipo   de   buraco   possível   nos   seus  gráficos. Veremos como calcular um bom intervalo a partir do próximo capítulo.  6)  Os campos “Keep history” e “Keep trends” indicam por quanto tempo, em dias, os  dados coletados serão armazenados. O primeiro é tempo dele na tabela “history” do  banco de dados que mantém os dados “ipses­literis” como coletados. A segunda  é  uma   média   de   3   horas   dos   valores   coletados   para   economizar   espaço.   Como  veremos, o  Zabbix  tem uma operação rotineira chamada “house keeping”  que limpa  os dados vencidos (depois que passar os dias em “keep history”) da tabela “history”,  passando a média para a “trends”. Depois que vencer o tempo em “Keep trends” os  dados são apagados definitivamente.   7)  Escolha o  “application”  ICMP  que criamos anteriormente. Se existirem mais de um  “application” nesta lista, você pode pressionar “CTRL” para selecionar vários.  8)  Clique em “Save” para finalizar.

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

O resultado final é mostrado na Figura 3.55.

3.6.2. Interdependência de templates Em várias situações práticas seremos obrigados a criar uma lógica de checagens entre os  triggers que irão gerar alertas e usar “applications  ”que estão em outros “templates”. Isso só  pode   ser   feito   se   criarmos   “templates”   que   são   associados   a   outros.   No   nosso   cenário   de  exemplos teremos vários casos deste tipo.

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

Normalmente os templates mais próximos da  raiz são aqueles que  realizam os testes  mais primários, como o template de ICMP criado anteriormente. De fato ele será a raiz da maioria  dos   outros   templates,   com   destaque   para   o   de   JBoss,   sistemas   operacionais   e   SNMP.   Para   exemplificar crie um novo template chamado “4Linux – JBoss Base”. Antes de salvar note que há  um campo no final do formulário chamado “Link with template”.

Figura 3.56: Campo para associação de templates

Clique no botão “Add” para abrir a tela de templates.

Figura 3.57: Tela para escolha de templates

Na janela de dialogo que aparecer selecione “4Linux – ICMP” e clique em “Select”. Você  pode escolher tantos templates quanto precisar nesta tela.

Figura 3.58: Template associado

A Figura  3.58  mostra como a tela ficará. Ela indica que o novo template é vinculado ao  “4Linux – ICMP”. Finalmente salve o template.

Figura 3.59: Template associado na lista de templates

Note que todo template que tem alguma associação será mostrado na coluna “Linked  templstes” na tela de “Templates List”. Agora todo host que for associado ao template “4Linux –   JBoss” será automaticamente associado ao “4Linux – ICMP”, além disso o primeiro pode utilizar  os “applications” do segundo e seus “triggers” podem depender dos do segundo. Para finalizar com os templates, crie todos os templates indicados abaixo e associe­os  conforme a estrutura de árvore indicada:

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

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

3.7. Associando os templates aos hosts Agora   que   temos   os   templates   criados   podemos   vincular   cada   um   deles   aos   hosts   criados. Fazer isso para um host é muito simples, siga os passos abaixo.

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

Vá até  Configuration  →  Hosts  e clique sobre o nome do host (no nosso caso vamos  usar “JBoss AS”) para editar as preferências do mesmo.

Figura 3.62: Associando o template do JBoss ao host JBoss AS (2/6)

Na parte direita da tela localize o quadro “Linked templates” (Figura 3.62) e clique sobre  o botão “Add”. Figura 3.63: Associando o template do JBoss ao host JBoss AS

(3/6)

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

No diálogo que surgir, escolha o template desejado (“4Linux – JBoss Base”) e clique em  “Select”. Você pode escolher tantos templates o quanto quiser aqui, desde que eles não estejam  associados entre si e nem tenham um template “pai” em comum.

Figura 3.64: Associando o template do JBoss ao host JBoss AS (4/6)

Você verá o nome dos templates escolhidos aparecerem neste quadro, conforme a Figura  3.64 demonstra.

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

Para finalizar clique em “Save”. Figura 3.66: Associando o template do JBoss ao host JBoss AS (6/6)

Note que o template escolhido e suas dependências, entre parênteses, serão exibidas na  Lista de templates.

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

Agora vamos fazer um pequeno exercício que vai demonstrar outro recurso interessante  do Zabbix: o “Mass update”. Imagine que você possui uma quantidade grande de hosts e precisa  associá­los   ao   mesmo   template,   temos   um   caso   destes   no   nosso   cenário:   os   hosts  “Presentation”, “application”, “Database” e “Zabbix server” precisam ser vinculados ao template  “4Linux – Linux”, uma vez que todas estas máquinas virtuais são servidores Gnu/Linux. Vá até a  tela de hosts e siga os passos a seguir.

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

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

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

Figura 3.69: Associando um template a múltiplos hosts simultaneamente (2/4)

 1)  Marque a opção “Link addictional templates”;  2)  Clique em “Add”. Nossa velha tela de templates irá surgir.

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

Figura 3.70: Associando um template a múltiplos hosts simultaneamente (3/4)

Marque “4Linux – S.O. Linux” e clique em “Select”.

Figura 3.71: Associando um template a múltiplos hosts simultaneamente (4/4)

Note  que o  template  ficará  logo  acima  dos botões de  adicionar e  remover. Clique  em  “Save” para finalizar.

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

Todos os hosts selecionados estã agora associados ao mesmo template.

3.8. Ativando um host Criamos os templates e hosts, demos permissões e montamos um mapa, mas nada esta sendo monitorado ainda. Isso é porque temos que habilitar todos os hosts. Realizar esta tarefa é muito simples.

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

Figura 3.73: Host presentation não monitorado

Vá em Configuration  →  Hosts e clique sobre o link “Not monitored”  conforme a Figura  3.73 indica.

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

Um dialogo irá surgir perguntando se o host deve ser mesmo ativado. Confirme clicando  em “OK”.

Figura 3.75: Host presentation monitorado

A coluna onde clicamos inicialmente agora deve estar com o link “Monitored”  em verde.  Aproveite e ative todos os hosts. Ao   invés   de   ativar   um   por   um.   Use   o   recurso   de   ativação   de   todos   os   hosts  simultaneamente   ativando  “Enable   selected”  na   caixa   de   opções  abaixo   da   lista   de  hosts.

3.8.1. Throubleshooting para itens com problemas Tecnicamente, com os templates, a instalação e a ativação em ordem, a esta altura o Zabbix estará coletando dados. Mas se formos até Monitoring → Overview veremos que nada aparece. Isso aconteceu porque, deliberadamente, um componente da instalação foi omitido: é o item que o criamos dentro do template “4Linux – ICMP”. O objetivo deste tópico é justamente ensinar a você como lidar com itens com problemas dentro do Zabbix. Sempre que suspeitar que uma métrica não esta funcionando devidamente, o lugar correto para descobrir o que pode estar acontecendo, está dentro dos itens do host. Vá até Configuration → Hosts e clique sobre um dos nomes dos hosts.

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

Figura 3.76: Item não suportado

A Figura  3.76  mostra como o item “ICMP Ping” deve estar com problemas. Note que o  “Status”   do   mesmo   é   “Not   supported”   e   um   sinal   de   erro   está   aparecendo   na   última   coluna  “Error”. Passe   o   mouse   por   cima   do   ícone   e   o   Zabbix   irá   mostrar   uma   dica   do   que   esta  acontecendo. A mensagem neste caso é “/usr/sbin/fping: [2] No such file or directory”. O servidor  não esta conseguindo encontrar o executável que ele utiliza para realizar os “pings ICMP” (fping).  Um outro lugar que também indica o que pode estar acontecendo  é o log do servidor.  Entre no console do Zabbix server e liste o final do arquivo de log conforme abaixo. # tail /var/log/zabbix/zabbix_server.log    2518:20110201:202018.896 server #18 started [Escalator]   2519:20110201:202018.900 server #19 started [Proxy Poller]   2506:20110201:202020.097 server #6 started [Poller. SNMP:YES]   2511:20110201:202020.108 Deleted 0 records from history and trends   2504:20110201:202020.147 server #4 started [Poller. SNMP:YES]   2502:20110201:202020.150 server #2 started [Poller. SNMP:YES]   2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]   2503:20110201:202020.242 server #3 started [Poller. SNMP:YES]   2505:20110201:202020.293 server #5 started [Poller. SNMP:YES]   2509:20110201:202023.022 /usr/sbin/fping: [2] No such file or directory A   última   linha   mostra   a   mesma   mensagem   que   no   “front   end”.   Para   remediar   esta  situação devemos instalar o fping pelo gerenciador de pacotes da distro que estamos utilizando.  No caso do Debian: # aptitude install fping Note que mesmo depois de instalar o aplicativo o erro persiste! Novamente consulte os  logs (ou o “front end”).

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

# tail /var/log/zabbix/zabbix_server.log    2506:20110201:202020.097 server #6 started [Poller. SNMP:YES]   2511:20110201:202020.108 Deleted 0 records from history and trends   2504:20110201:202020.147 server #4 started [Poller. SNMP:YES]   2502:20110201:202020.150 server #2 started [Poller. SNMP:YES]   2507:20110201:202020.218 server #7 started [Poller for unreachable hosts. SNMP:YES]   2503:20110201:202020.242 server #3 started [Poller. SNMP:YES]   2505:20110201:202020.293 server #5 started [Poller. SNMP:YES]   2509:20110201:202023.022 /usr/sbin/fping: [2] No such file or directory   2509:20110201:202923.237 /usr/sbin/fping: [2] No such file or directory   2509:20110201:203002.281 /usr/sbin/fping: [2] No such file or directory Mesmo após instalar o pacote, o erro persiste! Então provavelmente o Zabbix deve estar  procurando o executável no lugar errado.   Vamos usar o comando  which  (pode ser o  whereis  também) para saber onde ele está armazenado. root@zabbixsrv:~# which fping /usr/bin/fping ←  Note que ele está em “/usr/bin” e o servidor esta procurando ele em “/usr/sbin”. Isso é  claro   varia   de   uma   distribuição   de  Gnu/Linux   para   outra.   O   que   fazer   neste   caso?   Simples  mudaremos a configuração do servidor para se adequar ao ambiente em que ele foi instalado.  Edite o arquivo  “/etc/zabbix/zabbix_server.conf”  e procure as linhas com as opções indicadas  abaixo. # vim /etc/zabbix/zabbix_server.conf … #  ======================================================================== ==== # Localização do programa de ping (ipv4 e ipv6) # FpingLocation=/usr/bin/fping 

Capítulo 3 Criando uma Infraestrutura de Monitoramento - Parte 2, Front end - 127 Fping6Location=/usr/bin/fping6  …  1)  FpingLocaltion:   indica   o   caminho   do  “fping”  para   pacotes   ICMP   usando   IPV4.  Mude para “/usr/bin/fping”.  2)  Fping6Localtion: como acima, mas para IPV6. Mude para “/usr/bin/fping6”. Com as opções modificadas reinicie o servidor. # /etc/init.d/zabbix­server restart Stopping Zabbix server daemon: zabbix_server Starting Zabbix server daemon: zabbix_server

Uma outra possibilidade para resolver o problema  é fazer um link simbólico no sistema  operacional. A vantagem deste método é que não será necessário alterar nenhum arquivo de  configuração e nem reiniciar o Zabbix. ln ­s /usr/bin/fping /usr/sbin/fping Confira   no   s   logs   se   alguma   outra   mensagem   apareceu   e   acesse  Coonfiguration  →  hosts, se o item aparecer como não suportado ainda não se preocupe ele retornará em breve. Se  quiser que  ele seja  ativado  agora, clique sobre  o  “Not supported”  e ele será  restabelecido. A  imagem abaixo mostra como ele deve ficar ao final da operação.

Figura 3.77: Item suportado e ativo

Capítulo 4 Monitoramento voltado para disponibilidade - 128

Capítulo 4  Monitoramento voltado para disponibilidade

OBJETIVOS • Utilizar o Zabbix como uma ferramenta para medir disponibilidade: • Medir   a   disponibilidade   dos   equipamentos   via   checagens   simples   e     agente  (incluindo aqui o Zapcat) • Alertar quedas de hosts, serviços e reinicializações. • Medir a saúde da infraestrutura: • Latência de rede e de serviços. • Espaço em disco nos servidores. • Serviços ativos. • Interface • Teste manual. • Uso de gráficos e mapas. • Comandos externos.

Capítulo 4 Monitoramento voltado para disponibilidade - 129

4.1. Introdução Disponibilidade!   Provavelmente   é   o   que   vem   na   mente   da   maioria   dos   consultores   e  gerentes de TI quando ouvem a palavra “monitoramento”. Enquanto a disponibilidade não seja o  único   motivo   de   se   monitorar   ativos   e   serviços,   ela   é   o   fator   que   mais   impacta   em   custo   e  investimentos   realizados.   Quanto   custa   uma   hora   de   seu   principal   serviço   parado   para   sua  empresa? Neste   capítulo   será   abordado   uma   multitude   de   possibilidades   para   medir   o   quão  disponível estão seus servidores, serviços e ativos de rede. O Zabbix possui diversas maneiras de  descobrir   se   algo   não   esta   funcionando   e   aqui   veremos   como   fazer   isso   usando   protocolos  básicos de rede, testadores de protocolos, cenários de teste web, o próprio agente do Zabbix,  SNMP e o agente do Zabbix para JBoss. Também vamos entender como criar triggers (gatilhos) e Actions (ações tomadas quando  um gatilho muda de estado) e enviar alertas de parada de maneira inteligente, para evitar falsos   positivos e permitir que a equipe de suporte reaja a tempo quando um incidente acontecer. Além disso, vamos ver como medir diversas métricas e gerar nossos primeiros gráficos  dentro do “front end”.

4.2. Checagens manual via front end Obviamente o Zabbix permite que realizemos várias checagens de maneira automática,  afinal essa é sua principal função, mas antes de começar a coletar métricas e mais métricas,  vamos   ver   como   usar   o   “front   end”   para   realizar   testes   manuais,   incluindo   também   a  personalização destes testes. Vá até Monitoring  →  Maps e clique sobre o host “Database” com o botão esquerdo do  mouse (de fato pode ser qualquer host a sua escolha). Um menu  “popup”  irá surgir como na  Figura 4.1.

Capítulo 4 Monitoramento voltado para disponibilidade - 130

Figura 4.1: Menu de Ferramentas acessado pelo mapa

Note que uma aba divisória chamada “Tools” apresenta duas opções de comando que  podemos   pedir   ao   servidor   para   realizar:   “Ping”  e   “Traceroute”.   Ambos   são   comandos   bem  conhecidos de um administrador de sistemas “*nix”. Realize um teste clicando sobre o comando  “Ping”.

Figura 4.2: Saída de um comando ping

Depois de alguns segundos você verá um dialogo surgir como na Figura 4.2. Ele é a saída  textual do comando. No caso demonstrado o “ping” foi bem sucedido e o comando executado  é  inclusive mostrado no título da tela.  Vamos agora ao outro comando. Clique em “Close”  para fechar esta janela e execute o  outro comando via o menu “popup”. 

Capítulo 4 Monitoramento voltado para disponibilidade - 131

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

Apesar   do   comando   ter   retornado   uma   saída,   ela   é   extremamente   inadequada,   pois  sabemos que os hosts do cenário estão a 1 ou dois “hops” (saltos de roteadores) apenas. Isso  aconteceu porque o Firewall das máquinas esta bloqueando pacotes UDP, que são o padrão do  traceroute. Neste caso teríamos duas possibilidades:  1)  Liberar no firewall uma regra permitindo que o servidor do Zabbix alcance os hosts por  UDP;  2)  Modificar o comando para que ele realize traceroute baseado em ICMP que já esta  liberado no Firewall. Nesta caso vamos optar pela segunda, para demonstrar como alterar as configurações  destes comandos (que o Zabbix chama de scripts). Mas dependendo de seu cenário real, pode  ser preciso liberar o Firewall para permitir a passagem de determinados pacotes. Sempre cabe ao administrador ou gerente de rede tomar estas decisões com base na   simplicidade, segurança e necessidade do ambiente. Infelizmente estas são regras que   sempre entram em conflito, pondere bastante para não deixar falhas de segurança e   verifique se o comando a ser habilitado é mesmo necessário.

Capítulo 4 Monitoramento voltado para disponibilidade - 132

4.2.1. Adequando o script de traceroute O servidor do Zabbix, assim como seu agente, são executado em forma de “daemon” e  por questões de segurança eles são executados com permissões do usuário 6zabbix (e grupos ao  qual esta conta pertença).  Este   usuário  não  deve   ter   permissões   de   superusuário   (conforme   sua   criação   nos  capítulos anteriores) e sendo assim, somos obrigados a checar se os comandos que colocaremos  no “front end” podem ser executados pelo “daemon”. Primeiro vamos testar como root o funcionamento do comando. No caso do traceroute a  opção para realizar traçamento de rotas via ICMP é o “­I”. # traceroute ­I win2003 traceroute to win2003 (172.28.0.10), 30 hops max, 60 byte packets  1  gateway.curso468.4linux.com.br (172.27.0.1)  0.954 ms  0.820 ms  0.724 ms  2  172.28.0.10 (172.28.0.10)  1.158 ms  1.066 ms  1.054 ms Perfeito! Via ICMP o traceroute consegue chegar até o destino e mostrar as rotas. Agora  vamos tentar como usuário Zabbix. # su – zabbix $ traceroute ­I win2003 The specified type of tracerouting is allowed for superuser only $ logout # Você   não   pensou   que   seria   tão   fácil,   pensou?   Como   verificado,   o   usuário   não   tem  permissão de executar o traceroute com ICMP. Isso aconteceu porque somente o usuário root tem  direitos de criar pacotes da camada de rede arbitrariamente. Programas como “ping”, “fping”, entre  outros tem permissão SUID ativa para garantir que usuários convencionais sejam capazes de  executar estes programas. Evite usar SUID para dar permissões de execuções aos usuários normais! Isso pode   causar falhas de segurança.

Capítulo 4 Monitoramento voltado para disponibilidade - 133

Felizmente existe uma alternativa no mundo UNIX: o sudo, um programa que verifica se  um usuário tem permissão de execução a partir de suas configurações. Mesmo   o   sudo   teve   seu   histórico   de   segurança   comprometido,   por   isso   sempre   mantenha   sua   distribuição   atualizada   com   os   últimos  “patches”  de   segurança,  pois   nunca se sabe quando uma nova falha vai sair.  Instale o “sudo” a partir do repositório do Debian no host Zabbix server. # aptitude install sudo Agora use o comando visudo para adicionar a permissão do usuário zabbix de executar o comando traceroute. # visudo 1

# /etc/sudoers

2

#

3

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

4

#

5

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

6

#

7 8

Defaults        env_reset

9 10

# Host alias specification

11 12

# User alias specification

13 14

# Cmnd alias specification

15 16

# User privilege specification

17

root    ALL=(ALL) ALL

18 19

# Allow members of group sudo to execute any command

Capítulo 4 Monitoramento voltado para disponibilidade - 134 20

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

21

# it further down)

22

%sudo ALL=(ALL) ALL

23

#

24

#includedir /etc/sudoers.d

25 26

zabbix ALL = NOPASSWD: /usr/bin/traceroute Salve o arquivo e teste novamente o comando usando agora o sudo antes dele.

# su – zabbix $ sudo traceroute ­I win2003 traceroute to win2003 (172.28.0.10), 30 hops max, 60 byte packets  1  gateway.curso468.4linux.com.br (172.27.0.1)  0.980 ms  0.855 ms  0.926 ms  2  172.28.0.10 (172.28.0.10)  3.805 ms  4.292 ms  4.211 ms Voilá! Seu usuário Zabbix já consegue usar o comando no sistema. Vamos voltar ao front  end. Entre em Administration  →  Scripts e clique sobre o nome do comando “Traceroute”. Uma  tela de edição do script irá surgir.

No campo “Command” modifique o valor, colocando “sudo” seguido de espaço antes do  “traceroute”  e   clique   em  “Save”.   Agora   volte   até   o   mapa   (Monitoring  →  Maps)   e   execute   o  comando em vários hosts.

Capítulo 4 Monitoramento voltado para disponibilidade - 135

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

A saída da Figura 4.4 mostra a saída do comando sobre o host “Windows2003”. Note que  ela é idêntica à saída do terminal.

4.2.2. Criando novos comandos para o menu Quando as coisas começam a dar errado e os alertas chegam, você pode necessitar que  usuários de primeiro nível sem conhecimento profundo de Unix ou Windows, e consequentemente   sem acesso aos consoles do servidor, precisem realizar testes. Logo, existirão casos em que seu  ambiente demande de vários scripts a serem executado a partir do servidor via “front end”. Um  exemplo muito comum é o de testes de portas de serviços TCP.  Para exemplificar este caso, vamos criar um script que chama um comand “nmap” para  testar   a   porta   22/TCP   (SSH)   dos   servidores   Gnu/Linux   em   nosso   cenário.   Volte   para  Administration → Scripts.

Capítulo 4 Monitoramento voltado para disponibilidade - 136

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

Clique sobre o botão “Create script” conforme a Figura 4.5 para acessar a tela de criação  de comandos.

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

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

Capítulo 4 Monitoramento voltado para disponibilidade - 137

 5)  Qual tipo de permissão o grupo do usuário deve ter no “host groups” para exibir o  comando. Ao menos a permissão de “READ” é requerida. Depois de cadastrar os campos clique em “Save” e vá até o mapa para testar o comando.  Clique sobre um host Gnu/Linux.

Figura 4.7: Nova entrada de menu com o script criado

A Figura 4.7 demonstra como o “popup” será mostrado. Clique sobre o novo scipt “SSH”  para executá­lo.

Figura 4.8: Resultado do comando ativado no host

Se tudo correu bem a saída do comando deve ser mostrada conforme a Figura 4.8. Note  que os hosts switch, JBoss AS e Windows 2003 não devem exibir este comando.

Capítulo 4 Monitoramento voltado para disponibilidade - 138

4.2.3. Exercícios  1)  Gerencie   o   permissionamento   para   que   o   comando   SSH   seja   somente   executado  pelos usuários “suporte” e “sysadmin”.  2)  Crie o seguinte conjunto de comandos para teste de portas:  2.1)  Testar a porta 445/TCP dos hosts com sistema operacional Windows. Somente  os usuários “suporte” e “winadmin” devem pode executá­lo.  2.2)  Testar  as   portas   8009/TCP   do   servidor  de   aplicações.   Somente   os   usuários  “suporte” e “javaeng” devem poder executá­lo   2.3)  (Desafio) Testar a porta 80/TCP do  “gateway”  onde fica o sistema de cache e  proxy reverso  e  do  servidor de  aplicações.  Somente os  usuários  “suporte”  e  “sysadmin”  podem executá­los. No caso deste exercício você deve verificar se  foi retornado HTTP 200.  2.4)  (Desafio) Testar a porta 5432/TCP do host  “Database”. Somente os  usuários  “suporte” e “dba” podem executá­lo. No caso deste exercício você deve verificar  se foi retornado o valor um a partir de um “SELECT 1”.  2.5)  (Desafio) O  “Varnish”  tem um console local de comandos acessado por uma  porta. Na máquina  “Presentation”  crie um script que acessa este console e  limpa o cache do “Varnish” para ser chamado via script do Zabbix. Somente o  sysadmin pode executar este comando.

4.3. Checando disponibilidade via protocolo ICMP Criar   comandos   de   teste   é   interessante   mas   não   automatiza   o   monitoramento   que   o  servidor deve  fazer constantemente. Logo, chegou  o  momento de  verificar como  o  host pode   apresentar indisponibilidade a partir da checagem de retorno de pacotes “ICMP reply”. Nem todos os sistemas permitem pacotes ICMP. Se este for o caso, não adianta criar   testes como o a seguir, pule direto para verificação de agentes e portas.

4.3.1. Como funciona o ping ICMP O  ICMP ­ Internet Control Message Protocol  é um protocolo da camada de rede do  modelo TCP/IP responsável por trocar mensagens de controle entre os hosts (por exemplo, falhas  de rotas). 

Capítulo 4 Monitoramento voltado para disponibilidade - 139

O utilitário ping ou fping (instalado no capítulo anterior e usado pelo Zabbix para enviar  testes de ICMP) e tantos outros, utilizam apenas duas mensagens definidas na RFC 792 para  fazer testes de rede. Um para envio da mensagem e outro para resposta (Figura 4.9).

Figura 4.9: Diagrama de comportamento do echo ICMP

Este teste já esta sendo realizado em nosso cenário, visto que criamos o item “icmpping”  dentro do template “4Linux – ICMP” e ativamos os hosts. Embora muito primário, este teste valida  todo o caminho físico entre os componentes de rede do destino e da origem (switches, cabos,   placas, roteadores, etc.) e por isso é muito utilizado dentro de vários cenários reais. Podemos ver  a troca de pacotes acontecer através do comando “tshark” a seguir. # tshark ­ni eth0 icmp and host 172.27.0.1 Running as user "root" and group "root". This could be dangerous. Capturing on eth0   0.000000  172.27.0.10 ­> 172.27.0.1   ICMP Echo (ping) request   0.000959   172.27.0.1 ­> 172.27.0.10  ICMP Echo (ping) reply   1.000731  172.27.0.10 ­> 172.27.0.1   ICMP Echo (ping) request   1.001954   172.27.0.1 ­> 172.27.0.10  ICMP Echo (ping) reply   2.000778  172.27.0.10 ­> 172.27.0.1   ICMP Echo (ping) request   2.001882   172.27.0.1 ­> 172.27.0.10  ICMP Echo (ping) reply Note que para todos os pacotes “echo request”, um “echo reply” retorna do destino.

4.3.2. Visualizando o ping ICMP no Front end Podemos   visualizar   o   resultado   dentro   da   tela   de   “Overview”   do   “front   end”.   Acesse  Monitoring → Overview para exibi­la.

Capítulo 4 Monitoramento voltado para disponibilidade - 140

Figura 4.10: Hosts ativos com ping ICMP em funcionamento

Na Figura 4.10 temos um exemplo desta tela mostrando todos os hosts. Se ela não estiver  aparecendo não se esqueça de selecionar no comapo “Type” o valor “Data”. Embora   o   “Overview”  esteja   exibindo   corretamente   o  valor  1   da   “key  icmpping”  não   é  muito intuitivo olhar para um número em meio a uma tabela (sem levar em conta que esta tabela  pode ser demasiadamente extensa). Por isso o Zabbix oferece um recurso interessante chamado  “Values Maps” que permitem dar nomes aos valores.  Já existem vários deles definidos por padrão. Entre em Administration → General, no canto direito da tela e selecione “Value Maps”. Aproveite a oportunidade e apague todos eles, exceto “Service State” e “Windows Services”, assim mantemos o ambiente limpo.

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

Agora   conforme   a   Figura  4.11  indica,   clique   sobre   o   nome   do   “Value   Map”  chamado  “Service State” para editá­lo. Vamos transformar seus valores “Up” e “Down” em “Ok “ e “Falha”.

Figura 4.12: Editando o value map para nossa necessidade

 1)  Name: Aqui   é  definido  o  nome  do   novo  conjunto  de  valores, vamos mudá­lo  para  “Estado”. 

Capítulo 4 Monitoramento voltado para disponibilidade - 141

 2)  Mapping  e  New mapping: Estes campos permitem a edição dos valores que são  mapeados.   Clique   sobre   os   valores   de   “Up”  e  “Down”  e  clique  no   botão  “Delete   Selected”  para removê­los e  depois  use o  “New Mapping”  para adicionar os novos  valores conforme a ilustração demonstra. Clique em “Save” para salvar e sair.

Figura 4.13: Value map editado e pronto para uso

Note   que   o   “Value   Map”  foi   alterado.   Agora   vamos   associar   o  “Ping   ICMP”  ao   novo  “Estado”. Vá até Configuration  →  templates, clique sobre o valor “items” do “4Linux – ICMP” e  depois sobre o nome do item “ICMP Ping”.

Figura 4.14: Selecionando um value map no trigger

Procure o comando “Show value” conforme indicado na Figura  4.14  e escolha a opção  “Estado”. Salve o item e volte ao “Overview”.

Figura 4.15: Values maps no overview

Note que agora todas as opções que possuem o valor 1 estão com a string “OK”. Isso  facilita e muito a visualização dos valores e sempre que possível iremos criar ou usar “Values   Maps” prontos para melhorar a apresentação de dados.

4.3.3. Criando um gatilho de parada de host Embora já saibamos qual host esta OK, ainda não pedimos ao servidor para nos alertar  via 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 

Capítulo 4 Monitoramento voltado para disponibilidade - 142 nossos hosts. Primeiro pause uma das máquinas virtuais (o exemplo utiliza o “Database”), pelo console  do Virtual Box selecione o menu Machine → Pause (Ou use CTRL Direito + P).

Figura 4.16: Pausando o host Database

Depois de alguns segundos (dez  para  ser mais exato) o  “Overview” vai indicar que  o   “Database” esta parado.

Figura 4.17: Host database parado no overview

 1)  Caso deseje pode­se escolher o grupo “Database servers” para facilitar a visualização  dentro do “Overview”. Agora   que   já   sabemos  que   o   item  esta   funcionando   corretamente,  vamos  criar  nosso  “trigger”. Antes ative a máquina virtual, assim o “trigger” entrará desligado.

Capítulo 4 Monitoramento voltado para disponibilidade - 143

Um trigger, ou gatilho, é um teste de condição que possui um estado (OK, PROBLEM ou  UNKNOWN) e permite que o Zabbix tome uma decisão sobre a ocorrência de um incidente dentro  do cenário monitorado.   Um único “trigger” pode conter um simples teste boleano como o que  usaremos daqui a pouco, como também verdadeiras equações boleanas que testam inúmeras  possibilidades para decidir o que aconteceu. Felizmente a grande maioria dos casos requerem  testes simples de valores de um único item. Vá para a tela de templates em  Configuration  →  Templates onde esta o “4Linux – ICMP”.

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

Edite os “triggers” do template conforme mostrado na Figura 4.18 .

Figura 4.19: Criando um trigger para a parada do host (2/9)

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

Figura 4.20: Criando um trigger para a parada do host (3/9)

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

Figura 4.21: Criando um trigger para a parada do host (4/9)

Capítulo 4 Monitoramento voltado para disponibilidade - 144 Note que a tela vai mudar conforme a Figura 4.21. Para criar nossa expressão use o botão  “Edit”. A tela “Condition” irá surgir para que possamos montar a opção do teste.

Figura 4.22: Criando um trigger para a parada do host (5/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 gatilho. Ao clicar na caixa de combinação  você verá uma grande quantidade de funções possíveis. O Zabbix é muito extenso e é  provável que você não venha a usar todas estas funções em produção, no entanto  elas estão lá se você precisar. No curso veremos apenas as mais relevantes. Escolha  “Last value = N” para que possamos testar se o último valor do “ping” foi uma falha.  3)  Last   of   (T):   define   o   tempo   ou   contagem   de   coletas   a   serem   analisadas.   Vamos  selecionar 1 coleta (a última).  4)  N: O valor de “N” na expressão da função escolhida no item 2. É zerono nosso caso,  que define um “ping” mal sucedido. Temos ainda o “Time shift” que permite retroceder no tempo para coletar métricas a um  espaço definido de segundos, no passado. Não usaremos ele ainda. Clique no botão “Insert” para  retornar a tela anterior.

Figura 4.23: Criando um trigger para a parada do host (6/9)

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

Capítulo 4 Monitoramento voltado para disponibilidade - 145

É   um   erro   muito   comum   dos   iniciantes   (e   mesmo   de   alguns   veteranos)   que  esqueçamos de clicar em “Add”. No caso de você receber um erro ao salvar dizendo  que a expressão é inválida verifique se você deixou de adicionar a fórmula.

Figura 4.24: Criando um trigger para a parada do host (7/9)

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.

Figura 4.25: Criando um trigger para a parada do host (8/9)

 1)  The trigger depends on: aqui podemos escolher se este “trigger” depende de outros,  de forma que ele não seja ativado se outro mais básico esta com status “PROBLEM”.  Vamos ver dependências mais a frente, por hora deixe vazio.  2)  Event generation: indica se o “trigger” vai gerar um evento apenas uma ou múltiplas  vezes.  3)  Severity: um dos campos mais importante de todos, indica o quão grave pode ser a  ocorrência de um incidente.

Capítulo 4 Monitoramento voltado para disponibilidade - 146

 4)  Comments: um texto explicando o que este “trigger” representa e o que acarreta ele  esta   ligado.   Útil   para   o   pessoal   de   primeiro   nível   de   suporte   que   não   tem  conhecimento profundo do sistema.  Clique em “Save” para finalizar este passo.

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

O gatilho deve estar sendo exibido na lista de “triggers”.

4.3.4. Lidando com os eventos Todo gatilho gera um evento que representa um único incidente, normalmente um evento  representa o início ou término do mesmo. Dentro do Zabbix você deve aprender a lidar com os  eventos   e   usar   o   “front   end”   para   verificar   se   um   deles   ocorreu.   São   muitas   as   telas   onde  podemos verificar que um incidente aconteceu em um host. Pause novamente o host  Database  para provocar o incidente de chamada dele e vá até Monitoring →  Dashboard. 

Figura 4.27: Indicação de problemas no Dashboard

Note que a coluna “Disaster” do quadro “System status” esta indicando que um host do  grupo  “Database Servers”  e  “Linux Servers”  está com problemas. Na verdade é o mesmo host  “Database” que esta nos dois grupos.  Outro lugar que deve estar refletindo a condição de falha é o próprio “Overviiew”, tanto no  modo de dados como na Figura 4.28 como na de gatilhos na Figura 4.29.

Capítulo 4 Monitoramento voltado para disponibilidade - 147

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

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

O Mapa também deve estar mostrando o status do “trigger” no host “Database”. Vá até  Monitoring →  Maps e perceba como o Zabbix colocou um círculo vermelho no fundo do host. O  nome do gatilho também esta aparecendo abaixo do label de nome.

Capítulo 4 Monitoramento voltado para disponibilidade - 148

Figura 4.30: Mapa indicando o host Database como down

Por fim existe a  tela  de  eventos  em  Monitoring  →  Events,  onde  podemos manipular  estes eventos. Antes de entrar nela,  remova a pausa da máquina  “Database”. Isso vai forçar o  Zabbix a gerar um evento de retorno que será visualizado na próxima tela.

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

 1)  Group: filtra as opções de “host groups”.  2)  Host: filtra os hosts do grupo escolhido.  3)  Source: define a origem dos eventos, um evento pode ser gerado por um gatilho ou  por detecções de hosts feitas pelo Zabbix.

Capítulo 4 Monitoramento voltado para disponibilidade - 149

Perceba que a coluna “Status” tem duas linhas: uma para a ativação do “trigger” e outra  para a desativação. Este comportamento é desejado pois para sabemos por quanto tempo um  determinado “trigger” ficou ativo (e por consequência, por quanto tempo o incidente ocorreu na  sua infra), basta analisar a coluna “Duration”.  Na coluna “Duration” se um evento mudou de estado uma última vez, o valor mostrado   indica o tempo desde aquele ponto até o presente momento.  Outro ponto importante é a coluna “Ack” (acknowledgement, ou confirmação). Ela mostra  se um determinado evento foi percebido por alguém, e é de boa prática sempre preenchê­lo com  algo relevante, mesmo que seja um simples texto de “esta sendo verificado”. Isso permite que o  Zabbix seja usado como um sinalizador de “tickets”. Clique sobre o link “No”  indicado na Figura  4.31 da linha com status “PROBLEM”.

Figura 4.32: Tela de acknowledgement

Na tela que surgir preencha o quadro de texto e clique em “Acknowledge & Return”. 

Figura 4.33: Acknowledge (confirmação) aplicado

Note   que   a   coluna   “Ack”  agora   apresenta   o   valor  “Yes”  em   azul.   Faça   o   mesmo  procedimento para o final do incidente. Nunca deixe eventos sem “acknowledgement”, isso faz com que o histórico de eventos   do Zabbix fique impreciso e deixe de ser confiável. 

Capítulo 4 Monitoramento voltado para disponibilidade - 150

ATENÇÃO!  A   partir   de   agora   você   é   obrigado   a   colocar   confirmação   em   todos   os   eventos que ocorrerem no curso, principalmente se eles estiverem dentro das práticas   dirigidas e exercícios.

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

Figura 4.34: Criando uma action para enviar o alerta (1/9)

Conforme na Figura 4.34, no canto direto da tela clique em “Create Action”.  Uma janela  de cadastro da ação irá surgir conforme a seguir.

Figura 4.35: Criando uma action para enviar o alerta (2/9)

Capítulo 4 Monitoramento voltado para disponibilidade - 151  1)  Name: indica o nome da ação e ele deve ser único.  2)  Event source: mostra de onde o evento foi originado. No nosso caso é um “trigger”.   3)  Default   subject:   é   o   campo   assunto   do   e­mail   a   ser   enviado   ou   valor   do  SMS/mensagem jabber. Note que é possível, e indicado, o uso de macros.  4)  Default Message: é uma descrição detalhada do evento, também é aconselhável o  uso de macros.  Os outros campos deste quadro não são relevantes no momento, deixe­os no default.  Antes de clicar em “Save” há mais dois lugares a serem configurados.

Figura 4.36: Criando uma action para enviar o alerta (3/9)

Um   deles   é   o   quadro   “Action   condition”  logo   abaixo   do   quadro   principal.   Clique   em  “New” conforme indicado na Figura 4.36. 

Figura 4.37: Criando uma action para enviar o alerta (4/9)

 1)  Na primeira caixa de opções, escolha “Trigger”, note que há vários tipos de valores  que podem ser usados para disparar uma ação.  2)  Na segunda caixa escolha “=”.  3)  Por fim clique em “Select” e ative o “trigger” que criamos anteriormente. Esta condição diz que toda vez que o gatilho escolhido mudar de estado esta “action” será  disparada. Clique em “Add” para adicionar e finalizar esta parte.

Figura 4.38: Criando uma action para enviar o alerta (5/9)

Note   que   a   condição   é   exibida   no   “Action   conditions”.   É   possível   adicionar  quantas  condições você desejar.

Capítulo 4 Monitoramento voltado para disponibilidade - 152

Figura 4.39: Criando uma action para enviar o alerta (6/9)

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

Figura 4.40: Criando uma action para enviar o alerta (7/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   enviada.   Podemos  escolher grupos ou usuários em particular. Para o nosso caso, uma parada de “ping”  deve ser enviada ao grupo “Network administrattors”.  3)  Send only to: aqui escolhemos quais “media types” devemos usar. Pode­se optar por  usar todos os disponíveis.  4)  Default   message:   envia   a   mensagem   padrão   à   operação.   Geralmente   este   é   o  desejado, mas podem haver casos de operações que precisem de uma mensagem  mais específica, como um SMS com um corpo de texto mais compacto. Clique em “Add” e você verá que a nova operação será adicionada ao quadro.

Figura 4.41: Criando uma action para enviar o alerta (8/9)

Após isso clique em “Save”  no quadro principal.

Capítulo 4 Monitoramento voltado para disponibilidade - 153

Figura 4.42: Criando uma action para enviar o alerta (9/9)

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

Figura 4.43: Mensagens de alerta recebidas no Evolution

Você   deve   receber   dois   alertas:   um   de   parada   (PROBLEM)   e   outro   de   retorno   (OK).  Perceba que os valores das macros foram substituídos pelo Zabbix.

4.3.6. Exercícios  1)  Aproveite o momento que você tem com uma “action” plenamente funcional e consulte  o manual on­line do Zabbix para conhecer as macros disponíveis no servidor, e altere  os   textos   e   títulos   das   mensagens   para   experimentar   os   valores   possíveis   nas  mensagens.  2)  Reinicie a máquina virtual “Database” conforme a Figura abaixo indica, e diga o que  aconteceu com os eventos. Você acha que isso é um comportamento correto? ________________________________________________________________________ ________________________________________________________________________

Capítulo 4 Monitoramento voltado para disponibilidade - 154

Figura 4.44: Reiniciando o host Database

4.3.7. Boas práticas com triggers Se você fez o último exercício, deve ter percebido que o evento foi acionado pelo “reboot”  da máquina virtual. Este tipo de comportamento é esperado, afinal a resposta do “ping”  deixou de  ser   enviado   ao   servidor.   No   entanto   a   máquina   não   caiu,   e   uma   simples   reinicialização  providencial em um servidor ou serviço, não deve ser acusada como queda de host. Ambos são  situações diferentes. Por isso devemos sempre ter em mente que nossos “triggers” não devem se limitar a  verificar um único valor de mudança de estado. É preciso de uma lógica mais bem trabalhada e  fazer uso de um recurso chamado “janela de tempo”. A Figura 4.45 ilustra como a janela de tempo  funciona.

Capítulo 4 Monitoramento voltado para disponibilidade - 155

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

As   janelas   de   tempo   são   intervalos   de   segurança   nos   quais   nos   baseamos   a   fim   de  permitir que o servidor de monitoramento se adapte a uma mudança nos valores de coleta. Seu  principal efeito é não alertar falsos positivos, que podem ser piores do que falsos negativos em   certas circunstâncias (lembra da história do lobo?). O alerta de queda de host ao reiniciar o host é  um falso positivo, não houve queda real, apenas uma reinicialização. Note que quando o servidor parar de responder, nenhum alerta é enviado imediatamente.  O “trigger” irá aguardar o tempo determinado na janela até decidir mudar de estado. O mesmo  acontece com o retorno do host. Embora pareça contra produtivo isso reduz o risco de envio de  mensagens de alerta a toa. Dependendo do tipo de mensagem, isso pode inclusive representar  uma economia para a empresa se o “Media type” usado for pago (como o SMS). Imagine receber  centenas (ou milhares de SMS) por causa de trafego excessivo que impediu que os “pings” ICMP   chegassem ao servidor! Nada saiu do ar, apenas o trafego de rede ficou insuportavelmente lento.   E a intermitência dos pacotes pode gerar mais dores de cabeça do que auxílio. Obviamente temos que tomar cuidados para que hajam alertas de outros estados que  um host ou toda a infraestrutura pode alcançar. Mais adiante neste capítulo vamos, por  exemplo, criar uma “trigger” para alertas de reinicializações. Definir gatilhos e ações para todas as possibilidades de sua infraestrutura é justamente  o maior desafio depois de responder a pergunta “o que devo monitorar?”. Geralmente  este tipo de granulação só é alcançado depois de alguns meses com o  monitoramento  ativado, e a melhor maneira de se planejar tudo isso é começar pequeno e cobrir novas  necessidades   conforme   elas   aparecem.   “Receitas   de   bolo”   como   a   “ITIL”   são  excelentes guias para se decidir por onde e quando começar.

Capítulo 4 Monitoramento voltado para disponibilidade - 156

Vamos então criar um “trigger” com uma janela de tempo. Edite a condição do nosso  “trigger” criado anteriormente, acessando Configuration  →  Templates, clique no valor “triggers”  do template “4Linux – ICMP” e depois abra a condição do gatilho. Dois campos serão alterados  como a seguir:

 1)  Function: mude a função para “Sum of values for period of time T = N”, justamente o  “T” é nossa janela.  2)  Last of (T): a definição da janela, no nosso exemplo, será de 60 segundos, visto que  nosso item “pinga” o host de destino a cada 10 segundos. Procure deixar a janela  próxima ao tempo de coleta entre “x3” a “x6”. Salve tudo e reinicie o host novamente. Se tudo correr bem a janela vai evitar que o alerta  seja enviado. Se ainda assim você receber o alerta é preciso aumentar a janela de tempo. Qual   um   bom   tamanho   de   janela   de   tempo?   Isso   é   uma   pergunta   que   depende   inteiramente de seus sistemas. A maioria dos casos não requer uma janela menor do   que 5 minutos. Janelas muito extensas podem diminuir o tempo de resposta da equipe   de   TI   e   janelas   muito   pequenas   tendem   a   gerar   falsos   positivos.   Tente   achar   o   equilíbrio.

4.4. Checagem genérica de portas e serviços Como dito anteriormente “ICMP requests” podem ser barrados por Firewalls. Se este for o  seu caso, então você não pode depender deles para medir a sua disponibilidade e deve recorrer a  outros métodos. Neste tópico veremos um muito comum, a checagem de portas TCP.

Capítulo 4 Monitoramento voltado para disponibilidade - 157

4.4.1. Conexões TCP e handshakes Como se dá a verificação remota de um serviço rodando em um soquete TCP? Vamos  fazer   uma   pequena   prática   para   a   verificação   do   mesmo,   e   entender   o   famoso   “Three   wy  handshake” do protocolo TCP. Primeiro ative no host “Application” o seguinte comando: # tshark ­ni eth0 host 172.27.0.10 and port 8080 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 O “tshark” é o comando de linhas de console do “Wireshark”, e é muito mais poderoso  que   o  “tcpdump”.   No   caso   do   comando   acima   pedimos   que   ele   capture   todo   o   trafego   da  interface “eth0” que vier do “Zabbix server” e usar a porta “8080”. Agora no servidor do Zabbix de nosso cenário, use o comando “nmap” para varrer a porta  “8080” do host “Application”. # nmap ­sT ­P0 ­p 8080 172.27.0.20

Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­09 17:08 BRST Interesting ports on application.curso468.4linux.com.br (172.27.0.20): PORT     STATE SERVICE 8080/tcp open  http­proxy

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds Note que usamos o parâmetro “­sT” para forçar o “nmap” a usar o “handshake” completo  em vez do “SYN scan1” padrão. Volte ao “Application” para ver o resultado no “tshark”. # tshark ­ni eth0 host 172.27.0.10 and port 8080 Running as user "root" and group "root". This could be dangerous.

1 O SYN Scan é um método considerado furtivo antigamente. Ele fazia apenas metade dos passos para abertura de uma conexão.

Capítulo 4 Monitoramento voltado para disponibilidade - 158 Capturing on eth0   0.000000  172.27.0.10 ­> 172.27.0.20  TCP 50952 > 8080 [SYN] Seq=0 Win=5840 Len=0  MSS=1460 TSV=4629163 TSER=0 WS=4   0.000090  172.27.0.20 ­> 172.27.0.10  TCP 8080 > 50952 [SYN, ACK] Seq=0 Ack=1 Win=5792  Len=0 MSS=1460 TSV=4617797 TSER=4629163 WS=4   0.000602  172.27.0.10 ­> 172.27.0.20  TCP 50952 > 8080 [ACK] Seq=1 Ack=1 Win=5840  Len=0 TSV=4629163 TSER=4617797   0.000727  172.27.0.10 ­> 172.27.0.20  TCP 50952 > 8080 [RST, ACK] Seq=1 Ack=1 Win=5840  Len=0 TSV=4629163 TSER=4617797 Perceba que 4 pacotes foram trocados. O primeiro é o “SYN” (syncronization) que pede a  abertura da conexão. O segundo que parte do servidor de destino como resposta é o “SYN/ACK”  (syncronization and acknowledgement) que confirma a abertura de pacotes e o terceiro é o “ACK”  apenas para concluir a abertura. O “nmap” usará ainda um último pacote para “resetar” a conexão  (RST, ACK) que não vem ao caso. A troca destes pacotes nesta ordem é o esperado pelas funções de soquete do sistema  operacional, se ela for realizada dessa forma isso significa que a porta remota esta em estado de  escuta (listening) ou que esta aberta. Mas ai vem a pergunta e uma porta fechada, o que retorna?  Vamos seguir com a prática, novamente no host “Application” execute os seguintes comandos. # iptables ­A INPUT ­j ACCEPT ­p tcp ­­dport 10000 # tshark ­ni eth0 host 172.27.0.10 and port 10000 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 O “iptables” 2libera no filtro de pacotes de entrada a porta 10000/TCP. Agora a partir do  servidor Zabbix teste a porta 10000. # nmap ­sT ­P0 ­p 10000 172.27.0.20

Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­09 17:13 BRST Interesting ports on application.curso468.4linux.com.br (172.27.0.20): PORT      STATE  SERVICE 10000/tcp closed snet­sensor­mgmt

Capítulo 4 Monitoramento voltado para disponibilidade - 159

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds Note o estado “closed” da saída do “nmap”! Vá até o “tshark” do “Application” e veja o  trafego dos pacotes capturado. # tshark ­ni eth0 host 172.27.0.10 and port 10000 Running as user "root" and group "root". This could be dangerous. Capturing on eth0   0.000000  172.27.0.10 ­> 172.27.0.20  TCP 47673 > 10000 [SYN] Seq=0 Win=5840 Len=0  MSS=1460 TSV=4696578 TSER=0 WS=4   0.000096  172.27.0.20 ­> 172.27.0.10  TCP 10000 > 47673 [RST, ACK] Seq=1 Ack=1 Win=0  Len=0 # iptables ­D INPUT ­j ACCEPT ­p tcp ­­dport 10000 Note que há apenas dois pacotes, o “SYN” de início de conexão como no exemplo anterior  e   outro   com   “RST/ACK”   pedindo   para   encerrar   imediatamente   a   conexão.   É   assim   que   um  sistema operacional informa que uma porta esta fechada para uma tentativa de conexão remota. Um “timeout” na abertura de uma conexão TCP é porque o cliente não recebeu nem  um “RST/ACK” ou um “SYN/ACK” após um período (que na maioria das vezes é de 60  segundos).

4.4.2. Criando um teste de serviço via varredura de portas Com estes dados disponíveis vamos criar uma situação onde haverá três casos de portas:  aberta, fechada e filtrada por firewall.  Não existe uma maneira confiável de se checar serviços que usam "UDP sem apelar  para a camada de apresentação do modelo TCP/IP. Primeiro pare o serviço de SSH no “Database”. # /etc/init.d/ssh stop Depois remova a regras de permissão de acesso de SSH da “Application”. 

Capítulo 4 Monitoramento voltado para disponibilidade - 160

# iptables ­D INPUT ­j ACCEPT ­p tcp ­­dport 22 A partir do “zabbixsrv” faça a seguinte varredura de portas. # nmap ­p 22 application presentation database ­P0 

Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­09 14:04 BRST Interesting ports on application.curso468.4linux.com.br (172.27.0.20): PORT   STATE    SERVICE 22/tcp filtered ssh MAC Address: 08:00:27:4B:97:E3 (Cadmus Computer Systems) Interesting ports on gateway.curso468.4linux.com.br (172.27.0.1): PORT   STATE SERVICE 22/tcp open  ssh MAC Address: 08:00:27:BD:55:12 (Cadmus Computer Systems) Interesting ports on database.curso468.4linux.com.br (172.27.0.30): PORT   STATE  SERVICE 22/tcp closed ssh MAC Address: 08:00:27:A3:73:61 (Cadmus Computer Systems) Nmap done: 3 IP addresses (3 hosts up) scanned in 0.48 seconds Note   que   no   “Database”  que   desligamos   o   SSH   retornou  “closed”  e   o   firewall   do  “Application” retornou “filtered”, somente o “Presentation” deu um “open”. Anote este resultados  pois iremos compará­los com o que o Zabbix retornar. No template “4Linux – S.O. Linux” crie um novo item de “simple check” com a “key ssh”.  Para que o servidor possa usá­la é preciso que ele esteja compilado com suporte a libSSH (opção  ­­enable­libssh).

Capítulo 4 Monitoramento voltado para disponibilidade - 161

Figura 4.46: Simple check para o SSH

 1)  Key: a chave “ssh” faz um teste na porta 22 dos servidores.  2)  Show value: escolha o “value map” “Estado”  como fizemos no ICMP ping. A chave  escolhida também retorna 1 para sucesso e 0 para falha.  3)  New application: crie uma aplicação exclusiva para o serviço de SSH. Não esqueça de preencher os outros campos conforme a ilustração. Depois de salvar  este novo item, consulte a saída do “Overview”.

Capítulo 4 Monitoramento voltado para disponibilidade - 162

Figura 4.47: Overview exibindo os serviços de SSH

Note como os dois serviços com firewall e com o SSH desligado retornaram Falha (0) e o  que estava em funcionamento retornou 1. Uma das grandes vantagens de testar portas TCP é que a possibilidade de incidência de  perdas de pacotes é bem baixa em relação ao teste realizado com o UDP.  Enquanto  o  manual   do   Zabbix  contém a  informação   de  que   a  checagem  de  vários  serviços retornam o valor 2 ao achar um timeout, o autor não foi capaz de reproduzir  este comportamento com sucesso.

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

Capítulo 4 Monitoramento voltado para disponibilidade - 163 Serviços OpenSSH Varnish cacher)

Porta 22/TCP

(HTTP 80/TCP

Host

Template

Key

Todos os Linux

S.O. Linux

ssh

Presentation

Varnish

http

Presentation

Apache

http

JBoss base

tcp,8009

Apache (proxy)

8080/TCP

JBoss (Aplicativo)

8009/TCP (AJP) Application

Apache (Aplicativo)

80/TCP

Application

Apache

http

PostgreSQL

5432/TCP

Database

PostgreSQL

tcp,5432

OpenLDAP

389/TCP

Database

OpenLDAP

ldap

8080/TCP (HTTP)

http,8080

Tabela 8: Serviços do cenário do curso Serviço não monitorável: ___________________________________________________ ________________________________________________________________________

4.5. Validação de páginas WEB Um recurso a parte no sistema de monitoramento do Zabbix é o teste de cenários web. O  servidor é capaz de disparar checagem pelo protocolo HTTP e reconhecimento de padrões HTML  para validar páginas HTML, inclusive com validação de formulários (tanto com GET ou POST). Para   suportar   este   tipo   de   checagem   o   servidor   deve   ser   compilado   com   suporte   à  biblioteca CURL (­­enable­curl).

4.5.1. Disponibilidade do site. O Zabbix denomina um teste de um site como um “scenario” (cenário), e dentro deste  cenário há vários elementos chamados de “steps” (passos) que correspondem a uma requisição,  ou seja, a uma URL. O   principal   uso   deste   tipo   de   teste   é   verificar   se   a   URL   esta   respondendo  adequadamente, podemos, por exemplo, verificar se o HTML contém uma determinada “string” ou  se o código  de  retorno  corresponde  a um sucesso, que normalmente  é “200  OK”. Mas estas  checagens tem outros itens embutidos nela. O servidor calcula automaticamente a latência de  rede e a velocidade de download dos dados na URL e já gera gráficos destas estatísticas. Um 

Capítulo 4 Monitoramento voltado para disponibilidade - 164 “trigger” também é criado automaticamente para alertar códigos de retornos inesperados ou falta  em   uma   determinada   “string”   na   página   de   resposta.   Ele   no   entanto,   não   gera   uma   “action”  sozinho. Muitas destas funcionalidades são encontradas em outras ferramentas como o “JMeter”  (que   possui   “asserts”   capazes   de   realizar   este   tipo   de   verificação),   porém   uma   solução   não  substitui a outra, pois a intenção do Zabbix não é ser um validador de aplicativos web e sim um  verificador de funcionalidades pontuais de URL. Ele também não deve ser usado como gerador de  cargas  para   testes  de   performance.  No   entanto   o   Zabbix   consegue   armazenar  o   histórico   de  resultados on­line por um longo tempo. Para criar um novo cenário acesse Configuration →  Web. Na tela que surgir você verá  que o botão de criação estará desabilitado (Figura  4.48). Para habilitá­lo é preciso escolher um  grupo e host conforme abaixo:

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

 1)  Group: escolha o grupo “Linux servers”.  2)  Host: escolha  “Application”, que é o host interno de nosso cenário que possui um  JBoss e um Apache executando aplicações. Ao escolher os dois valores o botão será habilitado. Isso acontece porque não é possível  colocar  um cenário dentro de um template, apenas dentro de um host. Daí a necessidade de se  escolher um host.

Figura 4.49: Criando um cenário para disponibilidade Web (2/6)

Clique sobre “Create scenario”, uma nova janela de cadastro irá surgir.

Capítulo 4 Monitoramento voltado para disponibilidade - 165

Figura 4.50: Criando um cenário para disponibilidade Web (3/6)

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

Capítulo 4 Monitoramento voltado para disponibilidade - 166

Figura 4.51: Criando um cenário para disponibilidade Web (4/6)

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

Capítulo 4 Monitoramento voltado para disponibilidade - 167

Figura 4.52: Criando um cenário para disponibilidade Web (5/6)

Note que no final do quadro da janela de cenário o novo step fica listado em forma de  tabela.   Ainda   não   vamos   acrescentar   outros   “steps”   neste   cenário.   Salve   clicando   no   botão  “Save”.

Figura 4.53: Criando um cenário para disponibilidade Web (6/6)

Na lista de cenários, temos agora o nosso cadastrado. Para verificar este monitoramento  temos uma tela especial só para ele. Acesse Monitoring → Web.

Figura 4.54: Visualizando a checagem Web

Clique sobre o nome do cenário e note que ele esta sendo organizado pela “application”  escolhida quando o cadastramos.

Figura 4.55: Detalhes do monitoramento Web

Na tela seguinte um resumo da última coleta com a velocidade (Speed), latência de rede  (Response   time),   último   código   HTTP   de   resposta   (Response   code)   e   Status   dos   “triggers”  gerados automaticamente. Logo abaixo deste quadro temos dois gráficos de velocidade e tempo  de resposta prontos.

Capítulo 4 Monitoramento voltado para disponibilidade - 168

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

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

Como você pode ver, a criação de um cenário é simples, mas permite uma flexibilidade  muito grande. Vamos em seguida ver como realizar uma validação de um formulário web.

4.5.2. Exercícios  1)  Crie um “action” para os “triggers” que o cenário gerou e faça os seguintes testes:  1.1)  Parar o servidor Apache no host “Application”.  1.2)  Parar o servidor Apache no host “Presentation”.  1.3)  Parar o servidor Varnish no host “Presentation”.  1.4)  Mudar o HTML da página principal para não retornar a string esperada.

Capítulo 4 Monitoramento voltado para disponibilidade - 169

4.6. Checando disponibilidade via agentes As duas “simple checks icmpping” e “ssh” que usamos e o cenário web criado não utilizam  o agente, por isso são denominadas “agentless”. Isso é útil quando o sistema final não permite  que seja instalado o agente por um motivo qualquer e usa apenas protocolos de rede para avaliar   a disponibilidade do objeto final. Porém   essas   checagens   são   muito   limitadas   e   se   não   houver,  ao   menos,   um   agente  SNMP no host de destino não é possível coletar métricas do servidor e determinar o que causou  uma determinada parada. Por isso o Zabbix vem com um agente que pode ser instalado nos hosts   de destino, como fizemos no Capítulo  2. Chegou a hora de utilizar este agente para realizar as  checagens   de   disponibilidade.  Vamos  começar  com   métricas   simples  e   depois  passaremos  a  checar métricas de sistema operacional muito mais ricas.

4.6.1. Checando se o agente esta operacional O primeiro  passo  é verificar se o agente esta funcionando e  escutando  na  sua porta,  normalmente 10050/TCP. Usamos em capítulos anteriores o “zabbix_get” para coletar dados da  “key agent.ping” como um teste. Esta “key” retorna 1 se o agente esta operando, mas considere  que se ele não estiver funcionando não há como ele retornar 0 para alertar uma queda! Por isso essa “key” tem um tratamento especial dentro do Zabbix. Se algum problema de   rede, firewall, daemon, etc não permitir que o agente seja alcançado e o servidor registrar erro ele  irá  gravar um valor nulo na coleta. Este  valor poderá  ser testado num “trigger” com a função  “nodata()” (veja mais a frente) o que requer um tratamento especial para o caso. Vá até a tela de  i”tems” do template “4Linux – S.O. Base” e crie um novo item.  Ao criar o item aqui os templates  “4Linux – S.O. Linux”  e  “4Linux – S.O. Windows”  automaticamente herdarão ele.

Capítulo 4 Monitoramento voltado para disponibilidade - 170

Figura 4.58: Novo item para monitorar o agente

O preenchimento dos campos já é bem trivial a esta altura. A Figura  4.58  mostra quais  são os valores que devem ser colocados em cada um. Como este item é suportado pelo Zapcat  também iremos copiá­lo para o outro template. Salve e siga os passos abaixo.

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

 1)  Selecione o item dentro da lista  2)  Escolha “Copy selected to...” na caixa de ações.  3)  Clique em “Go” (1).

Capítulo 4 Monitoramento voltado para disponibilidade - 171

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

 1)  Target   Type:   esta   parte   um   pouco   confusa,   pois   antigamente   o   Zabbix   não  diferenciava hosts e templates (de fato ele ainda  faz pouca  dissociação  entre  eles  algumas vezes). Você vai escolher “Host”  neste campo para que logo abaixo possa  escolher os templates.  2)  Group: escolha o host group “Templates”.  3)  Target: marque o template do JBoss como indicado. Clique em “Copy” para finalizar a operação. O item agora faz parte de ambos templates.  Confira pelo “Overview” se todos os hosts Gnu/Linux e Window, além do JBoss é claro, estão com  este item funcionando. 

4.6.2. Criando um trigger com a função nodata() Agora   vamos   criar   um   “trigger”   que   opera   com   a   função   “nodata()”   conforme   citação  anterior. O procedimento é muito similar ao do gatilho para o ICMP, exceto pela função usada.  A “nodata()” opera com base em erros de coleta para definir a queda de um agente. Se   algum erro ocorrer ela retorna 1, caso contrário um dado foi recebido e armazenado e ela retorna  0.   Usaremos   este   truque   mais   a   frente   para   “triggers”   que   podem   parar   de   receber   dados   e  apresentar constantemente os indesejáveis estados “UNKNOWN”. Dentro do template “4Linux – S.O. Base” crie um novo “trigger”. Note que o “trigger” herdado do ICMP Base esta aparecendo na sua lista de “triggers”   deste template.

Capítulo 4 Monitoramento voltado para disponibilidade - 172

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

Exceto pelo “Expression”  preencha os campos conforme a Figura  4.61. Depois mude o  método de entrada e clique em “Edit”.

Figura 4.62: Criando um trigger para o agent.ping (2/5)

 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.

Capítulo 4 Monitoramento voltado para disponibilidade - 173

Figura 4.63: Criando um trigger para o agent.ping (3/5)

Adicione a expressão ao “trigger”.

Figura 4.64: Criando um trigger para o agent.ping (4/5)

Agora vamos adicionar uma dependência a este “trigger, ele só deve ser avaliado se o  teste de “ping ICMP” for bem sucedido. Isso evita suas coisas: primeiro que mais de um “action”   seja ativado em caso de um congelamento do host (o que economiza alertas), segundo permite  que o Zabbix não perca tempo com processamento de gatilhos que são desnecessários para a  ocasião (que gastam tempo de CPU no servidor de monitoramento). No nosso cenário se o host  não estiver respondendo à requisição ICMP é inútil testar o agente.  Note que isto pode não ser verdade no cenário de sua empresa! Avaliar a dependência   dos   “triggers”   é   importante   quando   se   está   construindo   uma   solução   eficiente   de   monitoramento. Clique no botão “Add” e selecione o “trigger” do ICMP.

Figura 4.65: Criando um trigger para o agent.ping (5/5)

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

Capítulo 4 Monitoramento voltado para disponibilidade - 174 Perceba que ambas, a dependência e a nova função, aparecem na lista de “triggers”.  Vamos realizar um teste agora, parando o agente do “zabbixsrv”.  # /etc/init.d/zabbix­agent stop Vá até o “Overview”, selecione “triggers”  no campo  “Type”  e aguarde o ativamento do  mesmo.

Figura 4.67: Trigger de agente ativado

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

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

Perceba   como   ambos   os   “triggers”   de   agente   ficaram   cinzas   enquanto   os   de   ICMP  alertaram uma queda.

Capítulo 4 Monitoramento voltado para disponibilidade - 175

Se o seu teste não funcionou pode ser necessário aumentar a janela de tempo em   relação ao “trigger” pai. Nunca deixe a janela do filho exatamente igual ou menor que a   do pai, a folga pode ser pequena mas deve existir.

Não é possível usar a função “nodata()” para verificar a disponibilidade via SNMP.

4.6.3. Exercícios  1)  Copie o “trigger” para o template do “JBoss”.  2)  Crie   as  “actions”  necessárias  para   enviar  os  alertas  de  paradas  dos hosts  a  seus  respectivos responsáveis, conforme a tabela abaixo. Host

Responsáveis

Application

sysadmin, javaeng

Database

sysadmin, dba

JBoss AS

javaeng

Presentation

sysadmin

Switch

sysadmin, winadmin

Windows2003

winadmin

Zabbixsrv

sysadmin

Tabela 9: Responsáveis de cada host

4.7. Tempo on­line e última inicialização do S.O. Vimos anteriormente  que  o  Zabbix  alertou  uma  queda  de  host  quando  nosso  “trigger”  ICMP   estava   realizando   uma   checagem   ruim   sem   janela   de   tempo.   Ao   concertar   este  comportamento deixamos de saber quando um host foi reiniciado. Verificar a reinicialização de  hosts é importante na medição da disponibilidade do mesmo. Este tópico trata justamente desta  questão. Primeiro vamos ao problema prático que temos em mãos: temos que medir o tempo de  “uptime” de todos os hosts incluindo ai os Gnu/Linux, Windows, switch e a máquina virtual java na  qual o JBoss é executado. Isso nos dá três casos de coleta: pelo agente normal, pelo agente  Zapcat e pelo SNMP.

Capítulo 4 Monitoramento voltado para disponibilidade - 176

Isso   vai   demonstrar   como   o   sistema   do   Zabbix   consegue   lidar   com   ambiente  heterogêneos e vai demonstrar que depois da coleta o tratamento, armazenamento e análise não  muda. O primeiro passo é analisar o retorno dos valores via console. Isso é importante para que  tenhamos parâmetros de tipos de dados (inteiros, float); nome correto das “keys”, “OIDs”, etc e  acesso. O agente do Zabbix possui uma “key” chamada “system.uptime”  que retorna o tempo  desde   o   último   boot.   De   maneira   equivalente   o   JBoss   tem   um   “JMX  java.lang:type=Runtime,Uptime” que também faz isso, mas para a inicialização da JVM e o SNMP  por padrão tem o OID “DISMAN­EVENT­MIB::sysUpTimeInstance”. A OID do SNMP é muito variável de um equipamento para outro, sempre consulte o   manual ou a MIB do seu fabricante para determinar o que esta disponível para coleta. Vamos usar os seguintes comandos para os casos de uso. # zabbix_get ­k "system.uptime" ­s application  59545 # echo "jmx[java.lang:type=Runtime][Uptime]" | nc application 10052; echo ZBX59374361 # snmpget ­v2c ­c public 172.27.0.135 DISMAN­EVENT­MIB::sysUpTimeInstance DISMAN­EVENT­MIB::sysUpTimeInstance = Timeticks: (6026194) 16:44:21.94 Se você fez o desafio do tópico  2.12, página  72  pode usar o seu script em vez do   segundo comando. Cada comando retornou um valor inteiro, todos representando o “uptime” do sistema. A  grande diferença entre eles é a precisão de tempo utilizada, o agente do Zabbix retorna o valor em  segundos, o Zapcat em milissegundos e o agente SNMP em centésimos 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 

Capítulo 4 Monitoramento voltado para disponibilidade - 177 configuração de cada item. Primeiro vamos coletar o dado do agente do Zabbix. No template  “4Linux – S.O. Base” crie um novo item conforme a seguir.

Figura 4.69: Item para tempo de uptime

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

Capítulo 4 Monitoramento voltado para disponibilidade - 178

Figura 4.70: Uptime via Zapcat

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

Figura 4.71: Uptime via SNMP

 1)  Type: como este item é obtido pelo SNMP, temos que configurar o item para que o  Zabbix entenda como coletá­lo. No nosso caso estamos usando SNMP versão 2, no  caso   de   outros   equipamentos   a   versão   1   (obsoleta)   ou   3   (mais   segura)   pode   ser  usada. Consulte o manual de seu fabricante. Esta opção requer que o servidor seja  compilado com suporte a “net­snmp” (­­enable­snmp). Note que os campos abaixo se  alteram conforme você escolhe outros tipos de valores.

Capítulo 4 Monitoramento voltado para disponibilidade - 179  2)  SNMP   OID:   coloque   a   “object   identifier”  da   métrica   desejada   conforme   sua  necessidade, no nosso caso é “DISMAN­EVENT­MIB::sysUpTimeInstance”.  3)  SNMP Community: coloque a  “string”  de comunidade do SNMP, normalmente este  valor é “public”.  4)  SNMP Port: A porta UDP em que o agente SNMP esta ouvindo, o padrão é 161.  5)  Key:   invente   uma  “key”  a   seu   gosto,   ela   só   não   pode   conflitar   com   outras  “keys”  criadas ou repetir uma “key” registrada. Para padronizar o curso, todas as chaves de  SNMP são definidas como “snmp.função”. Neste exemplo utilizamos “snmp.uptime”.  6)  Units: repita o usado no item do agente.  7)  Use custom multiplier: como o SNMP, retorna um valor em centésimos de segundos  temos que multiplicá­lo por “.01” para converter para segundos. Salve o item e vá até o “Overview”.

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

A Figura 4.72 mostra todos os hosts, com as métricas de tempo ligado obtidas conforme  sua interface de coleta. Graças ao campo “Unit”  todas estão exibindo o tempo em um formato  legível por humanos e o campo “Use custom multiplier” ajustou os valores para segundos, que  uma unidade com a qual o Zabbix sabe trabalhar.

Novamente, isso demonstrou a capacidade em coletar dados de ambiente heterogêneos,  desde que você tenha um agente suportado não há problemas. O agente padrão do Zabbix é  compatível com 9 sistemas operacionais do mercado, as “JVMs” com “Tomcat” e/ou “JBoss” são  suportadas   pelo   Zapcat   e   a   maioria   esmagadora   de   ativos   de   redes   (desde  “switches”  até 

Capítulo 4 Monitoramento voltado para disponibilidade - 180 impressoras, passando por no­breaks) suportam alguma versão de SNMP hoje em dia.

4.7.1. Trigger para alerta de reinicialização Avaliar se um host foi reinicializado é fácil. Devemos verificar se o “uptime” dele é menor  que um valor pré estabelecido. No entanto, reinicialização de servidores pode não é um incidente  crítico, de fato, normalmente ele é apenas um evento planejado (a menos que você possua uma  hardware com problemas sérios), por isso iremos categorizá­la como um evento de severidade  “warning” (aviso). Não um erro, mas ainda assim digna de uma atenção mais pontual. Vamos criar  a “trigger” para o “4Linux – S.O. Base” primeiro.

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

 1)  Expression:   defina   a   expressão   como   sendo   o   último   valor   da   última   hora   como  sendo  menor do que “1800” (meia hora). Dois pontos importantes aqui: primeiro  o  tempo de janela da função “last()” deve ser sempre maior do que o valor comparado e  segundo, o tempo de ativação deve ser maior do que o tempo de coleta.

 2)  Trigger depends on: coloque como dependência deste “trigger” o da verificação do  agente. Não há sentido em tentar analisar uma métrica que não esta sendo recebida.  Isso evita que ela apresente valores desconhecidos.

Capítulo 4 Monitoramento voltado para disponibilidade - 181

4.7.2. Exercícios  1)  Crie as “triggers” para os templates do JBoss e do SNMP.  2)  Crie as devidas “actions” para alerta de reinicialização enviando mensagens apenas  aos indivíduos responsáveis por cada host (consulte a Tabela  9  na página  175  para  detalhes).

4.8. Checando serviços pelo agente Checar   se   um   determinado   serviço   está   em   funcionamento   através   de   sua   porta   é  funcional, mas algumas vezes precisamos de mais informações do que exatamente ocorreu no  host. Imagine que por exemplo ao invés de queda do “daemon”, um sistema proteção como o  “OSSEC” barrou acidentalmente a porta de destino de hosts legítimos como o  próprio servidor de  monitoramento. Isso não foi uma queda de serviço e outros hosts podem ainda não conseguir se  conectar. Para detectar este tipo de coisa precisamos de mais dados sobre o sistema onde o  serviço esta sendo executado e podemos fazê­lo através do agente do Zabbix.

4.8.1. Verificando os processos ativos na memória O Zabbix tem uma “key” chamada “proc.num” que pode ser usada para verificar o número  de processos na memória. Se usada sem nenhum parâmetro ela faz uma contagem de todos os  processos sem discriminação, para exemplificar o uso dele vamos verificar se o processo do SSH  esta na memória das máquinas Gnu/Linux. A sintaxe da chave é a seguinte (todos os parâmetros são opcionais): proc.num[,,,]  Onde, name:   é   o   nome   do   processo.   Se   você   estiver   checando   processos   numa   máquina  Windows, certifique­se que o processo dele contém a extensão “.exe” (ou similar) no final  do nome. • user: qual  o usuário que esta executando  um determinado  processo ou conjunto de  processos. O padrão é verificar de todos os processos.

Capítulo 4 Monitoramento voltado para disponibilidade - 182 • state: qual o estado do processo. Podendo ser “all” (padrão), “run”, “sleep” ou “zombie”  (este último somente em ambientes “*nix”).  • cmdline: filtra pela linha de comando. Isso é útil para aplicações que sempre iniciam o  mesmo processo, como o java. Em nossa   prática  atual, o   único  parâmetro   relevante   é  o  primeiro,  pois vamos buscar  apenas um processo bem definido dentro da memória (o “daemon” do SSH). Para descobrir qual  o processo usaremos o comando “ps”. Entre no console do servidor do “Zabbixsrv”. # ps uax | grep ssh ­i root      1161  0.0  0.3   5496   988 ?        Ss   14:09   0:00 /usr/sbin/sshd root      3594  0.2  1.1   8304  2868 ?        Ss   14:40   0:00 sshd: root@pts/0  root      3674  0.0  0.3   3316   836 pts/0    S+   14:41   0:00 grep ­­color ssh O   primeiro   processo   é   o   “daemon”,   o   segundo   é   uma   conexão   ssh   acontecendo   e   o  terceiro é o próprio “grep” na memória que usamos na linha de comando e portanto pode ser  ignorado. Note que o nome do processo é “sshd” e não simplesmente ssh. Com isso em mãos,  podemos ser mais pontuais com o “ps”, a opção “­C” pouco conhecida e usada, lista apenas os  processos com o nome indicado. Ela é incompatível com as opções “a” e “x”, por isso à usaremos  em combinação com a “u”, apenas. # ps u ­C sshd USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root      1161  0.0  0.2   5496   624 ?        Ss   14:09   0:00 /usr/sbin/sshd root      3594  0.0  0.8   8304  2204 ?        Ss   14:40   0:00 sshd: root@pts/0 Guarde esta opção do “ps”, você vai precisar dela no futuro. Vamos usar o “zabbix_get” para coletar a informação da chave agora.

# zabbix_get ­s localhost ­k "proc.num[sshd]" 2 ←  A chave retornou “2”, que é exatamente o número de processos que contamos com o ps.  Com o teste concluído vamos à criação do “item” e “trigger”. Use o template “4Linux – S.O. Linux”.

Capítulo 4 Monitoramento voltado para disponibilidade - 183

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

A Figura 4.74 ilustra como o item para contagem de processo deve ser criado, ele é bem  trivial. 

Figura 4.75: Overview refletindo o número de processos

No “Overview”, já podemos rastrear o funcionamento da contagem de processos. Note 

Capítulo 4 Monitoramento voltado para disponibilidade - 184 que o número de processos do host “Zabbix Server”  esta com 2 porque há uma conexão ssh  ocorrendo nele, nos outros apenas o “daemon”, aguardando a conexão, está sendo executado. Com os dados sendo coletado já podemos criar um “trigger”. 

Figura 4.76: Trigger para queda do daemon

 1)  A condição do “trigger” é bem padrão em relação aos nossos gatilhos anteriores: use  a função “sum()” para descobrir se algum processo esta rodando na janela de tempo  de 1 minuto.

 2)  Ele deve depender da checagem de agente porque não há sentido em testar uma  métrica que depende dela mesmo. Além disso se não o fizermos esta “trigger” vai  resultar em um “unknown” se o agente cair.  3)  A severidade deste incidente vai ser classificada como “Average” pois o SSH não é um  serviço   prioritário   para   o   funcionamento   das   aplicações,   no   entanto   ele   não   é   um  “Warning”, pois ainda é classificado como erro e precisa de intervenção imediata. Salve o “trigger” e vá até o console do host “Database” e para o SSH. # /etc/init.d/ssh stop Acesse  a  lista  de   eventos em  Monitoring  →  Events  para  acompanhar  a  ativação   do 

Capítulo 4 Monitoramento voltado para disponibilidade - 185 “trigger”.

Figura 4.77: Teste de queda do sshd

Também olhe no “Overview” como o “trigger” ficou exibido.

Figura 4.78: Reflexo da queda do daemon SSH no overview

Note que o teste de porta também falhou, mas não emitiu alerta pois ainda não temos  “triggers” associados a ele. # /etc/init.d/ssh start

4.8.2. Checagem de portas e serviços localmente via agente Além do teste feito pelo servidor na porta “22/TCP”, também podemos pedir ao agente  para   realizar   o   mesmo   teste.   Este   tipo   de   teste   de   agente   é   útil   para   criarmos   lógicas   mais  inteligentes de análise do cenário.  A key “net.tcp.service[ssh]” tem o mesmo efeito e comportamento que a ssh. Sua solene  diferença é que ela é do tipo “zabbix agent”  em vez de “simple check”. Crie o item conforme a  Figura a seguir.

Capítulo 4 Monitoramento voltado para disponibilidade - 186

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

Após a criação do item, verifique se a coleta esta sendo realizada. Se tudo estiver correto,   é hora de passar para a verificação das mudanças de status. Até o momento temos 3 maneiras de  checar o serviço: contando os processos ativos na máquina, checando a porta remotamente pelo  servidor do Zabbix e/ou checando a porta localmente pelo agente do Zabbix. Todas   tem   suas   vantagens   e   desvantagens,   mas   em   vez   de   usá­las   de   forma  discriminada, vamos juntar a força de todas elas e fazer com que a lógica de todos os gatilhos  trabalhem em conjunto. Essa capacidade de oferecer dependência entre uma checagem e outra  que o Zabbix oferece é de extremo poder, e mesmo sem expressões booleanas complexas dentro  de cada “trigger” seremos capazes de determinar qual o possível acontecimento, dependendo de  qual “trigger” foi ativado. Acompanhe a explicação a seguir, começando pela leitura do fluxograma  na Figura 4.80.

Capítulo 4 Monitoramento voltado para disponibilidade - 187

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

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

O segundo,  é a análise  da porta localmente  a  partir do agente, se  não há  processos  escutando na porta a partir da própria máquina local então o processo “master” da aplicação  provavelmente caiu. Note que se você parar o ssh pelo serviço de boot as conexões que estão em  andamento não são interrompidas! Logo é possível ter uma situação onde há processos “sshd” na  memória   que   estão   apenas   atendendo   a   conexões   que   foram   estabelecidas   anteriormente   à  queda do processo principal e só vão morrer se estas conexões forem encerradas. 

Capítulo 4 Monitoramento voltado para disponibilidade - 188 Esse tipo de comportamento é muito comum em serviços que são baseados em “forks”,  como   o   Apache,   o   próprio   Zabbix,   muitos   “daemons”   escritos   em   Perl,   etc.  Programas   que  trabalham puramente com “threads”, como as aplicações feitas em java, incluindo aqui o Tomcat e  o JBoss tem um processo monolítico e não seguem esta regra. Finalmente,  o   terceiro   “trigger”   checa   se   servidor  consegue   abrir uma   conexão   com  a  porta remotamente. No caso de um bloqueio por filtro de pacotes no host de destino ou no meio  do caminho, ou falhas de rotas, este gatilho é ativado. Este caso cobre a ocorrência do “daemon”  estar em perfeito funcionamento mas os pacotes de rede não estarem alcançando o destino (ou  não estão voltando apropriadamente). Como o terceiro só é checado se o segundo estiver com status OK, e este último se o  primeiro estiver com status OK, o Zabbix não gasta processamento com os três gatilhos, a menos  que tudo esteja na mais perfeita ordem. Se um dos primários falharem então os outros não serão  executados. Obviamente pode haver muito mais tipos de problemas, que vão além da contagem de   processos   e   verificação   de   portas.   Um   binário   corrompido   pode   causar   quedas   de   conexões legítimas alguns segundos depois de serem estabelecidas pelo serviço, ou   ainda ele pode sempre retornar um erro na cara do cliente sem sair completamente do   ar. Para estes casos continue empilhando outras checagens após verificar estas três   que geralmente estão sempre perto da base. Mas vamos continuar com nossa prática dirigida e criar os dois “triggers” que faltam, pois  o primeiro já esta pronto desde o tópico anterior. 

Capítulo 4 Monitoramento voltado para disponibilidade - 189

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

O “trigger” da Figura  4.81  é a segunda checagem (porta local). Note que ele tem como  dependência o “trigger” da contagem de processos.

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

Capítulo 4 Monitoramento voltado para disponibilidade - 190 Já o da Figura  4.82  faz a verificação da porta remotamente e tem como dependência o  segundo gatilho. Outro ponto importante é que sua janela de tempo é de 70 segundos (10 a mais  que o anterior), esta folga evita que ambos sejam ativados simultaneamente.  Deixar uma margem entre 10 e 5 segundos na janela de um “trigger” que depende de   outro é uma boa prática.

Como foi dito anteriormente, não há como verificar de maneira confiável se uma porta   UDP está aberta. Mas o agente tem uma chave chamada “net.udp.listen” que verifica   se localmente uma dada porta UDP esta esperando requisições.

4.8.3. Exercícios  1)  Agora teste os gatilhos realizando as seguintes tarefas:  1.1)  Pare   o   “daemon”   ssh   de   um   Gnu/Linux   sem   conexões   abertas   para   ele  (somente o primeiro gatilho deve disparar). Restaure o “daemon”.  1.2)  Pare o “daemon” ssh de um Gnu/Linux com ao menos uma conexão aberta  (somente o segundo gatilho deve disparar). Restaure o “daemon”.  1.3)  Corte a regra  de SSH dos filtro de pacotes (iptables) de um dos Gnu/Linux,  somente o terceiro gatilho deve disparar. Restaure a regra após o termino.

4.8.4. Verificando serviços no Windows Assim  como  o   Gnu/Linux,  o  Windows  tem  seu   sistema  de   gerenciamento   do   serviços  ativos na memória. Usamos ele no tópico 2.7.1. , página 50 para executar o serviço do agente do  Zabbix. Acesse o Painel de Controles → Ferramentas Administrativas → Serviços. Na tela que lista os serviços, localize o serviço de “Telnet”. Ele deve estar desativado.

Figura 4.83: Serviço telnet do Windows

Vamos usá­lo como exemplo para monitoramento de serviços no Windows. O “Telnet” é  simples de se colocar em funcionamento, de fato quase nada é configurado. Clique duas vezes  sobre o nome dele.

Capítulo 4 Monitoramento voltado para disponibilidade - 191

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

 1)  Nome do serviço: anote o nome do serviço! O Zabbix precisa dele para conseguir  localizá­lo no sistema. No nosso caso é “TlntSvr”.  2)  Tipo de inicialização: mude para “automático”. Depois de terminar clique em “OK”, o serviço vai entrar registrado mas ainda não iniciado.

Figura 4.85: Ativando o serviço de telnet

Para iniciar use a barra de ferramentas no topo da tela como indicado na Figura   4.85.  Agora pressione CTRL+ALT+DEL, e abra o Gerenciador de tarefas.

Capítulo 4 Monitoramento voltado para disponibilidade - 192

Figura 4.86: Processo do telnet na memória

Confira se um dos processos bate com o nome do serviço. Provavelmente você achará o  processo “tlntsvr.exe”. Anote também este nome. Antes   de   cadastrar   novos   “items”   vamos   fazer   um   pequeno   teste   via   console:   use   o  “zabbix_get” para coletar o número de processos “telnet” na memória (deve retornar 1).  Novamente lembramos que no Windows, deve­se incluir a extensão “.exe” no final dos   processos para a “key” “proc.num”. # zabbix_get ­s win2003 ­k 'proc.num[tlntsvr.exe]' 1 Agora vamos testar a key “service_state” que faz a verificação dos serviços do Windows  no Zabbix. Use o nome que pegamos das configurações do “Telnet” como parâmetro dela. # zabbix_get ­s win2003 ­k 'service_state[TlntSvr]' 0

Capítulo 4 Monitoramento voltado para disponibilidade - 193

Note que o resultado foi zero. Isso porque zero significa rodando, experimente pausar o   serviço no Windows e execute o comando novamente. # zabbix_get ­s win2003 ­k 'service_state[TlntSvr]' 1  Agora retornou 1. Sim, parece contra produtivo, mas esta tabela foi baseada em números  que a própria API do sistema Windows retorna. Os valores possíveis estão na Tabela abaixo. Valor

Estado

0

Rodando

1

Pausado

2

Início requisitado

3

Pausa requisitada

4

Continuação requisitada

5

Parada requisitada

6

Parado

7

Desconhecido

255

Serviço não existe (não esta cadastrado na lista de serviços do Windows)

Table 10: Valores da key service_state Mas  isso   ainda   não   é  suficiente.  Temos que   pedir  ao   Windows  que   libere   a  porta   do  Firewall para o acesso ao Telnet. Por padrão todos os “telnets” usam a porta “23/TCP”. Acesse  Painel de Controles → Firewall para abrir as preferências.

Capítulo 4 Monitoramento voltado para disponibilidade - 194

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

Clique   em   “Adicionar   Porta...”  e   preencha   a   janela   que   aparecer  conforme   indicado   a  seguir.

Figura 4.88: Liberando o telnet no firewall do Windows (2/3)

Capítulo 4 Monitoramento voltado para disponibilidade - 195

 1)  Nome: o nome do serviço é apenas um “label” para o Firewall. Defina como “telnet”.  2)  Número da porta: coloque 23.  3)  O protocolo usado é o “TCP”. Clique em OK para finalizar.

Figura 4.89: Liberando o telnet no firewall do Windows (3/3)

Por fim, clique em “OK” novamente. Para averiguar se tudo esta correto faça um teste a  partir do console do host “Zabbix server”.

Capítulo 4 Monitoramento voltado para disponibilidade - 196

# nmap ­P0 ­p 23 win2003

Starting Nmap 5.00 ( http://nmap.org ) at 2011­02­15 18:39 BRST Interesting ports on 172.28.0.10: PORT   STATE SERVICE 23/tcp open  telnet Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds # telnet win2003 Trying 172.28.0.10... Connected to win2003.curso468.4linux.com.br. Escape character is '^]'. Welcome to Microsoft Telnet Service  login: administrador password:  *=============================================================== Bem­vindo ao Microsoft Telnet Server. *===============================================================

C:\Documents and Settings\Administrador>exit Se o teste correu bem, vá até o template “4Linux – S.O. Windows 2003” e crie um novo  “item” conforme abaixo.

Capítulo 4 Monitoramento voltado para disponibilidade - 197

Figura 4.90: item para monitorar serviços Windows

Nenhuma   grande   novidade   aqui,   apenas   atente   para   a   key   e   para   o   campo   “New   application”. Outro ponto importante é o uso do “Value map Windows service state”. 

Figura 4.91: Estado do serviço Telnet no Overview

Capítulo 4 Monitoramento voltado para disponibilidade - 198

Verifique que no “Overview” o serviço esta aparecendo e funcionando.

4.8.5. Restabelecendo serviços offline via Zabbix Um aviso de cautela logo no início. Permitir que o agente execute comandos remotos   no host monitorado pode causar falhas de segurança se não houver cuidado triplicado.   Somente use este recurso se você realmente precisar e tiver absoluta certeza do que   esta fazendo. Um   recurso   poderoso   é   a   capacidade   do   agente   do   Zabbix   de   executar   comandos  remotos a pedido do servidor. Isso possibilita que sejamos capazes de restaurar um serviço que  caiu, ou reiniciar um que está com problemas no atendimento de requisições. Obviamente   o   agente   por   padrão   não   executa   nada,   tampouco   é   capaz   de   executar  comandos administrativos arbitrariamente. Isso se deve a dois fatos: os “defaults” dos arquivos de  configuração e a execução do daemon do Zabbix como usuário não privilegiado. Nossa primeira prioridade é justamente liberar o agente para executar os comandos. O  arquivo   “/etc/zabbix/agent.d/remote_command.conf”   contém   as   configurações   para   tal  procedimento. Eleja uma das máquinas virtuais Gnu/Linux e comece a realizar os procedimentos  a seguir. # vim /etc/zabbix/agent.d/remote_commands.conf  1

# Este é o arquivo de configuração do agente do Zabbix para comandos 

2

# remotos.

3 4

# 

======================================================================== 5

# Liga/Desliga o recurso de comandos remotos do agente.

6

#

7

# Este tipo de feature vem desligada por padrão devido ao risco de segurança

8

# que ela pode apresentar se mal configurada.

9

#

10

# Note que o usuário do Zabbix tem que ter direitos de execução do comando em

Capítulo 4 Monitoramento voltado para disponibilidade - 199 11

# questão enviado pelo servidor. Para isso ou ele é executado como root 

12

# (desaconselhável) ou chama executáveis com suid (desaconselhável) ou utiliza

13

# sudo para rodar os comandos. Este último é a opção mais segura das três, mas

14

# requer configurações extras no arquivo sudoers.

15

#

16

EnableRemoteCommands=1

17 18

# 

======================================================================== 19

# No caso de habilitada a execução de comandos remotos, é aconselhável deixar

20

# esta opção ativada para auditoria do sistema. Ela vai registrar no arquivo 

21

# de logs do agente quando e qual comando foi executado (ou no mínimo foi 

22

# tentado).

23

#

24

LogRemoteCommands=1

# /etc/init.d/zabbix­agent restart é   preciso   mudar  para   1   ambos   “EnableRemoteCommands”  e  “LogRemoteCommands”.  Seus nomes são bem subjetivos, e apesar de não haver necessidade de ativar o segundo para  que a coisa toda funcione é extremamente aconselhável fazê­lo. Já   estamos   ampliando   bastante   a   confiança   do   agente   no   servidor,   vamos   ser  cautelosos e ao menos colocar as tentativas de execução de comandos nos logs para  auditoria. É recomendável que você desabilite o arquivo de log também e faça o agente gravar no  syslog, dessa forma ele não terá direito de escrita nos arquivos usados para armazenar  suas mensagens. Agora   a   segunda   parte:   como   usuário   “zabbix”,   o   agente   não   será   capaz   de   iniciar  nenhum   serviço   do   Gnu/Linux,   somente   o   “root”   pode   fazê­lo.   Então   vamos   apelar  ao   “sudo”  novamente para execução do comando (instale o “sudo” se necessário). Configure   o   sudo   para   permitir   que   o   agente   execute   sem   senha   o  “script”  de  reinicialização do ssh.

Capítulo 4 Monitoramento voltado para disponibilidade - 200

# visudo … zabbix ALL = NOPASSWD: /usr/init.d/ssh restart

Seja metódico e defina exatamente quais são os parâmetros permitidos dentro do sudo,   principalmente para “scripts” de sistema. Não queremos ninguém dando “stop” no ssh   pelo Zabbix, acidentalmente ou não! Crie uma “action” para conter o comando remoto.

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

As   configurações   padrões   são   bem   apropriadas,   apenas   acrescente   o   adendo   na  mensagem que o serviços esta sendo reiniciado manualmente.

Figura 4.93: Action para parada do SSH (2/3)

Nas condições, é importante notar que há três delas. Uma indica que o status do “trigger”  deve ser “PROBLEM”. 

Capítulo 4 Monitoramento voltado para disponibilidade - 201

Você não quer que o serviço seja reiniciado quando o gatilho voltar a OK, certo? As outras duas possibilidades são o “trigger” de processo ou de checagem local de portas  serem ativados. Qualquer um deles que apresentar “PROBLEM” dispara esta ação.

Figura 4.94: Action para parada do SSH (3/3)

Uma   mensagem   para   os   envolvidos   com   esse   host   deve   ser   enviada.   E   por   fim   o  comando remoto, ativado a partir do quadro “Action operations”.

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

 1)  Operation   type:   escolha  “Remote   command”  ao   invés   do   valor   para   envio   de  mensagens. Note que o campo abaixo vai mudar.  2)  Remote command: você precisa colocar o comando com a sintaxe “Host:command”,  onde host é o local onde o comando será executado (onde você habilitou o comando  remoto   no   agente)   e   “command”   é   o   comando   propriamente   dito.   No   nosso   caso  usaremos “Database:sudo /etc/init.d/ssh restart”. Você pode usar macros nos comandos e pode invocar quantos comandos você quiser,   em quaisquer servidores, em qualquer sequência. Agora   vamos   ao   teste:   vá   até   o   host   no   qual   você   configurou   o   agente   para   aceitar  comandos remotos e pare o serviço de SSH, em seguida abra o log e aguarde.

Capítulo 4 Monitoramento voltado para disponibilidade - 202 # /etc/init.d/ssh stop # tail /var/log/zabbix/zabbix_agentd.log ­f …   7287:20110215:192625.462 Executing command 'sudo /etc/init.d/ssh restart' Starting OpenBSD Secure Shell server: sshd. Se você voltar à tela de eventos verá que há dois deles, um de queda e outro de volta. 

4.8.6. Exercícios  1)  Crie o mesmo esquema de monitoramento feito para o SSH para o Apache dentro do  “application”.   Gere   um   template   a   parte   para   o   Apache   para   conter   os   “items”   e  configurações. Também crie uma “action” capaz de reiniciar o serviço se for detectado  que nenhum “daemon” do apache esta rodando.  2)  Crie um “trigger” para avaliar se um serviço do Windows não esta rodando e uma  “action”   para   alertar   o   administrador  Windows.  No   corpo   da   mensagem   coloque   o  estado em que o estado se encontrava no momento do alerta. Use a mesma tática de  checagem de portas e múltiplos gatilhos.

4.9. Medindo a “saúde” de sua rede Até   o   momento   nossos   esforços   foram   dirigidos   a   checagem   de   dados   que   indicam  apenas se um dado host (ou serviço) está operacional ou não. Vamos começar a abordar outros  tópicos,   que   embora,   indiretamente   relacionados   com   os   serviços   podem   afetar   seu  funcionamento. Este tópico aborda a parte de “networking” e mostra como monitorar o quão saudável sua  rede está.

4.9.1. Latência de rede O primeiro ponto que vamos analisar são as causas de indisponibilidade por excesso de  trafego na rede. Note que medir a banda pode ajudar a identificar gargalos de rede, mas a métrica  mais indicada para medir lentidão é a latência de rede, que pode estar baixa mesmo quando não  há trafego! Como sempre vamos começar com a criação do item dentro do template “4Linux –   ICMP”.

Capítulo 4 Monitoramento voltado para disponibilidade - 203

A chave “icmppingsec” também faz um “ping” como a “icmpping”, mas diferente desta ela  retorna o número de segundos que o pacote levou para ir e voltar (na verdade a média de três  pacotes). 

Figura 4.96: Item para latência de rede

Neste   item,   atente   para   o   campo   “Units”  que   contém   o   valor  “s”  (segundos).   Ele   irá  formatar o valor recebido pelo item para uma forma legível por seres humanos. E mais importante,  desta   vez  “Type   of   Information”  esta   como  “Numeric   (float)”,   porque   o   retorno   da   key  “icmppingsec” é em segundos, mas normalmente os tempos de respostas são quebrados em três  casas decimais (milissegundos).

Capítulo 4 Monitoramento voltado para disponibilidade - 204

4.9.2. Macro para o limiar da latência de rede Um ponto muito importante é definir o que é uma latência ruim. Isso é muito variável de  um ambiente para outro, se você estiver medindo a latência em uma rede local então, é provável  que   uma   latência   acima   de   10   milissegundos   seja   alta.   No   caso   de   medir   a   latência   de   um  equipamento com link via satélite, podemos encontrar latências de alguns segundos como padrão  dependendo da tecnologia. Para   deixar   nossos   templates   flexíveis   o   suficiente   para   se   adequarem   a   quaisquer  ambientes   podemos   usar   um   recurso   muito   interessante   do   Zabbix   chamado   “macros   de   usuários”. Existem três tipos de escopo de macro: global (definido em Administration  →  General)  que vale para todos os templates e hosts; macros de templates, cujo alcance vale para todos os   hosts associados a um dado template e macros de host, que vale só para aquele host. Se você  redefinir (como vamos fazer) uma macro num ambiente mais restrito, o que irá valer será este  último. O Zabbix tem várias macros internas e já tivemos contato com algumas quando criamos  nossos “triggers”. {HOSTNAME}, que é a mais comum, armazena o nome do host definido dentro  do “front end”. Quando definirmos uma macro de usuário é importante que em sua sintaxe um  sinal de cifrão ($) seja colocado antes do nome e dentro das chaves. Por exemplo, vamos definir uma macro para latência de rede com o nome “LATENCIA”,  logo sua sintaxe será “{$LATENCIA}”. Evite o uso de outros caracteres no nome da macro exceto  por “underline”  (_).  Também  não  comece  o nome da  macro  por números.  É  uma  boa  prática  manter os nomes em caixa alta. No   caso   de   nosso   cenário   iremos   definir   um   padrão   de  “0.01”  segundos   (10  milissegundos) para nossa macro, ela vai ser uma macro de template, mais especificamente o  template  “4Linux   –   ICMP”.   Abra   as   configurações   do   mesmo   clicando   no   nome   dele   em  Configuration  →  Templates.   No   canto   direito   do   quadro   principal   você   vai   achar   a   área   de  definição de macros.

Capítulo 4 Monitoramento voltado para disponibilidade - 205

Figura 4.97: Macro para latência de rede

Acrescente os valores conforme a Figura  4.97  e salve o template. Ela já estará valendo  para todos os hosts associados a ele. Vamos agora usá­la no gatilho para verificação de latência  alta de rede. Crie o “trigger” no template conforme a seguir.

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

A grande diferença deste template para os anteriores é o uso da macro. Preste atenção  no   campo  Expression,   seu   valor   indica   a   fórmula     “{HOST:ITEM.avg(60)}>{$LATENCIA}”.  Podemos inserir quantas macros quisermos na expressão do gatilho. A   partir   de   agora   se   reutilizarmos   estes   templates   em   outros   ambientes,   podemos  adequar a latência de rede globalmente alterando o valor da macro no template. No caso de um  dos hosts em nosso sistema ter um limiar diferente de latência, podemos ainda redefinir a macro  dentro do próprio host, alterando assim o comportamento de seu “trigger” pontualmente.

4.9.3. Nosso primeiro gráfico Vamos agora criar um gráfico que irá usar este “trigger” para exibir o limiar de teste na  tela. O resultado será similar ao da Figura 4.99. 

Capítulo 4 Monitoramento voltado para disponibilidade - 206

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

Vá até a tela de criação de gráficos e clique em “Create Graph”. Siga as instrução abaixo  para construir um gráfico como demonstrado acima.

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

 1)  Name: nome do gráfico. A partir da versão 1.8.4 do Zabbix é possível usar macros  aqui.  2)  Width e Height: tamanho padrão do gráfico para algumas telas. Na maioria dos casos  o “front end” ajusta o gráfico ao tamanho corrente da tela do Browser.

Capítulo 4 Monitoramento voltado para disponibilidade - 207

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

Figura 4.101: Adicionando métricas ao gráfico

 1)  Parameter: qual key cadastrada no template este elemento representará.  2)  Type: se  este item  é  “Simple”  ou  “Agregated”. Campos  agregados  agrupam várias  contagem em um  único valor. São úteis para  visualização de variação  com menor  granularidade num dado espaço de tempo. Por exemplo, se você quiser apenas a  média, de hora em hora, ao invés de usar o intervalo de coleta.  3)  Function: qual valor deve ser mostrado se houver a existência de mais de um valor  por pixel no eixo “x”. As funções são “avg” (média, o mais comum), “max” (máximo),  “min”  (mínimo) ou “all”  (todos os três). Em variações muito baixas, “all”    pode não  exibir nada significante.

Capítulo 4 Monitoramento voltado para disponibilidade - 208

 4)  Draw style: Como a linha será desenhada. Os valores possíveis são: “Line”  (linha  simples),   “Filled   region”  (área   preenchida),   “Bold   line”  (linha   mais   espessa),   “Dot”  (pontos),   “Dashed   line”  (tracejado)   e   “Gradient”  (área   com   gradiente   da   cor  gradativamente indo para transparente). Este gráfico usa “alpha blender”.   5)  Colour: obviamente a cor.  6)  Y axis side: Se os valores deste item serão exibidos do lado esquerdo ou direito do  gráfico.  7)  Sort order: um número indicando a ordem de desenho no gráfico, vai de 0 a 100.  Você pode ordenar os elementos dos gráficos como desejar na tela de construção do  gráfico depois de acrescentar todos eles.  Clique   em  “Save”  em   ambas   as   telas   e   o   gráfico   estará   pronto   para   exibição   em  Monitoring → Graphs.  O botão de “Preview” que existe na tela de construção dos gráficos não será capaz de  exibir   os   gráficos   se   você   estiver   acrescentando   ele   a   um   template   como   estamos  fazendo. Ele só funciona no caso de um gráfico ser criado direto em um host.

4.9.4. Personalizando o mapa para exibição de informações O   mapa   do   Zabbix   é   extremamente   personalizável,   e   permite   que   visualizemos  praticamente qualquer valor que coletamos e processamos, desde “items” até “triggers”. Vamos  aproveitar que coletamos várias métricas importantes e associá­las ao mapa. O resultado final  deve ficar como na Figura .

Capítulo 4 Monitoramento voltado para disponibilidade - 209

Figura 4.102: Mapa com labels personalizadas exibindo dados

Para definir estes valores é bastante simples: edite a o item de host clicando sobre ele e  preencha, linha a linha, os valores do campo “Label”. No exemplo que vimos, vários hosts exibem  o   “Uptime”   obtido   de   “{Host:system.uptime.last(0)}”  e   de   latência   de   rede,   obtido   de  “{Host:icmppingsec.avg(60)}”. Atenção especial ao segundo, pois usamos a função “avg” e não  “last”, isso é totalmente permitido. Na Figura 4.103 temos um exemplo com o host “Presentation”. Após editar o valor clique  em “Apply”. 

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

Capítulo 4 Monitoramento voltado para disponibilidade - 210

Não esqueça de salvar o mapa constantemente no botão “Save”.

4.9.5. Exercícios  1)  Assim como o “icmppingsec”  esta para o “icmpping”, várias keys com sufixo “_perf”  estão   para   os   equivalentes   das   “simple   checks”   de   portas   TCP.   Por   exemplo,  “ssh_perf” é a medição de latência para o servidor de conexões remotas segura. Crie  os “items” e gráficos (veja o exemplo abaixo) para os outros serviços que você já criou  anteriormente de disponibilidade. Cadastre macros para medir o limiar e finalize com  os “triggers” dos mesmos. Em sala de aula, crie pelo menos um deles, os outros podem ser feitos em casa.

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

4.10. Espaço disponível em disco A latência de rede pode medir o nível de resposta final das aplicações disponibilizadas via  TCP. Mas um item extremamente crítico, pois pode causar paradas de serviços abruptamente, é o  espaço disponível em disco. 

Capítulo 4 Monitoramento voltado para disponibilidade - 211

Vários   daemons   simplesmente   saem   de   funcionamento   porque   não   são   capazes   de  escrever em partições de logs, e bancos de dados e pastas de usuários sempre podem exceder  as estimativas previstas. Por isso é importante que verifiquemos ambas as partições de sistema e  de dados dentro de um servidor. Como exemplo iremos criar uma verificação da raiz nos Gnu/Linux. Depois estenderemos  o   mesmo   princípio   ao   Windows.   Outro   ponto   é   que   nos   servidores   sempre   existem   várias  partições (ao menos nos bem instalados), e por isso temos que ter múltiplos “items” para cobrir  todos os casos e deixar margem, através de macros, para partições com nomes personalizados  pelo administrador. Por fim, desta vez teremos que coletar várias métricas (ao menos três) para criação dos  gráficos e “triggers”. Espaço total, usado e livre.  Existem   outras   métricas   como   porcentagem   utilizada   e   livre   do   disco   (“pfree”   e   “pused”), além de “items” baseados em “inodes”. Consulte o manual do Zabbix para   mais detalhes. Antes de começar a criar “items” vamos definir um valor limite para nossos “triggers” como  fizemos   na   latência   de   rede.   A   utilização   dos   espaços   em   disco   pode   variar   muito   entre   os  servidores.  Todas   as  nossas  ações  serão   dentro   do   template   “4Linux   –   S.O.   Linux”.   Comece  criando a macro conforme abaixo.

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

O valor padrão usado para nosso cenário será “80” (80% da partição cheia), todo servidor  que exceder este limite deverá disparar um alerta para os administradores. Vamos criar os item agora, a key “vfs.fs.size[mount_point, mode]”, diferente das anteriores  exige parâmetros para funcionar. O primeiro é obrigatório e indica qual das partições devem ser  analisada. O segundo é opcional e diz qual parâmetro deve ser coletado. Os valores possíveis  são: “total” (bytes totais da partição. É o tipo padrão), “used” (bytes utilizados), “free” (bytes livres), 

Capítulo 4 Monitoramento voltado para disponibilidade - 212 “pused”  (porcentagem   utilizada)   e   “pfree”  (porcentagem   livre).   Vamos   usar   apenas   os   três  primeiros, começando pelo total, conforme a seguir. O agente não verifica se o diretório colocado no parâmetro é a raiz de um ponto de  montagem. No caso de não ser, ele continuará obtendo o valor do espaço da partição  como um todo (pense nele como um “df” ao invés de um comando “du”.

Figura 4.106: Primeiro item de espaço em disco

 1)  Description: aqui temos uma novidade: uma vez que estamos usando parâmetros na  key, podemos capturá­los e inseri­los no “description” usando a notificação “$n”, onde  “n” é o número do parâmetro começando por 1. Em nosso exemplo usaremos “$1”  para pegar o ponto de montagem da partição. Isso alivia bastante a digitação, pois os  outros “items” que iremos clonar não precisam ter “descriptions” muito diferentes.  2)  Key: a chave de espaço conforme explicado anteriormente. Para o total sua sintaxe  final é “vfs.fs.size[/,total]”.  3)  Units: “b” representa valores em “bytes”. O Zabbix é inteligente o suficiente para fazer  as conversões para “kilo”, “mega”, “giga”, “tera”, etc. Usando múltiplos de 1024.

Capítulo 4 Monitoramento voltado para disponibilidade - 213

Salve o item e ao invés de criar o próximo item “no braço”, vamos usar um recurso de  clonagem de valores do Zabbix. Várias telas permitem que usemos o recurso de clonagem. Neste  caso vamos clonar o total para usado e livre, conforme o esquema na Figura 4.107.

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

Edite o item de “Espaço total” e clique no botão “Clone”. 

Figura 4.108: Botão para clonar items

Você   verá   que   os  dados  se   repetirão.  Altere   apenas  a  key  (que   deve   ser  única)   e   o  “description”. Repita para o outro item e você terá outras duas métricas prontas e coletando em  tempo   recorde!   Confira   no   “Overview”   se   os   dados   estão   sendo   coletados   adequadamente  (atentando para que eles estejam em notação abreviada, Mb, Gb, etc).

4.10.1. Gráficos para espaço em disco Vamos criar dois gráficos para visualização de espaço em disco: o primeiro é um gráfico  de pizza (também chamados de torta, mas o nome oficial é gráfico circular) para mostrar o atual  volume de uso do disco. Apesar de parecer inútil, este tipo de gráfico tem uma vantagem grande  sobre   o   de   linha:   ele   exibe   de   maneira   visual   o   estado   atual   com   proporções   facilmente  reconhecíveis por olhos humanos. Veja a Figura 4.109, que ilustra o gráfico que vamos criar daqui  a pouco, facilmente conseguimos ver que esta partição esta com mais de 50% ocupada somente  olhando para o gráfico. Novamente,   como   usamos   o   campo   “Unit”  igual   a  “b”,   os   valores   já   aparecerão  convertidos e abreviados para facilitar leitura humana.

Capítulo 4 Monitoramento voltado para disponibilidade - 214

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

Para gerar um gráfico como esse siga os passos a seguir.

Figura 4.110: Criando um gráfico de pizza

Não há muitos segredos nesta tela, ao selecionar “Pie” em “Graph Type” menos campos  irão   aparecer  no   formulário.  Vamos  deixar  a   legenda   ativa.  Pode­se   fazer  gráficos  em   3D   se  desejado,   mas   não   há   grandes   vantagens   neles   em   relação   aos   normais   em   termos   de  visualização, é apenas estética. Note que vamos utilizar dois “items” ao mesmo tempo: espaço utilizado e livre.  Foi   usado   vermelho   para   o   espaço   utilizado   por  um  bom   motivo,  as  cores  quentes  tendem a atrair o olho humano quando em contraste com cores frias ou mais claras.  Isso   faz   com   que   inconscientemente   o   administrador   ou   suporte,   fixe   no   espaço  utilizado o que é o crítico neste caso.

Capítulo 4 Monitoramento voltado para disponibilidade - 215 Enquanto   o   gráfico   circular   é   indicado   para   mostrar   o   último   status   de   vários   “items”  relacionados, proporcionalmente ele oculta o histórico do espaço ocupado. Por isso precisamos  criar, também, um gráfico simples. O procedimento é similar ao anterior e resultará no gráfico da  Figura 4.111. Seu diferencial é que vamos usar um limite superior ao invés de um limite calculado. Para  indicar o topo do gráfico vamos apontar para o espaço total da partição obtido através de um item.

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

Crie um gráfico como antes, mas atente para o detalhes em destaque abaixo.

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

Capítulo 4 Monitoramento voltado para disponibilidade - 216

Após   acrescentar  o   item  de   espaço   utilizado,  no   campo   “Y   axis  MAX  value”  escolha  “Item” e selecione o item de espaço total. Isso vai limitar o topo do gráfico e dar uma visualização  mais precisa do espaço que está sendo utilizado em relação ao total. Se você não o fizer e tiver  por exemplo pouco espaço usado o gráfico ficará ajustado ao tamanho máximo atingido o que  pode levar um observador desavisado a interpretar como disco cheio!

4.10.2. Gatilhos para alertas de espaço em disco Agora vamos usar a macro que definimos anteriormente para calcular o volume de disco  usado. Para isso vamos usar uma fórmula para, a partir do total, saber qual é a porcentagem em  “bytes” que a partição terá de limiar. A expressão lógico­matemática seria. ESPAÇO_USADO > (ESPAÇO_TOTAL * LIMITE / 100) Sendo que: • ESPAÇO_USADO: é a média da janela de tempo do espaço utilizado na partição. • ESPAÇO_TOTAL: é o último valor coletado do espaço total da partição. • LIMITE:   o   valor   definido   em   nossa   macro,   representando   a   porcentagem   de   limite  (padrão 80%) para averiguação de estouro de uso de disco. Note que, você poderia usar o “pused” para pegar a porcentagem utilizada ao invés   desta fórmula, mas isso acrescenta mais um item no monitoramento. Além do mais   este é um exemplo bem didático para expressões mais complexas. No caso de nosso cenário a expressão completa é apresentada na Figura 4.113 e calcula  exatamente quantos porcentos de uso da partição apresenta.

Capítulo 4 Monitoramento voltado para disponibilidade - 217

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

Note ainda que, como sempre, colocamos uma dependência ao “Agent Ping” para evitar  testes com valores inexistente que resultam em “UNKNOWN”.  Verifique se alguma máquina excedeu o espaço e acionou o  “trigger”. Neste caso você  deve aumentar o valor da macro  para aquele host somente. Isso é um caso atípico no nosso  cenário então o trataremos como uma exceção. Para testar o “trigger” use o seguinte comando em uma das máquinas Gnu/Linux: # dd if=/dev/zero of=/tmp/lixo bs=1k count=$(( 200 * 1024 )) Isso vai gerar um arquivo de 200 Mb no  “/tmp”. Mude o tamanho do arquivo conforme  achar necessário para fazer o teste. Deixe ele lá até o “trigger” alarmar e depois apague­o para  liberar o espaço e forçar a troca de estado para “OK”.

4.10.3. Exercícios  1)  Clone os “items” criados para a partição “/” alterando para as partições “/usr”, “/var”,  “/tmp”, “/boot” e “/home” (as normalmente criadas numa instalação). Replique também  as   macros,   os   gráficos   e   os   “triggers”. Deixe todas estas métricas e gatilhos como “disabled” por padrão! Elas dependem da  instalação de Gnu/Linux. Em sala replique ao menos uma, as outras podem ser feitas  em casa.  2)  Crie as mesmas métricas para o Windows, mas com as partições de “C:” até “G:”. Em  sala crie ao menos uma, as outras podem ser feitas em casa.

Capítulo 4 Monitoramento voltado para disponibilidade - 218

 3)  Desafio:   crie   métricas   que   checam   partições   personalizadas   pelo   administrador,  usando macros para definir os pontos de montagem.

4.11. Scripts externos Fizemos   várias   checagens   até   o   momento   usando   os   recursos   do   Zabbix.   Mas   nem  sempre teremos tudo a mão. Este trecho do curso ensina a estender o agente de tal forma a criar  novas keys através da chamada de scripts externos. Além   disso   algumas   métricas   do   Windows   só   podem   ser   obtidas   pelo   sistema   de  “performance counters” que é um tipo de registro de coleta de performance padrão do Windows.  Veremos como utilizar ambos para adicionar mais poder de fogo ao nosso arsenal de  monitoramento.

4.11.1. Checando a disponibilidade do PostgreSQL O Zabbix não tem suporte a todos os protocolos TCP da face da Terra. De fato isso seria  um feito impressionante para um aplicativo de monitoramento. O protocolo do PostgreSQl esta   entre os não suportados, e embora tenhamos utilizado keys como “tcp” e “tcp_perf” para medir  sua disponibilidade podem ocorrer situações onde o banco aceite conexões mas não responda  nada, ou o faça muito lentamente. Nestes casos iremos criar uma extensão do agente apta a realizar uma  única consulta  (SELECT 1) e verificar se ele retornou o valor correto. Esta extensão vai chamar um script criado  em “bash” que aciona localmente o servidor, faz a consulta e determina o resultado. Prepare os  conhecimentos de “shell script”, respire fundo e vamos começar acessando o host “Database”. O primeiro passo é permitir que o usuário zabbix se conecte ao banco sem a necessidade  de   senhas.   Isso   é   necessário   porque   o   comando   será   executado   automaticamente   sem   a  intervenção manual de um administrador. Como vamos usar o “psql”, cliente padrão via console do PostgreSQL, podemos usar um  artifício interessante com o arquivo “.pgpass”. Este arquivo deve ficar dentro do diretório home do  zabbix e deve conter uma “string” com os parâmetros de acesso. Cada permissão de acesso do 

Capítulo 4 Monitoramento voltado para disponibilidade - 219 usuário zabbix deve estar em uma linha (assim podemos acessar múltiplos bancos de dados). O formato das linhas deste arquivo seguem a sintaxe: hostname:porta:basededados:usuário:senha E no nosso caso vamos acessar o banco principal do sistema “postgres”, logo o valor final  será “localhost:5432:postgres:zabbix:zabbixdb”. Os seguintes comandos criam o arquivo, ajustam  sua permissão e fazem o teste local. # su ­ zabbix $ echo "localhost:5432:postgres:zabbix:zabbixpwd" > .pgpass $ chmod 0400 .pgpass $ psql ­h localhost ­U zabbix postgres ­c “SELECT 1;” 1 $ logout A permissão do arquivo “.pgpass” deve ser 0600 ou 0400 e o dono do arquivo deve ser   o usuário zabbix. Ainda temos que criar o usuário “zabbix” dentro do banco com a senha “zabbixpwd”. # su – postgres $ psql postgres postgres# CREATE ROLE zabbix LOGIN; postgres# \passwd zabbix Digite nova senha: zabbixpwd Digite­a novamente: zabbixpwd postgres#  \q Agora   vamos   criar   um   arquivo   para   conter   as   configurações   do   script.   Ele   vai   conter  apenas   uma   variável   por   enquanto.   Mais   a   frente   vamos   colocar   outros   valores   aqui   para   o  conjunto de scripts do PostgreSQL. # vim /etc/zabbix/pgaccess.conf  1

HOST=localhost

Capítulo 4 Monitoramento voltado para disponibilidade - 220

Enfim chegamos ao script. Basicamente ele executa o comando “psql” com o SQL de  testes   e   verifica   se   tudo   ocorreu   bem.   Mas   há   algumas   partes   do   script   que   merecem   um  destaque. # vim /etc/zabbix/externalscripts/pgsql_ping.sh  1

#!/bin/bash

2 3

BASE="/etc/zabbix"

4

CONF=$BASE/pgaccess.conf

5

QUERY_PING="SELECT 1;"

6

ERROR_LOG=/var/log/zabbix/pgsql_ping.error

7 8

function showerror {

9

        echo ­e "PostgreSQL ping error:\n$(cat $ERROR_LOG)" 1>&2

10

}

11 12

if [ ­r $CONF ]; then

13

        . $CONF

14

fi

15 16

PING_OK=1

17

PING_FAIL=0

18

PING=$(psql ­h $HOST ­c "$QUERY_PING" postgres ­tA 2> $ERROR_LOG) 

19

RETURN=$? 

20 21

if [[ $RESULT ­ne 0 ]]; then 

22

        showerror

23

        exit 1

24

else

25

        if [[ $PING ­eq 1 ]]; then 

26

                echo $PING_OK

27

        else

Capítulo 4 Monitoramento voltado para disponibilidade - 221 28

                showerror 

29

                echo $PING_FAIL

30

        fi

31

fi

32 33

exit 0  1)  O   primeiro   destaque   do   script   é   justamente   o   comando   que   faz   o   “SELECT   1”   e  armazena seu conteúdo em uma variável chamada “$PING”.  Note que o “psql” está  usando os parâmetros “­t” e “­A” para que o comando retorne apenas um valor 1. No  caso de algum erro o valor de “$PING” será diferente de 1.  2)  O retorno do comando é verificado e no caso de erros, uma mensagem é gravada na  saída de erros e o script para com retorno 1. O Zabbix trata isto enviando a saída para  o “zabbix_agentd.log”.  3)  No   caso   do   SELECT   ser   bem   sucedido,   o   valor   retornado   será   1   (definido   no  cabeçalho do script).   4)  Caso contrário o script retorna 0 e grava uma mensagem no log indicando porque. Note que o comportamento, de 1 significa sucesso e 0 para falha, replica o padrão das 

keys de disponibilidade que vimos anteriormente. Isso ajuda a manter o padrão e permite o uso do  “value maps” que criamos. Todo   script  de   comando   externo   deve  retornar  um,  e   apenas  um  valor!  Repita   isso   consigo mesmo! Não há como pegar valores compostos no Zabbix e trabalhar com eles   individualmente depois. Cada item armazena um “single content”.   Agora vamos criar uma nova key  “pgsql.ping”, dentro do agente. Para isso usamos o  “UserParameter”, dentro de um dos arquivos de configuração do agente. A sintaxe desta linha é: UserParamente=key,comando arg1 arg2 ... No caso de nossa necessidade ficará como a seguir. # cat /etc/zabbix/agent.d/pgsql_checks.conf  1

UserParameter=pgsql.ping,/etc/zabbix/externalscripts/pgsql_ping.sh

Capítulo 4 Monitoramento voltado para disponibilidade - 222

Temos que acertar as permissões dos arquivos e reiniciar o agente. # chown root.zabbix /etc/zabbix/pgaccess.conf /etc/zabbix/agent.d/pgsql_checks.conf  /etc/zabbix/externalscripts/pgsql_ping.sh # chmod 0640 /etc/zabbix/pgaccess.conf /etc/zabbix/agent.d/pgsql_checks.conf # chmod 0750 /etc/zabbix/externalscripts/pgsql_ping.sh # /etc/init.d/zabbix­agent restart Já podemos fazer o teste local, o script deve retornar o valor 1. # su zabbix ­c “/etc/zabbix/externalscripts/pgsql_ping.sh” 1 A partir do Zabbix server teste o acesso a nova chave. O resultado também deve ser 1. # zabbix_get ­s database ­k 'pgsql.ping' 1 ←  Se todos os testes foram resolvidos é o momento de voltar ao “front end”. Crie um novo  template “4Linux  – PostgreSQL  8.4  on  Linux”,  ele  deve depender do  “template 4Linux – S.O.   Linux”. Depois entre no host “Database”, remova o template “4Linux – S.O. Linux”  pelo botão  “Unlink”  (conservando assim os dados coletados) e adicione o novo modelo conforme a Figura  4.114. 

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

Verifique se no “Overview” os dados estão sendo recebidos.

Capítulo 4 Monitoramento voltado para disponibilidade - 223

Figura 4.115: Disponibilidade do PostgreSQL ativa no database

Com isso já poderíamos criar “triggers” e fazer o mesmo escalonamento de gatilhos para  averiguar qual tipo de erro pode acontecer.

4.11.2. Medindo a disponibilidade de um link Internet Agora faremos um abordagem diferente: vamos medir a latência do link de Internet a partir  do host “Presentation” (assim podemos obter um valor puro entre o host de borda e o “gateway”   da operadora).  Este script, um pouco mais complexo que o anterior, permite que coletemos a média de  latência entre um conjunto de sites.  # vim /etc/zabbix/externalscripts/internet_perf.sh  1

#!/bin/bash

2 3

BASE=/etc/zabbix

4

CONF=$BASE/internet_perf.links

5

BC=$(which bc)

6 7

function showerror {

8

        echo ­e "Check link error: $1" 1>&2

9

}

Capítulo 4 Monitoramento voltado para disponibilidade - 224 10 11

if [[ ! ­x $BC ]]; then

12

        showerror "aplicativo bc não instalado"

13

        exit 1

14

fi

15 16

if [[ ! ­r $CONF ]]; then

17

        showerror "arquivo $CONF não existe ou não esta acessível para leitura"

18

        exit 1

19

fi

20 21

NTESTS=$(wc ­l $CONF | cut ­f1 ­d" ")

22

SUM_AVG=0

23

for destination in $(cat $CONF); do 

24

        PING=$(ping ­n ­c 1 ­w 1 ­W 1 $destination 2>&1)

25

        if [[ $? ­eq 0 ]]; then

26

                AVG=$(echo $PING | cut ­f34 ­d" " | cut ­f2 ­d"/")

27

                SUM_AVG=$(echo "scale=3; $AVG + $SUM_AVG;" | bc)

28

        else

29

                NTESTS=$(( $NTESTS ­ 1 ))

30

                showerror "ping para $destination falhou com erro: $PING"

31

        fi

32

done

33 34

if [[ $NTESTS ­eq 0 ]]; then

35

        showerror "Todos os testes falharam"

36

        exit 1

37

fi

38 39

echo "scale=3; $SUM_AVG / $NTESTS / 1000;" | bc 

40 41

exit 0

Capítulo 4 Monitoramento voltado para disponibilidade - 225

 1)  Este trecho é o corpo principal do script, ele pega o arquivo de links (abaixo) e realiza  um “ping” em cada um dos endereços lá dentro. Para cada coleta bem sucedida ele  soma a média que o comando retorna (em milissegundos).  2)  No segundo trecho a partir do resultado da soma e da quantidade de testes é obtida a  média   final   e   convertida   para   segundos   (assim   podemos   usar   o   “Unit”  “s”  para  formatar a saída). O   arquivo   de   links   pode   conter   tantas   entradas   o   quanto   quisermos,   mas   não   é  recomendável que haja mais do que 5, que é o tempo limite que o Zabbix espera por um script  executar antes de desistir e retornar nulo. # vim /etc/zabbix/internet_perf.links  1

www.google.com

2

www.uol.com.br Como fizemos anteriormente, criaremos uma nova key “Internet.perf”  que aponta para o 

nosso script.  # vim /etc/zabbix/agent.d/internet_perf.conf  1

UserParameter=internet.perf,/etc/zabbix/externalscripts/internet_perf.sh Finalmente acerte as permissões dos arquivos.

# chown root.zabbix /etc/zabbix ­R # chmod 0640 /etc/zabbix/internet_perf.links /etc/zabbix/agent.d/internet_perf.conf # chmod 0750 /etc/zabbix/externalscripts/internet_perf.sh Já podemos fazer os testes locais e os remotos conforme mostrado no tópico anterior.  Também já podemos criar as macros, “items”, “triggers” e gráficos seguindo a mesma filosofia.  Somente mude o seguinte: para o item e gatilho deixe­os desabilitados no template “4Linux – S.O.   Linux” e habilite somente no host “Presentation”.  Para concluirmos com outra novidade vamos colocar no “label” do link de Internet o valor  médio dos últimos 60 segundos de coleta (Figura 4.116).

Capítulo 4 Monitoramento voltado para disponibilidade - 226

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

Abra o link e edite os valores de seus campos como a seguir.

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

 1)  Label: coloque o valor “Latência: {Presentation:internet_perf.avg(60)}”.   2)  Adicione o “trigger” da latência que você acabou de criar. Não esqueça de salvar antes de sair do mapa. Para testar, diminua o valor da macro de  limite para um valor bem baixo.

Figura 4.118: Link no mapa identificando status do trigger

Capítulo 4 Monitoramento voltado para disponibilidade - 227

Note  como  o  link  mudou de  cor (Figura  4.118)  quando o  host  acusou alta  latência  de  Internet. 

4.11.3. Exercícios  1)  Desafio:   Crie   um   script   externo   capaz   de   ler   a   temperatura   dos   processadores   e  armazená­los no Zabbix. O script deve receber um parâmetro indicando de qual core  deve ser coletado a temperatura (0 – primeiro, 1 – segundo, e assim por diante). Crie   ao menos um gráfico para visualizar o valor coletado dos cores.

- 228

REFERÊNCIAS  BIBLIOGRÁFICAS

- 229

OLUPS, RIHARDS. Zabbix 1.8 Network Monitoring. Packet Publishing. Abril  de 2010. Homepage oficial da documentação do Zabbix, website:  http://www.zabbix.com/documentation/. Acesso em 16 de Fevereiro de 2011.

- 230

Anexo I Performance do Sistema Operacional

Introdução Aqui vamos passar as dicas e métricas que podem ser usadas para monitorar as quatro  principais características de desempenho. Uso de CPU, memória, “throughput” de rede e I/O de  disco. Este capítulo utiliza o template completo do Gnu/Linux para coleta de todas as informações.

Processamento Esta é primeira métrica de performance que, geralmente, é observada quando o sistema  fica lento. Algumas considerações devem ser feitas quando se busca monitorar o processamento  para identificar gargalos:  1)  100% de processamento não quer dizer nada!  1.1)  Picos   de   processamentos   são   mais   corriqueiros   do   que   imaginamos,   eles  acontecem   frequentemente,   mas   são   tão   momentâneos   que   nem   os  percebemos mesmo em gráficos com curtos intervalos de coleta. Sempre que  procurar por eles, concentre­se apenas nos de longa duração.

- 231

 1.2)  Se você criar gatilhos de verificação de CPU, faça­os com uma janela de tempo  razoável.   O   aconselhado   é   que   ela   seja   em   torno   dos   15   minutos,   se   o  processamento   ficou   muito   alto,   por   tanto   tempo   assim,   provavelmente   há  alguma coisa errada na sua aplicação ou seu hardware está mal dimensionado.

 2)  Quando coletar informações de CPU você pode se deparar com muitas opções, aqui  vão algumas dicas sobre o que fazer para decidir o que coletar.  2.1)  Antes   de   olhar   a   porcentagem   da   CPU,   olhe   para   o   “system   load”   (key  “system.cpu.load”). Ela indica o enfileiramento de processos, o que pode ser  bem pior do que simplesmente ter CPU alta o tempo todo.  2.2)  Mantenha ao menos uma coleta geral de baixo nível. O consumo de CPU  é  dividido   em   vários   tipos,   os   mais   relevantes   são   “user”   (consumo   realizado  pelos processos), “system” (consumo realizado pelo kernel) e “wait” (consumo  realizado   por   espera   de   I/O,   geralmente   de   disco).   Existem   outros   menos  relevantes,   portanto   consulte   a   documentação   do   Zabbix   sobre   a   key  “system.cpu.util” para obter mais detalhes.  2.3)  Ao monitorar múltiplos cores individualmente, colete apenas o “idle” de cada um  deles. Raramente você precisará de coletas detalhadas por núcleo.  2.4)  Monitore   também   o   “context   switch”   pela   key   “system.cpu.switches”  para  verificar o número de vezes que os processos nascem, dormem, acordam e  morrem nos “cores”, além de indicar a migração de “threads”.

Métricas de memória O segundo ponto mais importante de se monitorar num S.O. É a memória, incluindo aqui  a área de troca (swap).  1)  Consumo de memória pode ser bem complicado de se monitorar se você não prestar  atenção   nos   tipos   de   memória   que   existem.   No   Gnu/Linux,   por   exemplo,   temos   a  memória de processos, a de “buffer” e a de cache. Por padrão a key “vm.memory.size”  não é capaz de capturar a memória dos processos (que é a importante).  Para fazer  isso você tem que criar um item calculado que subtrai a memória “available” (e não a  “free”) do total.

- 232

 2)  Monitore a memória de “swap” com “system.swap.size” para determinar o consumo, e  mais importante, com “system.swap.in”  e  “system.swap.out”  que mostram a leitura e  escrita na mesma. A área de troca é diretamente ligada ao I/O de disco (abaixo). 

Throughput e banda de rede Banda pode ser um item importante se você não tem um “link” suficientemente grande  para comportar suas necessidades, mas é o “throughput” o que realmente deve ser observado.   1)  Grande   largura   de   banda   com   baixo   “throughput”   e   alta   latência   de   rede   indicam,  problemas   de   rede   (provavelmente   físicos).   A   key   “net.if.in”  e   “net.if.out”  são   as  indicadas para isso.  2)  Lembre­se que o Zabbix, o sistema operacional e seus aplicativos medem o consumo  de rede em “bytes” e não em “bits”. No entanto todos os equipamentos de rede e links  de Internet são comprados pelo segundo. Prefira exibir mesmo assim os dados em  “bytes”. Se você realmente tiver que exibir em “bits” terá que criar um campo calculado  que lê e multiplica o valor do item em “bytes”.  3)  Cuidado   ao   estipular   valores   de   topo   dos   gráficos   de   banda   para   redes   internas.  Enquanto nos links de Internet isso é uma prática recomendável, para consumos de  servidores em redes de 100 ou 1000 Mbps os valores vão ficar tão próximos do eixo x  que a impressão será de tráfego zero.

Performance de Disco Para bancos de dados, analise a performance de disco. O template da 4Linux faz uso de   um script externo que coleta dados de baixo nível, o padrão do Zabbix ainda não é capaz de  coletar estes dados.  1)  Não se atenha a “throughput” de disco em “bytes”, eles variam tanto de um hardware   para  outro que   é  difícil  de estabelecer um padrão.  Use  métricas como  número de  operações, tempo  gasto em escrita/leitura e enfileiramento de operações, eles são  muito mais significativos.  2)  Procure por pontos de incidência de operações irregulares, se o tempo todo seu disco  fica numa média de operações e de repente ele muda, avalie o que pode ter ocorrido  neste período, mesmo que seja para menos carga (o que pode indicar “delays” de  operação).

- 233

Anexo II Performance de serviços

Introdução Performance de serviços é um assunto extenso e demandaria vários cursos a parte para  poder   cobrir   sua   toda   a   sua   extensão.   De   fato,   uma   parte   dos   cursos   avançados   da   4Linux  detalham este tipo de estudo. Aqui vamos apenas arranhar a ponta do iceberg.  Os   templates   completos   do   final   do   curso   contém   muito   mais   detalhes   dos   que   os  discutidos aqui.

PostgreSQL O banco de dados do PostgreSQL possui um sistema de tabelas chamadas catálogos.  Estas tabelas armazenam diversas operações importantes.  1)  Não perca tempo olhando estatísticas de nível muito baixo. Comece por dados como  número de conexões e de operações no banco. Não aumente as conexões do banco  arbitrariamente, essa é uma prática ruim!

- 234

 2)  Procure distinguir o comportamento de sua aplicação. Muitas operações de escrita e  pouca leitura, ou vice­versa, ou ainda ambas! Isso torna as coisas mais fáceis para  dimensionar “tunnings”.  3)  Monitore a instância como um todo e depois desça para bancos específicos, seguido  de tabelas e por último índices e sequências. Assim você ganha uma visão global do  sistema antes de depurar qual tabela você precisa separar, particionar, etc.

JBoss O servidor de aplicações JBoss tem todos aqueles “MBeans” que o Zapcat dissecou para  nós. Vamos comentar os mais importantes.  1)  Aplicações   java   não   usam   “fork”.   Eles   sempre   trabalham   em   “threads”,   por   isso  monitorar “threads” (principalmente os HTTP e AJP) vão mostrar o uso da JVM para  conexões.  2)  O   JBoss   usa   “datasources”,   que   possuem   “poolings”   de   conexões.   Monitorar   as  conexões destes “pools” também é uma boa métrica. Via de regra uma boa aplicação,  mesmo   muito   ocupada,   não   deve   usar   mais   do   que   algumas   poucas   dezenas   de  conexões.  3)  Consumo   de   memória   “heap”   pode   indicar   “garbage   collectors”   fazendo   muitas  operações (nunca coloque muita memória de “heap” para as JVMs, pois o GC pode  derrubar   as   JVMs).   Vazamentos   ­   “Leaks”   ­   de   memórias   também   podem   ser  detectados com este tipo de monitoramento.  4)  Monitorar  a   área   de   “perm   gen”  normalmente  não   é   necessário,  mas  pode   indicar  quando “redeploys” acabam consumindo toda a memória destinada a “byte codes”.

Apache O template do Apache precisa do “mod_status” ativado para coleta de informações.   1)  Normalmente   a   métrica   mais   significativa   é   o   número   de   conexões   e   uso   de  processos.  2)  Verificar os processos em “idle” pode indicar que a configuração pode ser ajustada  para menos, para consumir menos recursos.