Monitoraggio distribuito

Livestatus è un'interfaccia integrata nel nucleo di monitoraggioche permette ad altri programmi esterni di interrogare i dati di stato ed eseguire comandi. Livestatus può essere reso disponibile attraverso la rete in modo da potervi accedere da un'istanza remota in Checkmk. L'utente dell'istanza Checkmk utilizza Livestatus per combinare tutti i siti collegati in una panoramica generale. In questo modo si ha l'impressione di un "grande" sistema di monitoraggio.

Il seguente diagramma mostra schematicamente la struttura di un monitoraggio con Livestatus distribuito su tre sedi. L'istanza Checkmk Central Site si trova nella sede centrale del processo. Da qui i sistemi centrali vengono controllati direttamente. Inoltre, ci sono il Sito Remoto 1 e il Sito Remoto 2 che si trovano in altre reti e sono controllati dai loro sistemi locali:

La particolarità di questo metodo è che lo stato di monitoraggio dei siti remoti non viene inviato continuamente al sito centrale. La GUI recupera sempre i dati in tempo reale dai siti remoti solo quando sono richiesti da un utente del centro di controllo. I dati vengono poi compilati in una visualizzazione centralizzata. Non c'è quindi un archivio centrale di dati, il che significa che offre enormi vantaggi in termini di scalabilità!

Ecco alcuni dei vantaggi di questo metodo:

In un sistema distribuito utilizzando Livestatus come descritto in precedenza, è possibile che i singoli siti siano gestiti in modo indipendente da diversi provider e che il sito centrale abbia solo il compito di fornire un dashboard centralizzato.

Nel caso di più siti o di tutti i siti che devono essere amministrati dallo stesso team, una configurazione centrale è molto più facile da gestire. Checkmk supporta questo aspetto e si riferisce a una configurazione di questo tipo come ambiente di configurazione distribuito. In questo modo tutti gli host e i servizi, gli utenti e i permessi, i periodi di tempo e le notifiche, ecc. saranno mantenuti e configurati nel sito centrale e poi, a seconda dei loro compiti, saranno distribuiti automaticamente ai siti remoti.

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

È possibile estendere questo sistema con istanze-viewer dedicate, ad esempio, che fungono solo da interfaccia di stato per sottoaree o gruppi specifici di utenti.

Il sito centrale non richiede requisiti particolari: ciò significa che un sito consolidato da tempo può essere ampliato in un monitoraggio distribuito senza richiedere ulteriori modifiche.

I siti remoti vengono generati come nuovi siti nel modo consueto con omd create. Questo avviene naturalmente sul server (remoto) destinato al rispettivo sito remoto.

Note speciali:

Ecco un esempio di creazione di un sito remoto con il nome remote1:

Il passo più importante è ora quello di abilitare Livestatus via TCP sulla rete. Nota che Livestatus non è di per sé un protocollo sicuro e deve essere utilizzato solo all'interno di una rete sicura (LAN protetta, VPN, ecc.). L'abilitazione appare su omd config come utente dell'istanza su un sito fermo:

Ora seleziona Distributed Monitoring:

Imposta LIVESTATUS_TCP su ‘on’ e inserisci un numero di porta disponibile perLIVESTATUS_TCP_PORT che sia esplicito su questo server. Il valore predefinito è 6557:

Dopo aver salvato, avvia il sito come di consueto con omd start:

Mantieni la password di cmkadmin. Una volta che il sito remoto è stato subordinato al sito centrale, tutti gli utenti dell'istanza saranno sostituiti da quelli del sito centrale.

Il sito remoto è ora pronto. Verifica con netstat che la porta 6557 sia aperta. La connessione a questa porta viene effettuata da un sito del superserver Internet xinetd, che funziona direttamente nel sito:

La configurazione del monitoraggio distribuito avviene esclusivamente sul sito centrale nel menu Setup > General > Distributed monitoring, che serve a gestire le connessioni ai singoli siti. Per questa funzione il sito centrale stesso conta come sito ed è già presente nell'elenco:

Utilizzando Add connection, definisci ora la connessione al primo sito remoto:

In Basic settings è importante utilizzare il nome ESATTO del sito remoto - definito con omd create- come Site ID. Come sempre, l'alias può essere definito a piacere e può essere modificato in seguito.

Le impostazioni di Status connection determinano il modo in cui la centrale interroga lo stato dei siti remoti tramite Livestatus. L'esempio nella schermata mostra una connessione con il metodo Connect via TCP(IPv4). Questo è il metodo ottimale per connessioni stabili con brevi periodi di latenza (come ad es. in una LAN). Parleremo in seguito delle impostazioni ottimali per le connessioni WAN.

Inserisci qui l'URL HTTP dell'interfaccia web remota (solo la parte che precede il componente check_mk/ ). Se accedi a Checkmk tramite HTTPS, sostituisci http con https. Ulteriori informazioni sono disponibili nella guida online o nell'articolo sulla protezione dell'interfaccia web con HTTPS.

La replica della configurazione e quindi l'utilizzo dell'ambiente di configurazione distribuito è, come abbiamo detto nell'introduzione, facoltativa. Attivala se desideri configurare il sito remoto con e dal sito centrale. In questo caso seleziona le impostazioni esatte come mostrato nell'immagine qui sopra.

L'impostazione corretta di URL of remote site è molto importante: l'URL deve sempre terminare con /check_mk/. Si raccomanda una connessione con HTTPS, a condizione che Apache del sito remoto supporti HTTPS. Questo deve essere installato manualmente sul sito remoto a livello Linux. Per l'istanza remota in Checkmk Appliance, HTTPS può essere impostato tramite l'interfaccia web di configurazione. Se utilizzi un certificato self-signed, dovrai selezionare il box Ignore SSL certificate errors.

Una volta salvata la maschera, nella panoramica apparirà un secondo sito:

Lo stato di monitoraggio del sito remoto (finora vuoto) è ora correttamente integrato. Per utilizzare l'ambiente di configurazione distribuito è necessario disporre di un login per l'istanza remota Checkmk. A tal fine, il sito centrale scambia con il sito remoto un segreto di login generato in modo casuale, attraverso il quale avverranno tutte le comunicazioni future. In seguito, l'accesso cmkadmin del sito remoto non sarà più utilizzato.

Per effettuare il login utilizza i dati di accesso cmkadmin e la relativa password del sito remoto. Non dimenticare di selezionare il box Confirm overwrite prima di cliccare il pulsante Login:

Un login riuscito verrà confermato:

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

I punti 1. e 2. possono essere facilmente verificati richiamando manualmente l'URL del sito remoto nel browser.

Quando tutto è andato a buon fine, esegui Activate Changes. Questo ti porterà, come sempre, a una panoramica delle modifiche non ancora attivate. Contemporaneamente la panoramica mostrerà anche gli stati delle connessioni Livestatus e gli stati di sincronizzazione dell'ambiente di configurazione distribuito dei singoli siti:

La colonna Version mostra la versione di Livestatus del rispettivo sito. Se utilizzi il CMC come istanza Checkmk (edizioni commerciali), il numero di versione del core (indicato nella colonna ‘Core’ ) è identico a quello di Livestatus. Se utilizzi Nagios come core (Checkmk Raw), il numero di versione di Nagios sarà visibile qui.

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

Nella colonna Status è possibile vedere lo stato della connessione Livestatus per il sito in questione. Questo viene mostrato a titolo puramente informativo poiché la configurazione non viene trasmessa tramite Livestatus, ma piuttosto tramite HTTP. Sono possibili i seguenti valori:

Facendo clic sul pulsante Activate on selected sites, tutti i siti verranno sincronizzati e le modifiche verranno attivate. L'operazione viene eseguita in parallelo, in modo che il tempo complessivo corrisponda a quello richiesto dal sito più lento. Nel tempo sono inclusi la creazione di un'istantanea di configurazione per il rispettivo sito, la trasmissione via HTTP, lo scompattamento dell'istantanea sul sito remoto e l'attivazione delle modifiche.

Importante: Non abbandonare la pagina prima che la sincronizzazione sia stata completata su tutti i siti: l'abbandono della pagina interromperà la sincronizzazione.

Una volta installato l'ambiente distribuito, puoi iniziare a usarlo. In realtà devi solo indicare a ciascun host da quale sito deve essere monitorato. Il sito centrale è specificato per impostazione predefinita.

L'attributo richiesto è ‘Monitored on site’. Puoi impostarlo individualmente per ogni host, naturalmente anche a livello di cartella:

L'aggiunta di host funziona come al solito: a parte il fatto che il monitoraggio e la scoperta del servizio saranno eseguiti dal rispettivo sito remoto, non ci sono considerazioni particolari.

Quando si migrano gli host da un sito all'altro, ci sono un paio di punti da tenere in considerazione. Idati di stato dell'host, sia attuali che storici, non verranno trasferiti.Solo la configurazione dell'host viene mantenuta nell'ambiente di configurazione. In effetti è come se l'host fosse stato rimosso da un sito e installato di recente nell'altro sito:

Se la continuità della cronologia è importante per te, al momento di implementare il monitoraggio devi 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 saranno generati automaticamente con un nuovo sito e non si tratta di CA o certificati statici predefiniti. Si tratta di un fattore di sicurezza molto importante per evitare che gli aggressori utilizzino certificati falsi, perché qualsiasi aggressore potrebbe accedere 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 efficacemente che si verifichino problemi di connessione che non si possono classificare. Allo stesso tempo è ovviamente possibile che una volta che un certificato è stato compromesso sia di conseguenza aperto ad abusi. Quindi, se temi che un malintenzionato possa accedere alla CA o al certificato del sito firmato con essa, sostituisci sempre entrambi i certificati (CA e sito)!

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 comportare l'impossibilità di interrogare i tuoi siti remoti.

Se finora hai usato Livestatus in chiaro e ora decidi di usare la crittografia, devi attivarla manualmente. Per farlo, arresta prima i siti interessati e poi attiva il TLS con il seguente comando:

Poiché i certificati sono stati generati automaticamente durante l'aggiornamento, il sito utilizza immediatamente la nuova funzione di crittografia. Per poter accedere al sito dal sito centrale, verifica che l'opzione Encryption sia impostata su Encrypt data using TLS nel menu alla voce Setup > General > Distributed Monitoring:

L'ultimo passo è quello descritto in precedenza; anche in questo caso devi prima contrassegnare la CA del sito remoto come attendibile.

Tutti gli accessi a un host monitorato vengono effettuati 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 di diagnostica, lenotifiche, i gestori di avvisi e tutto il resto. Questo punto è molto importante perché non si presume che il sito centrale abbia effettivamente accesso a questo host.

Alcune delle visualizzazioni standard sono raggruppate in base al sito da cui l'host sarà monitorato: questo vale ad es. per All hosts:

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

Queste informazioni sono generalmente disponibili per essere utilizzate in una colonna quandocrei le tue visualizzazioni. Esiste anche un filtro con il quale è possibile filtrare la visualizzazione degli host di un sito specifico:

Esiste uno snap-in Site status per la barra laterale che può essere aggiunto utilizzando . Questo visualizza lo stato dei singoli siti. Offre inoltre la possibilità di disabilitare e riabilitare temporaneamente un singolo sito cliccando sullo stato - o tutti i siti in una volta sola cliccando su Disable all o Enable all.

I siti disabilitati saranno contrassegnati dallo stato. Con questa funzione puoi anche disabilitare un sito che sta generando timeout, evitando così timeout superflui. Questa disabilitazione non è uguale alla disabilitazione della connessione Livestatus utilizzando la configurazione della connessione in Setup. In questo caso la "disabilitazione" riguarda solo l'utente dell'istanza attualmente connesso e ha una funzione puramente visuale. Facendo clic sul nome di un sito verrà visualizzata la visualizzazione di tutti i suoi host.

In un monitoraggio distribuito, lo snap-in Master control ha un aspetto diverso:ogni sito ha il proprio switch globale:

Se effettui il monitoraggio con l'istanza Checkmk HA, i singoli nodi del cluster devono essere assegnati allo stesso sito del cluster stesso. Questo perché la determinazione dello stato dei servizi del cluster accede ai file di cache generati dal monitoraggio del nodo. Questi dati si trovano localmente nel rispettivo sito.

Alcuni plug-in di controllo utilizzano dati piggyback, ad esempio per assegnare i dati di monitoraggio recuperati da un host ESXi alle singole macchine virtuali. Per lo stesso motivo del monitoraggio distribuito, l'host piggyback e gli host dipendenti devono essere monitorati dallo stesso sito. Nel caso di ESXi, ciò significa che le macchine virtuali devono essere assegnate allo stesso sito in Checkmk del sistema ESXi da cui vengono raccolti i dati di monitoraggio. Questo può significare che è meglio interrogare direttamente il sistema host ESXi piuttosto che interrogare un vCenter globale. I dettagli a riguardo si trovano nella documentazione sul monitoraggio di ESXi.

L'inventario hardware/software di Checkmk funziona anche in ambienti distribuiti. A tal fine, i dati dell'inventario della directoryvar/check_mk/inventory devono essere trasmessi regolarmente dai remoti al sito centrale. Per motivi di prestazioni, l'interfaccia utente accede sempre a questa directory a livello locale.

Nelle edizioni commerciali la sincronizzazione viene effettuata automaticamente su tutti i siti in connessione con il proxy Livestatus.

Se esegui le istanze Checkmk Raw in sistemi distribuiti, la directory deve essere regolarmente sincronizzata con il sito centrale con strumenti propri (es. rsync).

Anche quando tutti i siti sono monitorati centralmente, è possibile e spesso opportuno effettuare un login sull'interfaccia di un singolo sito. Per questo motivo Checkmk fa in modo che la password dell'utente dell'istanza Checkmk sia sempre la stessa per tutti i siti.

Una modifica della password effettuata dall'amministratore avrà effetto automaticamente non appena sarà condivisa con tutti i siti con Activate Changes.

Una modifica apportata dall'utente stesso tramite la barra laterale delle sue impostazioni personali funziona in modo diverso. Questo non può essere autorizzato da Activate changes poiché l'utente non ha un'autorizzazione generale per questa funzione. In questo caso Checkmk condividerà automaticamente la password modificata su tutti i siti, direttamente dopo averla salvata.

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 changes o, rispettivamente, fino alla successiva modifica della password, questo sito manterrà la vecchia password per l'utente. Un simbolo di stato informerà l'utente dello stato della condivisione della password nei singoli siti.

È evidente che i tag degli host utilizzati nel sito remoto devono essere noti anche al sito centrale per poter essere trasferiti. Controllali prima della migrazione e aggiungi manualmente i tag mancanti al sito centrale. In questo caso è essenziale che i Tag-ID corrispondano: il titolo del tag è irrilevante.

Successivamente, sposta gli host e le regole nell'ambiente di configurazione del sito centrale. Questo funziona solo per gli host e le regole presenti nelle sottocartelle (cioè non nella cartella Main ). Gli host presenti nella cartella principale devono essere spostati nella sottocartella di un sito remoto tramite Setup > Hosts > Hosts.

La migrazione vera e propria può essere effettuata semplicemente copiando le cartelle appropriate. Ogni cartella nell'ambiente di configurazione corrisponde a una directory all'interno di ~/etc/check_mk/conf.d/wato/. Queste possono essere copiate con uno strumento a tua scelta (es. scp) dal sito collegato alla stessa posizione nel sito centrale. Se esiste già una directory con lo stesso nome, è sufficiente rinominarla. Tieni presente che gli utenti e i gruppi Linux sono utilizzati anche dal sito centrale.

Dopo la copia, gli host appariranno nella cartella Setupdel sito centrale, così come le regole che hai creato in queste cartelle. Anche le proprietà delle cartelle saranno incluse nella copia. Queste possono essere trovate nella directory nel file nascosto .wato.

Affinché gli attributi delle funzioni della cartella madre del sito centrale vengano ereditati correttamente, come ultimo passo dopo la migrazione è necessario aprire e salvare una volta le caratteristiche della cartella madre: in questo modo gli attributi dell'host padre saranno definiti con pertinenza.

L'installazione del proxy Livestatus è molto semplice. È attivato per impostazione predefinita nelle edizioni commerciali, come si può vedere all'avvio di un sito:

Seleziona l'impostazione "Use Livestatus Proxy-Daemon" per la connessione ai siti remoti invece di "Connetti via TCP":

I dettagli relativi a host e porta sono quelli di sempre. Non è necessario apportare alcuna modifica al sito remoto. In Number of channels to keep open inserisci il numero di connessioni TCP parallele che il proxy deve stabilire e mantenere verso il sito di destinazione.

Il pool di connessioni TCP è condiviso da tutte le richieste GUI. Il numero di connessioni limita il numero massimo di query che possono essere processate simultaneamente, limitando indirettamente il numero di utenti. In situazioni in cui tutti i canali sono riservati, questo non porterà immediatamente a un errore. Il GUI attende un determinato tempo per trovare un canale libero. La maggior parte delle interrogazioni richiede solo pochi millisecondi.

Se la GUI deve aspettare più a lungo di Timeout waiting for a free channel per un canale, verrà interrotta con un errore e l'utente riceverà un messaggio di errore. In questo caso, il numero di connessioni dovrebbe essere aumentato. Tieni comunque presente che sul sito remoto devono essere consentite un numero sufficiente di connessioni parallele in entrata: l'impostazione predefinita è 20. Questa impostazione si trova nelle opzioni globali alla voceMonitoring core > Maximum concurrent Livestatus connections.

Il sito Regular heartbeat fornisce un monitoraggio costantemente attivo delle connessioni direttamente a livello di protocollo. Nel processo il proxy invia regolarmente una semplice domanda Livestatus alla quale il sito remoto deve rispondere entro un tempo prestabilito (default: 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 tempo di "raffreddamento" (predefinito: 4 secondi), vengono ristabilite. Tutto questo avviene in modo proattivo, cioè senza che l'utente debba aprire una finestra GUI. In questo modo le interruzioni possono essere rilevate rapidamente e, tramite un recupero, le connessioni possono essere ristabilite immediatamente e, nel migliore dei casi, essere disponibili prima che l'utente si accorga dell'interruzione.

Il sito Caching garantisce che le query statiche debbano essere risposte una sola volta dal sito remoto e che da quel momento possano essere risposte direttamente e localmente, senza ritardi. Un esempio è l'elenco degli host monitorati richiesto da Quicksearch.

Il proxy Livestatus ha un proprio file di log che si trova all'indirizzo var/log/liveproxyd.log. In un sito remoto correttamente configurato con cinque canali (standard) avrà un aspetto simile a questo:

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

Quando un sito è attualmente fermo, lo stato sarà simile a questo:

In questo caso lo stato è 'starting'. Il proxy sta quindi tentando di stabilire delle connessioni. Non ci sono ancora canali. In questo stato le richieste al sito riceveranno una risposta di errore.

Per prima cosa, sul sito remoto, crea una copia delle configurazioni dei suoi host e servizi in formato Nagios-configuration. Inoltre, reindirizza l'output di livedump -TC in un file:

L'inizio del file sarà simile a questo:

Trasmetti il file al sito centrale (ad es. con scp) e salvalo nella directory ~/etc/nagios/conf.d/ - qui Nagios si aspetta di trovare i dati di configurazione di host e servizi. Scegli un nome di file che finisca con.cfg, ad esempio ~/etc/nagios/conf.d/config-remote1.cfg. Se è possibile un accesso SSH dal sito remoto a quello centrale, si può fare, ad esempio, come segue:

Ora effettua il log-in al sito centrale e attiva le modifiche:

Ora tutti gli host e i servizi del sito remoto dovrebbero apparire nel sito centrale, inizialmente con lo stato IN SOSP:

Nota:

Una volta che gli host sono visibili nel sito centrale, dovremo impostare una trasmissione (regolare) dello stato di monitoraggio dei remoti. 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 controlli. L'inizio del file è simile a questo:

Copia questo file sul sito centrale nella directory ~/tmp/nagios/checkresults.Importante: il nome di questo file deve iniziare con c ed essere lungo sette caratteri. Con scp avrà un aspetto simile a questo:

Infine, crea un file vuoto sul sito centrale con lo stesso nome e l'estensione .ok. In questo modo Nagios saprà che il file di stato è stato trasferito completamente e può essere letto:

Lo stato degli host/servizi dei telecomandi sarà ora immediatamente aggiornato sul sito centrale:

D'ora in poi la trasmissione dello stato deve avvenire regolarmente. Purtroppo Livedump non supporta questa operazione e dovrai quindi guardare tu stesso. Lo script livedump-ssh-recv si trova in ~/share/check_mk/doc/treasures/livedump, che puoi utilizzare per ricevere gli aggiornamenti di Livedump (compresi quelli della configurazione) sul sito centrale tramite SSH. Per i dettagli, vedi i commenti nello script stesso.

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

Ulteriori informazioni su Livedump sono disponibili nel file README nella directory ~/share/doc/check_mk/treasures/livedump.

Le edizioni commerciali prevedono un meccanismo integrato per le notifiche centralizzate che possono essere attivate individualmente per ogni sito remoto. Tali siti remoti inviano tutte le notifiche al sito centrale per un'ulteriore elaborazione. La notifica centralizzata è quindi indipendente dal fatto che il monitoraggio distribuito sia stato impostato nel modo standard, con CMCDump o utilizzando una combinazione di questi processi. Tecnicamente parlando, il server di notifica centrale non deve nemmeno essere "centrale". Questo compito può essere svolto da qualsiasi istanza Checkmk.

Se un sito remoto è stato impostato su "inoltro", tutte le notifiche verranno inoltrate direttamente al sito centrale come se provenissero dal core, ovvero in formato grezzo. Una volta arrivate, verranno valutate le regole di notifica che decidono chi deve essere notificato e come. Gli script di notifica necessari verranno invocati sul sito centrale.

Gli spooler di notifica dei siti remoti e centrali comunicano tra loro tramite TCP. Le notifiche vengono inviate dal sito remoto a quello centrale. La centrale conferma ai remoti che le notifiche sono state ricevute, evitando così che le notifiche vadano perse anche in caso di interruzione della connessione TCP.

Esistono due alternative per la creazione di una connessione TCP:

Di conseguenza, non c'è nulla che impedisca di inoltrare le notifiche se per motivi di rete è possibile stabilire connessioni solo in una direzione specifica. Le connessioni TCP sono supervisionate dallo spooler di notifica con un segnale heartbeat e vengono immediatamente ristabilite se necessario, non solo in caso di notifica.

Poiché il sito remoto e quello centrale richiedono impostazioni globali diverse, è necessario effettuareimpostazioni specifiche per tutti i telecomandi. La configurazione del sito centrale viene eseguita utilizzando le normali impostazioni globali. Nota: queste impostazioni verranno ereditate automaticamente da tutti i telecomandi per i quali non sono state definite impostazioni specifiche.

Vediamo prima un esempio in cui il sito centrale stabilisce le connessioni TCP con i siti remoti.

Passo 1: sul sito remoto, modifica l'impostazione globale specifica del sitoNotifications > Notification Spooler Configuration e attivaAccept incoming TCP connections. La porta TCP 6555 sarà consigliata per le connessioni in entrata. Se non ci sono obiezioni, adotta queste impostazioni.

Fase 2: Ora, allo stesso modo, nel sottomenu Notification Spooling solo sul sito remoto, seleziona l'opzioneForward to remote site by notification spooler.

Fase 3: ora, sul sito centrale, cioè nelle normali impostazioni globali, configura la connessione al sito remoto (e poi ad altri telecomandi se necessario):

Fase 4: imposta l'impostazione globale Notification Spooling suAsynchronous local delivery by notification spooler, in modo che anche le comunicazioni del sito centrale vengano processate attraverso lo stesso spooler centrale.

Passo 5: attiva le modifiche.

Se la connessione TCP deve essere stabilita da un sito remoto, la procedura è identica e differisce solo dalla descrizione precedente per il semplice scambio dei ruoli di sito centrale e remoto.

È possibile anche una combinazione delle due procedure. In questo caso, il sito centrale deve essere installato in modo da ascoltare le connessioni in entrata e connettersi ai siti remoti. Tuttavia, in ogni relazione centrale/remotasolo uno dei due è autorizzato a stabilire la connessione!

Lo spooler di notifica registra nel file var/log/mknotifyd.log. Nella configurazione dello spooler è possibile aumentare il livello di log in modo da ricevere un maggior numero di messaggi. Con un livello di log standard si dovrebbe vedere qualcosa di simile sul sito centrale:

In ogni momento il file var/log/mknotifyd.state contiene lo stato attuale dello spooler e di tutte le sue connessioni:

Una versione dello stesso file è presente anche sul sito remoto, dove la connessione avrà un aspetto simile a questo:

Per testare, seleziona un qualsiasi servizio remoto monitorato e impostalo manualmente su CRIT con il comando Fake check results.

Ora sul sito centrale dovrebbe apparire una notifica in arrivo nel file di log delle notifiche (notify.log):

Lo stesso evento apparirà come segue sul sito remoto:

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

Dopo aver configurato tutto come descritto, noterai che sul sito centrale, e rispettivamente sui remoti, sarà presente un nuovo servizio che dovrà essere assolutamente monitorato. Ogni connessione sarà quindi monitorata due volte: una volta dal sito centrale e una volta dal sito remoto: