Checkmk da riga di comando

Quando amministri Checkmk, a parte alcune eccezioni, non devi mai lavorare come utente di root. In questo articolo assumeremo generalmente che tu sia loggato come utente dell'istanza. Questo si fa con, es:

È anche possibile effettuare un login SSH diretto a un sito senza passare per root. Poiché l'utente dell'istanza è un utente Linux "completamente normale", devi semplicemente assegnare una password (il che richiede i permessi di root, una sola volta, per la configurazione):

Successivamente dovrebbe essere possibile effettuare un login SSH direttamente da un altro computer (gli utenti Windows preferiscono utilizzare PuTTY). Da Linux questo login viene effettuato semplicemente dalla linea di comando utilizzando il comando ssh:

Al primo login verrà probabilmente ricevuto un "avviso" relativo a una chiave host sconosciuta. Quando sei sicuro che in questo breve momento nessun malintenzionato si sia impossessato dell'indirizzo IP del tuo sistema operativo, puoi semplicemente verificarlo con yes.

Puoi anche lavorare con la linea di comando della Checkmk Appliance. Le modalità di esecuzione sono spiegate in un apposito articolo.

Affinché si verifichino il minor numero possibile di problemi, in particolare a causa di distribuzioni individuali o configurazioni diverse del sistema operativo, il sistema Checkmk fa in modo che l'utente dell'istanza - e allo stesso modo tutti i processi del monitoraggio - abbiano sempre un ambiente chiaramente definito. Oltre alla directory home e ai permessi, le variabili d'ambiente svolgono un ruolo importante.

Tra le altre cose, quando si effettua il log-in come utente dell'istanza, vengono impostate o modificate le seguenti variabili. Queste variabili sono disponibili per l'utilizzo in tutti i processi in esecuzione all'interno del sito. Questo vale anche per gli script che vengono invocati indirettamente da questi processi (ad esempio, gli script di notifica dell'utente).

Con il comando env puoi ottenere l'output di tutte le variabili d'ambiente - aggiungendo | sort a questo comando l'elenco è più chiaro:

In Linux l'ambiente è un attributo di un processo. Ogni processo ha le proprie variabili che trasmette automaticamente ai sottoprocessi, i quali iniziano inizialmente con le stesse variabili ereditate, ma possono anche modificarle.

Con il comando env puoi sempre visualizzare solo l'ambiente della shell corrente. Se sospetti che ci sia un errore nell'ambiente di un particolare processo, con un piccolo trucco puoi comunque produrre un elenco del suo ambiente. A questo scopo ti serve solo l'identificatore del processo (ID), che puoi identificare con, ad es. ps ax, pstree -p o top. Con questo comando puoi accedere al file environ del processo direttamente tramite il file system /proc. Ecco un esempio di comando adatto al PID 13222:

Se hai bisogno di variabili personalizzate per i tuoi script o altri software da eseguire nel sito, memorizzale nel file etc/environment che è stato creato appositamente per questo scopo. Tutte le variabili definite qui saranno disponibili ovunque nel sito:

Se desideri personalizzare la tua shell (Prompt o altro), puoi farlo come al solito nel file .bashrc. Le variabili d'ambiente appartengono comunque aetc/environment, quindi sono sicuramente disponibili per tutti i processi.

Inoltre, nulla ti impedisce di avere un tuo file .vimrc se ti piace lavorare con VIM.

Il grafico seguente mostra le directory più importanti di un'installazione di Checkmk con un sito chiamato mysite e un <version> chiamato ad esempio 2.0.0p8.cee:

La base di questa struttura è costituita dalla directory /omd. Senza eccezioni, tutti i file di Checkmk si trovano qui./omd è in realtà un link simbolico a /opt/omd, mentre i dati fisiciveri e propri si trovano in /opt - ma tutti i percorsi dei dati in Checkmk utilizzano sempre /omd.

È importante la separazione tra dati (evidenziati in giallo) e software (in blu): i dati del sito si trovano in /omd/sites e il software installato in /omd/versions.

Come ogni utente dell'istanza Linux, anche l'utente del sito ha una directory home, a cui ci riferiamo come directory del sito. Se il tuo sito si chiamamysite, si troverà in /omd/sites/mysite. Come di consueto in Linux, la shell abbrevia la propria directory home con una tilde (~) (o trattino mobile). Poiché subito dopo il login ti troverai in questa directory, la tilde appare automaticamente nel prompt di input:

Le sottodirectory della directory del sito sono indicate rispetto alla tilde:

All'interno della directory del sito sono presenti diverse sottodirectory, che possono essere elencate con ll:

Come si può notare, le directory bin, include, lib,share e version sono collegamenti simbolici, mentre le altre sono directory "normali". Questo rispecchia la separazione tra software e dati spiegata in precedenza. La directory software deve essere accessibile come sottodirectory nel sito, ma si trova fisicamente in /omd/versions e può essere utilizzata anche da altri siti.

Le directory software, come di consueto in Linux, appartengono a roote quindi non possono essere modificate dall'utente dell'istanza. Sono presenti le seguenti sottodirectory: quelle dell'esempio si trovano fisicamente all'interno di/omd/versions/2.0.0p8.cee e sono accessibili tramite link simbolici dalla directory del sito:

Il link simbolico version/ è una "tappa intermedia" e serve come punto di collegamento per la versione utilizzata dal sito. Durante un aggiornamento del software verrà switchato dalla vecchia alla nuova versione. Tuttavia, ti invitiamo a non tentare di eseguire un aggiornamento manualmente modificando il link, poiché l'aggiornamento richiede una serie di altri passaggi che non andranno a buon fine.

I dati effettivi di un sito si trovano nelle altre sottodirectory della directory del sito. Senza eccezioni, queste appartengono all'utente dell'istanza. Anche la directory del sito è inclusa. Checkmk non memorizza nulla oltre alle directory elencate. Puoi creare senza problemi i tuoi file e le tue directory in cui conservare i test, i dati scaricati, le copie dei file di log e così via.

Le seguenti directory sono state predefinite:

Come mostrato nella tabella precedente, la directory local con le sue numerose sottodirectory è destinata alle tue estensioni. In un nuovo sito, tutte le directory di local/ sono inizialmente vuote.

Con il pratico comando tree puoi ottenere rapidamente una panoramica della struttura di local. L'opzione -L 3 limita la profondità a 3:

Tutte le directory del livello più basso sono integrate attivamente nel software. Un file memorizzato qui sarà trattato come se si trovasse nella directory con lo stesso nome all'interno di /omd/versions/…​ (o rispettivamente nel percorso logico dal sito sotto bin, lib o share).

Esempio: Nel sito, i programmi eseguibili verranno cercati in bine in local/bin.

In questo caso vale il principio che, in caso di nomi identici, il file in localha sempre la priorità. Questo permette di modificare il software senza dover cambiare i file di installazione in /omd/versions/. La procedura è semplice:

Per quanto riguarda il punto 3, se non si sa esattamente a quale servizio si applica la modifica, è sufficiente riavviare l'intero sito con omd restart.

In Checkmk - come già descritto - i file di log sono archiviati nelladirectory var/. Tutti i file di log dei componenti rilevanti si trovano lì:

Nell'interfaccia web puoi facilmente configurare la misura in cui i dati devono essere scritti nei file di log cercando in Setup > General > Global settings tutte le voci con logging:

In alternativa, è possibile personalizzare i livelli di log anche da linea di comando in file di configurazione. I file si chiamano global.mk, ma si trovano in directory diverse. Specifica le voci se non sono già presenti, nel caso in cui un Factory setting non sia ancora stato modificato.

In questo file vengono impostate le voci Monitoring Core, Notifications e Alert Handlers:

In questo file di log puoi impostare il log di User Interface.

Il livello di log più basso è 50 (Critical) mentre la maggior parte dei dati verrà registrata a 10, che corrisponde al livello più alto (Debug).

Questo file viene utilizzato per Livestatus Proxy logging. I valori possibili qui corrispondono a quelli per il log User Interface.

Importante: I file di log possono diventare rapidamente molto grandi se è stato impostato un livello elevato. In genere è consigliabile utilizzare queste impostazioni per una personalizzazione "temporanea", ad esempio come aiuto nell'identificazione dei problemi.

Il comando cmk è in realtà un'abbreviazione di check_mk, introdotta per rendere più veloce la digitazione del comando. Il comando include una guida in linea integrata e molto dettagliata, che può essere richiamata con l'opzione --help:

Come puoi vedere nel comando qui sopra, abbiamo richiamato l'aiuto con l'opzione -h invece di --help. Perché ciò che è vero per il comando stesso è vero anche per le sue opzioni: Non per tutte le opzioni, ma per quelle che sono spesso necessarie, esiste una forma breve oltre a quella lunga. Anche se la forma lunga è più intuitiva, soprattutto per i principianti (check_mk --list-hosts) rispetto a quella breve (cmk -l), nella Guida per principianti utilizzeremo quella breve. In caso di dubbio, puoi sempre consultare la guida del comando. In ogni caso, è consigliabile dare un'occhiata alla guida del comando, poiché non presenteremo tutte le opzioni nella guida dell'utente.

Inserendo un'opzione, avvii il comando cmk in una determinata modalità. Di seguito trovi una panoramica delle opzioni che presenteremo in questo capitolo, ma anche in altre parti del manuale:

In alcune modalità sono disponibili ulteriori opzioni specifiche, ad esempio puoi limitare la scoperta del servizio a determinati controlli, ad es. al controllo df con il comando cmk -I --detect-plugins=df myserver123.

Alcune opzioni funzionano sempre, indipendentemente dalla modalità di esecuzione del comando:

Nella sezione seguente mostreremo come possono essere utilizzati i comandi. Gli esempi sono mostrati per lo più in forma abbreviata.

Le edizioni commerciali utilizzano Checkmk Micro Core (CMC) come nucleo di monitoraggio, mentre Checkmk Raw utilizza Nagios. Un compito importante di cmk è la generazione di un file di configurazione leggibile per il nucleo e contenente tutti gli host, i servizi, i contatti, i gruppi di contatti, i periodi di tempo, ecc. configurati. Sulla base di queste informazioni, il core sa quali controlli devono essere eseguiti e quali oggetti deve fornire utilizzando il Livestatus della GUI.

Sia per Nagios che per il CMC, è fondamentale che il numero di host, servizi e altri oggetti rimanga sempre statico durante l'operazione e che questo numero possa essere modificato solo attraverso la generazione di una nuova configurazione, seguita da un ricaricamento del core. Con Nagios è necessario anche un riavvio del core. Il CMC ha una funzione molto efficiente per ricaricare la configurazione durante il processo attivo.

La tabella seguente evidenzia le differenze più importanti tra le configurazioni dei due core:

La rigenerazione della configurazione è sempre necessaria se il contenuto del file di configurazione in etc/check_mk/conf.d o i servizi rilevati automaticamente in var/check_mk/autochecks sono stati modificati. Il Setup tiene traccia di tali modifiche e le evidenzia nella GUI per attivare le modifiche. Nel caso in cui dovessi "aggirare il Setup" modificando la configurazione manualmente o con uno script, dovrai occuparti anche dell'attivazione manualmente. I seguenti comandi svolgono questa funzione:

Per riassumere: Se vuoi personalizzare la configurazione di Checkmk e attivare le modifiche, in Nagios dovrai successivamente richiedere:

E con la CMC:

Una seconda modalità di Checkmk riguarda l'esecuzione dei controlli basati su Checkmk di un host. Con questa modalità puoi permettere a tutti i servizi rilevati automaticamente e configurati manualmente di essere controllati immediatamente, senza doverti preoccupare del nucleo di monitoraggio o della GUI.

Per farlo, inserisci cmk --check seguito dal nome di un host configurato nel monitoraggio. Dato che l'opzione --check è l'opzione predefinita di cmk, puoi anche ometterla. Inoltre, dovresti sempre aggiungere le due opzioni -n (non inviare i risultati al core) e -v (inviare tutti i risultati). Per saperne di più, leggi la descrizione delle opzioni qui sotto.

Altri suggerimenti:

Le seguenti opzioni influenzano il comando:

Il comando cmk -d recupera e visualizza l'output dell'agente Checkmk di un host. Con cmk -d i dati dell'agente vengono recuperati allo stesso modo del monitoraggio. Non vengono né convalidati né processati. Pertanto i dati mostrati corrispondono esattamente a quelli che vengono trasmessi all'Agent Controller (quando è abilitata la crittografia TLS) o a un programma di tunneling nel caso in cui siano configurati programmi datasource.

Puoi anche eseguire cmk -d utilizzando il nome o l'indirizzo IP di un host non configurato nel monitoraggio. In questo caso verranno assunte le impostazioni tradizionali dell'host (connessione TCP alla porta 6556, nessun Agent Controller, nessuna crittografia, nessun programma datasource).

Nelle edizioni commerciali puoi anche creare gli agenti dalla linea di comando, come faresti altrimenti tramite l'interfaccia web. Questo ti dà la possibilità, ad esempio, di aggiornare regolarmente gli agenti, ad esempio tramite un cronjob.

Per creare gli agenti, usa l'opzione -A seguita dal nome di un host (o di più host):

L'output mostra che i pacchetti di agenti disponibili per l'host myserver123 sono stati preparati con successo. Se non specifichi un host, i pacchetti verranno creati per tutti gli host.

Il comando esegue il bake solo quando è necessario. Se i pacchetti sono ancora aggiornati, l'output sarà simile a questo:

Puoi comunque forzare la cottura con l'opzione -f (force).

Il comando cmk -l elenca semplicemente i nomi di tutti gli host configurati nel Setup:

Poiché i dati vengono forniti "nudi" e "non elaborati", è facile utilizzarli negli script: ad esempio è possibile costruire un ciclo su tutti i nomi host:

Se al posto di echo inserisci un comando che esegua qualcosa di significativo, questo può essere davvero utile.

Anche l'invocazione cmk --list-tag fornisce i nomi host, ma offre anche la possibilità di filtrare in base ai tag degli host. Basta inserire un tag host e riceverai tutti gli host che hanno questo tag. L'esempio seguente elenca tutti gli host monitorati da SNMP:

Se inserisci più tag, questi verranno collegati con "e". Il comando seguente fornisce tutti gli host monitorati sia dagli agenti SNMP che da Checkmk. Poiché nessun host soddisfa questa condizione, l'output rimane vuoto:

Per uno o più host specificati, cmk -D mostra i servizi configurati, le etichette dell'host, le etichette e altri attributi. Dato che l'elenco dei servizi è così ampio, il terminale può creare un po' di confusione. Invia l'output attraverso less -S per evitare un'interruzione:

Checkmk fornisce di serie un gran numero di plug-in pronti all'uso. In ogni versione ne vengono aggiunti alcuni nuovi e la versione 2.0.0 include già circa 2.000 plug-in. Tre opzioni del comando cmk ti permettono di accedere alle informazioni su questi plug-in.

cmk -L produce una tabella di tutti i plug-in con il loro nome, il tipo e una descrizione. Allo stesso tempo, vengono elencati anche i plug-in scritti in proprio memorizzati in local/.

I tipi possibili sono i seguenti:

Naturalmente l'elenco può essere filtrato semplicemente con grep se si cerca qualcosa di specifico:

Se vuoi maggiori informazioni su un determinato plug-in, la documentazione come pagina di manuale (o pagina man) può essere richiamata con cmk -M:

Questo produce il seguente output:

Utilizzando cmk -m senza altre opzioni, si accede a un catalogo completo di tutte le pagine man dei plug-in di controllo.

Puoi navigare in modo interattivo in questo catalogo:

Se ti aspetti un compendio completo sulla struttura esatta di tutti i file di configurazione utilizzati da Checkmk, purtroppo dobbiamo deluderti. La complessità e la diversità dei file di configurazione è semplicemente troppo grande per essere descritta completamente in questo manuale d'uso.

L'esempio seguente mostra un set completo di parametri del check plug-in che monitora i file system in Checkmk. A causa dei numerosi parametri, la schermata è divisa in due parti ed è impostata con caratteri minuscoli:

Il passaggio corrispondente nel file di configurazione si presenta così (con una formattazione un po' più gradevole):

Come si può notare, ci sono più di 10 parametri diversi, ognuno con una propria logica. Alcuni sono configurati con numeri in virgola mobile (0.8), altri con numeri interi (24), altri ancora con keyword ('onlow'), altri con valori booleani (True) e altri ancora con tuple per codificare varie combinazioni di questi ((5.0, 10.0)).

Questo è solo un esempio di oltre 2.000 plug-in. E naturalmente sono possibili altre configurazioni come parametri del check: Basti pensare ai periodi di tempo, alle regole della Console degli Eventi, ai profili degli utenti e molto altro ancora.

Naturalmente questo non significa che non si possano usare i file di testo come parametri di configurazione: se non conosci ancora la sintassi esatta per l'attività di configurazione che hai scelto, ti basta avere a disposizione lo strumento giusto, che noi chiamiamo Setup:

In questo modo, devi solo sapere in quale file scrive Setup.

Nota: quando si parla di nomi di directory, file o anche di contenuti di file, troverai spesso il termine wato. Setup W ATO è l'abbreviazione di Web Administration Tool: lo strumento di configurazione di Checkmk fino alla versione 1.6.0 inclusa. A partire dalla versione 2.0.0, la funzione di WATO è stata assunta dal menu di configurazione, o UP. Sebbene WATO sia stato (quasi) completamente sostituito da Setup nell'interfaccia web, continua a vivere nel file system.

Esiste un comando pratico per scoprire quale file Setup ha appena modificato: find. Invocando "find" con i seguenti parametri puoi trovare tutti i file (-type f) sotto etc/ che sono stati modificati nell'ultimo minuto (-mmin -1):

La base di una configurazione è sempre la directory etc/check_mk. Al di sotto di questa c'è una suddivisione in vari domini, che generalmente si riferiscono a un servizio specifico. Allo stesso tempo, ognuno di essi ha una directory con il suffisso .d, sotto la quale verranno letti automaticamente tutti i file con il suffisso .mk in ordine alfabetico. In alcuni di essi ci sarà anche un file principale che viene letto per primo. Quest'ultimo è destinato solo alla modifica manuale e non viene mai modificato da Setup.

Al di sotto delle directory di configurazione .d/ c'è sempre la sottodirectory wato, ad es. etc/check_mk/conf.d/wato. Il servizio di Setup fondamentalmente legge e scrive solo qui. Tuttavia, il servizio responsabile della directory di configurazione legge anche gli altri file nella "sua" directory .d, se vi hai memorizzato dei file creati manualmente. Ciò significa che:

Dal punto di vista puramente formale, tutti i file di configurazione di Checkmk sono scritti con la sintassi di Python 3. Esistono due tipi di file:

I file eseguibili si riconoscono per la presenza di variabili che vengono sostituite da assegnazioni con valori (=). Gli altri file contengono solitamente un dizionario Python che inizia con una parentesi di apertura {. A volte si tratta di semplici valori.

Se in un file è richiesto un carattere non ASCII (un Umlaut tedesco (ä, ö, ü), per esempio), il seguente commento deve essere codificato nella prima o nella seconda riga:

Altrimenti si verificherà un errore di sintassi durante la lettura del file. Per ulteriori suggerimenti sulla sintassi di Python ti consigliamo di visitare un sito specializzato, ad esempio:The Python Language Reference.

Se modifichi manualmente i file di configurazione in etc/check_mk/, è bene che la configurazione venga controllata. Puoi farlo con lo strumento cmk-update-config, che in realtà viene eseguito automaticamente solo dopo un aggiornamento di versione con omd update:

Ad esempio, nell'estratto qui sopra puoi vedere il riferimento a una parentesi non chiusa.