Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:sa:cacti_122 [2019/08/05 18:46] – [Riferimenti Web] niccolo
+++ doc:appunti:linux:sa:cacti_122 [2019/08/22 11:48] – [Check passivo] niccolo
@@ Line 293: / Line 293: @@
 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 **[[https://icinga.com/docs/icingaweb2/latest/modules/monitoring/doc/05-Command-Transports/#use-a-local-command-pipe|external command sent via command pipe]]**, che è direttamente derivata dai **[[nagios_passivo|check passivi con Nagios3]]**, FIXME probabilmente si tratta di una configurazione deprecabile, soprattutto per l'utilizzo di **NSCA** (Nagios Service Check Acceptor).
+Nel nostro caso si vuole monitorare l'**esecuzione di un backup** su un host remoto. Il monitoraggio deve accorgersi non solo di un eventuale errore, ma anche della mancata esecuzione, per questo si utilizza una combinazione di **check passivi** e **attivi**.
-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.
+  * In condizioni normali l'host remoto esegue il backup e notifica Icinga 2 con un **check passivo**.
+  * Se l'host Icinga 2 non riceve il check passivo, esegue un **check attivo** //dummy// che restituisce lo stato 3 UNKNOWN.
+Il check passivo utilizza il meccanismo **[[https://icinga.com/docs/icingaweb2/latest/modules/monitoring/doc/05-Command-Transports/#use-a-local-command-pipe|external command sent via command pipe]]**, che è direttamente derivata dai **[[nagios_passivo|check passivi con Nagios3]]**. Probabilmente si tratta di una configurazione deprecabile, soprattutto per l'utilizzo di **NSCA** (Nagios Service Check Acceptor).
+Per qusto 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:
@@ Line 309: / Line 314: @@
 <file>
 template Service "passive-backup-service" {
-  import "generic-service"
+    import "generic-service"
-  check_command = "passive"
+    check_command = "passive"
-  enable_active_checks = false
+    /* Do active checks to detect missing passive updates. */
-  enable_passive_checks = true
+    enable_active_checks = true
-  check_interval = 1d
+    enable_passive_checks = true
-  retry_interval = 4h
+    /* Use a runtime function to retrieve the last check time and more details. */
-  max_check_attempts = 1
+    vars.dummy_text = {{
+        var service = get_service(macro("$host.name$"), macro("$service.name$"))
+        var lastCheck = DateTime(service.last_check).to_string()
+        return "No check results received. Last result time: " + lastCheck
+    }}
+    check_interval = 1d  /* This determines the freshness of the check. */
+    retry_interval = 1h  /* Execute the active check if freshness is due. */
+    max_check_attempts = 3  /* Retry the active check some times, before notification. */
+    vars.notification_interval = 1d
 }
 </file>
-FIXME La configurazione qui sopra non attiva le notifiche quando il check passivo non viene inviato. Evidentemente il controllo della //freshness// non va bene in quel modo. Vedere il **[[https://icinga.com/docs/icinga2/latest/doc/08-advanced-topics/#check-result-freshness|check result freshness]]** e il **[[https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#itl-dummy|built-in dummy check]]**, bisogna forse sostituire il check_command //passive// con il //dummy//? Pare di no, il comando //passive// definito in ''/usr/share/icinga2/include/command-icinga.conf'', altro non è che il comando //dummy//.
+Il //check_command// **passive** è definito in ''/usr/share/icinga2/include/command-icinga.conf'', si tratta in effetti del comando built-in **[[https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#itl-dummy|dummy]]** con il valore di //dummy_state// impostato a 3 (stato UNKNOWN). Il valore di //dummy_text// invece utlizza una funziona per recuperare il timestamp dell'ultimo esito positivo del check.
-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**).
+In condizioni normali viene ricevuto un **check passivo** ogni 24 ore, quindi il check attivo giornaliero (//check_interval = 1d//) non viene eseguito. Qualora il check passivo non venga ricevuto, viene eseguito il check attivo //dummy// e lo stato passa da **OK** ad **UNKNOWN soft**. Il check viene ripetuto ogni ora (//retry_interval =1h//) e al terzo tentativo (//max_check_attempts = 3//) lo stato passa a **UNKNOWN hard**.
-Quindi si definisce un servizio associato ad un host, ad esempio nel file **/etc/icinga2/conf.d/services.conf** o analogo:
+Per definire il servizio associato ad un host si aggiunge ad esempio nel file **/etc/icinga2/conf.d/services.conf** o analogo:
 <file>