Business Intelligence (BI)

Prima di iniziare a lavorare passo dopo passo all'applicazione pratica della BI, è necessario conoscere alcuni termini:

Ogni applicazione formalizzata con la BI è chiamata Aggregazione, poiché uno stato generale è aggregato da molti stati individuali.

Un'aggregazione è costruita come un "albero" di oggetti. I nodi inferiori - le foglie dell'albero - sono gli host e i servizi delle tue istanze Checkmk. I nodi rimanenti sono oggetti BI creati artificialmente.

Ogni nodo è creato da una regola. Questo vale anche per la radice dell'albero, il nodo più alto. Queste regole determinano quali nodi si trovano sotto un altro nodo e come determinare, a partire dai loro stati, lo stato del nodo superiore.

Anche il nodo superiore di un'aggregazione - la radice dell'albero - viene generato con una regola. In questo modo una regola può generare più aggregazioni.

Il modo più semplice per capirlo è utilizzare un esempio concreto. Per questo articolo abbiamo pensato a una "applicazione misteriosa". Supponiamo che si tratti di un'applicazione importante in un'azienda non specificata. Tra le altre cose, cinque server e due switch di rete svolgono un ruolo importante. Per farti capire meglio l'esempio, utilizziamo nomi semplici come srv-mys-1 o switch-1. Il diagramma seguente offre una panoramica della struttura:

Se vuoi eseguire i passaggi seguenti uno alla volta, puoi semplicemente replicare gli oggetti di monitoraggio come mostrato nel nostro esempio. Per un test è sufficiente clonare più volte un host esistente e nominare i cloni di conseguenza. In seguito dovrai aggiungere alcuni servizi, per i quali avrai il tempo di registrare i relativi host nel monitoraggio. Anche in questo caso puoi imbrogliare: con semplicicheck locali fittizi otterrai rapidamente servizi corrispondenti con cui giocare.

Gli host avranno quindi un aspetto simile a questo nel monitoraggio:

Inizia con qualcosa di semplice, con l'aggregazione più semplice possibile: un'aggregazione con solo due nodi. Vuoi riassumere gli stati degli host switch-1 e switch-2. L'aggregazione dovrebbe chiamarsi Rete e dovrebbe essere OKse entrambi gli switch sono disponibili. In caso di guasto parziale, dovrebbe passare aWARN e, se entrambi gli switch sono spenti, a CRIT.

Iniziare: configurare la BI tramite Setup > Business Intelligence > Business Intelligence.La configurazione delle regole e delle aggregazioni viene eseguita all'interno dei pacchetti di configurazione - i pacchetti BI. I pacchetti non sono solo pratici perché con essi puoi gestire meglio le configurazioni più complesse: puoi anche applicare dei permessi a un pacchetto e assegnare a determinati gruppi di contatto - e persino consentire agli utenti senza diritti di amministrazione - i permessi per modificare parti della configurazione. Ma di questo parleremo più avanti...

La prima volta che richiami il modulo BI, il risultato dovrebbe essere questo:

È già presente un pacchetto intitolato Default Pack che contiene una demo per un'aggregazione che riassume i dati di un singolo host.

Per questo esempio è meglio creare un nuovo pacchetto - con il pulsante Add BI Pack - che chiamerai Mystery. Come sempre in Checkmk, specifica un ID interno (mystery) che non può essere modificato in seguito e un titolo descrittivo. L'opzione Public è necessaria per gli altri utenti che desiderano utilizzare le regole di questo pacchetto per le proprie regole o aggregazioni. Poiché probabilmente vuoi fare i tuoi esperimenti da solo in tutta tranquillità, lascia questa opzione disabilitata:

Dopo la creazione, troverai due pacchetti nell'elenco principale:

Ogni voce è accompagnata da un simbolo per modificare le proprietà () e da un simbolo per accedere al contenuto vero e proprio del Pacchetto (), che è il punto in cui vuoi andare ora. Una volta lì, crea subito la tua prima regola tramite Add rule.

Come sempre in Checkmk, anche questa regola deve avere un ID unico e un titolo. Il titolo della regola non ha solo una funzione di documentazione, ma in seguito sarà visibile anche come nome del nodo creato da questa regola:

Il box successivo si chiama Child Node Generation ed è il più importante. Qui specifichi quali oggetti di questo nodo devono essere riassunti. Possono essere altri nodi BI - per i quali sceglierai una regola BI diversa - oppure oggetti di monitoraggio, ad esempio host o servizi.

Per il primo esempio, seleziona la seconda variante (State of a host) e crea due oggetti come figli, ovvero i due host switch-1e switch-2. Questo si fa con il pulsante Add child node generator. Qui scegli naturalmente State of a host e inserisci un nome per ogni host:

Nel terzo e ultimo box, Aggregation Function, specifica come deve essere calcolato lo stato di monitoraggio del nodo. La base è sempre l'elenco degli stati dei sotto-nodi. Sono possibili diversi collegamenti logici.

La casella pre-selezionata è Best — take best of all node states. Ciò significa che il nodo diventa CRIT quando tutti i sottonodi sono CRIT o DOWN. Come già detto, questo non dovrebbe essere il caso. Scegli inveceCount the number of nodes in state OK per ottenere come parametro di riferimento il numero di sottonodi con statoOK. In questo caso vengono suggeriti i numeri 2 e 1 per le soglie, il che è ottimo perché è esattamente ciò di cui hai bisogno:

Ecco come apparirà la maschera compilata:

Con un clic su Create otterrai la tua prima regola:

Ora è importante capire che una regola non è ancora un'aggregazione. Checkmk non è ancora in grado di sapere se si tratta di tutto o solo di una parte di un albero più grande! I veri oggetti BI vengono creati e diventano visibili nell'interfaccia di stato solo quando crei un'aggregazione. Per farlo, passa all'elenco delle aggregazioni.

Il pulsante ti porta a una maschera per la creazione di una nuova aggregazione. Qui c'è poco da compilare. Nel sito Aggregation groups puoi specificare qualsiasi nome a tua scelta. Questi nomi appaiono nell'interfaccia di stato come gruppi, sotto i quali sono visibili tutte le aggregazioni che condividono il nome del gruppo. In realtà si tratta dello stesso concetto degli hashtag o delle keyword.

Definisci il contenuto dell'aggregazione tramite Add new element.Seleziona il set di regole Call a rule e Rule: la regola che hai appena creato (e prima ancora il pacchetto di regole in cui si trova).

Se ora salvi l'aggregazione con , il gioco è fatto: la tua prima aggregazione dovrebbe apparire nell'interfaccia di stato, a patto che tu abbia almeno uno degli host switch-1 o switch-2!

Se hai fatto tutto correttamente, ora potrai vedere la tua prima aggregazione nell'interfaccia di stato. Il modo più semplice per farlo è tramite Monitor > Business Intelligence > All Aggregations:

Dai un'occhiata più da vicino all'aspetto dell'albero della BI. L'esempio seguente mostra la mini-aggregazione in una situazione in cui uno dei due switch èDOWN e l'altro UP. Come desiderato, l'aggregazione entra nello stato WARN:

Puoi anche vedere che per standardizzare gli host e i servizi, l'host DOWN viene trattato quasi come un servizio CRIT. Allo stesso modo UP diventa OK.

Le foglie dell'albero mostrano gli stati degli host e dei servizi. Il nome dell'host - e per i servizi anche il nome del servizio - è cliccabile e ti porta allo stato attuale dell'oggetto corrispondente. Inoltre, puoi anche vedere l'ultimo output del plug-in di controllo.

A sinistra di ogni aggregazione troverai due simboli: e . Con il primo simbolo - - si accede a una pagina che mostra solo quella singola aggregazione. Questa è naturalmente utile soprattutto se hai creato più di un'aggregazione. Ad esempio, è molto adatta come segnalibro. ti porterà al calcolo della disponibilità. Maggiori informazioni in seguito.

A sinistra del nome host troverai un simbolo interessante: . Questo permette di effettuare un'analisi "e se?". L'idea alla base è semplice: cliccando sul simbolo, l'oggetto passerà a un altro stato come test - ma solo per l'interfaccia BI - NON per la realtà! Più switch ti porteranno da (OK) a(WARN), (CRIT) e(SCONOSCIUTO), per poi tornare a .

La BI costruisce quindi l'albero completo in base allo stato ipotizzato. La figura seguente mostra l'aggregazione minima nell'ipotesi che accanto aswitch-1, che si è effettivamente guastato, anche switch-2 sia DOWN:

Lo stato complessivo dell'aggregazione passa quindi da WARN a CRIT. Allo stesso tempo, il colore dello stato è supportato da un modello controllato. Questo schema indica che lo stato reale è effettivamente diverso. Non è sempre così, perché alcuni cambiamenti in un host o in un servizio non sono più rilevanti per la condizione generale, ad esempio se il servizio in questione è già CRIT.

Puoi utilizzare questa analisi "e se?" in diversi modi, ad esempio:

In quest'ultimo caso, come test imposta il dispositivo da manutenere o i suoi servizi su . Se l'intera aggregazione rimane OK, significa che il guasto può essere attualmente compensato dalla ridondanza.

Esiste un altro modo per testare le aggregazioni BI: cambiando direttamente lo stato reale di un oggetto. Questo è particolarmente pratico in un sistema di test.

A questo scopo, i comandidispongono di un comando host/servizio chiamato Fake check results. Per impostazione predefinita è disponibile solo per il ruolo di Amministratore. Questo metodo è stato utilizzato, ad esempio, per la creazione delle schermate utilizzate in questo articolo dove switch-1è stato impostato su DOWN. È da qui che proviene il testo rivelatoreManually set to Down by cmkadmin.

Ecco un piccolo suggerimento utile: se utilizzi questo metodo, è meglio disabilitare i check attivi per gli host e i servizi in questione, altrimenti al prossimo intervallo di controllo torneranno immediatamente al loro stato attuale. Se sei pigro, fallo a livello globale tramite l'elemento della barra laterale Master Control. Ma non dimenticare MAI di riattivarlo in seguito!

Durante la creazione dell'aggregazione abbiamo affrontato brevemente le possibilità dell'input Aggregation Groups. Nell'esempio hai semplicemente confermato l'elemento Main suggerito qui. Naturalmente sei completamente libero nell'assegnazione dei nomi e puoi anche assegnare un'aggregazione a più gruppi.

I gruppi diventano importanti quando il numero di aggregazioni è superiore a quello che puoi vedere su una schermata. Puoi accedere a un gruppo cliccando su uno dei nomi dei gruppi visualizzati nella pagina All aggregations - nell'esempio precedente si tratta semplicemente dell'intestazione Main. Naturalmente, se finora hai solo questa singola aggregazione non cambierà molto. Tuttavia, se guardi attentamente, te ne renderai conto:

Se vuoi visitare questa visualizzazione più spesso, ti basterà metterla tra i preferiti, preferibilmente con l'elemento Bookmarks nella barra laterale.

Una volta impostate le aggregazioni BI, nel menu contestuale dei tuoi host e servizi troverai un nuovo simbolo:

Questo simbolo ti porta all'elenco di tutte le aggregazioni in cui è incluso l'host o il servizio in questione.

Ora che hai un albero un po' più interessante puoi avvicinarti alle varie opzioni di visualizzazione offerte da CMK. Il punto di partenza è il sito Modify display options, al quale puoi accedere tramite il menu Display. Si apre un box con varie opzioni il cui contenuto è sempre conforme agli elementi mostrati nella pagina. Nel caso della BI sono attualmente disponibili quattro opzioni:

Infine, puoi impostare un Refresh interval di 30, 60 o 90 secondi e specificare il numero di colonne tramite Entries per row.

Dalla versione 1.6.0, oltre alle rappresentazioni tabellari Checkmk padroneggia anche la visualizzazione delle aggregazioni BI. Puoi visualizzare le aggregazioni da una nuova prospettiva, a volte più chiara. Troverai il sitoBI Visualization nella normale visualizzazione delle aggregazioni.

Puoi spostare liberamente l'albero cliccando sullo sfondo e scalare l'intera visualizzazione con la rotella del mouse. Non appena il puntatore del mouse si trova su un singolo nodo, ottieni le informazioni sullo stato associato al nodo tramite una finestra hover. Usa la rotella del mouse per scalare la lunghezza dei rami dell'albero.

Facendo clic sui nodi laterali si accede direttamente alle visualizzazioni dettagliate dell'host o del servizio. Cliccando con il tasto destro del mouse sugli altri nodi, a seconda del tipo di nodo, puoi accedere alle opzioni di visualizzazione e, ad esempio, alla regola responsabile -Edit rule nell'immagine seguente.

Continuiamo con la configurazione. Finora l'esempio è stato così semplice che è stato possibile elencare singolarmente tutti gli oggetti dell'aggregazione senza difficoltà. Ma se le cose si fanno più complesse? Se vuoi formulare molte dipendenze ricorrenti uguali o simili? Se un'applicazione non include una sola istanza, ma più istanze? Se vuoi unire centinaia di servizi individuali di un database in un unico nodo BI?

Ebbene, per queste esigenze hai bisogno di metodi di configurazione più potenti, che sono esattamente ciò che distingue Checkmk BI da altri strumenti - e purtroppo in questo caso la curva di apprendimento è un po' più ripida. Questo è anche il motivo per cui Checkmk BI non permette di essere configurato tramite "trascinamento". Tuttavia, una volta che ne conoscerai le possibilità, non vorrai più farne a meno.

Prendiamo la seguente situazione: non solo vuoi sapere se i due switch sono UP, ma vuoi anche conoscere lo stato delle due porte responsabili dell'uplink. In termini generali, si tratta dei seguenti quattro servizi:

Ora il nodo Switch 1 & 2 deve essere esteso per sostituire i due stati host degli switch 1 e 2, in modo che ognuno di essi abbia un sottonodo che mostri lo stato host e le due interfacce di uplink. Questi due sottonodi dovrebbero essere Switch 1 o Switch 2.

In realtà hai bisogno di due nuove regole, una per ogni switch. È meglio creare una nuova regola <switch> e dotarla di un parametro. Questo parametro è una variabile che viene richiamata quando si richiama la regola dal nodo padre - che in questo caso può essere fornito dalla vecchia regola Switch 1 & 2. In questo esempio puoi semplicemente passare un 1 o un 2. Il parametro riceve un nome che puoi scegliere liberamente. Prendiamo ad esempio il nome NUMBER. L'ortografia con le lettere maiuscole è puramente arbitraria e se trovi più belle le lettere minuscole sei libero di usarle.

L'intestazione della regola avrà questo aspetto:

Puoi scegliere switch come ID della nuova regola. In parameterinserisci semplicemente il nome della variabile: NUMBER. È importante che la variabile venga utilizzata nella regola Rule Title, in modo che entrambi i nodi non vengano chiamati solo switch e quindi abbiano lo stesso nome. Quando si utilizza la variabile, viene impostato un segno di dollaro iniziale e finale, come di consueto in molti punti di Checkmk. Di conseguenza, i due nodi si chiameranno Switch 1 eSwitch 2.

L'argomento delle espressioni regolari merita ancora una volta un'analisi più approfondita. Quando si tratta di abbinare il nome del servizio, all'inizio abbiamo tacitamente sottinteso che si tratta fondamentalmente solo di espressioni regolari. Come appena detto, esiste un match parola (prefisso).

Quindi, in un nodo BI, se ad esempio alla voce nome del servizio specifichi disk, tutti i servizi dell'host in questione che iniziano con Diskverranno catturati.

In generale si applicano i seguenti principi:

Forse ti sembra un po' azzardato! Non è pericoloso omettere silenziosamente cose che dovrebbero essere presenti se mancano?

Beh, con il tempo ti accorgerai di quanto sia pratico questo concetto, perché ti permetterà di scrivere regole "intelligenti" in grado di reagire a situazioni molto diverse. C'è un servizio che non è presente in ogni istanza di un'applicazione? Non c'è problema: viene considerato solo se c'è! Oppure è possibile rimuovere temporaneamente host o servizi dal monitoraggio? In questo caso, questi spariscono semplicemente dalla BI senza causare errori o simili. La BI non è lì per vedere se la configurazione del monitoraggio è completa!

Per inciso, questo principio si applica anche ai servizi definiti esplicitamente, in quanto questi non esistono realmente perché i nomi del servizio vengono sempre visualizzati come espressioni regolari anche se non contengono caratteri speciali come .*. Si tratta sempre automaticamente di un modello di ricerca.

Ma puoi comunque automatizzare ulteriormente e, soprattutto, reagire in modo flessibile ai cambiamenti. Continua con l'esempio dei due server applicativisrv-mys-1 e srv-mys-2 dell'esempio. L'albero dovrebbe continuare a crescere. Il nodo Infrastructure dovrebbe passare al livello 2. E come radice definitiva, dovrebbe esserci una regola con il titolo The Mystery Application sotto la quale tutto sarà sospeso. Accanto a Infrastructure dovrebbe esserci un nodo chiamato Mystery Servers. Sotto di esso dovrebbero essere sospesi i due server misteriosi (attualmente). In ognuno di essi vengono aggregati alcuni servizi generici. Il risultato dovrebbe essere simile a questo:

Come per la ricerca di host figlio, esiste anche un tipo di generatore figlio chiamatoCreate nodes based on a service search. Ecco un esempio:

In questo caso puoi utilizzare () - parentesi di espressioni parziali - sia per l'host che per il servizio, dove:

E non dimenticare che puoi sempre utilizzare l'aiuto inline.

Nei tuoi tentativi potresti esserti imbattuto nel generatore di figliState of remaining services. Questo genera un nodo per tutti i servizi del tuo host che non sono ancora stati ordinati nell'aggregazione BI. Questo è utile se utilizzi la BI per combinare gli stati di tutti i servizi di un host in gruppi chiaramente ordinati, come avviene nell'esempio incluso.

Per tutte le azioni di modifica in BI, di solito è necessario avere il ruolo Administrator. Più precisamente, per BI ci sono due permessi, da trovare sotto Setup > Users > Roles & permissions:

Per impostazione predefinita, il ruolo User è solo il primo dei due permessi attivi. Gli utenti normali possono lavorare solo nei pacchetti di regole per i quali sono stati definiti come contatti. Questo avviene nei Dettagli del pacchetto di regole.

Nell'esempio seguente Permitted Contact Groups è stato autorizzato il gruppo di contatto The Mystery Admins: tutti i membri di questo gruppo possono quindi modificare le regole di questo pacchetto:

Inoltre, con Public > Allow all users to refer to rules contained in this packpuoi permettere ad altri utenti di utilizzare almeno le regole contenute in questo pacchetto, cioè di definire (altrove) le proprie regole, che possono essere richiamate come sotto-nodi.

Come funziona l'effettiva visibilità delle aggregazioni nell'interfaccia di stato? Quali contatti possono vedere qualcosa?

Non è possibile assegnare alcun diritto alle aggregazioni BI stesse, ma ciò avviene indirettamente attraverso la visibilità degli host e dei servizi ed è regolata dall'opzione See all hosts and services.Setup > Roles & Permissions:

Nel ruolo User, questo diritto è disabilitato per impostazione predefinita. Gli utenti normali possono vedere solo gli host e i servizi condivisi e in BI questi sono espressi in modo tale da poter vedere esattamente tutte le aggregazioni BI che contengono almeno un host o un servizio condiviso. Tali aggregazioni, tuttavia, contengono solo questi oggetti autorizzati e possono quindi essere in qualche modo "assottigliate". E questo significa che possono avere stati diversi per utenti diversi!

In caso di dubbio, puoi disattivare il permesso e, attraverso una deviazione via BI, permettere ad alcuni o a tutti gli utenti di vedere host e servizi per i quali non sono in contatto, garantendo così che lo stato di un'aggregazione sia sempre lo stesso per tutti.

Ovviamente questo problema è importante solo se ci sono aggregazioni così colorate che solo alcuni utenti sono contatti solo per alcune di esse.

Come fa la BI a gestire i tempi di manutenzione? Abbiamo riflettuto a lungo sulla questione e ne abbiamo discusso con molti utenti: il risultato è il seguente:

Per capire in base a quale regola BI calcola lo stato "in manutenzione", è utile ricordare qual è la vera idea alla base dei tempi di manutenzione:l'oggetto in questione è attualmente in lavorazione. Ci si può aspettare dei guasti. Anche se l'oggetto è attualmente OK, non devi fare affidamento su di esso. Può diventare CRIT in qualsiasi momento. Questo è noto e documentato, quindi non dovrebbe far scattare una notifica.

Questa idea può essere trasferita 1:1 nell'aggregazione BI: nell'aggregazione possono esserci alcuni host e servizi che sono attualmente in manutenzione. Il fatto che siano solo OK o CRIT non ha alcun ruolo, perché in realtà è una coincidenza se durante i lavori di manutenzione gli oggetti a volte si spengono e si riaccendono, oppure no. Il fatto che ci sia un oggetto di manutenzione nell'unità non significa immediatamente che l'applicazione che mappa l'aggregazione sia a sua volta "minacciata" e debba essere contrassegnata come "in manutenzione". Può anche avere una ridondanza installata che compensa il fallimento degli oggetti in manutenzione. Solo se un guasto di questo tipo porterebbe effettivamente a uno stato di CRIT per l'aggregazione - quindi non c 'è abbastanza ridondanza e l'aggregazione è davvero minacciata - solo allora Checkmk la contrassegnerà come "in manutenzione". Anche in questo caso lo stato attuale degli oggetti generalmente non ha importanza.

Per dirla in modo più conciso, la regola esatta è la seguente:

Se uno stato CRIT di un host/servizio comporta uno stato CRIT dell'aggregazione, uno stato "in manutenzione" di quell'host/servizio comporta uno stato "in manutenzione" dell'aggregazione.

Importante: il reale stato attuale degli host/servizi non ha alcun ruolo nel calcolo - ciò che è in manutenzione viene assunto come CRIT nella logica della BI. Perché? Perché uno stato UP o OK durante un periodo di manutenzione è una pura coincidenza, ad esempio se un host riporta UP per qualche secondo tra diversi riavvii.

Ecco un altro esempio. Per risparmiare spazio, questa è una variante con un solo server misterioso invece di due:

Innanzitutto, l'host switch-1 è in manutenzione. Per il nodo Infrastructure questo non ha alcun effetto, perché switch-2non è in manutenzione e quindi anche Infrastructure non è in manutenzione. Non c'è quindi alcun simbolo per i tempi di manutenzione derivati.

Ma anche il servizio Memory su srv-mys-1 è in manutenzione e non è ridondante. La manutenzione viene quindi ereditata dal nodo padre Mystery Server 1, poi continua fino a Mystery Serverse infine al nodo superiore The Mystery Application. Quindi anche questo nodo superiore è in manutenzione.

Abbiamo scritto sopra che non è possibile mettere manualmente in manutenzione un'aggregazione BI. Questo è vero solo a metà, perché in realtà è possibile trovare un comando per impostare i tempi di manutenzione nelle aggregazioni BI! Ma questo non fa altro che registrare una voce di manutenzione per ogni host e servizio dell'aggregazione! Questo ovviamente porta di solito a segnalare l'aggregazione stessa come in manutenzione, ma questo è solo indiretto.

Come hai visto sopra, il calcolo del tempo di manutenzione si basa su un presunto stato CRIT. Nelle proprietà di un'aggregazione puoi personalizzare l'algoritmo in modo che un nodo che assume lo stato WARN sia contrassegnato come in manutenzione. L'opzione per questo si chiama Escalate downtimes based on aggregated WARN state:

L'ipotesi di base rimane che gli oggetti in manutenzione siano CRIT. C'è solo una differenza quando, a causa della funzione di aggregazione, un CRIT può diventare un WARN, come nel nostro primo esempio con Count the number of nodes in state OK. In questo caso un tempo di manutenzione sarebbe già stato accettato se solo uno dei due switch fosse stato in manutenzione.

In modo del tutto simile al processo con i tempi di manutenzione, se un problema è stato confermato l'informazione viene calcolata automaticamente da BI. Questa volta lo stato degli oggetti gioca sicuramente un ruolo importante.

L'idea è quella di trasferire alla BI il seguente concetto: un oggetto ha un problema(WARN, CRIT), ma questo è noto e qualcuno ci sta lavorando ().

È possibile calcolare questo concetto per un'aggregazione nel modo seguente:

Tuttavia, se l'aggregazione dovesse rimanere WARN o CRIT, non verrebbe considerata come confermata, perché deve esserci almeno un problema importante che non è stato confermato e quindi lo stato OK verrà rimosso dall'unità.

A proposito, il programma offre un comando per far sì che l'aggregazione BI confermi i suoi problemi, ma questo significa solo che tutti gli host e i servizi rilevati nell'aggregazione saranno confermati (solo quelli che attualmente hanno problemi).

Utilizzare la funzione di congelamento è molto semplice: attiva l'opzione New aggregations are frozen in Aggregation Properties.

Questo congelerà l'aggregazione quando viene salvata e lo farà ogni volta che il segno di spunta viene impostato di nuovo, anche se l'aggregazione esisteva già in precedenza (nonostante il riferimento a New aggregations …​). Per sbloccare lo stato congelato, rimuovi il segno di spunta di conseguenza.

Nel monitoraggio, ora vedrai un nuovo simbolo a forma di fiocco di neve accanto all'aggregazione, che ti porterà alla visualizzazione delle differenze: a sinistra l'albero congelato, a destra l'albero attuale con le modifiche evidenziate (in questo caso la rimozione del servizio backup3):

Se vuoi congelare nuovamente lo stato corrente, puoi farlo tramite Commands > Freeze aggregations. Ma fai attenzione: Esiste sempre un solo stato corrente congelato e non esiste una cronologia che includa gli stati precedenti.

È possibile notificare i cambiamenti di stato delle aggregazioni BI? All'inizio non è possibile, poiché la BI esiste esclusivamente nella GUI e non ha alcuna relazione con lo stato di monitoraggio. Tuttavia, è possibile trasformare le aggregazioni BI in normali servizi, i quali possono a loro volta attivare delle notifiche. Ci sono due possibilità:

Inizieremo con il metodo del programma di origine dati, perché è sempre utile se desideri generare più di una manciata di aggregazioni come servizi. Troverai il set di regole appropriato alla voce Setup > Agents > Other integrations > BI Aggregations:

Qui puoi anche specificare diverse opzioni per quali host devono essere aggiunti i servizi. Non è necessario attenersi necessariamente all'host che esegue il programma di origine dati (Assign to the querying host). È anche possibile assegnare agli host che sono interessati dall'aggregazione (Assign to the affected hosts). Questo però ha senso solo se riguarda un solo host. Le espressioni regolari e le sostituzioni possono renderti ancora più flessibile con le assegnazioni. Il tutto viene poi eseguito tramite il meccanismo del piggyback.

Importante: se l'host a cui assegnerai questa regola deve continuare ad essere monitorato attraverso il normale agente, assicurati che nelle sue impostazioni vengano eseguiti i programmi agente e sorgente dati:

La notifica tramite active check è più o meno il metodo più diretto e non richiede un "check helper host" artificiale durante l'esecuzione del programma di origine dati, poiché deve interrogare ogni unità individualmente, ma con un numero elevato di aggregazioni è decisamente meno efficiente e anche più complicato da configurare.

In parole povere: Esiste un active check che può recuperare lo stato delle aggregazioni BI utilizzando HTTP dall'API REST di Checkmk. Puoi configurarlo facilmente con il set di regoleSetup > Services > Other services > Check State of BI Aggregation:

Nota quanto segue:

Nell'esempio è stato attivato Automatically track downtimes of aggregation. In senso stretto, questo significa i tempi di manutenzione programmata, quindi i tempi di manutenzione pianificati. In questo modo il nuovo servizio attivo otterrà automaticamente un tempo di manutenzione, anche se l'aggregazione BI fa lo stesso!

Il nuovo servizio mostra quindi, con un ritardo massimo di un intervallo di controllo, lo stato dell'unità. L'esempio mostra il BI-Check sull'host srv-mys-1:

Come al solito, puoi assegnare questo servizio ai contatti e utilizzarlo come base per le notifiche.