Business Intelligence (BI)

Prima di iniziare passo dopo passo con l'applicazione pratica della BI, devi prima conoscere alcuni termini:

Ogni applicazione formalizzata con BI viene chiamata aggregazione BI, poiché uno stato complessivo viene aggregato da molti stati individuali.

Un'aggregazione è costruita come un "albero" di oggetti. Questi oggetti sono chiamati nodi. I nodi finali — le foglie dell'albero — sono gli host e i servizi nelle tue istanze Checkmk. I nodi rimanenti sono oggetti BI creati artificialmente.

Ogni nodo viene creato da una regola. Questo vale anche per le radici dell'albero — il nodo di livello superiore. Queste regole determinano quali nodi sono in connessione con un altro nodo e come, a partire dai loro stati, si debba determinare lo stato dei nodi superiori.

Anche il nodo principale di un’aggregazione — la radice dell’albero — viene generato da una regola. In questo modo una regola può generare più aggregazioni.

Il modo più semplice per capirlo è usare un esempio concreto. Abbiamo creato l'applicazione Mystery appositamente come dimostrazione per questo articolo. Supponiamo che si tratti di un'applicazione importante in un'organizzazione non specificata. Tra le altre cose, cinque server e due switch di rete svolgono ruoli importanti. Per aiutarti a capire meglio il nostro esempio, useremo nomi semplici come srv-mys-1 o switch-1. Il diagramma seguente offre una semplice panoramica della struttura:

Se vuoi seguire i passaggi seguenti uno per uno, puoi semplicemente replicare gli oggetti di monitoraggio come mostrato nel nostro esempio. Per un test è sufficiente clonare più volte un host esistente e denominare i cloni di conseguenza. In seguito ci saranno alcuni servizi da aggiungere al gioco, per i quali avrai poi tempo di aggiungere gli host corrispondenti al monitoraggio. Anche lì puoi barare di nuovo: con semplici check locali otterrai rapidamente servizi che corrispondono con cui giocare.

Gli host appariranno quindi più o meno così nel monitoraggio:

Inizia con qualcosa di semplice — con l'aggregazione significativa più semplice possibile — un'aggregazione con solo due nodi. Vuoi quindi riassumere gli stati degli host switch-1 e switch-2. L'aggregazione dovrebbe chiamarsi Network e dovrebbe essere OK quando entrambi gli switch sono disponibili. In caso di guasto parziale, lo stato dovrebbe passare a WARN, e se entrambi gli switch sono spenti, CRIT.

Per iniziare: configura BI tramite Setup > Business Intelligence > Business Intelligence. La configurazione delle regole e delle aggregazioni BI viene eseguita all’interno dei pacchetti di configurazione, i pacchetti BI. Questi pacchetti non sono solo pratici perché ti permettono di gestire meglio configurazioni più complesse, ma puoi anche applicare permessi a un pacchetto e assegnare determinati gruppi di contatti, e persino consentire agli utenti senza diritti di amministratore di modificare parti della configurazione. Ma ne parleremo più avanti…​

La prima volta che chiami il modulo BI dovrebbe apparire qualcosa del genere:

È già presente un pacchetto intitolato Default Pack. Questo 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 potrà essere modificato in seguito, e un titolo descrittivo. L’opzione “Public” è necessaria agli altri utenti se in questo pacchetto ci sono regole che vogliono utilizzare per le loro regole o aggregazioni. Dato che probabilmente vorrai fare i tuoi esperimenti da solo in tutta tranquillità, lascia questa opzione disabilitata:

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

Accanto a ogni voce c'è un simbolo () per modificare le proprietà, e un simbolo per aprire il contenuto effettivo del pacchetto (), che è dove 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 univoco e un titolo. Il titolo della regola non ha solo una funzione di documentazione, ma in seguito sarà visibile anche come nome del nodo che verrà creato da questa regola:

La box successiva si chiama Child Node Generation ed è la più importante. Qui specifichi quali oggetti in questo nodo devono essere riepilogati. Può trattarsi di altri nodi BI — per i quali sceglieresti una regola BI diversa — oppure di oggetti sottoposti a monitoraggio, ovvero 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-1 e switch-2. Questo si fa con il pulsante Add child node generator. Qui ovviamente scegli State of a host e inserisci un nome per ogni host:

Nella terza e ultima box, Aggregation Function, specifichi come deve essere calcolato lo stato di monitoraggio del nodo. La base per questo è sempre l'elenco degli stati dei sottonodi. Sono possibili vari collegamenti logici.

L'impostazione predefinita è Best — take the best of all node states. Ciò significa che il nodo diventa CRIT quando tutti i sottonodi sono CRIT o DOWN. Come accennato sopra, in questo caso non dovrebbe essere così. Scegli invece Count the number of nodes in state OK per utilizzare come parametro di riferimento il numero di sottonodi con stato OK. Qui vengono suggeriti i numeri 2 e 1 come thresholds. Questo è ottimo perché è esattamente ciò di cui hai bisogno:

Ecco come apparirà il modulo una volta compilato:

Con un clic su Create avrai la tua prima regola:

Nota: è importante capire che una regola non è ancora un'aggregazione. Checkmk non può ancora sapere se si tratta di tutto o solo di una parte di un albero più grande. I veri oggetti BI verranno creati e diventeranno visibili nell'interfaccia di stato solo quando creerai un'aggregazione BI. Per farlo, switch all'elenco delle aggregazioni BI "".

Il pulsante "" ti porta a un modulo per creare una nuova aggregazione. Qui c'è poco da compilare. Nel campo "Aggregation groups" puoi specificare qualsiasi nome a tua scelta. Questi nomi appariranno poi nell'interfaccia di stato come gruppi, sotto i quali saranno visibili tutte le aggregazioni che condividono quel nome di gruppo. In realtà si tratta dello stesso concetto degli hashtag o delle keyword. Puoi anche assegnare liberamente l'Aggregation ID come al solito, ma non potrai cambiarlo in seguito.

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

Se ora salvi l'aggregazione con "", il gioco è fatto! La tua prima aggregazione dovrebbe ora apparire nell'interfaccia di stato, ammesso che tu disponga effettivamente di almeno uno degli host, switch-1 o switch-2.

Se hai fatto tutto correttamente, ora dovresti 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 BI. L'esempio seguente mostra la tua 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 notare che, per standardizzare host e servizi, l'host che è DOWN viene trattato quasi come un servizio che è CRIT. Allo stesso modo, UP diventa di conseguenza OK.

Le foglie dell'albero mostrano gli stati degli host e dei servizi. Il nome 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 arriva a una pagina che mostra solo quella singola aggregazione. Questo è naturalmente utile soprattutto se hai creato più di un’aggregazione. È, ad esempio, perfetto come segnalibro. ti porterà al calcolo della disponibilità. Ne parleremo più avanti.

A sinistra del nome host troverai un simbolo interessante: . Questa consente un'analisi "what if?". L'idea alla base è semplice: facendo clic sul simbolo, l'oggetto switcherà a un altro stato a titolo di test — ma solo per l'interfaccia BI — non nella realtà! Cliccando più volte passerai da (OK) a (WARN), (CRIT) e (SCONOSCIUTO) per poi tornare a .

BI costruisce quindi l'albero completo in base allo stato ipotizzato. Il grafico seguente mostra l'aggregazione minima partendo dal presupposto che, oltre a switch-1 che ha effettivamente fallito, anche switch-2 sia DOWN:

Lo stato complessivo dell'aggregazione passa quindi da WARN a CRIT. Allo stesso tempo, il colore dello stato è accompagnato da un motivo a quadretti. Questo motivo ti indica che lo stato reale è in realtà diverso. Non è sempre così, perché alcune modifiche in un host o in un servizio non sono più rilevanti per la condizione complessiva — ad esempio, se quello in questione è già CRIT.

Puoi utilizzare questa analisi "what if?" in diversi modi, ad esempio:

In quest'ultimo scenario, come test imposti il dispositivo da sottoporre a manutenzione o i suoi servizi su "". Se l'intera aggregazione rimane quindi "OK", significa che il guasto può essere attualmente compensato dalla ridondanza.

C'è un altro modo per testare le aggregazioni BI: modificando direttamente lo stato effettivo di un oggetto. Questo è particolarmente pratico in un sistema di test.

A questo scopo, i comandi dispongono di un comando host/servizio denominato Fake check results. Per impostazione predefinita, questo è disponibile solo per il ruolo di Amministratore. Questo metodo è stato utilizzato, ad esempio, per la creazione degli screenshot utilizzati in questo articolo, dove switch-1 è stato impostato su DOWN. Da qui deriva il testo rivelatore Manually set to Down by cmkadmin.

Ecco un piccolo suggerimento utile: Se lavori con questo metodo, è meglio disabilitare gli active checks per gli host e i servizi interessati, altrimenti al prossimo intervallo di controllo torneranno immediatamente al loro stato effettivo. Se sei pigro, fallo semplicemente a livello globale tramite lo snap-in Master Control. Ma non dimenticare mai di riattivarlo dopo!

Durante la creazione dell'aggregazione abbiamo accennato brevemente alle possibilità disponibili per l'input Aggregation Groups. Nell'esempio hai semplicemente confermato l'Maine suggerita qui. Ovviamente 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 supera quello che vuoi visualizzare su uno schermo. Puoi accedere a un gruppo cliccando su uno dei nomi dei gruppi visualizzati nella pagina "All aggregations" — nel nostro esempio sopra, semplicemente sull'intestazione "Main". Ovviamente, se finora hai solo questa singola aggregazione, non cambierà molto. Tuttavia, se guardi attentamente, ti accorgerai che:

Se vuoi visitare questa visualizzazione più spesso, basta aggiungerla ai preferiti — preferibilmente con l'elemento Bookmarks nella barra laterale.

Una volta configurate 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 un po' di più alle varie opzioni di visualizzazione offerte da Checkmk. Il punto di partenza sono le "Modify display options", a cui puoi accedere tramite il menu "Display". Si aprirà una box con varie opzioni. Il contenuto della box corrisponde sempre agli elementi visualizzati nella pagina. Nel caso della BI, al momento sono disponibili quattro opzioni:

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

Oltre alle rappresentazioni tabellari, Checkmk è in grado di gestire anche la visualizzazione delle aggregazioni BI. Puoi visualizzare le aggregazioni da una nuova prospettiva e, in alcuni casi, in modo più chiaro. Troverai l'BI Visualizatione tramite nella visualizzazione delle aggregazioni standard.

Puoi spostare liberamente l'albero cliccando sullo sfondo e ridimensionare l'intera visualizzazione utilizzando la rotella del mouse. Non appena il puntatore del mouse si trova sopra un singolo nodo, ottieni le informazioni sullo stato associate al nodo tramite una finestra a comparsa. Usa la rotella del mouse per ridimensionare la lunghezza dei rami dell'albero.

Cliccando sui nodi foglia si accede direttamente alle visualizzazioni dettagliate dell'host o del servizio. Un clic destro sugli altri nodi — a seconda del tipo di nodo — dà accesso alle opzioni di visualizzazione e, ad esempio, alla regola responsabile stessa — Edit rule nell'immagine qui sotto.

Continuiamo con la configurazione. Ora è il momento di mettersi davvero al lavoro. Finora l'esempio è stato così semplice che è stato possibile creare un elenco di tutti gli oggetti nell'aggregazione BI senza difficoltà. Ma cosa succede se le cose si complicano? Cosa succede se vuoi formulare molte dipendenze ricorrenti che sono uguali o simili? Cosa succede se un'applicazione include non una, ma più istanze? Cosa succede se dovessi voler unire centinaia di singoli servizi di un database in un unico nodo BI?

Per tali requisiti avrai bisogno di metodi di configurazione più potenti. E questi sono esattamente ciò che distingue Checkmk BI dagli altri strumenti — e purtroppo qui la curva di apprendimento è un po’ più ripida. È anche il motivo per cui Checkmk BI non si lascia configurare tramite “trascina”. Una volta che avrai scoperto le possibilità, però, non vorrai più farne a meno.

Cominciamo dai parametri. Prendiamo la seguente situazione: non vuoi solo sapere se i due switch sono UP, ma vuoi anche conoscere lo stato delle due porte responsabili dell'uplink. In generale, questo dipende dai seguenti quattro servizi:

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

In realtà ora avrai bisogno di due nuove regole: una per ogni switch. È meglio farlo creando una nuova regola switch e dotandola di un parametro. Questo parametro è una variabile che chiami quando chiami la regola dal nodo padre — che qui 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. Prendi qui, ad esempio, il nome NUMBER. L'ortografia con le lettere maiuscole qui è puramente arbitraria, e se trovi le lettere minuscole più belle sei libero di usare anche quelle.

L'intestazione della regola avrà quindi questo aspetto:

Puoi scegliere switch come ID per la nuova regola. In Parameters inserisci semplicemente il nome della variabile: NUMBER. È importante anche che la variabile venga utilizzata nell’Rule Titlee della regola, in modo che entrambi i nodi non si chiamino semplicemente switch e abbiano quindi lo stesso nome. Quando si utilizza la variabile, vengono inseriti un simbolo del dollaro all’inizio e alla fine, come è consuetudine in molti punti di Checkmk. Di conseguenza, i due nodi si chiameranno Switch 1 e Switch 2.

Vale la pena dare un'altra occhiata alle espressioni regolari. Quando abbiamo abbinato il nome del servizio all'inizio, abbiamo sottinteso che si trattasse fondamentalmente solo di espressioni regolari. Come appena detto, c'è una corrispondenza inizio parola (prefisso).

Quindi, in un nodo BI, se ad esempio sotto il nome del servizio specifichi disk, verranno catturati tutti i servizi dell’host in questione che iniziano con Disk.

In generale si applicano i seguenti principi:

Forse all’inizio ti sembrerà un po’ azzardato, perché non è rischioso omettere semplicemente, senza commenti, elementi che dovrebbero essere presenti?

Beh, col tempo noterai 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 esiste in tutte le istanze all'interno di un'applicazione? Nessun problema: verrà preso in considerazione solo se è presente. Oppure gli host o i servizi possono essere temporaneamente rimossi dal monitoraggio? In tal caso scompariranno semplicemente dal BI senza causare errori o simili. BI non serve a verificare se la tua configurazione di monitoraggio è completa!

A proposito: questo principio vale anche per i servizi definiti esplicitamente, poiché questi in realtà non esistono perché i nomi dei servizi sono 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 applicativi srv-mys-1 e srv-mys-2 dell'esempio. Il tuo albero dovrebbe continuare a crescere. Il nodo Infrastructure dovrebbe scivolare al livello 2. E come radice definitiva, dovrebbe esserci una regola con il titolo The Mystery Application sotto la quale sarà appeso tutto. Accanto a Infrastructure dovrebbe esserci un nodo chiamato Mystery Servers. I due server misteriosi (attualmente) dovrebbero essere appesi sotto questo nodo. In ciascuno di essi entrano nell'aggregazione alcuni servizi generici. Il risultato dovrebbe apparire così:

Analogamente alla ricerca dell'host, esiste anche un tipo di generatore figlio chiamato Create nodes based on a service search. Ecco un esempio:

Qui puoi usare () – racchiudendo espressioni parziali – sia a livello di host che di servizio, dove:

E non dimenticare mai che puoi sempre usare per ottenere l'aiuto in linea.

Nei tuoi tentativi potresti esserti imbattuto nel generatore di figli State of remaining services. Questo genera un nodo per qualsiasi servizio del tuo host che non sia stato ancora ordinato nella tua aggregazione BI. Questo è utile se usi BI per combinare gli stati di tutti i servizi di un host in gruppi chiaramente organizzati, come avviene nel nostro esempio incluso.

Torniamo ancora una volta ai pacchetti di regole. Per tutte le azioni di modifica in BI di solito devi avere il ruolo di amministratore. Più precisamente, per BI ci sono due permessi, che trovi in Setup > Users > Roles & permissions:

Nel ruolo utente di monitoraggio normale, solo il primo dei due permessi è attivo per impostazione predefinita. Gli utenti di monitoraggio normali possono quindi lavorare solo in quei pacchetti di regole per i quali sono stati definiti come contatto. Questo si fa in Dettagli del pacchetto di regole.

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

A proposito, con l'Public > Allow all users to refer to rules contained in this pack puoi consentire ad altri utenti almeno di utilizzare le regole qui contenute — ovvero di definire (altrove) le proprie regole — che possono poi richiamare queste regole come sottonodi.

Qual è la situazione riguardo alla visibilità effettiva delle aggregazioni nell'interfaccia di stato? Quali contatti sono autorizzati a vedere qualcosa?

Beh, non puoi assegnare alcun permesso nelle aggregazioni BI stesse. Questo viene fatto indirettamente attraverso la visibilità degli host e dei servizi, ed è regolato dall'opzione See all hosts and services in Setup > Roles & Permissions:

Nel ruolo "User", questa autorizzazione è disabilitata per impostazione predefinita. Gli utenti normali possono vedere solo host e servizi condivisi, e in BI questo si traduce nel fatto che possono vedere esattamente tutte le aggregazioni BI che contengono almeno un host o un servizio condiviso. Tali aggregazioni, tuttavia, contengono solo questi oggetti autorizzati e potrebbero quindi risultare un po' "svuotate". E questo a sua volta significa che possono avere stati diversi a seconda degli utenti.

Che questo sia un bene o un male dipende da ciò che desideri. In caso di dubbio puoi attivare il permesso e, passando per BI, consentire ad alcuni o a tutti gli utenti di vedere host e servizi per i quali non sono contatti — assicurandoti così che lo stato di un'aggregazione sia sempre lo stesso per tutti.

Ovviamente tutta questa questione ha importanza solo se ci sono effettivamente aggregazioni così eterogenee che solo alcuni utenti sono contatti solo per parti specifiche di esse.

In che modo BI gestisce effettivamente il tempo di manutenzione programmata dell'? Ci abbiamo riflettuto a lungo e ne abbiamo discusso con molti utenti: il risultato è il seguente:

Per capire con quale regola BI calcola lo stato "in downtime", è utile ricordare qual è la vera idea alla base delle tempe di manutenzione programmate: l'oggetto in questione è attualmente in fase di lavorazione. Sono prevedibili dei guasti. Anche se l'oggetto è attualmente "OK", non dovresti fare affidamento su di esso. Può diventare "CRIT" in qualsiasi momento. Questo è noto e documentato — non dovrebbe quindi attivare una notifica.

Questo concetto può essere trasferito 1:1 in BI: Nell'aggregazione BI potrebbero esserci alcuni host e servizi attualmente in tempo di manutenzione programmata. Che questi siano semplicemente OK o CRIT non ha importanza, perché in realtà è una coincidenza se durante i lavori di manutenzione gli oggetti a volte si spengono e si riaccendono, o meno. Solo perché nell'aggregazione c'è un oggetto in tempo di manutenzione programmata non significa immediatamente che l'applicazione che effettua la mappatura dell'aggregazione sia essa stessa "minacciata" e debba essere contrassegnata come "in tempo di manutenzione programmata". L'applicazione può anche avere una ridondanza installata che compensa il guasto degli oggetti in tempo di manutenzione programmata. Solo se tale guasto portasse effettivamente a uno stato di "CRIT" per l'aggregazione — quindi se non c'è abbastanza ridondanza e l'aggregazione è davvero a rischio — solo allora Checkmk la contrassegnerà come "in tempo di manutenzione programmata". Anche in questo caso, lo stato attuale degli oggetti in genere non ha importanza.

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

Se uno stato "CRIT" di un host/servizio comporterebbe uno stato "CRIT" dell'aggregazione, uno stato "in tempo di manutenzione programmata" di quell'host/servizio comporta uno stato "in tempo di manutenzione programmata" per l'aggregazione.

Importante: lo stato attuale reale degli host/servizi non ha alcun ruolo nel calcolo — ciò che è in tempo di manutenzione programmata viene considerato come "CRIT" nella logica BI. Perché? Perché uno stato "UP" o "OK" durante una manutenzione programmata è pura coincidenza, ad esempio se un host segnala "UP" per pochi secondi tra un riavvio e l'altro.

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

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

Tuttavia, anche il servizio Memory su srv-mys-1 è in tempo di manutenzione programmata. Questo non è ridondante. Il tempo di manutenzione programmata viene quindi ereditato dal nodo padre Mystery Server 1, per poi proseguire fino a Mystery Servers e infine al nodo principale The Mystery Application. Anche questo nodo principale sarà quindi in tempo di manutenzione programmata.

Abbiamo scritto sopra che non è possibile inserire manualmente un'aggregazione BI in un periodo di tempo di manutenzione programmata? Questo è vero solo a metà, poiché in realtà esiste un comando per impostare periodi di tempo di manutenzione programmata nelle aggregazioni BI. Ma questo non fa altro che registrare una voce di tempo di manutenzione per ogni host e servizio nell'aggregazione. Questo ovviamente porta solitamente a contrassegnare l'aggregazione stessa come inattiva, ma si tratta solo di una procedura indiretta.

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

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

In modo molto simile al processo con le tempistiche di manutenzione programmate, se un problema è stato confermato, l'informazione verrà calcolata automaticamente anche da BI. In questo caso lo stato degli oggetti gioca sicuramente un ruolo.

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

Puoi calcolarlo per un'aggregazione come segue:

Tuttavia, se l'aggregazione dovesse rimanere in stato "WARN" o "CRIT", allora non verrebbe considerata come confermata, perché in tal caso ci sarebbe almeno un problema importante che non è stato confermato, e quindi lo stato "OK" verrebbe rimosso dall'aggregazione.

A proposito, l' ti offrirà un comando per far sì che l'aggregazione BI riconosca i propri problemi, ma questo significa solo che tutti gli host e i servizi rilevati nell'aggregazione verranno riconosciuti (solo quelli che attualmente presentano problemi).

Usare la funzione di congelamento è molto semplice: Abilita l'opzione "New aggregations are frozen" in "Aggregation Properties".

Questo congelerà l'aggregazione al momento del salvataggio — 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.

Nel monitoraggio, vedrai ora un nuovo simbolo a forma di fiocco di neve "" accanto all'aggregazione. Questo ti porterà alla visualizzazione che mostra le 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 attuale, puoi farlo tramite Commands > Freeze aggregations. Ma fai attenzione: c'è sempre e solo uno stato attuale congelato e nessuna cronologia, inclusi gli stati precedenti.