Ottimizzare il monitoraggio

Il monitoraggio è davvero utile solo se è preciso. Il più grande ostacolo all'accettazione da parte dei colleghi (e probabilmente anche da parte tua) sono i falsi positivio, in parole povere, i falsi allarmi.

Con alcuni principianti di Checkmk, abbiamo visto che hanno aggiunto molti sistemi al monitoraggio in poco tempo, forse perché è così facile farlo in Checkmk. Quando poco dopo hanno attivato le notifiche per tutti gli utenti, i loro colleghi sono stati sommersi da centinaia di e-mail al giorno e dopo pochi giorni il loro entusiasmo per il monitoraggio è stato effettivamente distrutto.

Anche se Checkmk si sforza di definire valori predefiniti appropriati e validi per tutte le possibili impostazioni, non può sapere con precisione come dovrebbero essere le cose nel tuo ambiente IT in condizioni normali. Pertanto, è necessario un po' di lavoro manuale da parte tua per mettere a punto il monitoraggio fino a quando non verrà inviato nemmeno l'ultimo falso allarme. A parte questo, Checkmk troverà anche alcuni problemi reali che tu e i tuoi colleghi non avete ancora sospettato. Anche questi devono essere prima risolti in modo adeguato - nella realtà, non nel monitoraggio!

Il seguente principio si è dimostrato valido: prima la qualità, poi la quantità, o in altre parole:

Nei prossimi capitoli dedicati alla configurazione, ti mostreremo quali opzioni di messa a punto hai a disposizione - in modo che tutto ciò che non causa problemi sia verde - e come tenere sotto controllo eventuali cadute occasionali.

Prima di iniziare la configurazione, dobbiamo prima dare un'occhiata alle impostazioni degli host e dei servizi in Checkmk. Poiché Checkmk è stato sviluppato per ambienti grandi e complessi, questo viene fatto utilizzando delle regole. Questo concetto è molto potente e porta molti vantaggi anche agli ambienti più piccoli.

L'idea di base è quella di non specificare esplicitamente ogni singolo parametro per ogni servizio, ma di implementare qualcosa del tipo:"Su tutti i sistemi di produzione Oracle, i file system con il prefisso /var/ora/ al 90 % saranno WARN e al 95 % saranno CRIT".

Una regola di questo tipo permette di impostare delle soglie per migliaia di file system con una sola azione e, allo stesso tempo, documenta in modo molto chiaro quali sono i sistemi di monitoraggio IT in vigore nella tua azienda.

Sulla base di una regola di base, puoi definire separatamente le eccezioni per i singoli casi. Una regola adatta potrebbe essere la seguente:"Sul server Oracle srvora123, il file system /var/ora/db01/ al 96% di riempimento sarà WARN e al 98% sarà CRIT". Questa regola di eccezione viene impostata in Checkmk allo stesso modo della regola di base.

Ogni regola ha la stessa struttura: è sempre composta da una condizione e da un valore. Puoi anche aggiungere una descrizione e un commento per documentare lo scopo della regola.

Le regole sono organizzate in set di regole. Per ogni tipo di parametro, Checkmk ha già pronto un set di regole adatto, quindi puoi scegliere tra diverse centinaia di set di regole. Ad esempio, ce n'è uno chiamato Filesystems (used space and growth) che stabilisce le soglie per tutti i servizi che monitorano i file system. Per implementare l'esempio precedente, devi impostare la regola di base e la regola di eccezione da questo set di regole. Per determinare quali sono le soglie valide per un particolare file system, Checkmk passa in sequenza tutte le regole valide per il controllo. La prima regola per la quale si applica la condizione imposta il valore - in questo caso, il valore percentuale al quale il controllo del file system diventa WARN o CRIT.

Hai diverse opzioni per accedere ai set di regole in Checkmk.

Da un lato, puoi trovare i set di regole nel menu Setup sotto i temi degli oggetti per i quali esistono set di regole (Hosts, Services e Agents) in diverse categorie. Ad esempio, ci sono le seguenti voci di set di regole per i servizi:Service monitoring rules, Discovery rules, Enforced services, HTTP, TCP, Email, …​ e Other Services. Se selezioni una di queste voci, nella pagina principale verranno elencati i set di regole associati, che possono essere pochi o molti, come nel caso di Service monitoring rules. Pertanto, hai la possibilità di filtrare nella pagina dei risultati - nel campo Filter della barra del menu.

Se non sei sicuro di quale sia la categoria in cui si trova il set di regole, puoi anche cercare tutte le regole in una sola volta, utilizzando il campo di ricerca nel menu di configurazione o aprendo la pagina di ricerca delle regole tramite Setup > General > Rule search. Seguiremo quest'ultima strada nel capitolo successivo, in cui introdurremo il processo di creazione delle regole.

Con il gran numero di set di regole disponibili, non è sempre facile trovare quella giusta, con o senza ricerca. Tuttavia, esiste un altro modo per accedere alle regole appropriate per un servizio esistente. In una visualizzazione che include il servizio, clicca sull'opzione menu e seleziona la voce Parameters for this service:

Si aprirà una pagina da cui potrai accedere a tutti i set di regole di questo servizio:

Nel primo box intitolato Check origin and parameters, la voce Filesystems (used space and growth) ti porta direttamente al set di regole per le soglie di monitoraggio del file system. Tuttavia, nella panoramica puoi vedere che Checkmk ha già impostato dei valori predefiniti, quindi devi creare una regola solo se vuoi modificarli.

Il modo migliore per iniziare è formulare la regola che vuoi implementare in una frase, come questa:"Su tutti i server Oracle di produzione, i tablespace DW20 e DW30 al 90% di riempimento avranno uno stato WARN e al 95% uno stato CRIT".

A questo punto puoi cercare un set di regole appropriato, in questo esempio tramite la ricerca di regole: Setup > General > Rule search. Si apre una pagina in cui puoi cercare "Oracle" o "tablespace" (senza distinzione tra maiuscole e minuscole) e trovare tutti i set di regole che contengono questo testo nel loro nome o nella loro descrizione (non mostrati qui):

Il set di regole Oracle Tablespaces viene trovato in due categorie. Il numero che segue il titolo (qui ovunque 0) mostra il numero di regole che sono già state create a partire da questo set di regole.

In questo esempio, non vogliamo l'impostazione del servizio forzato. Pertanto, clicca sul nome della categoria Service monitoring rules per aprire la pagina di panoramica del set di regole:

Questo set di regole non contiene ancora alcuna regola. Puoi creare la prima regola con il pulsante Add rule. Creando - e successivamente modificando - questa regola si apre un modulo con tre box: Rule properties Value e Conditions. Analizzeremo ciascuno di questi tre riquadri a turno.

Nel box Rule properties tutte le voci sono facoltative. Oltre ai testi informativi, qui hai anche la possibilità di disattivare temporaneamente una regola. Questo è pratico perché a volte puoi evitare di cancellare e ricreare una regola se non ne hai temporaneamente bisogno.

Quello che trovi nel box Value dipende in ogni caso specifico dal contenuto della regola:

L'esempio mostra un caso tipico: ogni singolo parametro può essere attivato da un checkbox e la regola si applicherà solo a questo parametro. Puoi, ad esempio, lasciare che un altro parametro sia determinato da una regola diversa se questo semplifica la tua configurazione. In questo esempio, verranno definiti solo i valori di threshold per la percentuale di spazio libero nel tablespace.

Il box Conditions per l'impostazione delle condizioni è un po' più confuso a prima vista:

In questo esempio ci occuperemo solo dei parametri assolutamente necessari per definire questa regola specifica:

Con Folder specifichi in quale cartella deve essere applicata la regola. Ad esempio, se cambi il valore predefinito Main in Windows, la nuova regola sarà applicata solo agli host situati direttamente nella cartella Windows o al di sotto di essa.

La cartella Host tags è una funzione molto importante di Checkmk, per cui le dedicheremo un capitolo a parte subito dopo questo capitolo. A questo punto, utilizza uno degli host tag predefiniti per specificare che la regola deve essere applicata solo ai sistemi di produzione. Per prima cosa seleziona il gruppo di tag host Criticality dall'elenco, poi clicca su Add tag condition e seleziona il valore Productive system.

Molto importanti in questo esempio sono i valori Explicit tablespaces, che limitano la regola a servizi molto specifici. Due punti sono importanti in questo caso:

Una volta completate tutte le voci della definizione, salva la regola con Save. Dopo il salvataggio, ci sarà esattamente una nuova regola nel set di regole:

Controlla i valori di soglia per il monitoraggio dei file system e regolali se necessario. Abbiamo già mostrato brevemente i valori predefiniti sopra nella ricerca delle regole.

Per impostazione predefinita, Checkmk considera le soglie dell'80% per WARN e del 90% per CRIT per il livello di riempimento dei file system. Ora, l'80% per un disco rigido da 2 terabyte equivale a 400 gigabyte: forse un po' troppo buffer per un avviso. Ecco quindi alcuni suggerimenti sul tema dei file system:

Alcuni server vengono riavviati regolarmente per l'applicazione di patch o semplicemente perché è previsto che lo facciano. Puoi evitare falsi allarmi in questi momenti in due modi:

In Checkmk Raw devi innanzitutto definire un periodo di tempo che copra gli orari del riavvio. Puoi scoprire come fare nell'articolo sui periodi di tempo. Poi crea una regola in ciascuno dei set di regole Notification period for hosts e Notification period for services per gli host interessati e seleziona il periodo di tempo definito in precedenza. La seconda regola per i servizi è necessaria affinché qualsiasi servizio che vada in CRIT durante questo periodo di tempo non faccia scattare una notifica. Se i problemi si verificano entro questo periodo di tempo e vengono risolti entro lo stesso periodo di tempo, non scatterà alcuna notifica.

Nelle edizioni commerciali esistono tempi di manutenzione programmata che puoi impostare per tutti gli host interessati.

Non è sempre un problema quando un computer viene spento. Le stampanti sono un esempio classico. Monitorarle con Checkmk è perfettamente sensato - alcuni utenti organizzano persino il riordino dei toner utilizzando Checkmk. Di regola, però, spegnere una stampante prima dell'orario di chiusura non è un problema. È semplicemente insensato, invece, quando a questo punto Checkmk invia una notifica perché l'host corrispondente alla stampante è DOWN.

Puoi dire a Checkmk che è perfettamente OK che un host sia spento. Per farlo, trova il set di regole Host check command, crea una nuova regola e imposta il suo valore su Always assume host to be up:

Nel box Conditions, assicurati che questa regola venga applicata solo agli host appropriati, a seconda della struttura che hai scelto. Ad esempio, puoi definire un tag host e utilizzarlo qui, oppure puoi impostare la regola per una cartella in cui si trovano tutte le stampanti.

Ora, tutte le stampanti saranno sempre visualizzate come UP, indipendentemente dal loro stato effettivo.

Tuttavia, i servizi della stampante continueranno a essere controllati e qualsiasi timeout comporterà uno stato CRIT. Per evitare anche questo, configura una regola per gli host interessati nel set di regole Status of the Checkmk services, in cui imposti rispettivamente i timeout e i problemi di connessione su OK:

Se monitorizzi uno switch con Checkmk, noterai che durante la configurazione dei servizi viene creato automaticamente un servizio per ogni porta attiva in quel momento. Si tratta di una configurazione predefinita ragionevole per gli switch core e di distribuzione, cioè quelli a cui sono collegati solo dispositivi infrastrutturali o server. Tuttavia, per gli switch a cui sono collegati dispositivi finali come workstation o stampanti, questo comporta da un lato continue notifiche se una porta si abbassa e dall'altro la ricerca continua di nuovi servizi perché una porta precedentemente non monitorata si alza.

Due approcci si sono dimostrati efficaci in queste situazioni: il primo è quello di limitare il monitoraggio alle sole porte uplink, creando una regola per i servizi disabilitati che escluda dal monitoraggio le altre porte.

Tuttavia, il secondo metodo è molto più interessante. Con questo metodo monitorizzi tutte le porte, ma permetti che il down sia uno stato di monitoraggio valido. Il vantaggio è che avrai un monitoraggio degli errori di trasmissione anche per le porte a cui sono connessi i dispositivi finali e potrai così rilevare molto rapidamente cavi patch difettosi o errori di auto-negoziazione. Per implementare questa funzione, hai bisogno di due regole:

Il primo set di regole Network interface and switch port discovery definisce le condizioni in cui le porte dello switch devono essere monitorate. Crea una regola per gli switch desiderati e seleziona se devono essere rilevate singole interfacce (Configure discovery of single interfaces) o gruppi (Configure grouping of interfaces). Poi, in Conditions for this rule to apply > Match port states, attiva 2 - down oltre a 1 - up:

Nella configurazione dei servizi degli switch, ora verranno presentate anche le porte con lo stato di down e potrai aggiungerle all'elenco dei servizi monitorati.

Prima di attivare la modifica, avrai bisogno di una seconda regola che garantisca che questo stato venga valutato come OK. Questo set di regole si chiama Network interfaces and switch ports. Crea una nuova regola e attiva l'opzione Operational state, disattiva Ignore the operational state sotto di essa e poi attiva gli stati 1 - up e 2 - down per Allowed operational states (e qualsiasi altro stato necessario).

Per alcuni servizi che non possono essere impostati in modo affidabile su OK, è meglio non monitorarli affatto. In questo caso, potresti semplicemente rimuovere manualmente i servizi dal monitoraggio per gli host interessati nella configurazione dei servizi (nella pagina Services of host ) impostandoli su Disabled o Undecided. Tuttavia, questo metodo è macchinoso e soggetto a errori.

È molto meglio definire delle regole in base alle quali determinati servizi non saranno sistematicamente monitorati. A questo scopo esiste il set di regole Disabled services. Qui puoi, ad esempio, creare una regola e specificare nella condizione che i file system con il mount point /var/test/ non devono essere monitorati per definizione.

Puoi leggere maggiori informazioni a riguardo nell'articolo sulla configurazione dei servizi.

Le notifiche sporadiche sono spesso generate da valori di soglia sulle metriche di utilizzo, come ad esempio l'utilizzo della CPU, che vengono superati solo per un breve periodo. Di regola, questi brevi picchi non sono un problema e non dovrebbero essere criticati dal monitoraggio.

Per questo motivo, molti plug-in di controllo hanno l'opzione nella loro configurazione di calcolare la media delle metriche su un periodo di tempo più lungo prima di applicare le soglie. Un esempio di ciò è il set di regole per l'utilizzo della CPU per i sistemi non-Unix chiamato CPU utilization for simple devices. Per questo esiste il parametro Averaging for total CPU utilization:

Se lo attivi e inserisci 15, l'utilizzo della CPU verrà prima calcolato come media su un periodo di 15 minuti e solo successivamente i valori di soglia verranno applicati a questo valore medio.

Quando non c'è altro da fare e i servizi continuano a passare occasionalmente a WARN o CRIT per un singolo intervallo di controllo, cioè per un minuto, c'è un ultimo metodo per prevenire i falsi allarmi: il set di regole Maximum number of check attempts for service.

Se crei una regola in questo set di regole e imposti il suo valore a, ad esempio, 3, un servizio che passa da OK a WARN, ad esempio, non attiverà ancora una notifica e non verrà visualizzato come un problema nel pannello di controllo. OverviewLo stato intermedio in cui si troverà il servizio è chiamato stato soft. Solo quando lo stato non sarà OK per tre controlli consecutivi (per una durata totale di poco più di due minuti) verrà segnalato un problema persistente. Solo uno stato hard farà scattare una notifica.

È vero che non si tratta di una soluzione attraente: dovresti sempre cercare di arrivare alla radice di ogni problema, ma a volte le cose sono così e basta, e con il numero di tentativi di controllo hai almeno una soluzione valida per ovviare a queste situazioni.

In qualsiasi data center, il lavoro viene svolto costantemente e quindi l'elenco dei servizi da monitorare non rimarrà mai statico. Per assicurarti di non perdere nulla, Checkmk imposta automaticamente un servizio speciale per te su ogni host: questo servizio è noto come Check_MK Discovery:

Per impostazione predefinita, ogni due ore questo servizio controlla se sono stati trovati nuovi servizi non ancora monitorati o se quelli esistenti sono stati abbandonati. In tal caso, il servizio passa a WARN. Puoi quindi richiamare la configurazione del servizio (alla pagina Services of host ) e riportare l'elenco dei servizi allo stato attuale.

Informazioni dettagliate su questo discovery check sono disponibili nell'articolo sulla configurazione dei servizi, dove potrai anche scoprire come aggiungere automaticamente i servizi non monitorati, semplificando così il lavoro in una configurazione di grandi dimensioni.

Continua con più utenti