User Tools

Site Tools


doc:appunti:linux:sa:cacti_122

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
doc:appunti:linux:sa:cacti_122 [2019/08/05 18:45] – [Riferimenti Web] niccolodoc: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. 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 errorema anche della mancata esecuzione, per questo si utilizza una combinazione di **check passivi** **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: Si verifica le //feature// abilitate, si abilita la //command// e si ricarica il servizio:
Line 309: Line 314:
 <file> <file>
 template Service "passive-backup-service" { 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> </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 ricevutoviene 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 hostad 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> <file>
Line 559: Line 572:
   * **[[https://icinga.com/docs/icinga2/latest/doc/09-object-types/|Object Types Docs]]**   * **[[https://icinga.com/docs/icinga2/latest/doc/09-object-types/|Object Types Docs]]**
   * **[[https://somoit.net/icinga/icinga-passive-checks-2|Icinga – How to configure passive checks made easy]]**   * **[[https://somoit.net/icinga/icinga-passive-checks-2|Icinga – How to configure passive checks made easy]]**
-  * **[[https://somoit.net/icinga/icinga2-understanding-checks-notification-types|Icinga2 Understanding checks notification types]]**+  * **[[https://somoit.net/icinga/icinga2-understanding-checks-notification-types|Icinga2 – Understanding checks and notification types]]**
doc/appunti/linux/sa/cacti_122.txt · Last modified: 2022/10/10 16:27 by niccolo