Monitoraggio distribuito

Livestatus è un'interfaccia integrata nel nucleo di monitoraggio che permette ad altri programmi esterni di interrogare i dati di stato ed eseguire comandi. Livestatus può essere reso disponibile in rete in modo che sia accessibile da un sito Checkmk remoto. L'interfaccia utente di Checkmk usa Livestatus per combinare tutti i siti collegati in una panoramica generale, che poi assomiglia a un unico, grande sistema di monitoraggio.

Il diagramma seguente mostra schematicamente la struttura di un monitoraggio con Livestatus distribuito su tre sedi. Il sito Checkmk Central si trova nella sede di elaborazione centrale. Da qui i sistemi centrali saranno controllati direttamente. Inoltre, ci sono l'istanza remota 1 e l'istanza remota 2, che si trovano in altre reti e sono controllate dai rispettivi sistemi locali:

Ciò che rende speciale questo metodo è che lo stato di monitoraggio delle istanze remote non viene inviato continuamente all'istanza centrale. La GUI recupera i dati in tempo reale dalle istanze remote solo quando richiesto da un utente nel centro di controllo. I dati vengono quindi compilati in una visualizzazione centralizzata. Non c'è quindi alcuna archiviazione centrale dei dati, il che offre enormi vantaggi per il ridimensionamento!

Ecco alcuni dei vantaggi di questo metodo:

In un sistema distribuito che utilizza Livestatus come descritto sopra, è del tutto possibile che le istanze possano essere gestite in modo indipendente da team diversi, e che l'istanza centrale abbia solo il compito di fornire una dashboard centralizzata.

Nel caso in cui più istanze, o tutte le istanze, debbano essere amministrate dallo stesso team, una configurazione centrale è molto più facile da gestire. Checkmk supporta questa opzione e definisce tale configurazione come configurazione centrale. In questo modo tutti gli host e i servizi, gli utenti e i permessi, i periodi di tempo, le notifiche, ecc. saranno gestiti nell'Setupe dell'istanza centrale e poi distribuiti automaticamente alle istanze remote secondo le tue specifiche.

Un sistema di questo tipo non solo offre una panoramica comune dello stato, ma anche una configurazione comune, e di fatto "sembra un unico grande sistema".

Puoi persino estendere questo sistema con istanze-viewer dedicate, ad esempio, che fungono solo da interfacce di stato per sotto-aree o gruppi di utenti specifici.

Non ci sono requisiti particolari per l'istanza centrale. Questo significa che un'istanza già esistente può essere ampliata in un sistema di monitoraggio distribuito con una sola modifica, necessaria per handle correttamente i dati piggyback. Tutto quello che devi fare è abilitare l'hub piggyback nella pagina di configurazione Setup > General > Global settings nella sezione Site management:

Quindi attiva le modifiche, poiché switchare l'hub piggyback richiede il riavvio dell'istanza.

Le istanze remote vengono quindi generate come nuove istanze nel modo consueto con omd create. Ciò avverrà naturalmente sul server (remoto) destinato alla rispettiva istanza remota.

Note speciali:

Ecco un esempio per creare un'istanza remota con il nome myremote1 e la password t0p53cr3t per l'amministratore dell'istanza cmkadmin:

I passaggi più importanti ora sono attivare Livestatus via TCP per la rete e abilitare anche l'hub piggyback qui. Tieni presente che Livestatus non è di per sé un protocollo sicuro e dovrebbe essere usato solo all'interno di una rete sicura (LAN protetta, VPN, ecc.). L'abilitazione si effettua usando omd config come utente dell’istanza mentre l’istanza è ferma:

Ora seleziona Distributed Monitoring:

Imposta LIVESTATUS_TCP su on e, per LIVESTATUS_TCP_PORT, inserisci un numero di porta non assegnato che sia unico su questo server. Il valore predefinito è 6557:

Dopo aver salvato, avvia l'istanza come al solito con omd start:

Ricordati la password per cmkadmin. Ti servirà solo due volte: prima per abilitare l'hub piggyback e poi per effettuare la connessione tra l'istanza remota e l'istanza centrale. Una volta che l'istanza remota è stata subordinata all'istanza centrale, tutti gli utenti saranno comunque sostituiti da quelli dell'istanza centrale.

L'istanza è ora pronta. Un check con netstat mostra che la porta 6557 è aperta. La connessione a questa porta viene effettuata con un'istanza del superserver internet xinetd , che gira direttamente sul sito:

Ora accedi una volta all'istanza remota come utente cmkadmin e attiva l'hub piggyback utilizzando le impostazioni Setup > General > Global nella sezione Site management:

Quindi attiva le modifiche, poiché switchare l'hub piggyback richiede il riavvio dell'istanza.

La configurazione del monitoraggio distribuito avviene esclusivamente sull'istanza centrale nel menu Setup > General > Distributed monitoring e serve per la gestione delle connessioni ai singoli siti. Per questa funzione, l'istanza centrale stessa conta come un sito ed è già presente nell'elenco:

Utilizzando Add connection , definisci ora la connessione all'istanza remota più vicina:

In Basic settings è importante utilizzare il nome ESATTO dell’istanza remota — come definito in omd create — come Site ID. Come sempre, l’alias può essere definito a piacere e modificato in un secondo momento.

Le impostazioni dell'Status connection determinano il modo in cui l'istanza centrale interroga lo stato delle istanze remote tramite Livestatus. L'esempio nella schermata mostra una connessione con il metodo Connect via TCP(IPv4). Questo è l'ideale per connessioni stabili con tempi di latenza brevi (come, ad esempio, in una LAN). Parleremo delle impostazioni ottimali per le connessioni WAN più avanti.

Qui inserisci l'URL HTTP dell'interfaccia web dell'istanza remota, senza check_mk/ alla fine dell'URL. Se di solito accedi a Checkmk tramite HTTPS, sostituisci qui http con https. Trovi ulteriori informazioni nella guida online o nell'articolo sulla protezione dell'interfaccia web con HTTPS.

La replica della configurazione e quindi l'utilizzo del Setup centrale è, come abbiamo discusso nell'introduzione, facoltativo. Attiva la replica selezionando Push configuration to this site se desideri configurare l'istanza remota dall'istanza centrale. In tal caso, seleziona le impostazioni esatte come mostrato nell'immagine sopra.

Assicurati di verificare quale Message broker port devi specificare. Per scoprirlo, accedi all'istanza remota e esegui omd config dalla riga di comando. Vai alla sezione Basic. Qui la variabile RABBITMQ_PORT è quella rilevante.

È molto importante impostare correttamente l'URL of remote site. L'URL deve sempre terminare con /check_mk/. Si consiglia una connessione HTTPS, a condizione che Apache sull'istanza remota supporti HTTPS. Questo deve essere installato manualmente sull'istanza remota a livello di Linux. Per Checkmk Appliance, HTTPS può essere configurato utilizzando l'interfaccia web di configurazione. Se utilizzi un certificato self-signed, dovrai selezionare la casella di controllo Ignore SSL certificate errors.

Una volta salvata la maschera, nella panoramica apparirà una seconda istanza:

Lo stato di monitoraggio dell'istanza remota (finora) vuoto è ora correttamente integrato. Per utilizzare la configurazione centrale hai ancora bisogno di un Login per l'istanza Checkmk remota. A tal fine, l'istanza centrale scambia con l'istanza remota un segreto di login generato casualmente, attraverso il quale avverrà tutta la comunicazione futura. L'account cmkadmin sull'istanza remota non verrà più utilizzato in seguito.

Nel seguente modulo, usa come Login credentials cmkadmin e la password assegnata al momento della creazione dell'istanza remota. A questo punto, conferma che vuoi sovrascrivere le impostazioni cliccando su "Confirm overwrite".

Un login riuscito verrà riconosciuto in questo modo:

Se si verifica un errore durante il login, ciò potrebbe essere dovuto a diversi motivi – ad esempio:

Le prime due voci dell’elenco possono essere facilmente verificate richiamando manualmente l’URL del sito remoto nel tuo browser.

Quando tutto è andato a buon fine, esegui Activate Changes. Questo, come sempre, ti porterà a una panoramica delle modifiche non ancora attive. Contemporaneamente, la panoramica mostrerà anche gli stati delle connessioni Livestatus, così come gli stati di sincronizzazione delle singole istanze nel Setup centrale:

La colonna Version mostra la versione Livestatus dell’istanza corrispondente. Quando si utilizza il CMC come core di Checkmk (edizioni commerciali), il numero di versione del core (visualizzato nella colonna ‘Core’) è identico a quello di Livestatus. Se stai utilizzando Nagios come core (Comunità Checkmk), qui verrà visualizzato il numero di versione di Nagios.

I seguenti simboli mostrano lo stato di replica dell'ambiente di configurazione:

Nella colonna "Status" puoi vedere lo stato della connessione Livestatus per l'istanza in questione. Questo viene mostrato solo a titolo informativo, poiché la configurazione non viene trasmessa tramite Livestatus, ma piuttosto tramite HTTP. Sono possibili i seguenti valori:

Cliccando sul pulsante "" (Sincronizza tutte le istanze) Activate on selected sites ora sincronizzerai tutte le istanze e attiverai le modifiche. Questo viene eseguito in parallelo, quindi il tempo totale corrisponde al tempo richiesto dall'istanza più lenta. Il tempo include la creazione di un'istantanea di configurazione per l'istanza corrispondente, la trasmissione via HTTP, la decompressione dell'istantanea sull'istanza remota e l'attivazione delle modifiche.

Importante: non abbandonare la pagina prima che la sincronizzazione sia stata completata su tutte le istanze — abbandonare la pagina interromperà la sincronizzazione.

Una volta completata l'installazione del tuo ambiente distribuito, puoi iniziare a utilizzarlo. In realtà devi solo indicare a ciascun host da quale istanza deve essere monitorato. L'istanza centrale è specificata di default.

L'attributo richiesto per questo è Monitored on site. Puoi impostarlo individualmente per ogni host. Naturalmente, questo può essere eseguito anche a livello di cartella:

L'aggiunta di host funziona come al solito: a parte il fatto che sia il monitoraggio che la scoperta del servizio verranno eseguiti dalle rispettive istanze remote, non ci sono considerazioni particolari.

Quando si migrano host da un sito a un altro, ci sono un paio di punti da tenere a mente. Né i dati di stato attuali né quelli storici dell'host verranno trasferiti. Solo la configurazione dell'host viene mantenuta nell'ambiente di configurazione. In pratica è come se l'host fosse stato rimosso da un sito e reinstallato ex novo sull'altro sito:

Se la continuità della cronologia è importante per te, quando implementi il monitoraggio dovresti pianificare attentamente quale host deve essere monitorato e da dove.

Per ottenere la crittografia, Checkmk utilizza il programma stunnel insieme al proprio certificato e alla propria autorità di certificazione (CA) per firmare il certificato. Questi vengono generati automaticamente in modo individuale con una nuova istanza e non sono quindi CA o certificati statici predefiniti. Questo è un fattore di sicurezza molto importante per impedire che certificati falsi vengano utilizzati dagli hacker, poiché qualsiasi hacker potrebbe altrimenti ottenere l'accesso a una CA disponibile pubblicamente.

I certificati generati hanno anche le seguenti proprietà:

Il fatto che il certificato standard sia valido per così tanto tempo impedisce in modo molto efficace di incorrere in problemi di connessione che non riesci a classificare. Allo stesso tempo è ovviamente possibile che, una volta che un certificato è stato compromesso, rimanga di conseguenza esposto ad abusi per un lungo periodo. Quindi, se temi che un hacker possa accedere alla CA o al certificato dell'istanza firmato con essa, sostituisci sempre entrambi i certificati (CA e istanza)!

Durante un aggiornamento di Checkmk, le due opzioni LIVESTATUS_TCP e LIVESTATUS_TCP_TLS non vengono mai modificate automaticamente. L'attivazione automatica di TLS potrebbe alla fine impedire di interrogare le tue istanze remote.

Se finora hai utilizzato Livestatus senza crittografia e ora decidi di utilizzare la crittografia, devi attivarla manualmente. Per farlo, prima ferma le istanze interessate e poi attiva TLS con il seguente comando:

Poiché i certificati sono stati generati automaticamente durante l'aggiornamento, l'istanza utilizza immediatamente la nuova funzione di crittografia. Per poter continuare ad accedere all'istanza dal sito centrale, verifica che l'opzione "Encryption" sia impostata su "Encrypt data using TLS" nel menu sotto "Setup > General > Distributed Monitoring": Check questo e, se necessario, imposta l'opzione come mostrato nella seguente schermata:

L'ultimo passaggio è quello descritto sopra: anche in questo caso devi prima contrassegnare la CA dell'istanza remota come attendibile.

Tutti gli accessi a un host monitorato vengono effettuati in modo coerente dal sito a cui l'host è assegnato. Questo vale non solo per il monitoraggio vero e proprio, ma anche per la scoperta del servizio, la pagina Diagnostics, le notifiche, i gestori di avvisi e tutto il resto. Questo punto è molto importante poiché non si presume che l'istanza centrale abbia effettivamente accesso a questo host.

Alcune delle visualizzazioni standard sono raggruppate in base all'istanza da cui verrà effettuato il monitoraggio dell'host — questo vale, ad esempio, per All hosts:

Il sito verrà mostrato anche nei dettagli dell'host o del servizio:

Queste informazioni sono generalmente disponibili per l'uso in una colonna quando crei le tue visualizzazioni personalizzate. C'è anche un filtro con cui è possibile filtrare una visualizzazione degli host su un'istanza specifica:

C'è uno snap-in "Site status" per la barra laterale che puoi aggiungere tramite . Questo mostra lo stato delle singole istanze. Offre anche la possibilità di disabilitare e riabilitare temporaneamente una singola istanza cliccando sullo stato — o tutte le istanze contemporaneamente cliccando su "Disable all" o "Enable all".

I siti disabilitati saranno contrassegnati con lo stato "". In questo modo puoi anche disabilitare un sito che sta generando timeout, evitando così timeout superflui. Questa disabilitazione non è la stessa cosa che disabilitare la connessione Livestatus utilizzando la configurazione della connessione in Setup. Qui la "disabilitazione" riguarda solo l'utente attualmente connesso e ha una funzione puramente visiva. Cliccando sul nome di un sito verrà visualizzata una visualizzazione di tutti i suoi host.

In un monitoraggio distribuito, lo snap-in "Master control" ha un aspetto diverso. Ogni istanza ha il proprio switch globale:

Se monitori con il cluster HA di Checkmk, i singoli nodi del cluster devono essere assegnati allo stesso sito del cluster stesso. Questo perché per determinare lo stato dei servizi in cluster si accede ai file di cache generati dal monitoraggio del nodo. Questi dati si trovano localmente sull’istanza corrispondente.

Alcuni plug-in di controllo utilizzano i dati Piggyback, ad esempio per assegnare i dati di monitoraggio che sono stati "piggybackati" da un host alle singole macchine virtuali. Nel monitoraggio distribuito, l'host piggyback — ovvero l'host che riceve i dati piggyback — e gli host che dipendono da esso — in quanto effettivi consumatori dei dati piggyback — non sono sempre monitorati dallo stesso sito. In questi casi, è possibile attivare un'assegnazione cross-site dei dati piggyback.

Per abilitare tale comunicazione, devi solo assicurarti che la porta del broker di messaggi sia impostata correttamente su tutte le istanze partecipanti e che l'hub piggyback sia abilitato.

Dovresti checkare questo aspetto al più tardi quando vedi "Disabled" qui:

Il traffico dati spesso crea un collo di bottiglia nella comunicazione. Se i dati vengono scambiati da ogni punto a ogni altro punto, questo può portare rapidamente a un enorme flusso di dati e quindi a un sovraccarico della rete di comunicazione. È quindi consigliabile ridurre il numero di canali di comunicazione e mantenere lo scambio di dati principalmente all’interno di una rete locale. Quindi, per ridurre il carico sull'istanza centrale o per ottimizzare il traffico di rete, puoi anche consentire alle istanze remote di comunicare direttamente tra loro (connessione peer-to-peer). Come prerequisito per questo, entrambe le istanze remote devono essere state configurate dall'istanza centrale, ovvero Push configuration to this site deve essere attivato per entrambe come descritto nella sezione Assegnazione delle istanze remote all'istanza centrale.

In Setup > General > Distributed monitoring seleziona la voce di menu "Connections > Add peer-to-peer message broker connection". Assegna qui un ID univoco e seleziona le due istanze per la connessione diretta. Assicurati di seguire le istruzioni nell'aiuto in linea.

L'inventario HW/SW di Checkmk funziona anche in ambienti distribuiti. A tal fine, i dati di inventario dalla directory ~/var/check_mk/inventory devono essere trasmessi regolarmente dalle istanze remote all'istanza centrale. Per motivi di performance, l'interfaccia utente accede sempre a questa directory localmente.

Nelle edizioni commerciali la sincronizzazione viene eseguita automaticamente su tutte le istanze collegate tramite il proxy Livestatus.

Se esegui l'inventario utilizzando la Comunità Checkmk in sistemi distribuiti, la directory deve essere regolarmente replicata sull'istanza centrale con i tuoi strumenti (ad es. con rsync).

Anche quando tutte le istanze sono sottoposte a monitoraggio centralizzato, è possibile e spesso anche opportuno effettuare il login sull'interfaccia di un'istanza singola. Per questo motivo Checkmk garantisce che la password di un utente sia sempre la stessa per tutte le istanze.

Una modifica della password effettuata dall'amministratore avrà effetto automaticamente non appena verrà condivisa con tutte le istanze tramite Activate pending changes.

Una modifica effettuata dall’utente stesso tramite la barra laterale nelle impostazioni personali funziona in modo leggermente diverso. In questo caso non è possibile eseguire un comando Activate pending changes poiché l’utente, ovviamente, non dispone del permesso generale per questa funzione. In tal caso Checkmk distribuirà automaticamente la password modificata a tutte le istanze — subito dopo che è stata salvata, in realtà.

Come tutti sappiamo, le reti non sono mai disponibili al 100%. Se un sito è non raggiungibile al momento della modifica della password, non riceverà la nuova password. Fino a quando l'amministratore non eseguirà con successo un Activate pending changes, o rispettivamente, fino alla successiva modifica della password riuscita, questo sito manterrà la vecchia password per l'utente. Un simbolo di stato informerà l'utente sullo stato della condivisione della password con le singole istanze.

È ovvio che i tag host utilizzati nell’istanza remota debbano essere noti anche all’istanza centrale affinché possano essere trasferiti. Checkali prima della migrazione e aggiungi manualmente all’istanza centrale eventuali tag mancanti. In questo caso è essenziale che gli ID dei tag corrispondano; il titolo del tag è irrilevante.

Successivamente, sposta gli host e le regole nell’ambiente di configurazione dell’istanza centrale. Questo funziona solo per gli host e le regole presenti nelle sottocartelle (cioè non nella cartella Main). Gli host nella cartella Main devono prima essere semplicemente spostati in una sottocartella dell’istanza remota tramite Setup > Hosts > Hosts.

La migrazione vera e propria può quindi essere effettuata semplicemente copiando le directory appropriate. Ogni cartella nell'ambiente di configurazione corrisponde a una directory all'interno di ~/etc/check_mk/conf.d/wato/. Queste possono essere copiate utilizzando uno strumento a tua scelta (ad es. scp) dall'istanza collegata alla stessa posizione nell'istanza centrale. Se lì esiste già una directory con lo stesso nome, basta rinominarla. Tieni presente che anche gli utenti e i gruppi Linux vengono utilizzati dall'istanza centrale.

Dopo la copia, gli host appariranno nell'istanza centrale in Setup, così come le regole che hai creato in queste cartelle. Anche le proprietà delle cartelle saranno incluse nella copia. Queste si trovano nella directory del file nascosto .wato.

Affinché gli attributi delle funzioni della cartella principale dell’istanza centrale vengano ereditati correttamente, come passo finale dopo la migrazione, le caratteristiche delle cartelle principali devono essere aperte e salvate una volta – in questo modo gli attributi dell’host verranno ridefiniti.

Installare il proxy Livestatus è semplicissimo. È attivato di default nelle edizioni commerciali — come puoi vedere all'avvio di un'istanza:

Seleziona l'impostazione Use Livestatus Proxy-Daemon per la connessione alle istanze remote invece di Connect via TCP:

I dettagli relativi all'host e alla porta sono gli stessi di sempre. Non è necessario apportare modifiche sull'istanza remota. In "Number of channels to keep open" inserisci il numero di connessioni TCP parallele che il proxy deve stabilire e mantenere con il sito di destinazione.

Il pool di connessioni TCP è condiviso da tutte le richieste della GUI. Il numero di connessioni limita il numero massimo di query che possono essere elaborate contemporaneamente. Questo limita indirettamente il numero di utenti. In situazioni in cui tutti i canali sono occupati, ciò non porterà immediatamente a un errore. La GUI attende un determinato tempo per un canale libero. La maggior parte delle query richiede in realtà solo pochi millisecondi.

Se la GUI deve attendere più a lungo di unTimeout waiting for a free channele per un canale, verrà interrotta con un errore e l'utente riceverà un messaggio di errore. In tal caso, il numero di connessioni dovrebbe essere aumentato. Tieni presente, tuttavia, che sull'istanza remota devono essere consentite sufficienti connessioni in entrata parallele — questo valore è impostato su 20 per impostazione predefinita. Questa impostazione si trova nelle opzioni globali alla voce "Monitoring core > Maximum concurrent Livestatus connections".

L'Regular heartbeate fornisce un monitoraggio costantemente attivo delle connessioni direttamente a livello di protocollo. Durante il processo, il proxy invia regolarmente una semplice query Livestatus a cui l'istanza remota deve rispondere entro un tempo prestabilito (impostazione predefinita: 2 secondi). Con questo metodo viene rilevata anche una situazione in cui il server di destinazione e la porta TCP sono effettivamente raggiungibili, ma il nucleo di monitoraggio non risponde più.

Se la risposta non arriva, tutte le connessioni vengono dichiarate "morte" e, dopo un periodo di "cooldown" (impostazione predefinita: 4 secondi), vengono ristabilite. Tutto questo avviene in modo proattivo, cioè senza che tu debba aprire una finestra della GUI. In questo modo è possibile rilevare rapidamente le interruzioni e, tramite un recupero, le connessioni possono essere ristabilite immediatamente e, nel migliore dei casi, essere disponibili prima ancora che un utente si accorga dell'interruzione.

L'Cachinga garantisce che le query statiche debbano ricevere una risposta dall'istanza remota una sola volta e che, da quel momento in poi, possano essere gestite direttamente e localmente, senza ritardi. Un esempio è l'elenco degli host monitorati richiesto da Quicksearch.

Il proxy Livestatus ha il proprio file di log ~/var/log/liveproxyd.log. Su un'istanza remota configurata correttamente con cinque canali (standard) avrà un aspetto simile a questo:

Il proxy Livestatus registra regolarmente il proprio stato nel file ~/var/log/liveproxyd.state:

E quando un'istanza è attualmente ferma, lo stato sarà simile a questo:

Qui lo stato è "starting". Il proxy sta quindi tentando di stabilire delle connessioni. Non ci sono ancora canali. In questo stato, le richieste all'istanza riceveranno una risposta di errore.

Per prima cosa, sull'istanza remota, crea una copia delle configurazioni dei suoi host e servizi nel formato di configurazione Nagios. Inoltre, reindirizza l'output di livedump -TC in un file:

L'inizio del file sarà simile a questo:

Trasmetti il file all'istanza centrale (ad es. con scp) e salvalo lì nella directory ~/etc/nagios/conf.d/ – dove Nagios si aspetta di trovare i dati di configurazione per host e servizi. Scegli un nome file che finisca con .cfg , ad esempio ~/etc/nagios/conf.d/config-myremote1.cfg. Se è possibile un accesso SSH dall'istanza remota all'istanza centrale, puoi procedere, ad esempio, come segue:

Ora accedi all'istanza centrale e attiva le modifiche:

Ora tutti gli host e i servizi del remote dovrebbero apparire nell’istanza centrale – inizialmente con lo stato IN SOSPENSIONE, che manterranno per il momento:

Note:

Una volta che gli host sono visibili nell'istanza centrale, dovremo impostare un Setup (regolare) dello stato di monitoraggio delle istanze remote. Crea nuovamente un file con livedump, ma questa volta senza opzioni secondarie:

Questo file contiene gli stati di tutti gli host e i servizi in un formato che Nagios può leggere direttamente dai risultati dei check. L'inizio di questo file è simile a questo:

Copia questo file nell'istanza centrale nella directory ~/tmp/nagios/checkresults. Importante: il nome di questo file deve iniziare con c ed essere lungo sette caratteri. Con scp sarà simile a questo:

Infine, crea un file vuoto sull'istanza centrale con lo stesso nome e l'estensione .ok. In questo modo Nagios saprà che il file di stato è stato trasferito completamente e potrà ora leggerlo:

Lo stato degli host/servizi remoti verrà ora aggiornato immediatamente sull'istanza centrale:

D'ora in poi la trasmissione dello stato deve essere effettuata regolarmente. Puoi utilizzare uno script per eseguire ripetutamente i passaggi sopra descritti a intervalli di tua scelta. Invece di copiare i dati tramite scp, il tuo script può essere eseguito direttamente dall'istanza centrale in modo che possa ricevere i dati di stato o di configurazione tramite ssh.

Uno script per eseguire queste azioni è disponibile su GitHub nella directory treasures.

Il dump di configurazione e stato può anche essere limitato utilizzando i filtri Livestatus. Ad esempio, potresti limitare gli host ai membri del gruppo di host mygroup:

Le edizioni commerciali offrono un meccanismo integrato per le notifiche centralizzate che può essere attivato individualmente per ogni istanza remota. Tali istanze remote inoltrano quindi tutte le notifiche all'istanza centrale per l'ulteriore elaborazione. La notifica centralizzata è quindi indipendente dal fatto che il monitoraggio distribuito sia stato configurato in modo standard, con CMCDump o utilizzando una combinazione di queste procedure. Tecnicamente parlando, il server di notifica centrale non deve nemmeno trovarsi letteralmente al “centro”. Questo compito può essere svolto da qualsiasi istanza Checkmk.

Se un'istanza remota è stata impostata su "inoltro", tutte le notifiche verranno inoltrate direttamente all'istanza centrale come se provenissero dal core — in pratica in formato grezzo. Una volta lì, le regole di notifica valuteranno chi deve essere effettivamente avvisato e in che modo. Gli script di notifica necessari verranno eseguiti sull'istanza centrale.

Gli spooler di notifica delle istanze remote e centrali (di notifica) comunicano tra loro tramite TCP. Le notifiche vengono inviate dalle istanze remote all'istanza centrale. L'istanza centrale conferma alle istanze remote che le notifiche sono state ricevute, il che impedisce che le notifiche vadano perse anche se la connessione TCP viene interrotta.

Ci sono due alternative per la creazione di una connessione TCP:

Di conseguenza, nulla impedisce l'inoltro delle notifiche se, per motivi di rete, è possibile stabilire connessioni solo in una direzione specifica. Le connessioni TCP sono monitorate dallo spooler tramite un segnale di heartbeat e vengono ristabilite immediatamente quando necessario — non solo in caso di evento.

Poiché le istanze remote e l'istanza centrale richiedono impostazioni globali diverse per lo spooler, devi definire impostazioni specifiche per tutte le istanze remote. La configurazione dell'istanza centrale viene eseguita utilizzando le normali impostazioni globali. Nota: queste impostazioni verranno automaticamente ereditate da tutte le istanze remote per le quali non sono state definite impostazioni specifiche.

Vediamo prima un esempio in cui l'istanza centrale stabilisce le connessioni TCP con le istanze remote.

Passaggio 1: sull'istanza remota, modifica l'impostazione globale specifica dell'istanza "Notifications > Notification Spooler Configuration" e attiva "Accept incoming TCP connections". Per le connessioni in entrata verrà consigliata la porta TCP 6555. Se non ci sono obiezioni, adotta queste impostazioni.

Passo 2: Ora, allo stesso modo, nel sottomenu "Notification Spooling" solo sull'istanza remota, seleziona l'opzione "Forward to remote site by notification spooler".

Passaggio 3: Ora, sull'istanza centrale — cioè nelle normali impostazioni globali — configura la connessione all'istanza remota (e poi a ulteriori istanze remote se necessario):

Passaggio 4: imposta l'impostazione globale "Notification Spooling" su "Asynchronous local delivery by notification spooler", in modo che anche le comunicazioni dell'istanza centrale vengano elaborate tramite lo stesso spooler centrale.

Passaggio 5: Attiva le modifiche.

Se la connessione TCP deve essere stabilita dall'istanza remota verso l'esterno, la procedura è identica, differendo dalla descrizione sopra riportata solo per lo scambio dei ruoli tra istanza centrale e istanza remota.

È possibile anche una combinazione delle due procedure. In tal caso, l'istanza centrale deve essere installata in modo da ascoltare le connessioni in entrata e da connettersi alle istanze remote. Tuttavia, in ogni relazione centrale/remota, solo uno dei due è autorizzato a stabilire la connessione!

Lo spooler di notifica registra i log nel file ~/var/log/mknotifyd.log. Nella configurazione dello spooler di notifica è possibile aumentare il livello di log in modo da ricevere più messaggi. Con un livello di log standard dovresti vedere qualcosa di simile sull'istanza centrale:

Il file ~/var/log/mknotifyd.state contiene sempre lo stato attuale dello spooler e di tutte le sue connessioni:

Una versione dello stesso file è presente anche sull'istanza remota. Lì la connessione apparirà più o meno così:

Per fare una prova, seleziona un servizio remoto monitorato e impostalo manualmente su CRIT con il comando Fake check results.

Ora sull'istanza centrale dovrebbe apparire una notifica in arrivo nel file di log delle notifiche (notify.log):

Lo stesso evento apparirà così sull'istanza remota:

Nelle impostazioni globali puoi impostare sia il file di log normale per le notifiche (notify.log) sia il file di log dello spooler di notifica su un livello di log più alto.

Una volta configurato tutto come descritto, noterai che sull'istanza centrale, e rispettivamente sulle istanze remote, sarà presente un nuovo servizio che deve assolutamente essere incluso nel monitoraggio. Questo monitora lo spooler di notifica e le sue connessioni TCP. Ogni connessione verrà quindi monitorata due volte: una volta dall'istanza centrale e una volta dall'istanza remota: