 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduzione
Una funzione utile del sistema di notifiche di Checkmk è quella che permette agli utenti — anche senza diritti di amministratore — di personalizzare le notifiche. Gli utenti possono:
Aggiungere notifiche che altrimenti non riceverebbero (“iscriversi”)
Eliminare le notifiche che altrimenti riceverebbero (se non ci sono restrizioni)
Personalizzare i parametri delle notifiche
Disabilitare completamente le notifiche
2. Gestire le notifiche con regole personalizzate
Il punto di accesso dal punto di vista dell'utente è il menu Utente, e lì la voce "Notification rules". Nella pagina "Your personal notification rules", puoi creare una nuova regola con "Add rule".
Il contenuto delle regole di notifica personali è simile a quello delle regole di notifica globali, con una differenza: non contengono una selezione dei contatti. L'utente stesso viene selezionato automaticamente come contatto. Ciò significa che un utente può solo aggiungere o eliminare le proprie notifiche personali.
Tuttavia, l'utente può eliminare le notifiche solo se l'opzione "Allow users to deactivate this notification" è attivata nella regola (globale) che le crea:
Nell'ordine delle regole di notifica, le regole personali vengono sempre dopo quelle globali e quindi possono modificare la tabella delle notifiche generata fino a quel momento. Quindi, a parte il blocco dell'eliminazione appena descritto, le regole globali valgono sempre come impostazione predefinita che puoi personalizzare.
 |
Le modifiche alle regole di notifica non richiedono di attivare le modifiche, ma hanno effetto immediato. |
2.1. Struttura delle regole di notifica
Di seguito presentiamo la struttura generale delle regole di notifica personali con le definizioni delle proprietà generali, del metodo di notifica e delle condizioni.
Proprietà generali
Come per tutte le regole in Checkmk, qui puoi inserire una descrizione e un commento per la regola, o anche disattivarla temporaneamente.
Metodo di notifica
Il metodo di notifica specifica la tecnica da utilizzare per l'invio della notifica, ad esempio tramite e-mail HTML.
Ogni metodo è realizzato tramite uno script. Checkmk include una serie di script. Puoi anche scrivere facilmente i tuoi script personalizzati in qualsiasi linguaggio di programmazione desiderato per implementare notifiche personalizzate, ad esempio per reindirizzare una notifica al tuo sistema di ticket.
Un metodo può includere dei parametri — come ad esempio consentire al metodo che invia e-mail ASCII e HTML di impostare esplicitamente l'indirizzo e-mail del mittente (From:).
Prima di effettuare le impostazioni direttamente nella regola di notifica, è bene sapere che i parametri per i metodi di notifica possono essere specificati anche tramite regole per host e servizi: In Setup > Services > Service monitoring rules, nella sezione Notifications, troverai un set di regole per ciascun metodo di notifica, che puoi utilizzare per definire le stesse impostazioni — e, come al solito, possono dipendere dall’host o dal servizio.
Le definizioni dei parametri nelle regole di notifica consentono di variare queste impostazioni nei singoli casi. Puoi quindi, ad esempio, definire un oggetto globale per la tua e-mail, ma anche definire un oggetto alternativo con una regola di notifica individuale.
Al posto dei parametri puoi anche selezionare "Cancel previous notifications", con cui verranno eliminate tutte le notifiche di questo metodo provenienti da regole precedenti. Per ulteriori informazioni, consulta il tema "eliminazione delle notifiche".
|
Per molti metodi di notifica per l'inoltro ad altri sistemi, troverai informazioni più dettagliate in articoli separati. L'elenco degli articoli è disponibile nel capitolo sugli script di notifica. Quando utilizzi un sistema di ticket, un servizio di messaggistica o un motore di eventi come metodo di notifica, dovresti anche osservare le note relative a questi casi speciali. |
Condizioni
Le condizioni determinano quando verrà utilizzata una regola. Per comprenderle è importante ricordare che la fonte è sempre un evento di monitoraggio su un host o un servizio concreto.
Le condizioni riguardano
gli attributi statici dell’oggetto — ad esempio, se il nome del servizio contiene il testo
/tmpo se un host appartiene a un gruppo di host specifico,allo stato attuale o al cambiamento di stato, ad esempio se il servizio è appena passato da OK a CRIT ,
o con elementi completamente diversi, ad esempio se il periodo di tempo di "orario di lavoro" è attualmente attivo.
Ci sono due punti importanti da considerare quando si impostano le condizioni:
Se non sono state definite condizioni, la regola avrà effetto per ogni evento di monitoraggio.
Non appena selezioni anche una sola condizione, la regola ha effetto solo se tutte le condizioni sono soddisfatte. Tutte le condizioni selezionate sono collegate con AND. C'è solo un'eccezione a questa importante regola, di cui parleremo più avanti e che non considereremo ora.
Ciò significa che dovresti prestare molta attenzione al fatto che le condizioni che hai scelto possano essere soddisfatte contemporaneamente, in modo che venga attivata una notifica per il caso desiderato.
Supponiamo che tu voglia che venga attivata una notifica quando si verifica un evento di monitoraggio per un servizio che inizia con il nome NTP su un host nella cartella Main:
Supponiamo inoltre che questa condizione venga ora estesa notificando anche tutti i cambiamenti di stato di un host allo stato DOWN:
Il risultato di questa regola di notifica con le tre singole condizioni è che non verrà mai inviata alcuna notifica, poiché nessun evento di monitoraggio conterrà il cambiamento di stato di un host e il nome del servizio NTP.
La seguente nota viene ripetuta di tanto in tanto in questo manuale. Tuttavia, in relazione alla configurazione delle tue notifiche, è opportuno sottolinearla nuovamente: Visualizza l'aiuto in linea con Help > Show inline help per ottenere dettagli sull'effetto delle varie condizioni. Il seguente estratto dall'aiuto in linea per l'opzione Match services illustra molto bene il comportamento: "Nota: le notifiche relative agli host non corrisponderanno mai a questa regola, se viene utilizzata questa opzione."
L'eccezione all'operazione AND
Solo se un evento di monitoraggio soddisfa tutte le condizioni configurate, si applicherà la regola di notifica. Come menzionato sopra, c'è un'importante eccezione a questa regola generale: per le condizioni Match host event type e Match service event type:
Se selezioni solo "Match host event type", la regola non corrisponderà a nessun evento di servizio. Lo stesso vale per la selezione di "Match service event type" e degli eventi host. Se invece attivi entrambe le condizioni, la regola corrisponderà se il tipo di evento è attivato in uno qualsiasi dei due elenchi di checkbox. In questo caso eccezionale, queste condizioni non saranno quindi collegate con un AND logico, ma piuttosto con un OR. In questo modo puoi gestire facilmente le notifiche host e di servizio con una sola regola.
Un ulteriore consiglio riguardo alle condizioni "Match contacts" e "Match contact groups":
La condizione verificata qui è se l'host/servizio in questione ha una determinata assegnazione di contatto. Questo può essere utilizzato per implementare funzioni come "Le notifiche relative agli host nel gruppo di contatto Linux non devono mai essere inviate tramite SMS". Ciò non ha nulla a che vedere con la selezione dei contatti descritta sopra.
2.2. Eliminazione delle notifiche tramite regole
Come già accennato nella selezione del metodo di notifica, troverai anche l'opzione "Cancel previous notifications". Per capire come funziona una regola del genere, è meglio visualizzare la tabella delle notifiche.
Supponiamo che alcune regole per un evento di monitoraggio specifico siano già state elaborate. Questo ha generato due notifiche per il nostro utente, una via e-mail e una via SMS.
Ora entra in gioco la regola successiva con il metodo "SMS" e la selezione "Cancel previous notifications". Come risultato di questa regola, la notifica via SMS al nostro utente verrà rimossa e verrà generata solo un'e-mail.
Se una regola successiva dovesse definire nuovamente una notifica via SMS per Bruno, allora questa regola avrà la priorità e l'SMS verrà aggiunto nuovamente alla tabella.
Riassumendo:
Le regole possono sopprimere (eliminare) notifiche specifiche.
Le regole di cancellazione devono seguire le regole che creano le notifiche.
Una regola di eliminazione non "elimina" effettivamente una regola precedente, ma sopprime le notifiche generate da (possibilmente più) regole precedenti.
Le regole successive possono ripristinare le notifiche precedentemente soppresse.
2.3. Consegna sincrona per le e-mail HTML
Puoi selezionare e configurare la consegna tracciabile tramite SMTP per il metodo di notifica e-mail HTML inserendo lo smarthost (con nome e numero di porta), i dati di accesso e il metodo di crittografia:
Per ulteriori informazioni su come tracciare le consegne riuscite o fallite nell'interfaccia utente di Checkmk e nei file di log, consulta l'articolo sulle regole di notifica globali.
Importante: le notifiche tracciabili non sono disponibili per le notifiche di massa!
3. Notifiche di massa
3.1. Panoramica
Chiunque si occupi di monitoraggio ha sicuramente sperimentato un problema isolato che ha scatenato una vera e propria valanga di notifiche (successive). Il principio degli host padre è un modo per ridurle in circostanze specifiche, ma purtroppo non è d’aiuto in tutti i casi.
Puoi prendere un esempio dallo stesso progetto Checkmk: Una volta al giorno creiamo pacchetti di installazione Checkmk per ogni distribuzione Linux supportata. Il nostro monitoraggio Checkmk è configurato in modo tale da avere un servizio che entra in stato "OK" solo se il numero corretto di pacchetti è stato creato correttamente. Può capitare occasionalmente che un errore generale nel software ostacoli la creazione dei pacchetti, causando l'entrata simultanea di 43 servizi nello stato "CRIT".
Abbiamo configurato le notifiche in modo tale che, in un caso del genere, venga inviata una sola e-mail che contiene l'elenco delle 43 notifiche in sequenza. Questo è ovviamente più chiaro rispetto a 43 e-mail singole e riduce anche il rischio che, "nel pieno della battaglia", si perda la 44ª e-mail relativa a un problema completamente diverso.
Il funzionamento di questa notifica di massa è molto semplice. Quando si verifica una notifica, inizialmente verrà trattenuta per un breve periodo. Le notifiche successive che si verificano durante questo periodo verranno immediatamente aggiunte alla stessa e-mail. Questa raccolta può essere definita per ogni regola. Quindi, ad esempio, durante il giorno puoi operare con e-mail singole, ma durante la notte con una notifica di massa. Se viene attivata una notifica di massa, ti verranno generalmente offerte le seguenti opzioni:
Il tempo di attesa può essere configurato a piacere. In molti casi è sufficiente un minuto, poiché entro quel momento dovrebbero essere comparsi tutti i problemi correlati. Ovviamente puoi impostare un tempo più lungo, ma ciò comporterà un ritardo sostanziale nelle notifiche.
Dato che ovviamente non ha senso mettere tutto nello stesso calderone, puoi specificare quali gruppi di problemi devono essere notificati collettivamente. L'opzione "Host" è molto usata: garantisce che vengano raggruppate solo le notifiche provenienti dallo stesso host.
Ecco alcune informazioni aggiuntive sulle notifiche di massa:
Se il raggruppamento è attivato in una regola, l'attivazione può essere disattivata da una regola successiva – e viceversa.
La notifica di massa avviene sempre per contatto. Ogni contatto ha di fatto il proprio "contenitore privato di raccolta".
Puoi limitare la dimensione del contenitore (Maximum bulk size). Una volta raggiunto il limite massimo, la notifica di massa verrà inviata immediatamente.
3.2. Notifiche di massa e periodi di tempo
Cosa succede quando una notifica rientra nel periodo di notifica, ma la notifica di massa che contiene questa notifica – e che arriva un po' più tardi – è fuori dal periodo di notifica? È possibile anche la situazione opposta…
Qui si applica un principio molto semplice: tutte le configurazioni che limitano le notifiche a determinati periodi di tempo sono valide solo per la notifica effettiva. La successiva notifica di massa verrà sempre recapitata indipendentemente da tutti i periodi di tempo.
4. Impostazioni amministratore
4.1. Disabilitazione temporanea delle notifiche
La disabilitazione completa delle notifiche da parte di un utente è protetta dal permesso General Permissions > Disable all personal notifications, che per impostazione predefinita è impostato su no per il ruolo utente user.
Un utente vedrà le checkbox corrispondenti nelle sue impostazioni personali solo se assegni esplicitamente questo permesso al ruolo user:
In qualità di amministratore con accesso alle impostazioni personali dell'utente, puoi eseguire azioni di disabilitazione per conto dell'utente, anche se il permesso sopra descritto non è presente. Puoi trovare questa impostazione in Setup > Users > Users e poi nelle proprietà del profilo utente.
In questo modo, ad esempio, puoi silenziare molto rapidamente le notifiche di un collega in ferie, senza dover modificare la configurazione effettiva.
4.2. Impedire le personalizzazioni definite dagli utenti
Se vuoi impedire del tutto le personalizzazioni, puoi revocare il permesso "General Permissions > Edit personal notification settings" del ruolo "user".
In qualità di amministratore, puoi visualizzare tutte le regole degli utenti selezionando "Setup > Events > Notifications" e poi la voce di menu "Display > Show user rules":
Dopo le regole globali, viene effettuato l'elenco delle regole personali, che puoi modificare anche con 
.