rigacci.org

User Tools

Site Tools

Trace:
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/09/26 11:41] – [Monitoraggio client remoto via NRPE] niccolodoc:appunti:linux:sa:cacti_122 [2022/03/25 17:37] – [Check passivo] niccolo
Line 361: Line 361:
         return "No check results received. Last result time: " + lastCheck         return "No check results received. Last result time: " + lastCheck
     }}     }}
-    check_interval = 1d  /* This determines the freshness of the check. */ +    check_interval = 1d +1h  /* This determines the freshness of the check. */ 
-    retry_interval = 1h  /* Execute the active check if freshness is due. */ +    retry_interval = 1h      /* Execute the active check if freshness is due. */ 
-    max_check_attempts = 3  /* Retry the active check some times, before notification. */+    max_check_attempts = 3   /* Retry the active check some times, before notification. */
     vars.notification_interval = 1d       vars.notification_interval = 1d  
 } }
Line 370: Line 370:
 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. 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.
  
-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**.+In condizioni normali viene ricevuto un **check passivo** ogni 24 ore, quindi il check attivo giornaliero (//check_interval = 1d + 1h//) 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**.
  
 Per definire il servizio associato ad un host si aggiunge 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:
Line 388: Line 388:
  
 Il timestamp in formato Unix si può ottenere da una shell Unix con il comando **%%date +%s%%**. Il timestamp in formato Unix si può ottenere da una shell Unix con il comando **%%date +%s%%**.
 +
 +La ricezione di un check passivo viene registrata nel log **/var/log/icinga2/icinga2.log**:
 +
 +<code>
 +[2022-02-22 02:49:04 +0100] information/ExternalCommandListener:
 +    Executing external command: [1645494544] PROCESS_SERVICE_CHECK_RESULT;Naxos;
 +    Backup Maildir;0;2022-02-22 02:49:03: santorini-naxos-rsync-maildir:
 +    rsync Maildir da Santorini a Naxos eseguito con successo.
 +</code>
 +
 +==== Ricezione check passivo via REST API ====
 +
 +Si verifica che la **[[#rest_api_interface|REST API interface]]** sia attiva (è la stessa che viene usata dal modulo **Icinga Web 2**). Dovrebbe essere in ascolto sulla porta **TCP/5665**.
 +
 +Nel file **/etc/icinga2/conf.d/api-users.conf** si definisce un utente con password che abbia l'autorizzazione ad inviare i risultati dei check. L'unico permesso richiesto è **actions/process-check-result**:
 +
 +<file>
 +// Used to submit passive checks results, e.g. from backup scripts.
 +object ApiUser "passive-check" {
 +  password = "MyUserSecret"
 +  permissions = [ "actions/process-check-result" ]
 +}
 +</file>
 +
 +Il client che deve inviare l'esito del check passivo può utilizzare ad esempio **curl**, con autenticazione su protocollo https:
 +
 +<code bash>
 +ICINGA2_SERVER='icinga2.rigacci.org'
 +ICINGA2_USER='passive-check'
 +ICINGA2_PASSWORD='MyUserSecret'
 +
 +SERVICE_HOST='Naxos'
 +SERVICE_NAME="Backup Remote Rsync"
 +EXIT_STATUS="0"
 +EXIT_MESSAGE="[OK] Rsync to remote storage"
 +
 +curl -k -s -u "${ICINGA2_USER}:${ICINGA2_PASSWORD}" \
 +    -H 'Accept: application/json' \
 +    -X POST "https://${ICINGA2_SERVER}:5665/v1/actions/process-check-result" \
 +    -d '{ "type": "Service",
 +          "filter": "host.name==\"'"$SERVICE_HOST"'\" && service.name==\"'"$SERVICE_NAME"'\"",
 +          "exit_status": '"$EXIT_STATUS"',
 +          "plugin_output": "'"$EXIT_MESSAGE"'" }' > /dev/null
 +</code>
 +
 +Un servizio Icinga può essere in uno dei seguenti stati:
 +
 +^  0 | OK        |
 +^  1 | WARNING   |
 +^  2 | CRITICAL  |
 +^  3 | UNKNOWN   |
  
 ==== Server NSCA ==== ==== Server NSCA ====
 +
 +:!: **ATTENZIONE**: L'utilizzo di NCSA è deprecato, Icinga2 ha la sua interfaccia **REST API** che può essere protetta con HTTPS e autenticazione. La ricezione dei check passivi va fatta via REST API come spiegato sopra.
  
 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**. 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**.
Line 546: Line 599:
 } }
 </file> </file>
 +===== Notifica custom su Host =====
 +
 +Vediamo come predisporre le notifiche per un singolo host inviando una mail ad un determinato indirizzo. Si crea un file (ad esempio **/etc/icinga2/conf.d/notification_dsl.conf**) in cui si definisce il tipo di notifica e l'utente che deve ricevere la mail:
 +
 +<file>
 +apply Notification "mail-dsl-users" to Host {
 +  import "mail-host-notification"
 +  users = host.vars.notification.mailcustomer.users
 +  times.begin = 3h
 +  interval = 12h
 +  assign where host.vars.notification.mailcustomer
 +}
 +
 +object User "dsl_user_1" {
 +  import "generic-user"
 +  display_name = "Alert for ADSL 1"
 +  email = "name@domain.tld"
 +}
 +</file>
 +
 +Le notifiche inizieranno solo **dopo 3 ore** che l'host ha il problema, e verranno ripetute **ogni 12 ore**. Quindi è sufficiente aggiungere una riga alla definizione dell'host:
 +
 +<file>
 +object Host "ADSL_1"     {
 +    import "generic-host"
 +    address = "185.121.12.106"
 +    vars.notification.mailcustomer = { users = [ "dsl_user_1" ] }
 +}
 +</file>
 +
 ===== Modifica servizi predefiniti ===== ===== Modifica servizi predefiniti =====
  
doc/appunti/linux/sa/cacti_122.txt · Last modified: 2022/10/10 16:27 by niccolo