 |
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
Per i controlli che misurano i valori delle prestazioni, spesso è difficile impostare le soglie giuste.
Mentre valori troppo bassi generano stati "WARN" o "CRIT" che indicano solo presunti problemi, impostarli troppo in alto li lascia in uno stato "OK", con il risultato che il monitoraggio non rileva i problemi.
Prendiamo come esempio il servizio CPU load su un host Linux (o, analogamente, Processor Queue su un host Windows): Potresti avere un server che rimane inattivo per la maggior parte del tempo, ma regolarmente, per alcuni brevi periodi ogni giorno tranne il sabato e la domenica, dalle 0:00 alle 7:00 del mattino circa, su questo server vengono eseguite alcune richieste di backup di grandi dimensioni. Durante questo periodo, un utilizzo della CPU pari a 10 (con 20 core) è del tutto normale. Nel resto del tempo, anche un carico pari a 3 potrebbe essere sospettosamente alto.
In Checkmk hai diverse possibilità per implementare questo esempio. Una di queste è definire prima i periodi di tempo con i vari carichi di lavoro e poi impostare valori di soglia specifici per questi orari. Nel nostro esempio, questo significa definire prima un nuovo periodo di tempo per il periodo con carico elevato (dal lunedì al venerdì dalle 0:00 alle 7:00). Poi puoi specificare una regola per il servizio (CPU load o Processor Queue). Seleziona questo nuovo periodo di tempo e imposta valori di soglia diversi (più alti) per esso.
L'uso di un periodo di tempo ha il vantaggio di rendere sempre facile capire perché si è verificato uno stato WARN / CRIT in un determinato momento. Tuttavia, il collegamento manuale dei valori di soglia ai periodi di tempo è anche piuttosto rigido e a volte semplicemente troppo complicato.
Se stai utilizzando una delle edizioni commerciali, c'è un altro modo per risolvere questo problema.
Si chiama monitoraggio basato sulla previsione e consiste nel valutare i dati per ricavarne una previsione su come si comporteranno in futuro.
Una volta impostata, la previsione non rimane statica, ma si adatta alla realtà che cambia nel tempo: la previsione di oggi per dopodomani non rimarrà invariata, perché i valori reali di domani saranno stati inclusi per dopodomani. Senza fare viaggi nel tempo (che fatica!), il processo può essere espresso anche in questo modo: Checkmk impara continuamente. Poiché i valori di soglia per gli stati "WARN" e "CRIT" sono sempre impostati in relazione ai valori di previsione, anche i valori di soglia si adattano insieme alla previsione.
2. Implementazione del monitoraggio basato sulla previsione
2.1. Dal nome del plug-in al parametro di previsione
Tutta una serie di plug-in di Checkmk supporta il monitoraggio basato sulla previsione. Di seguito troverai alcuni esempi importanti:
Le impostazioni per il monitoraggio basato sulla previsione si trovano nello stesso posto in cui si impostano le soglie per un servizio. Lì troverai l'opzione "Predictive levels (only on CMC)", se la funzione in questione la supporta.
2.2. Creazione di una regola per il monitoraggio basato sulla previsione
Per il servizio "CPU load" sull'host Linux del nostro esempio, puoi creare una nuova regola con il set di regole "CPU load (not utilization!)" in "Service monitoring rules", che puoi trovare più rapidamente cercando nel menu di configurazione.
Nella sezione Value troverai i parametri al livello del servizio per i quali puoi selezionare il valore Predictive levels (only on CMC):
2.3. Selezione dei valori di riferimento passati
Dopo aver selezionato "Predictive levels (only on CMC)", vengono visualizzati i parametri, di cui presenteremo prima i primi due in modo più dettagliato:
Con "Base prediction on" definisci la periodicità con cui è prevista la ripetizione dei dati misurati (mensile, settimanale, giornaliera o oraria):
Day of the month: i valori misurati di ogni giorno del mese vengono confrontati tra loro, ovvero il 1°, il 2°, il 3° ecc. di ogni mese.
Day of the week: Il confronto si basa sui giorni della settimana, cioè viene effettuata una previsione diversa per ogni giorno della settimana (lunedì, martedì, mercoledì, ecc.). Di solito questa è l'impostazione corretta.
Hour of the day: Vengono confrontate le singole ore di ogni giorno, cioè la previsione viene ripetuta ogni giorno.
Minute of the hour: Il confronto su base minutaria e la ripetizione oraria sono solitamente utili solo per testare una previsione.
Nel parametro successivo Time horizon inserisci fino a quanti giorni nel passato Checkmk deve valutare i dati di misurazione. Checkmk accede ai dati storici memorizzati nei file RRD. Sebbene i dati di misurazione nei file RRD vengano conservati per 4 anni, non ha senso risalire troppo indietro nel tempo. Da un lato, i valori tipici del passato recente potrebbero differire da quelli del passato più lontano.
D'altra parte, più si va indietro nel tempo, meno dati misurati per unità di tempo ci sono a disposizione per il confronto. Questo perché, per impostazione predefinita, Checkmk comprime i dati misurati disponibili per ogni minuto nei file RRD in tre fasi per risparmiare spazio: dopo 2, 10 e dopo 90 giorni. Compressione significa che il minimo, il massimo e la media vengono calcolati da più dati di misurazione e questi dati calcolati sostituiscono quelli misurati originariamente. Se i dati misurati degli ultimi due giorni sono disponibili con la risoluzione completa di 1 minuto, la risoluzione diventa di 5 minuti dopo 2 giorni, 30 minuti dopo 10 giorni e 6 ore dopo 90 giorni. Quando Checkmk accede ai dati storici per il monitoraggio basato sulla previsione, viene sempre preso il valore massimo tra i tre memorizzati.
Per il nostro server di esempio con un carico di lavoro elevato dalle notti di lunedì a venerdì, è consigliabile selezionare il periodo di riferimento settimanale e un periodo di tempo di riferimento di (massimo) 90 giorni. 90 giorni sono un compromesso accettabile, poiché da un lato questo intervallo contiene abbastanza giorni di confronto, mentre dall’altro i dati di misurazione sono ancora disponibili con una risoluzione di 30 minuti — a condizione che i valori predefiniti non siano stati modificati.
Seleziona come "Base prediction on" la voce "Day of the week" e inserisci come "Time horizon" "90", come mostrato nell'immagine sopra.
Impostando il periodo di riferimento settimanale su un intervallo di 90 giorni nel passato, Checkmk dispone delle informazioni necessarie per calcolare la curva di riferimento. Questo comporta la valutazione di ogni lunedì nel periodo di tempo (per 90 giorni ci sono 12 lunedì), il confronto del valore misurato di ogni lunedì con i valori misurati degli altri lunedì alla stessa ora e il calcolo della media. Dopo il lunedì, Checkmk handle gli altri giorni della settimana, dal martedì alla domenica, allo stesso modo. La curva di riferimento così calcolata per il passato viene poi aggiornata e diventa quindi la curva di riferimento prevista per il futuro.
 |
I valori utilizzati per calcolare la media per il periodo di riferimento potrebbero essere essi stessi valori già calcolati (cioè non misurati) — a seconda della risoluzione dei dati storici nei file RRD. |
La curva di riferimento calcolata da Checkmk sulla base dei due parametri definiti finora (periodo di riferimento e periodo di tempo di riferimento) è rappresentata come una linea nera nell'immagine seguente:
Come anteprima, questa immagine mostra il grafico di previsione, che potrai visualizzare una volta completato il Setup. Oltre alla curva di riferimento nera, i valori attuali vengono visualizzati come una linea blu — se sono disponibili nel periodo di tempo visualizzato.
Ciò che manca per completare il Setup sono le definizioni dei valori di soglia per gli stati "WARN" e "CRIT", contrassegnati nel grafico con sfondi di colore giallo e rosso. La sezione seguente tratta della definizione di queste soglie.
2.4. Definizione delle soglie per la previsione
Puoi definire i valori di soglia per WARN e CRIT in base ai valori di previsione mostrati nella curva di riferimento.
Per illustrare l'effetto dei diversi valori dei parametri utilizzati per definire le soglie, diamo un'occhiata da vicino a un singolo valore sulla curva di riferimento. Supponiamo che il valore previsto del servizio CPU load sia 10 alle 3:30 del mattino di venerdì.
Per le soglie superiori c'è il parametro Dynamic levels — upper bound, mentre per quelle inferiori c'è Dynamic levels — lower bound. Per entrambi i parametri hai tre opzioni, descritte nelle tre sezioni seguenti.
Differenza assoluta dalla previsione
Con questo valore le soglie vengono calcolate aumentando o diminuendo il valore della previsione di un valore assoluto fisso.
Esempio: Warning at 2.0 farà sì che venga visualizzato un avviso se il valore è superiore a 12 e inferiore a 8.
Differenza relativa rispetto alla previsione
Con questo valore le soglie vengono calcolate aumentando o diminuendo il valore della previsione di una percentuale.
Esempio: Warning at 10.0 % farà apparire un avviso se il valore è superiore a 11 e inferiore a 9.
In relazione alla deviazione standard
Con questo valore le soglie vengono calcolate aumentando o diminuendo il valore previsto di un multiplo della deviazione standard. La deviazione standard indica di quanto differiscono i valori in un periodo di riferimento (ad es. il venerdì alle 3:30 del mattino).
Con questa opzione il calcolo dei valori di soglia non è così facile da prevedere, perché Checkmk calcola internamente la deviazione standard da tutti i valori misurati del periodo di riferimento. Per illustrare l’effetto, abbiamo bisogno di maggiori informazioni sulle 12 misurazioni del periodo di riferimento il venerdì alle 3:30 del mattino: Supponiamo che 10 misurazioni siano pari a 10, una sia 11 e una sia 9. Le 12 misurazioni hanno quindi un valore medio di 10 (che corrisponde al valore previsto), una varianza di circa 0,167 e una deviazione standard di circa 0,41. (Qui tralasciamo i dettagli del calcolo, ma puoi consultare varie pagine di statistica su internet.)
Esempio: Warning at 1.0 come multiplo della deviazione standard farà sì che venga visualizzato un avviso se il valore è superiore a 10,41 e inferiore a 9,59.
Per evitare stati indesiderati di WARN / CRIT, non vengono applicate soglie se la deviazione standard è indefinita (ad esempio perché c'è un solo valore misurato nel periodo di riferimento) o è pari a zero (se tutti i valori misurati sono identici).
In generale, vale la seguente regola: più i valori del passato sono coerenti, minore è la deviazione standard e più rigorosa è la previsione. Questa opzione è quindi utile per definire soglie più ristrette per un periodo di riferimento con valori stabili e uniformi.
Valori minimi delle soglie superiori
Infine, con l'opzione "Limit for upper bound dynamic levels" hai la possibilità di impostare valori minimi assoluti per i valori di threshold superiori. Questo ti permette di evitare stati indesiderati di "WARN" / "CRIT" nei momenti in cui le previsioni sono molto basse.
Esempio: un valore di Warning level di 2.0 farà sì che venga visualizzato un avviso solo se il valore è superiore a 2, anche se il threshold superiore per un avviso è 1,5.
Grafico di previsione con valori di threshold
Gli effetti descritti come esempio per un valore vengono calcolati da Checkmk per tutti i valori sulla curva di riferimento. Puoi vedere il risultato nel grafico di previsione, che verrà descritto più dettagliatamente nel prossimo capitolo. Il grafico mostra le curve per i valori di soglia superiore e inferiore sopra e sotto la curva di riferimento. Le aree per WARN sono colorate in giallo e quelle per CRIT in rosso.
Dovresti controllare attentamente gli intervalli per WARN e CRIT nel grafico di previsione, specialmente se hai le soglie calcolate dalla deviazione standard, poiché i valori alla base della deviazione standard non possono essere letti direttamente dall’interfaccia utente di Checkmk. Controllando e, se necessario, regolando i livelli, puoi evitare che il servizio assuma involontariamente troppo spesso gli stati WARN o CRIT.
Questo completa l'implementazione del monitoraggio basato sulla previsione. Nel prossimo capitolo imparerai come osservare il Setup nel monitoraggio e come visualizzare il grafico della previsione.
3. Analisi delle previsioni
Se hai configurato il monitoraggio basato sulla previsione per un servizio, attiva le modifiche e, una volta che Checkmk avrà eseguito un controllo per questo servizio, nell'elenco dei servizi apparirà il nuovo simbolo 
:
|
Soprattutto dopo il Setup iniziale di un servizio, questo simbolo potrebbe non essere presente perché non ci sono dati sufficienti per la previsione configurata.
In questo caso, nella colonna "Summary" viene visualizzato un messaggio del tipo " |
Clicca su "" nell'elenco dei servizi e verrà visualizzata una rappresentazione grafica del periodo di tempo di previsione corrente — il grafico di previsione:
Nel grafico di previsione vedrai la curva di riferimento come una linea nera, i valori attuali come una linea blu e gli intervalli per gli stati "OK" in bianco, per "WARN" in giallo e per "CRIT" con uno sfondo rosso.
L'intervallo di tempo visualizzato si basa sul periodo di riferimento selezionato. Ad esempio, se hai un periodo settimanale, puoi visualizzare i singoli giorni della settimana e utilizzare l'elenco a discesa sopra il grafico per switchare a un altro giorno. Con la voce speciale dell'elenco "Everyday", il grafico ti mostrerà i valori medi per tutti i giorni per i quali sono disponibili i dati.
Nel grafico di esempio si notano l'elevato utilizzo della capacità durante la notte e il basso utilizzo durante il giorno. Dalle 0:00 alle 04:00, i valori attuali (linea blu) sono inferiori alla curva di riferimento della previsione (linea nera) — talmente bassi che i valori di soglia inferiori venivano periodicamente scavalcati, innescando stati di "WARN" / "CRIT". È visibile anche l'intervallo tra le 08:30 e le 23:30, quando la linea blu si trova costantemente nell'intervallo di sottoCRITe. Questo stato potrebbe essere evitato in futuro impostando valori più alti per le soglie inferiori.
Infine, il grafico mostra che le soglie superiori si basano sulla deviazione standard, poiché tra le 05:00 e le 07:30 le soglie superiori tendono ad aumentare mentre i valori nella curva di riferimento diminuiscono. Questo comportamento può essere spiegato solo dalla deviazione standard, poiché le altre due opzioni (valore assoluto e percentuale) avrebbero portato a un aggiustamento dei valori di soglia nella direzione della curva di riferimento.
|
Come per la configurazione iniziale, qualsiasi modifica al monitoraggio basato sulla previsione diventerà effettiva solo dopo un nuovo check del servizio.
Non è necessario attendere il prossimo controllo regolare, ma è possibile avviarne uno manualmente dall'elenco dei servizi con l'icona " |
