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

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

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

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation.

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

However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

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

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ 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           [email protected]
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           [email protected]
}

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

Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (Nagios Remote Plugin Executor) plugin needs to be deployed. The nagios-nrpe-plugin package needs to be installed on the Nagios server, and nagios-nrpe-server on the hosts where local tests need to run. The latter gets its configuration from /etc/nagios/nrpe.cfg. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new check_nrpe command.