Recupero dei dati di stato tramite Livestatus

L'accesso a Livestatus avviene tramite un socket Unix utilizzando il Livestatus Query Language (LQL). La sua sintassi si basa su HTTP.

Tramite la riga di comando ci sono diversi modi per accedere all'interfaccia. Una possibilità è usare i comandi printf e unixcat per inviare un'istruzione al socket. Lo strumento unixcat è già incluso in Checkmk per l'utente instance. Importante: tutti gli input al socket distinguono tra maiuscole e minuscole, quindi bisogna sempre tenerlo presente:

L'interfaccia richiede che tutti i comandi e le intestazioni siano su una riga separata. Puoi contrassegnare tale interruzione di riga con \n. In alternativa al comando sopra, puoi anche usare il comando di script lq, che ti risparmia un po' di lavoro completando automaticamente alcuni campi durante l'inserimento:

Oppure puoi avviare il flusso di immissione interattivo e inserire il comando seguito dall'intestazione. Con una riga vuota esegui il comando con la sua intestazione, e con un'ulteriore riga l'accesso al socket viene terminato. Nota che nell'esempio, tutto ciò che precede la riga vuota appartiene al comando, e tutto ciò che si trova tra la prima e la seconda riga vuota è la risposta:

Gli esempi seguenti vengono sempre eseguiti con il comando lq – nel modulo diretto quando la query è breve, e come flusso di immissione per query più lunghe.

Dato che Checkmk si basa in gran parte su Python, gli script in questo linguaggio sono molto pratici. Lo script seguente può essere usato come base per accedere al socket Livestatus:

Checkmk fornisce anche un'API per il linguaggio di programmazione Python, che semplifica l'accesso a Livestatus. Per questa API è disponibile un codice di esempio che ne spiega l'utilizzo. Puoi trovare questa API su GitHub.

Negli esempi che abbiamo visto finora, sono state interrogate TUTTE le informazioni per TUTTI gli host. In pratica, però, probabilmente ti serviranno solo colonne specifiche. Con l'intestazione Columns già menzionata, l'output può essere limitato a questa colonna. I nomi delle singole colonne saranno separati da un semplice carattere spazio.

Come puoi vedere, in una riga i singoli valori sono separati da un punto e virgola.

Per limitare la query a righe specifiche, è possibile filtrare le colonne in base a contenuti specifici. Se si desidera cercare solo servizi con uno stato specifico, è possibile farlo con un filtro:

Nell'esempio verranno cercati tutti i servizi con stato "CRIT" e verranno visualizzati il nome host, la descrizione del servizio e il suo stato. Questi filtri possono ovviamente essere combinati e limitati ai servizi con stato "CRIT" che non sono ancora stati sottoposti a conferma:

Come puoi vedere, puoi anche filtrare per colonne che non sono presenti nell'elenco di Columns.

Puoi usare l'intestazione OrderBy per ordinare l'output in base al contenuto di qualsiasi colonna o anche ai valori di qualsiasi chiave del dizionario. Questo ti permette di creare un elenco alfabetico di tutti gli host, ad esempio:

Implicitamente, l'output viene ordinato in ordine crescente (asc) come previsto. Tuttavia, puoi anche specificare esplicitamente l'ordinamento desiderato e invertirlo specificando desc`:

Con query leggermente più lunghe e ordinando, ad esempio, i dati sulla performance, è possibile creare interessanti elenchi. Nell'esempio seguente, gli host vengono visualizzati in ordine decrescente in base al loro tempo di attività:

Alcune colonne di una tabella restituiscono non solo un singolo valore, ma un intero elenco di valori. Affinché tale elenco possa essere cercato in modo efficace, in questi casi gli operatori hanno un'altra funzione. Un elenco completo degli operatori è disponibile alla voce Operatori per elenchi. Ad esempio, l'operatore >= ha la funzione "contiene". Con questo potresti, ad esempio, cercare contatti specifici:

Come si può vedere nell'esempio sopra, i contatti saranno elencati, separati da virgole, nella colonna contacts. Questo permette di distinguerli chiaramente in modo che non sembrino l'inizio di un'altra colonna. Una caratteristica speciale dell'operatore di uguaglianza è che checka se un elenco è vuoto:

Diversi filtri sono già stati combinati in precedenza. Sembrerebbe intuitivo che i dati debbano passare attraverso tutti i filtri per essere visualizzati. I filtri saranno quindi collegati dall'operazione logica "e". Per collegare determinati filtri con un "o" logico, alla fine della stringa del filtro digita "o:" seguito da un numero intero. Il contatore specifica quante delle ultime righe possono essere combinate con un "o". In questo modo è possibile formare gruppi e combinarli come richiesto. Ecco un semplice esempio. Qui vengono combinati due filtri in modo che vengano visualizzati tutti i servizi che hanno lo stato " WARN" o "SCONOSCIUTO":

Il risultato di una combinazione può anche essere negato, oppure i gruppi possono a loro volta essere combinati in altri gruppi. Nell'esempio vengono visualizzati tutti i servizi il cui stato non è OK e la cui descrizione inizia con Filesystem oppure che hanno uno stato diverso da SCONOSCIUTO:

Il formato di output può essere specificato in due modi. Un metodo consiste nel ridefinire i separatori utilizzati nell'output standard. L'altro metodo consiste nell'effettuare l'output in conformità con i formati Python o JSON.

Ci saranno situazioni in cui non ti interessa lo stato di un singolo servizio o di un gruppo di servizi. Molto più importante è il numero di servizi con uno stato "WARN" (in esecuzione), o il numero di database sottoposti a monitoraggio. Livestatus è in grado di generare e visualizzare statistiche con Stats.

L'Overviewe riceve i dati recuperando le statistiche relative a host, servizi ed eventi tramite Livestatus e visualizzandole nell'interfaccia di Checkmk. Con l'accesso diretto a Livestatus puoi creare il tuo riepilogo personalizzato:

A proposito, queste statistiche possono essere combinate con tutti i filtri.

Le statistiche possono anche essere combinate con l'and/or. Le intestazioni vengono quindi chiamate StatsAnd o StatsOr. Usa StatsNegate se l' output deve essere invertito. Nell'esempio verrà visualizzato il numero totale di host (l'Stats iniziale) e, in aggiunta, l'output includerà il conteggio degli host contrassegnati come stale e che non sono nell'elenco del tempo di manutenzione programmata (le statistiche 2 e 3 sono collegate con un 'AND' logico):

Non farti confondere dalle varie opzioni per combinare i risultati dei filtri e delle statistiche. Mentre tutti gli host che soddisfano le condizioni verranno visualizzati con l'intestazione " Filter", con le statistiche l'output sarà la somma di quante volte si applica il filtro "Stats".

È anche possibile eseguire calcoli sui valori e, ad esempio, visualizzare un valore medio o un valore massimo. Un elenco completo di tutti i possibili operatori è disponibile qui.

Nell'esempio seguente l'output fornirà un elenco dei tempi medi, minimi e massimi richiesti dai plug-in di controllo di un host per calcolare uno stato:

I calcoli con le metriche vengono handle in modo un po' speciale. Anche qui sono disponibili tutte le funzioni con l'intestazione Stats. Queste vengono però applicate singolarmente a tutte le metriche di un servizio. Ad esempio, nell'esempio seguente verranno sommate le metriche relative all'utilizzo della CPU di un gruppo di host:

Con la tabella log in Livestatus hai accesso diretto alla cronologia di monitoraggio del nucleo di monitoraggio, così puoi filtrare comodamente eventi specifici usando l'LQL. Le tabelle di disponibilità, ad esempio, vengono generate con l'aiuto di queste tabelle. Per migliorare la panoramica e restringere una query per argomento, hai accesso alle seguenti classi di log:

Semplicemente utilizzando queste classi di log puoi già limitare molto bene il tipo di voce di log da visualizzare. Il periodo di tempo preso in considerazione nella query verrà ulteriormente limitato. Questo è importante perché altrimenti verrebbe cercata l'intera cronologia dell'istanza – il che potrebbe logicamente rallentare notevolmente il sistema a causa del flusso di informazioni.

Un'ulteriore restrizione sensata dell'output sono i (Columns) che devono essere visualizzati per una voce. Nell'esempio qui sotto cercheremo tutte le notifiche che sono state registrate nell'ultima ora:

È possibile influenzare la rotazione dei file e le loro dimensioni massime. Puoi inoltre specificare quante righe di un file devono essere lette prima che Checkmk interrompa l'operazione. Tutto ciò può influire sulla performance delle tue query, a seconda della struttura dell'istanza. Sono disponibili i seguenti tre parametri, che puoi trovare e personalizzare in Setup > General > Global Settings > Monitoring Core:

Per accedere a Livestatus tramite la rete, puoi collegare il socket Unix del processo live status a una porta TCP. In questo modo puoi eseguire script su macchine remote e raccogliere i dati direttamente dal luogo in cui devono essere elaborati.

Quando un'istanza è disattivata, l'accesso tramite TCP può essere abilitato con il comando omd:

Una volta avviata l'istanza, Livestatus via TCP è solitamente attivo sulla porta predefinita 6557. Per i server Checkmk con più istanze che utilizzano Livestatus via TCP, viene scelta la porta inutilizzata immediatamente superiore.

Tutte le impostazioni, come la porta e gli indirizzi IP autorizzati, possono essere configurate tramite omd config. In alternativa, queste impostazioni possono essere effettuate nel Setup. In Checkmk la crittografia SSL della comunicazione Livestatus è abilitata di default:

Se è necessario accedere a Livestatus dall'esterno della tua rete locale, la protezione dell'accesso basata esclusivamente sugli indirizzi IP potrebbe non essere pratica. Il modo più semplice per ottenere un accesso autenticato in questo caso è utilizzare Secure Shell.

Con SSH, hai la possibilità di passare un comando che verrà eseguito sul server remoto:

In alternativa, puoi inoltrare la porta di Livestatus all'host su cui stai lavorando tramite un tunnel SSH:

Se la connessione è stata stabilita, in una seconda sessione della console puoi verificare se è possibile accedere con openssl s_client:

Se questo test ha esito positivo, qualsiasi script che hai scritto per l'accesso diretto alla rete Livestatus può essere utilizzato su localhost.

Livestatus non serve solo per le query sui dati, ma anche per inviare comandi direttamente al core (CMC o Nagios). Un comando corretto include sempre un timestamp: in realtà può essere qualsiasi cosa tu voglia. Dato che verrà utilizzato anche nei log per tracciare l' ora dell'elaborazione, però, è meglio inserire l'ora nel modo più preciso possibile. I comandi senza timestamp verranno ignorati, senza generare un messaggio di errore , ma solo con una semplice voce nell'cmc.log

Affinché il timestamp sia il più preciso possibile, si consiglia di non impostare il comando nel flusso di input, ma piuttosto di emetterlo direttamente. In tale situazione è possibile anche accedere alle variabili e fornire l'ora attuale:

Questo formato funziona sia con il Nagios-Core nell' Comunità Checkmk sia con il CMC nelle edizioni commerciali. Nei due core, tuttavia, i comandi si sovrappongono solo in parte. Un elenco completo dei comandi per il Nagios-Core è disponibile direttamente sul sito web di Nagios. I comandi disponibili per il CMC sono riportati nel Riferimento ai comandi.

Nell'elenco dei comandi la sintassi ha la seguente forma:

Come hai imparato, Checkmk utilizza un formato molto più semplice per l'emissione dei comandi. Per rendere il formato Nagios compatibile con Checkmk, ti servono semplicemente il comando, il timestamp e, se applicabile, le variabili: