• Nenhum resultado encontrado

Explorando os comandos de verificação do Nagios

}

define hostgroup {

hostgroup_name web-servers

alias Web Servers

}

define host {

use generic-host

host_name 192.168.33.10

hostgroups ssh-servers, debian-servers, db-servers }

define host {

use generic-host

host_name 192.168.33.12

hostgroups ssh-servers, debian-servers, web-servers }

Após recarregar o arquivo de configuração – usando o mesmo comando sudo service nagios3 reload– você pode verificar que os novos gru- pos existem clicando no link Host Groups na tela de administração do Nagios. Executar diversas verificações e enviar alertas quando algo está errado são as funcionalidades mais importantes de um sistema de monitoramento como o Nagios. Na próxima seção, vamos conhecer os diversos tipos de checagens que estão disponíveis para verificar que a loja virtual está funcionando corre- tamente.

3.3

Explorando os comandos de verificação do

Nagios

Cada serviço do Nagios está associado a um comando que é executado em cada verificação. O comando nada mais é do que um script que pode ser exe- cutado diretamente da linha de comando. Diversos comandos já vêm instala- dos com o Nagios por padrão, porém você pode criar seus próprios scripts ou instalar plugins da comunidade para estender sua biblioteca de verificações.

Casa do Código Capítulo 3. Monitoramento

Vamos explorar alguns dos comandos pré-instalados, que estão disponí- veis no diretório /usr/lib/nagios/plugins. Por exemplo, o comando check_ssh, que é executado na verificação do serviço SSH:

vagrant@monitor$ cd /usr/lib/nagios/plugins vagrant@monitor$ ./check_ssh 192.168.33.12

SSH OK - OpenSSH_5.9p1 Debian-5ubuntu1 (protocol 2.0) vagrant@monitor$ echo $? 0 vagrant@monitor$ ./check_ssh 192.168.33.11 No route to host vagrant@monitor$ echo $? 2

Perceba que ao rodar o comando check_sshpassando o endereço IP do servidor web, ele imprime uma mensagem com um resumo de uma linha do que aconteceu. Essa mensagem geralmente é da forma <VERIFICAÇÃO> <STATUS> - <MENSAGEM COM DETALHES>, porém o que define o re- sultado da verificação não é o formato da mensagem, mas sim, o código de saída do processo – ou exit code, representado pela variável $?no bash:

• 0 – OK: indica que a verificação passou com sucesso. Representado pelo status verde na interface web.

• 1 – WARNING: indica que a verificação passou o primeiro limite de alerta. Representado pelo status amarelo na interface web.

• 2 – CRITICAL: indica que a verificação falhou e algo está errado. Re- presentado pelo status vermelho na interface web.

• 3 – UNKNOWN: indica que a verificação não conseguiu decidir se o serviço está bem ou não. Representado pelo status laranja na interface web.

Outra verificação que podemos fazer é que conseguimos acessar o servi- dor web por HTTP:

vagrant@monitor$ ./check_http -H 192.168.33.12 Connection refused

3.3. Explorando os comandos de verificação do Nagios Casa do Código

HTTP CRITICAL - Unable to open TCP socket vagrant@monitor$ echo $?

2

vagrant@monitor$ ./check_http -H 192.168.33.12 -p 8080

HTTP OK: HTTP/1.1 200 OK - 2134 bytes in 0.007 second response time ... vagrant@monitor$ echo $?

0

Perceba que precisamos passar a opção -Hpara indicar qual host deve ser verificado. Além disso, como não especificamos a porta a ser verificada, o comando check_httpusa a porta 80 por padrão. Ao passarmos a opção -pcom o valor 8080 – a porta onde o servidor Tomcat está escutando – a verificação passa com sucesso.

Um último comando para explorarmos é a verificação de quanto espaço em disco ainda está disponível:

vagrant@monitor$ ./check_disk -H 192.168.33.12 -w 10% -c 5% /usr/lib/nagios/plugins/check_disk: invalid option -- ’H’ Unknown argument

Usage:

check_disk -w limit -c limit [-W limit] [-K limit] ... vagrant@monitor$ ./check_disk -w 10% -c 5%

DISK OK - free space: / 74473 MB (97% inode=99%); ...

Perceba que, ao contrário do comando check_http, o comando check_disknão aceita a opção -He consegue apenas verificar quanto es- paço em disco está disponível no servidor local. Isso acontece pois o serviço HTTP é um serviço de rede acessível remotamente. Por outro lado, o co- mando check_diskprecisa de informações locais do servidor para deci- dir quanto espaço de disco está disponível e não pode ser executado remota- mente.

O Nagios possui três opções quando você precisa realizar uma verificação remota de um serviço que não está disponível na rede:

• Checagem por SSH: através do comando check_by_ssh, o Nagios consegue abrir uma conexão SSH com o servidor remoto e executar o 46

Casa do Código Capítulo 3. Monitoramento

comando lá. Esta é uma opção simples pois não exige a instalação de nenhum agente no servidor supervisionado. No entanto, conforme o número de verificações remotas aumenta, isso pode aumentar a carga no servidor supervisor, pois ele precisará criar e destruir diversas co- nexões SSH.

• Checagem ativa com NRPE: o Nagios Remote Plugin Executor, ou NRPE, é um plugin que permite a execução de verificações que de- pendem de recursos locais no servidor supervisionado. Um processo agente do NRPE roda no servidor supervisionado e fica esperando pe- didos de verificação do supervisor. Quando o Nagios precisa executar uma verificação, ele pede para o agente NRPE rodá-la e coleta os resul- tados quando a verificação termina. Este tipo de verificação é ativa pois quem inicia o pedido de execução do comando é o servidor supervisor. • Checagem passiva com NSCA: o Nagios Service Check Acceptor, ou NSCA, é um plugin que permite a execução de verificações remotas de forma passiva no servidor supervisionado. Um processo cliente do NSCA roda no servidor supervisionado e executa as verificações peri- odicamente, enviando os resultados para um servidor NSCA que roda no supervisor. Este tipo de verificação é passiva pois quem inicia a exe- cução do comando é o próprio servidor supervisionado.

A figura 3.4mostra as diferentes formas de realizar verificações com o Nagios. Verificações de serviços de rede, como check_httprodam direto do servidor supervisor. Verificações que precisam rodar no servidor super- visionado, podem ser chamadas ativamente com check_by_sshou através do plugin NRPE. Por fim, verificações passivas podem rodar de forma inde- pendente no servidor supervisionado e os resultados enviados para o Nagios através do plugin NSCA.