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

→ https://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 no software disponível e a configuração corrente do hospedeiro. Contudo, essa autoconfiguração depende de um recurso que cada extensão deve fornecer, e geralmente é uma boa ideia revisar e ajustar os resultados manualmente. Explorar a Galeria de Extensões pode ser interessante, mesmo que nem todas as extensões tenham documentação ampla.

→ https://gallery.munin-monitoring.org

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 à 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 systemctl restart munin-node.

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.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

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

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

→ https://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 reúne 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 para configurar o Nagios é instalar os pacotes nagios4 e monitoring-plugins. Ao instalar os pacotes, se configura a interface web e o servidor Apache. Os módulos Apache authz_groupfile e auth_digest devem estar habilitados Para isto execute:

# a2enmod authz_groupfile
Considering dependency authz_core for authz_groupfile:
Module authz_core already enabled
Module authz_core already enabled
Enabling module authz_groupfile.
To activate the new configuration, you need to run:
  systemctl restart apache2
# a2enmod auth_digest
Considering dependency authn_core for auth_digest:
Module authn_core already enabled
Enabling module auth_digest.
To activate the new configuration, you need to run:
  systemctl restart apache2
# systemctl restart apache2

Adicionar outro usuário é uma simples questão de inseri-los is no arquivo /etc/nagios4/hdigest.users.

Apontar o navegador para http://servidor/nagios4/ 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.

Habilitar alguns recursos envolve editar /etc/nagios4/nagios.cfg. Nós também precisamos configurar permissões de escrita para o diretório usado pelo Nagios, através de comandos como os seguintes:

# systemctl stop nagios4
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4
# systemctl start nagios4

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/nagios4/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 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/nagios4/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.5. Arquivo /etc/nagios4/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.12
    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
}

Este 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 o funcionamento de um servidor SMTP 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/nagios4/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 objeto pai tem que ser identificável, o que requer dar a ele uma propriedade “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 reúne, 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 nas quais os testes locais precisam ser rodados. Este ú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. Do lado do Nagios, habilitar esses testes remotos é uma simples questão de adicionar os serviços correspondentes usando o novo comando check_nrpe.