User Tools

Site Tools


doc:appunti:linux:sa:cacti_122

This is an old revision of the document!


Cacti e Icinga2 su Debian Buster

Cacti 1.2.2

Password di admin

L'installazione predefinita crea un account admin con la stessa password utilizzata per l'accesso al database MySQL, quindi vedere il file /etc/cacti/debian.php per recuperare la password.

Una volta fatto accesso all'interfaccia di amministrazione (URL predefinito /cacti/) si può cambiare password da ConfigurazioneUtenti. Esiste anche la scorciatoia dal pulsante in alto a destra Autenticato come adminCambia password, ma da quel menu è attiva una restrizione che chiede una password più complessa (carattere non alfabetico, ecc.).

Poller: Spine invece di cmd.php

La raccolta dei dati avviene ogni 5 minuti eseguendo lo script cmd.php; essendo scritto in PHP l'efficienza è scarsa e potrebbe causare problemi se il numero di data source è elevato. Per questo esiste un poller alternativo da installare con il pacchetto cacti-spine, scritto in linguaggio compilato e che supporta il multithread.

Per attivare il poller alternativo è sufficiente fare login come amministratore nell'interfaccia web e quindi cliccare su ConfigurationSettingsPoller; nel menu a tendina Poller type scegliere spine invece di cmd.php.

Spine accede direttamente al database, controllare i parametri di accesso in /etc/cacti/spine.conf.

FIXME: L'installazione predefinita genera una errore perché il poller eseguito da /etc/cron.d/cacti non ha i permessi per scrivere su /var/log/cacti/poller-error.log. È normale che venga eseguito /usr/share/cacti/site/poller.php anche se si è selezionato Spine? Come mai il proprietario del file era root:root?

SNMP timeout detected [500 ms], ignoring host

Soprattutto dopo aver abilitato il poller Spine, capita molto di frequente di trovare l'errore SNMP timeout nei log. In effetti l'impostazione predefinita di 500 ms è davvero stringente: richiede tempi di latenza sulla rete molto brevi e host non troppo carichi. Inoltre pare che Spine sia molto più preciso nel calcolare il timeout, situazioni che non generavano alcun errore con il poller cmd.php, improvvisamente iniziano a generare grafici pieni di lacune e riempiono i file di log con errori SMTP timeout.

Pare che la soluzione sia quella di allungare il SNMP Timeout nella configurazione di ciascun host. Per dispositivi raggiungibili tramite connessione DSL, che possono essere interessati da congestioni di traffico e picchi di carico elevati (utilizzo della CPU prossimo al 100%) può essere necessario portare il timeout anche intorno ai 15000 ms (15 secondi).

Icinga 2

Istruzioni abbastanza dettagliate sono nella guida Getting Started.

L'installazione di Icinga e Icingaweb prevede l'attivazione di svariate componenti e la creazione di alcuni database di supporto:

  • Database IDO (Icinga Data Output) - È il database utilizzato dal modulo Monitoring di Icinga Web 2 per memorizzare i dati. Tale database viene denominato icinga2 dalla procedura di installazione Debian.
  • Servizio REST API - È l'interfaccia di comunicazione tra Icinga Web 2 e il servizio Icinga2. Deve essere attivata e si deve creare un utente con password per l'accesso, si consiglia di usare il nome icingaweb2.
  • Database per Icinga Web 2. Utilizzato dall'interfaccia web come database di servizio. Non contiene i dati del monitoraggio, ma contiene ad esempio l'elenco degli utenti autorizzati all'accesso. Deve essere creato manualmente e viene popolato dalla procedura di configurazione web. Si consiglia di utilizzare il nome icingaweb.

Si devono installare i seguenti pacchetti:

  • icinga2
  • icingaweb2
  • icinga2-ido-pgsql

Se al posto di PostgreSQL si intende usare MySQL come backend, è necessario installare il pacchetto icinga2-ido-mysql.

Installazione pacchetti Debian

Durante l'installazione del pacchetto IDO viene chiesto se attivare ido-pgsql, è necessario rispondere affermativamente.

Tramite procedura guidata da dbconfig-common, viene creato un utente PostgreSQL e un database, entrambi di nome icinga2. Il database verrà inizializzato con tabelle ecc. Le coordinate per l'accesso a questo database sono memorizzate in /etc/icinga2/features-available/ido-pgsql.conf.

Al termine dell'installazione viene abilitata la configurazione /etc/apache2/conf-enabled/icingaweb2.conf pertanto è attivo l'URL /icingaweb2/.

Database IDO (Icinga Data Output)

Il data base IDO serve a Icinga Web 2 come backend per la memorizzazione dei dati, col pacchetto Debian viene installato ma non attivato. Per vedere quali caratteristiche sono attive in Icinga2 da riga di comando si esegue:

# icinga2 feature list
Disabled features: api command compatlog debuglog elasticsearch gelf
                   graphite ido-pgsql influxdb livestatus opentsdb
                   perfdata statusdata syslog
Enabled features: checker mainlog notification

Per attivare la componente ido-pgsql si esegue:

icinga2 feature enable ido-pgsql
systemctl restart icinga2

REST API Interface

Il modulo Icinga Web 2 ha bisogno di una interfaccia di comunicazione con il servizio Icinga2 per inviare comandi, per recuparare informazioni sugli oggetti, ecc. È necessario pertanto attivare la funzionalità api di Icinga2, che la procedura di installazione Debian ha lasciato non attiva:

icinga2 api setup

La configurazione viene salvata in /etc/icinga2/conf.d/api-users.conf, la procedura crea un solo utente con nome root che ha pieni permessi sull'interfaccia API. È consigliato creare un altro utente di nome icingaweb2 che abbia solo i permessi necessari a Icinga Web 2 per il suo funzionamento.

object ApiUser "root" {
  password = "MySecretRoot"
  permissions = [ "*" ]
}

object ApiUser "icingaweb2" {
  password = "MySecretIcingaweb2"
  permissions = [ "status/query", "actions/*", "objects/modify/*", "objects/query/*" ]
}

Dopo questa modifica è necessario riavviare il servizio:

systemctl restart icinga2

Configurazione web

Database di backend

Durante la configurazione web verranno chieste le credenziali per un database che verrà usato da Icinga Web 2; è necessario creare tale database preventivamente e la procedura provvederà a popolarlo come necessario. Queste le istruzioni SQL utilizzate in PostgreSQL:

CREATE USER icingaweb PASSWORD 'MySecret';
CREATE DATABASE icingaweb OWNER icingaweb;

Prima di inziare la configurazione via web bisogna attivare un token di autorizzazione. Va creato sull'host eseguendo sulla riga di comando (da utente root):

icingacli setup config directory --group icingaweb2;
icingacli setup token create;

Il token visualizzato (viene salvato anche nel file /etc/icingaweb2/setup.token) deve essere copiato nella pagina web di configurazione /icingaweb2/setup.

Oltre al modulo principale Monitoring, si è scelto di installare anche Doc.

La procedura verifica che siano installate tutte le componenti PHP necessarie: volendo utilizzare come backend il database PostgreSQL, è necessario aver installato il pacchetto php7.3-pgsql (per il database MySQL è necessario invece il pacchetto php7.3-mysql). Altri pacchetti che potrebbero essere necessari sono: php-imagick, php-gd, ecc. Verificare anche che nel file /etc/php/7.3/apache2/php.ini sia presente una direttiva del tipo:

date.timezone = "Europe/Rome"

Ricordarsi di eseguire systemctl restart apache2 quando si modifica l'installazione di PHP.

Durante la configurazione si è ovviamente scelto di effettuare l'autenticazione su database. Quando si specificano i parametri per l'accesso al database è opportuno anche indicare la codifica dei caratteri UTF-8. In questa fase viene creato anche l'utente amministratore di Icinga2, si suggerisce di chiamarlo admin.

Monitoring e database IDO

Quando la procedura web configura il modulo Monitoring si devono indicare le coordinate del backend IDO creato durante l'installazione del pacchetto Debian icinga2-ido-pgsql. Aprire il file /etc/icinga2/features-available/ido-pgsql.conf per vedere username, password, ecc.

REST API

Infine la procedura web chiede i parametri per il Command Transport, cioè dell'interfaccia API. Immettere il nome utente e la password che sono stati aggiunti nel file /etc/icinga2/conf.d/api-users.conf, cioè l'utente icingaweb2 con le permissions limitate, non l'utente root.

Al termine della procedura, la configurazione viene salvata nel file /etc/icingaweb2/config.ini.

Comandi utili CLI

Elenco completo di tutti gli oggetti definiti nei file di configurazione:

icinga2 object list

Elenco delle feature attive del servizio Icinga 2:

icinga2 feature list

Si può anche usare la Console API, lanciando l'opportuno comando dopo aver dichiarato login e password tramite variabili d'ambiente (sono necessarie le credenziali di root contenute in /etc/icinga2/conf.d/api-users.conf):

#!/bin/sh
export ICINGA2_API_USERNAME=root
export ICINGA2_API_PASSWORD=MySecret
icinga2 console --connect 'https://localhost:5665/'

Ecco ad esempio come leggere il last_check e il next_check di un servizio:

<1> => get_service("Naxos", "Backup Web Sites").last_check
1563877042.745325
<2> => get_service("Naxos", "Backup Web Sites").next_check
1563962558.395343

Per convertire il timestamp Unix in una data comprensibile questo il comando shell:

$ date -d @1563962558.395343
Wed Jul 24 12:02:38 CEST 2019

Monitoraggio

Per attivare il monitoraggio di qualche host bisogna installare i plugin opportuni, Debian mette a disposizione i pacchetti monitoring-plugins-basic e monitoring-plugins-common.

Sintassi colorata con Vim

Per avere la sintassi colorata quando si editano i file di configurazione di Icinga2, si devono installare un paio di pacchetti e abilitare l'add-on. Con questi comandi si attiva solo per l'utente root (quindi nella directory /root/.vim/):

apt-get install vim-addon-manager vim-icinga2
vim-addons install icinga2

Monitoraggio client remoto via NRPE

Il protocollo NRPE nasce per NAGIOS: sul client remoto da monitorare gira il demone NRPE che sta in ascolto sulla porta 5666, l'interrogazione avviene su tale porta. Con Icinga 2 è possibile utilizzare tale meccanismo sebbene sia deprecato, vedere in proposito Agent-based Checks, NRPE. La soluzione nativa è Icinga 2 client.

Sul server si deve installare il plugin contenuto nel pacchetto Debian nagios-nrpe-plugin, sul client remoto va invece installato il pacchetto nagios-nrpe-server.

Nell'esempio che segue si definisce un servizio Software RAID, da eseguire tramite protocollo NRPE.

Nel file /etc/icinga2/conf.d/commands.conf (o altro file analogo) si definisce un CheckCommand:

object CheckCommand "disk_check_nrpe_swraid" {
    command = [ PluginDir + "/check_nrpe", "--timeout=60:UNKNOWN" ]
    arguments = {
        "-H" = "$address$"
        "-c" = "$nrpe_swraid$"
    }
}

Nel file /etc/icinga2/conf.d/services.conf (o analogo) si definisce il Service:

apply Service "Software RAID" {
    import "generic-service"
    check_command = "disk_check_nrpe_swraid"
    assign where host.vars.nrpe_swraid
}

Il servizio viene applicato a tutti gli host che hanno la variabile nrpe_swraid impostata, tale variabile viene usata per passare al server NRPE il nome del check da eseguire. Questa è la definizione dell'Host nel file /etc/icinga2/conf.d/hosts.conf (o analogo):

object Host "Mail Rigacci.Org" {
  import "generic-host"
  address = "mail.rigacci.org"
  vars.nrpe_swraid = "check_raid"
}

Sul client che esegue il server NRPE si installa il pacchetto nagios-plugins-contrib, che contiene il plugin per verificare il RAID software Linux. Quindi è sufficiente configurare /etc/nagios/nrpe.cfg per consentire le interrogazioni da parte del server Icinga 2:

allowed_hosts=127.0.0.1,52.92.232.192,2001:41d0:206:2232::9396

e definire il comando check_raid nel file /etc/nagios/nrpe_local.cfg:

command[check_raid]=/usr/lib/nagios/plugins/check_raid --plugin=mdstat

Check passivo

Normalmente Icinga 2 effettua check attivi, cioè interroga l'host remoto per conoscere lo stato di una specifica grandezza ed agire di consegunza. Se l'host remoto è dietro a un firewall o comunque non è possibile conoscerne lo stato con un check diretto, è possibile utilizzare i check passivi, cioè è l'host remoto che informa il server Icinga 2 sul proprio stato.

Utilizzeremo una configurazione external command sent via command pipe, che è direttamente derivata dai check passivi con Nagios3, FIXME probabilmente si tratta di una configurazione deprecabile, soprattutto per l'utilizzo di NSCA (Nagios Service Check Acceptor).

Anzitutto si deve abilitare l'opzione external command file. In pratica Icinga 2 inizierà a ricevere input dal named pipe /var/run/icinga2/cmd/icinga2.cmd: ogni eventuale check passivo deve solo aggiungere una riga sulla pipe per informare Icinga dello stato del check.

Si verifica le feature abilitate, si abilita la command e si ricarica il servizio:

icinga2 feature list
icinga2 feature enable command
systemctl reload icinga2

Nel file /etc/icinga2/conf.d/templates.conf (o analogo) si definisce un template per questo tipo di servizio:

template Service "passive-backup-service" {
  import "generic-service"
  check_command = "passive"
  enable_active_checks = false
  enable_passive_checks = true
  check_interval = 1d
  retry_interval = 4h
  max_check_attempts = 1
}

Da notare che lo stato viene controllato una sola volta al giorno (check_interval = 1d), in caso di problemi SOFT viene riprovato dopo 4 ore (retry_interval = 4h). Lo stato del servizio viene considerato valido alla prima verifica (max_check_attempts = 1).

Quindi si definisce un servizio associato ad un host, ad esempio nel file /etc/icinga2/conf.d/services.conf o analogo:

apply Service "Backup Maildir" {
  import "passive-backup-service"
  assign where host.name == "Naxos"
}

Per simulare l'invio di un check passivo è sufficiente scrivere una riga di testo sulla pipe. Questo è il formato da utilizzare:

[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<hostname>;<service>;<ret_code>;<plugin_output>

Il timestamp in formato Unix si può ottenere da una shell Unix con il comando date +%s.

Server NSCA

Nell'ottica di riutilizzare più possibile la configurazione di un vecchio server Nagios3, si utilizza il Nagios Service Check Acceptor per ricevere le notifiche dei check passivi. Si tratta di un demone che ascolta sulla porta TCP/IP 5667 e riceve le notifiche dai vari client per inoltrarle sulla named pipe monitorata da Icinga 2. Pertanto sullo stesso host dove viene eseguito Icinga si installa il pacchetto nsca.

Sul firewall si deve ovviamente aprire la porta 5667 in ingresso e si impostano questi valori nel file di configurazione /etc/nsca.cfg:

command_file=/var/run/icinga2/cmd/icinga2.cmd
158c158
password=MyNscaSecret
decryption_method=3

ATTENZIONE! Poiché il file di configurazione /etc/nsca.cfg contiene una password (che viene condivisa con tutti i client) è opportuno proteggerlo con mode 0640.

FIXME Pare che lo script start/stop per il servizio nsca non funzioni. Eseguendo il comando systemctl stop nsca si legge nel syslog:

nsca[16127]: Stopping Nagios Service Check Acceptor: nscastart-stop-daemon:
    matching only on non-root pidfile /var/run/nagios/nsca.pid is insecure

e infatti il servizio non viene fermato (non funziona neanche il restart). Bisogna killare il processo e riavviarlo manualmente.

Client NSCA

Sull'host che esegue il servizio con check passivo si deve installare il pacchetto nsca-client. Il file di configurazione /etc/send_nsca.cfg deve contenre configurazioni corrispondenti al server:

password=MyNscaSecret
encryption_method=3

ATTENZIONE! Non solo la password deve essere condivisa tra il server e tutti i client, ma non viene effettuato alcun controllo di accesso o simili. Ogni client può pretendere di inviare check passivi a nome di qualunque altro client. Si deve pertanto usare questa architettura solo se il trust fra server e client è totale.

Un semplice script di shell può essere utilizzato per inviare un check passivo:

#!/bin/sh
 
$hostname='ClientName'
$service='Backup Web Sites'
$ret_code=0
$message='All the DocumentRoot(s) were backed-up successfully.'
 
send_nsca -H icinga2.rigacci.org -c /etc/send_nsca.cfg <<END > /dev/null
$hostname    $service    $ret_code    $message
END

ATTENZIONE

  • $hostname deve corrispondere a un host definito in Icinga 2.
  • $service deve corrispondere a un servizio definito in Icinga 2.
  • $ret_code vale zero se il check ha esito positivo (OK), il valore 1 è per lo stato WARNING, il valore 2 per CRITICAL e il valore 3 per UNKNOWN.
  • Il separatore di campo nel testo da inviare a send_nsca è il TAB, non spazi.
  • Se il messaggio ha un formato errato, viene inviato un pacchetto di lunghezza zero che non produce errori nei log del server.

Notifiche

Per abilitare le notifiche via mail, si deve anzitutto verificare che la feature notification sia attiva; dalla riga di comando si esegue:

icinga2 feature list

Nella configurazione predefinita Debian è definito uno User nel file /etc/icinga2/conf.d/users.conf. Verificare che tale user abbia una email valida rispetto al servizio mail dell'host su cui gira Icinga 2.

object User "icingaadmin" {
  import "generic-user"
  ...
  email = "root@localhost"
}

Nel nostro caso la mail root@localhost viene inoltrata a chi di dovere tramite /etc/aliases e le opportune configurazioni di Postfix.

Nel file /etc/icinga2/conf.d/notifications.conf viene abilitata la notifica per ogni host che abbia definito la host.vars.notification.mail (clausola assign where):

apply Notification "mail-icingaadmin" to Host {
  import "mail-host-notification"
  user_groups = host.vars.notification.mail.groups
  users = host.vars.notification.mail.users
  ...
  assign where host.vars.notification.mail
}

Nello stesso file - con una sintassi praticamente identica - viene abilitata la notifica anche per ogni servizio che abbia definito la host.vars.notification.mail:

apply Notification "mail-icingaadmin" to Service {
  import "mail-service-notification"
  user_groups = host.vars.notification.mail.groups
  users = host.vars.notification.mail.users
  ...
  assign where host.vars.notification.mail
}

Quindi - definendo tale variabile per un host - si ottiene come risultato di ricevere notifiche per tutti gli eventi associati a tale host e per tutti gli eventi legati ai servizi che dipendono dallo stesso. Questa è la sintassi:

object Host "Webserver" {
  import "generic-host"
  address = "www.rigacci.org"
  ...
  vars.notification.mail = {
      users = [ "icingaadmin" ]
  }
}

Frequenza delle notifiche

L'impostazione predefinita Debian è di inviare una notifica ogni 30 minuti.

Riferimenti Web

doc/appunti/linux/sa/cacti_122.1564134504.txt.gz · Last modified: 2019/07/26 11:48 by niccolo