12.4. Monitorització

La monitorizació és un terme genèric, i les diverses activitats implicades tenen diversos objectius: d'una banda, fer seguiment de l'ús dels recursos proporcionats per una màquina permet anticipar la saturació i les posteriors actualitzacions necessàries; d'altra banda, alertar a l'administrador tan aviat com un servei no estigui disponible o no funcioni correctament significa que els problemes que ocorren es poden solucionar abans.

Munin cobreix la primera àrea, mitjançant la visualització de gràfics per a valors històrics d'una sèrie de paràmetres (RAM usada, espai de disc ocupat, càrrega de processador, trànsit de xarxa, càrrega Apache/MySQL, etc.). Nagios cobreix la segona àrea, comprovant regularment que els serveis estan funcionant i disponibles, i enviant alertes a través dels canals apropiats (e-mails, missatges de text, etc.). Tots dos tenen un disseny modular, que facilita la creació de nous connectors per monitorar paràmetres o serveis específics.

ALTERNATIVA Zabbix, una eina de monitorització integrada

Tot i que Munin i Nagios són d'ús molt comú, no són els únics jugadors en el camp de la monitorització, i cadascun d'ells només s'encarrega de la meitat de la feina (visualització gràfica en un costat, i alertes a l'altre). Zabbix, d'altra banda, integra les dues parts de la monitorització; també té una interfície web per configurar els aspectes més comuns. Ha fet passes de gegant durant els últims anys, i ara pot considerar-se un contendent viable. Al servidor de monitorització s'hi instal·laria zabbix-server-pgsql (o zabbix-server-mysql), possiblement juntament amb zabbix-frontend-php per tenir una interfície web. A les màquines per monitoritzar s'hi instal·laria zabbix-agent que alimentaria amb dades el servidor.

→ https://zabbix.com/

12.4.1. Configuració de Munin

El propòsit de Munin és controlar moltes màquines; per tant, utilitza de forma natural una arquitectura client/servidor. L'amfitrió central, el «grapher» o “generador de gràfiques”, recull dades de tots les màquines controladess, i genera gràfiques d'històrics.

12.4.1.1. Configuració dels equips a monitoritzar

El primer pas és instal·lar el paquet munin-node. El dimoni instal·lat per aquest paquet escolta pel port 4949 i envia les dades recollides per tots els connectors actius. Cada connector és un programa senzill que retorna una descripció de les dades recollides així com el valor mesurat més recent. Els connectors s'emmagatzemen a /usr/share/munin/plugins/, però només aquells amb un enllaç simbòlic a /etc/munin/plugins/ s'utilitzen realment.

Quan el paquet està instal·lat, es determina un conjunt de «plugins» actius basats en el programari disponible i la configuració actual de l'amfitrió. No obstant això, aquesta configuració automàtica depèn d'una característica que cada connector ha de proporcionar, i normalment és una bona idea revisar i afinar els resultats a mà. Navegar per la galeria d'extensions pot ser interessant encara que no tots els connectors tenen una documentació completa.

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

No obstant això, tots els connectors són scripts i la majoria són bastant simples i estan ben comentats. Navegar per /etc/munin/plugins/ és, per tant, una bona manera d'obtenir una idea de què tracta cada connector i determinar què es pot eliminar. De la mateixa manera, l'habilitació d'un connector interessant trobat a /usr/share/munin/plugins/ és simplement qüestió de configurar un enllaç simbòlic amb ln -sf /usr/share/munin/plugins/connector /etc/munin/plugins/. Tingueu en compte que, quan un nom de connector acaba amb un subratllat “_”, el connector requereix un paràmetre. Aquest paràmetre s'ha d'emmagatzemar en el nom de l'enllaç simbòlic; per exemple, el connector «if_» s'ha d'habilitar amb un enllaç simbòlic if_eth0, i monitoritzarà el trànsit de xarxa a la interfície eth0.

Una vegada que tots els connectors estan correctament configurats, la configuració del dimoni s'ha d'actualitzar per descriure el control d'accés de les dades recollides. Això implica directives allow al fitxer /etc/munin/munin-node.conf. La configuració per defecte és allow ^127\.0\.0\.1$, i només permet l'accés a l'amfitrió local. Un administrador normalment afegeix una línia similar que conté l'adreça IP de dels gràfics, i després reinicia el dimoni amb systemctl restart munin-node.

ANANT MÉS ENLLÀ Creació de connectors locals

Munin inclou documentació detallada sobre com s'han de comportar els connectors, i com desenvolupar-ne de nous.

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

Un connector es prova millor quan s'executa en les mateixes condicions que si s'activa amb el munin-node; això es pot simular executant munin-run connector com a superusuari. Un segon paràmetre potencial donat a aquesta ordre (com ara config) es passa al connector com a paràmetre.

Quan s'invoca un connector amb el paràmetre config, aquest ha de descriure's retornant un conjunt de camps:

# 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

Els diversos camps disponibles són descrits per la «Plugin reference» o “referència sobre els connectors” disponible com a part de la «Munin guide».

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

Quan s'invoca sense paràmetres, el connector simplement retorna els últims valors mesurats; per exemple, executant sudo munin-run load podria retornar load.value 0.12.

Finalment, quan s'invoca un connector amb el paràmetre autoconf, hauria de retornar «yes» (i un codi de sortida 0) o «no» (amb un estat de sortida 1) segons si el connector s'ha d'habilitar en aquest amfitrió.

12.4.1.2. Configuració del Grapher

El «grapher» és simplement l'ordinador que agrega les dades i genera les gràfiques corresponents. El programari necessari està al paquet munin. La configuració estàndard executa munin-cron (una vegada cada 5 minuts), que recopila dades de tots els amfitrions llistats a /etc/munin/munin.conf (només el host local és llistat per defecte), desa les dades històriques en fitxers RRD («Round Robin Database», un format de fitxer dissenyat per emmagatzemar dades que varien en el temps) emmagatzemats sota /var/lib/munin/ i genera una pàgina HTML amb els gràfics a /var/cache/munin/www/.

Per tant, totes les màquines controlades han d'estar llistades al fitxer de configuració /etc/munin/munin.conf. Cada màquina és llistada com una secció completa amb un nom que coincideixi amb la màquina i almenys una entrada address que indica l'adreça IP corresponent.

[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes

Les seccions poden ser més complexes, i descriure gràfiquess addicionals que es podrien crear combinant dades procedents de diverses màquines. Les mostres proporcionades al fitxer de configuració són bons punts d'inici per a la personalització.

L'últim pas és publicar les pàgines generades; això implica configurar un servidor web de manera que el contingut de /var/cache/munin/www/ estigui disponible en un lloc web. L'accés a aquest lloc web sovint es restringirà, utilitzant un mecanisme d'autenticació o control d'accés basat en IP. Vegeu Secció 11.2, «Servidor web (HTTP)» per als detalls pertinents.

12.4.2. Configuració de Nagios

A diferència de Munin, Nagios no necessàriament necessita instal·lar res en els equips controlats; la major part del temps, Nagios s'utilitza per comprovar la disponibilitat de serveis de xarxa. Per exemple, Nagios pot connectar-se a un servidor web i comprovar que una pàgina web donada es pot obtenir en un temps determinat.

12.4.2.1. Instal·lació

El primer pas en la configuració de Nagios és instal·lar els paquets nagios4 i monitoring-plugins. La instal·lació dels paquets configura la interfície web i el servidor Apache. Els mòduls Apache authz_groupfile i auth_digest han d'estar habilitats; per a això executeu:

# 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

Afegir altres usuaris és una simple qüestió d'inserir-los al fitxer /etc/nagios4/hdigest.users.

Carregant en un navegador http://servidor/nagios4/ mostra la interfície web; en particular, tingueu en compte que Nagios ja monitoritza alguns paràmetres de la màquina on s'executa. No obstant això, algunes característiques interactives com ara afegir comentaris a un amfitrió no funcionen. Aquestes característiques estan inhabilitades en la configuració predeterminada de Nagios, que és molt restrictiva per raons de seguretat.

Habilitar algunes característiques implica editar /etc/nagios4/nagios.cfg. També hem de crear permisos d'escriptura per al directori utilitzat per Nagios, amb ordres com les següents:

# 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. Configuració

La interfície web de Nagios és bastant agradable, però no permet la configuració, ni es pot utilitzar per afegir servidors o serveis monitoritzats. Tota la configuració es gestiona a través de fitxers referenciats al fitxer de configuració central, /etc/nagios4/nagios.cfg.

Aquests fitxers no s'han de “bussejar” sense una certa comprensió dels conceptes de Nagios. La configuració llista els objectes dels següents tipus:

un host és una màquina que s'ha de monitoritzar;
un hostgroup és un conjunt d'equips que s'han d'agrupar per a la seva visualització, o per abstraure alguns elements de configuració comuns;
un service és un element verificable relacionat amb un amfitrió o un grup d'amfitrions. La majoria de les vegades serà la comprovació d'un servei de xarxa, però també pot implicar comprovar que alguns paràmetres estan dins d'un rang acceptable (per exemple, l'espai de disc lliure o la càrrega de processador);
un servicegroup és un conjunt de serveis que s'han d'agrupar per a la visualització;
un contact és una persona que pot rebre alertes;
un contactgroup és un conjunt d'aquests contactes;
un timeperiod és un interval de temps durant el qual s'han de comprovar alguns serveis;
un command és la línia d'ordres invocada per comprovar un servei donat.

Segons el seu tipus, cada objecte té una sèrie de propietats que es poden personalitzar. Una llista completa seria massa llarga per incloure, però les propietats més importants són les relacions entre els objectes.

Un service utilitza un command per comprovar l'estat d'una característica en un host (o en un hostgroup) dins d'un timeperiod. En cas d'un problema, Nagios envia una alerta a tots els membres del contactgroup vinculat al servei. Cada membre rebrà l'alerta d'acord amb el canal descrit en el corresponent objecte contact.

Un sistema d'herència permet compartir fàcilment un conjunt de propietats entre molts objectes sense duplicar informació. A més, la configuració inicial inclou una sèrie d'objectes estàndard; en molts casos, la definició de nous amfitrions, serveis i contactes és una qüestió senzilla de derivar a partir dels objectes genèrics proporcionats. Els arxius de /etc/nagios4/conf.d/ són una bona font d'informació sobre com funcionen.

Els administradors de Falcot Corp utilitzen la següent configuració:

Exemple 12.5. Fitxer /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
}

This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup.

Adoneu-vos-en de l'ús de l'herència: es fa que un objecte hereti d'un altre objecte amb “use nom-pare". L'objecte “pare” ha de ser identificable, la qual cosa requereix donar-li una propietat “name identificador”. Si l'objecte pare no està pensat per ser un objecte real, sinó només per servir com a pare, indicant-li una propietat “register 0” li diu a Nagios que no li consideri, i per tant ignorar la manca d'alguns paràmetres que d'una altra manera serien necessaris.

ANANT MÉS ENLLÀ Tests remots amb NRPE

Molts connectors de Nagios permeten comprovar alguns paràmetres locals d'un amfitrió; si moltes màquines necessiten aquestes comprovacions al temps que una instal·lació centralitzada les recopila, el connector NRPE («Nagios Remote Plugin Executor» o “executador de connectors remots de Nagios”) ha de ser desplegat. El paquet nagios-nrpe-plugin s'ha d'instal·lar al servidor Nagios, i nagios-nrpe-server als amfitrions on s'han d'executar les proves locals. Aquest últim obté la configuració de /etc/nagios/nrpe.cfg. Aquest fitxer hauria de llistar les proves que es poden activar remotament, i les adreces IP de les màquines poden activar-les. A la banda de Nagios, permetre aquestes proves remotes és una simple qüestió d'afegir serveis corresponents utilitzant la nova ordre check_nrpe.