12.4. Monitoramento

O monitoramento é um termo genérico e as várias atividades envolvidas tem vários objetivos: por um lado, seguir o uso dos recursos fornecidos pela máquina permite antecipar a saturação e os subsequentes necessidades de upgrades; por outro lado, alertar o administrador assim que um serviço fica indisponível ou não está funcionando de maneira apropriada significa que os problemas que estão acontecendo podem ser consertados mais rapidamente.

O Munin cobre a primeira área, exibindo gráficos de valores históricos de inúmeros parâmetros (RAM usada, espaço de disco ocupado, carga do processador, tráfego de rede,carga do Apache/MySQL, e assim por diante). O Nagios cobre a segunda área,regularmente checando que os serviços estão funcionando e disponíveis, e enviando alertas através dos canais apropriados (e-mails, mensagens de texto e assim por diante). Os dois tem um design modular, o que torna fácil criar novas extensões para monitorar parâmetros específicos ou serviços.

ALTERNATIVA Zabbix, uma ferramenta de monitoramento integrada

Embora o Munin e o Nagios sejam os mais populares, eles não são as únicas opções no campo de monitoramento, e cada um deles apenas lida com metade da tarefa (um com gráficos, outro com alertas). O Zabbix, por outro lado, integra ambas as partes de monitoramento; ele também tem uma interface web para configurar a maioria dos aspectos comuns. Ele cresceu aos trancos e barrancos durante os últimos anos, e pode agora ser considerado um concorrente viável. No servidor de monitoramento, você instalaria o zabbix-server-pgsql (ou zabbix-server-mysql), possivelmente junto com o zabbix-frontend-php para ter uma interface web. Nas máquinas a serem monitoradas você instalaria o zabbix-agent, para alimentar o servidor com os dados.

→ http://www.zabbix.com/

12.4.1. Configurando o Munin

O propósito do Munin é monitorar muitas máquinas; logo, é bem natural que ele use uma arquitetura cliente/servidor. A máquina ("host") central — que faz o gráfico ("grapher") — coleta dados de todas as máquinas ("hosts") monitoradas, e gera gráficos com os históricos.

12.4.1.1. Configurando As Máquinas A Serem Monitoradas

O primeiro passo é instalar o pacote munin-node. O serviço ("daemon") instalado por esse pacote escuta na porta 4949 e envia de volta os dados coletados por todas as extensões ativas. Cada extensão é um programa simples que retorna um descrição dos dados coletados, assim como o último valor medido. As extensões são armazenadas em /usr/share/munin/plugins/, mas apenas aquelas com uma ligação simbólica em /etc/munin/plugins/ são realmente usadas.

Quando o pacote é instalado, um conjunto de extensões ativas é determinado com base nos softwares disponíveis e na configuração atual da máquina. Contudo, essa auto configuração depende da funcionalidade que cada extensão deve fornecer, e geralmente é uma boa ideia rever e ajustar os resultados manualmente. Navegar pela Plugin Gallery (galeria de extensões) pode ser interessante mesmo que nem todas as extensões tenham uma documentação compreensível. Entretanto, todas as extensões são scripts e a maioria é bem simples e bem comentado. Navegar por /etc/munin/plugins/ é portanto uma boa maneira de se ter uma ideia sobre para que cada extensão serve e determinar quais devem ser removidas. Similarmente, habilitar uma extensão interessante encontrada em /usr/share/munin/plugins/ é uma simples questão de configurar uma ligação simbólica com ln -sf /usr/share/munin/plugins/extensão /etc/munin/plugins/. Note que quando o nome de uma extensão termina com um sublinhado “_”, a extensão precisa de um parâmetro. Esse parâmetro tem que ser armazenado no nome da ligação simbólica; por exemplo, a extensão “if_” tem que ser habilitada como uma ligação simbólica if_eth0 para monitorar o tráfego de rede na interface eth0.

Uma vez que todas as extensões estejam configuradas corretamente, a configuração do serviço ("daemon") tem que ser atualizada para descrever o controle de acesso aos dados coletados. Isso envolve a diretiva allow no arquivo /etc/munin/munin-node.conf. A configuração padão é allow ^127\.0\.0\.1$, e apenas permite acesso a máquina local. Um administrador geralmente irá adicionar uma linha similar contendo o endereço IP da máquina que gera o gráfico ("grapher host"), e então reiniciar o serviço com service munin-node restart.

APROFUNDANDO Criando extensões locais

O Munin inclui documentação detalhada sobre como as extensões devem se comportar e como desenvolver novas extensões.

→ http://munin-monitoring.org/wiki/plugins

Uma extensão é melhor testada quando executada nas mesmas condições encontradas quando iniciada pelo munin-node; isso pode ser simulado rodando munin-run extensão como root. Um segundo parâmetro potecial dado a esse comando (tal como config) é passado para a extensão como um parâmetro.

Quando uma extensão é invocada com o parâmetro config, ela tem que descrever a si própria pelo retorno de um conjunto de campos:

$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average

Os vários campos disponíveis são descritos pela Referência das Extensões (“Plugin reference”) disponível como parte do Guia do Munin (“Munin guide”).

→ http://munin.readthedocs.org/en/latest/reference/plugin.html

Quando invocada sem um parâmetro, a extensão apenas retorna os últimos valores medidos; por exemplo, executando sudo munin-run load poderia retornar load.value 0.12.

Finalmente, quando uma extensão é invocada com parâmetro autoconf, ela deveria retornar “yes” (e um status de término 0) ou “no” (com um status de término 1) de acordo sobre se a extensão deve ser habilitada nesta máquina ("host").

12.4.1.2. Configurando a Máquina que faz o Gráfico ("Grapher")

O “grapher” é simplesmente o computador que agrega os dados e gera os gráficos correspondentes. O software necessário está no pacote munin. A configuração padrão roda o munin-cron (uma vez a cada 5 minutos), que reune dados de todas as máquinas ("hosts") listados em /etc/munin/munin.conf (apenas a máquina ("host") local é listada por padrão), salva os dados históricos em arquivos RRD (Round Robin Database, um arquivo com formato desenvolvido par armazenar dados que variam com o tempo) armazenados em /var/lib/munin/ e gera uma página HTML com os gráficos em /var/cache/munin/www/.

Portanto todas as máquinas monitoradas tem que estar listadas no arquivo de configuração /etc/munin/munin.conf. Cada máquina é listada como uma seção completa, com um nome correspondendo com a máquina e pelo menos uma entrada com endereço dando o endereço IP correspondente.

[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes

Seções podem ser mais complexas, e descrever gráficos extras que poderiam ser criados pela combinação de dados vindos de várias máquinas. Os exemplos fornecidos no arquivo de configuração são um bom ponto de partida para customizações.

O último passo é publicar as páginas geradas; isso envolve a configuração de um servidor web para que o conteúdo de /var/cache/munin/www/ seja disponibilizado em um site web. O acesso a esse site web geralmente será restrito, pelo uso de um mecanismo de autenticação ou controle de acesso baseado em IP. Veja Seção 11.2, “Servidor web (HTTP)” para os detalhes relevantes.

12.4.2. Configurando o Nagios

Diferentemente do Munin, o Nagios não necessariamente requer a instalação de alguma coisa nas máquinas (""hosts") monitoradas; na maioria das vezes, o Nagios é usado para conferir a disponibilidade de serviços de rede. Por exemplo, o Nagios pode se conectar em um servidor web e conferir que determinada página web pode ser obtida dentro de um determinado tempo.

12.4.2.1. Instalando

O primeiro passo na configuração do Nagios é a instalação dos pacotes nagios3, nagios-plugins e nagios3-doc. Instalando esses pacotes é configurada a interface web e criado o primeiro usuário, nagiosadmin (para o qual é perguntado uma senha). Adicionar outros usuários é uma simples questão de inseri-los no arquivo /etc/nagios3/htpasswd.users com o comando do Apache htpasswd. Se nenhuma pergunta do Debconf foi exibida durante a instalação, dpkg-reconfigure nagios3-cgi pode ser usado para definir a senha do nagiosadmin.

Apontar o navegador para http://servidor/nagios3/ exibe a interface web; em particular, note que o Nagios já monitora alguns parâmetros da máquina aonde ele roda. Contudo, algumas funcionalidades interativas, tais como adicionar comentários a uma máquina ("host") não funciona. Esses recursos estão desabilitados pela configuração padrão do Nagios, que é muito restritiva por razões de segurança.

Como ducomentado em /usr/share/doc/nagios3/README.Debian, habilitar alguns recursos envolve a editar o /etc/nagios3/nagios.cfg e configurar o parâmetro check_external_commands para “1”. Nós tambéms precisamos configurar permissões de escrita para o diretório usado pelo Nagios, através de comandos como os seguintes:

# service nagios3 stop
[...]
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
# service nagios3 start
[...]

12.4.2.2. Configurando

A interface web do Nagios é bem legal, mas elas não permite configurações, nem pode ser usada para adicionar máquinas ("hosts") monitorados e serviços. Toda a configuração é gerenciada através de arquivos referenciados pelo arquivo de configuração central, /etc/nagios3/nagios.cfg.

Não se deve mergulhar nesses arquivos sem algum entendimento dos conceitos do Nagios. A configuração lista objetos dos seguintes tipos:

um host é a máquina a ser monitorada;
um hostgroup é um conjunto de máquinas que devem ser agrupadas para exibição, ou para fatorar alguns elementos comuns de configuração;
Um service é um elemento testável relacionado a uma máquina ou um grupo de máquinas. Ele irá, muito frequentemente, ser uma checagem para um serviço de rede, mas ele também envolve a checagem de que alguns parâmetros estão dentro de um intervalo aceitável (por exemplo, espaço livre em disco ou carga do processador);
um servicegroup é um conjunto de serviços que devem ser agrupados para exibição;
um contact é uma pessoa que pode receber alertas;
um contactgroup é um grupo de tais pessoas;
um timeperiod é um intervalo de tempo durante o qual alguns serviços tem que ser checados;
um command é a linha de comando invocada para checar um dado serviço.

De acordo com seu tipo, cada objeto tem um número de propriedades que podem ser customizadas. Um lista completa seria muito longa para ser incluída, mas as propriedades mais importantes são as relações entre os objetos.

Um service (serviço) usa um command (commando) para checar o estado de uma funcionalidade em um host (máquina) (ou um hostgroup) dentro de um timeperiod (intervalo de tempo). Em caso de um problema, o Nagios envia um alerta para todos os membros de contactgroup (grupo de contatos) ligados ao serviço. É enviado um alerta a cada membro de acordo com o canal descrito no objeto contact (contato) correspondente.

Um sistema de herança permite o fácil compartilhamento de um conjunto de propriedades por entre muitos objetos sem a duplicação de informação. Além disso, a configuração inicial inclui um número de objetos padrão; em muitos casos, a definição de novas máquinas, serviços e contatos é uma simples questão de derivação a partir dos objetos genéricos fornecidos. Os arquivos em /etc/nagios3/conf.d/ são uma boa fonte de informação sobre como eles funcionam.

Os administradores da Falcot Corp usam a seguinte configuração:

Exemplo 12.3. arquivo /etc/nagios3/conf.d/falcot.cfg

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.6
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Services to check on www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Services to check on ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}

Ess arquivo de configuração descreve duas máquinas monitoradas. A primeira é o servidor web, e a checagem é feita nas portas HTTP (80) e HTTP-seguro (443). O Nagios também checa se um servidor SMTP está rodando na porta 25. A segunda máquina é um servidor FTP, e a checagem inclui garantir que uma resposta venha em 20 segundos. Além desse intervalo, um warning é emitido; além de 30 segundos, o alerta é considerado crítico. A interface web do Nagios também mostra que um serviço SSH é monitorado: isso vem de máquinas pertencentes ao grupo de máquinas ssh-servers. O serviço padrão correspondente é definido em /etc/nagios3/conf.d/services_nagios2.cfg.

Note o uso da herança: um objeto é feito para herdar de outro objeto através de “use parent-name”. O obejto pai tem que ser identificável, o que requer dar a ele uma prorpiedade “name identifier”. Se o objeto pai não se destina a ser um objeto real, mas apenas servir como um pai, dar-lhe uma propriedade “register 0” informa ao Nagios para não considerá-lo, e assim ignorar a falta de alguns parâmetros que de outra forma seriam necessários.

INDO ALÉM Testes remotos com NRPE

Muitas extensões Nagios permitem conferir alguns parâmetros locais de uma máquina ("host"); se muitas máquinas precisam dessas conferências enquanto uma instalação central as reune, a extensão NRPE (Nagios Remote Plugin Executor) precisa ser implantada. O pacote nagios-nrpe-plugin precisa ser instalado no servidor Nagios, e o nagios-nrpe-server nas máquinas ("hosts") aonde os testes locais precisam ser rodados. Esse último pega sua configuração de /etc/nagios/nrpe.cfg. Esse arquivo deve listar os testes que podem ser iniciados remotamente, e os endereços IP das máquinas que tem permissão para iniciá-los. Pelo lado do Nagios, habilitar esses testes remotos é uma simples questão de adicionar os serviços correspondentes usando o novo comando check_nrpe.