 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Perché la riga di comando?
Una volta effettuato l'installazione di un sistema Checkmk, è possibile configurarlo e gestirlo al 100% tramite l'interfaccia web. Ci sono tuttavia situazioni in cui è utile addentrarsi nei meandri della riga di comando, ad esempio:
Questo articolo ti presenterà i comandi, i file e le directory più importanti di Checkmk.
2. L'utente dell’istanza
2.1. Esegui il login come utente dell’istanza
Quando amministri Checkmk, salvo poche eccezioni, non dovrai mai lavorare come utente root.
In questo articolo daremo per scontato che tu abbia effettuato l'accesso come utente dell’istanza.
Questo si fa, ad esempio, con:
È anche possibile effettuare un login SSH diretto a un’istanza senza passare per root.
Dato che l'utente dell’istanza è un utente Linux "del tutto normale", devi semplicemente assegnargli 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 dovrebbero preferibilmente utilizzare PuTTY per questo).
Da Linux questo login viene semplicemente eseguito con il comando ssh:
Al primo login probabilmente riceverai un avviso relativo a una chiave host sconosciuta.
Se sei certo che in quel breve momento nessun hacker abbia preso il controllo dell'indirizzo IP del tuo sistema operativo, puoi semplicemente verificarlo con yes.
Puoi anche lavorare con la riga di comando sull'Checkmk Appliance. Come farlo è spiegato in un articolo a parte.
2.2. Profilo e variabili d'ambiente
Affinché sorgano il minor numero possibile di problemi, in particolare a causa delle singole distribuzioni o delle diverse configurazioni del sistema operativo, il sistema Checkmk garantisce che l'utente dell’istanza – e allo stesso modo tutti i processi di monitoraggio – abbiano sempre un ambiente chiaramente definito. Insieme alla directory home e ai permessi, le variabili d'ambiente giocano un ruolo importante.
Tra le altre cose, quando accedi come utente dell’istanza, le seguenti variabili verranno impostate o modificate. Queste variabili sono disponibili per l'uso in tutti i processi in esecuzione all'interno dell'istanza. Ciò vale anche per gli script richiamati indirettamente da questi processi (ad esempio, gli script di notifica propri dell'utente).
|
Il nome del sito ( |
|
Il percorso della directory dell'istanza ( |
|
Directory in cui verranno cercati i programmi eseguibili.
Ad esempio, Checkmk conserva qui il file |
|
Directory in cui vengono cercate le librerie binarie aggiuntive. Utilizzando questa variabile, Checkmk garantisce che le librerie fornite con Checkmk abbiano la priorità su quelle installate nel normale sistema operativo. |
|
Percorso di ricerca per i moduli Perl. Anche in questo caso, in caso di dubbio, le varianti dei moduli fornite da Checkmk hanno la priorità. |
|
L'impostazione della lingua per i comandi da riga di comando.
Questa impostazione viene ripresa dall'installazione di Linux.
Questa variabile viene automaticamente rimossa nelle istanze del sito e l'impostazione torna all'inglese predefinito!
Questo influisce anche su altre impostazioni regionali.
Rimuovere |
Con il comando env puoi visualizzare tutte le variabili d'ambiente; aggiungendo | sort a questo comando, l'elenco risulterà un po' più chiaro:
In Linux l'ambiente è un attributo di un processo. Ogni processo ha le proprie variabili, che trasmette automaticamente ai sottoprocessi. Questi iniziano inizialmente con le stesse variabili ereditate, ma possono anche modificarle.
Con il comando `env` puoi sempre effettuare la visualizzazione dell'ambiente della shell corrente.
Se sospetti che ci sia un errore nell'ambiente di un particolare processo, con un piccolo trucco puoi comunque visualizzare un elenco del suo ambiente.
Per questo ti serve solo l'ID del processo (PID).
Puoi identificarlo, ad esempio, con ps ax, pstree -p o top.
In questo modo puoi accedere direttamente al file environ del processo tramite il file system /proc.
Ecco, ad esempio, un comando adatto per il PID 13222:
Se hai bisogno di variabili personalizzate per i tuoi script o altri software da eseguire nell'istanza,
salvale nel file ~/etc/environment, creato appositamente per questo scopo.
Tutte le variabili definite qui saranno disponibili ovunque all'interno dell'istanza:
# Custom environment variables
#
# Here you can set environment variables. These will
# be set in interactive mode when logging in as site
# user and also when starting the OMD processes with
# omd start.
#
# This file has shell syntax, but without 'export'.
# Better use quotes if your values contain spaces.
#
# Example:
#
# FOO="bar"
# FOO2="With some spaces"
#
MY_SUPER_VAR=blabla123
MY_OTHER_VAR=10.88.112.172.3. Personalizzazione della shell
Se desideri personalizzare la tua shell (prompt o altre cose), puoi farlo come al solito nel file .bashrc.
Le variabili d'ambiente appartengono comunque a ~/etc/environment, in modo che siano sicuramente disponibili per tutti i processi.
Non c'è nulla che ti impedisca di avere il tuo file .vimrc se ti piace lavorare con Vim.
3. La struttura delle directory
3.1. La separazione tra software e dati
Il grafico seguente mostra le directory più importanti in un'installazione di Checkmk con un'istanza denominata mysite e un <version> chiamato, ad esempio, 2.4.0p24.cee:
La base di questa struttura è fornita dalla directory /omd.
Senza eccezioni, tutti i file di Checkmk si trovano qui.
/omd è in realtà un collegamento simbolico a /opt/omd, mentre i dati fisici effettivi 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 dell’istanza si trovano in /omd/sites/, mentre il software installato in /omd/versions/.
3.2. Directory dell'istanza
Come ogni utente Linux, anche l'utente dell'istanza ha una directory home, che chiamiamo directory dell'istanza.
Se il tuo sito si chiama mysite, lo troverai in /omd/sites/mysite/.
Come di consueto in Linux, la shell abbrevia la propria directory home con una tilde (~) (o trattino).
Dato che subito dopo il login ti troverai effettivamente in questa directory, la tilde appare automaticamente nel prompt di input:
OMD[mysite]:~$Le sottodirectory della directory dell'istanza vengono mostrate relative alla tilde:
All'interno della directory dell'istanza si trovano diverse sottodirectory, che possono essere elencate con ll (alias di ls -l):
Come puoi vedere, le directory bin , include , lib , share e version sono collegamenti simbolici.
Le altre sono directory "normali".
Questo rispecchia la separazione tra software e dati spiegata sopra.
La directory del software deve essere accessibile come sottodirectory all'interno dell'istanza,
ma si trova fisicamente in /omd/versions/ e può essere utilizzata anche da altri siti.
| Software | Dati | |
|---|---|---|
Directory |
|
|
Proprietario |
|
Utente dell’istanza ( |
Creato da |
Installazione di Checkmk |
Creazione, configurazione e monitoraggio dell'istanza |
Ubicazione fisica |
|
|
Tipo di file |
Collegamenti simbolici |
Directory normali |
3.3. Software
Le directory del software, come di consueto in Linux, appartengono a root e quindi non possono essere modificate dagli utenti dell’istanza.
Sono presenti le seguenti sottodirectory: quelle riportate nell'esempio si trovano fisicamente all'interno di /omd/versions/2.4.0p24.cee/ e sono accessibili tramite collegamenti simbolici dalla directory dell'istanza:
|
Directory per i programmi eseguibili.
Qui si trova, ad esempio, il comando |
|
Directory C, plug-in per Apache e Python – e nella sottodirectory |
|
La parte principale del software installato.
In |
|
Contiene file di inclusione per programmi in C, che dovrebbero essere collegati alle librerie in |
Il collegamento simbolico version è una "tappa intermedia" e funge da punto di transito per la versione utilizzata dall'istanza.
Durante un aggiornamento del software, questo verrà switchato dalla versione vecchia a quella nuova.
Tuttavia, non tentare di eseguire un aggiornamento manualmente modificando il collegamento, poiché un aggiornamento richiede una serie di ulteriori passaggi – che falliranno.
3.4. Dati
I dati effettivi di un sito si trovano nelle restanti sottodirectory della directory dell'istanza. Senza eccezioni, questi appartengono all’utente dell’istanza. È inclusa anche la directory dell'istanza stessa. Checkmk non memorizza nulla oltre alle directory elencate lì. Qui puoi creare senza problemi i tuoi file e directory, in cui puoi conservare a tuo piacimento test, dati di scaricamento, copie dei file di log, ecc.
Sono state predefinite le seguenti directory:
|
File di configurazione. |
|
Dati di tempo di esecuzione. |
|
Dati volatili. |
|
Estensioni personalizzate. |
3.5. Modifica ed estensione di Checkmk – i file locali
 |
Alcune affermazioni riportate in questa sezione riguardo alla priorità dei file locali (specifici del sito) rispetto ai file con lo stesso nome nella directory del software non sono più corrette. Aggiorneremo presto le sezioni interessate. |
Come appena mostrato nella tabella sopra, la directory ~/local/ con le sue numerose sottodirectory è destinata alle tue estensioni personalizzate.
In una nuova istanza, tutte le directory in ~/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 al livello più basso sono attivamente integrate nel software.
Un file memorizzato qui verrà trattato come se si trovasse nella directory con lo stesso nome all'interno di /omd/versions/…
(o, rispettivamente, nel percorso logico dall'istanza in ~/bin/, ~/lib/ o ~/share/).
Esempio: nell'istanza, i programmi eseguibili verranno cercati in ~/bin/ e in ~/local/bin/.
In questo caso, se i nomi sono identici, il file in ~/local/ ha sempre la priorità.
Questo permette di modificare il software senza dover cambiare i file di installazione in /omd/versions/.
La procedura è semplice:
Copia il file desiderato nella directory appropriata in
~/local/.Modifica questo file.
Riavvia il servizio corrispondente affinché la modifica abbia effetto.
Per quanto riguarda il punto 3 sopra, se non sai esattamente a quale servizio si applica la modifica, riavvia semplicemente l'intera istanza con omd restart.
3.6. File di log
In Checkmk – come già descritto – i file di log sono memorizzati nella directory dei dati var/.
Lì si trovano i file di log dei componenti rilevanti.
Di seguito è riportato un output abbreviato per una delle edizioni commerciali:
Sull'interfaccia web puoi configurare facilmente la quantità di dati da scrivere nei file di log
cercando in Setup > General > Global settings tutte le voci con logging:
|
I file di log possono diventare rapidamente molto grandi se è stato impostato un livello di log elevato. In genere è consigliabile utilizzare tali impostazioni per una personalizzazione temporanea, ad esempio come ausilio nell'identificazione dei problemi. |
4. Il comando cmk
Insieme al comando omd, che serve per avviare e arrestare le istanze, per la configurazione di base dei componenti
e per avviare un aggiornamento software, cmk è il comando più importante.
Con questo comando puoi creare una configurazione per un nucleo di monitoraggio, eseguire controlli manualmente, effettuare la scoperta del servizio e molto altro ancora.
4.1. Le opzioni del comando
Il comando cmk è in realtà un'abbreviazione di check_mk, introdotta per rendere il comando più veloce da digitare.
Il comando include una guida in linea integrata e molto dettagliata, che può essere richiamata con l'opzion--help:
Come puoi vedere nel comando sopra, abbiamo richiamato la guida con l'opzione -h invece che --help.
Perché ciò che vale per il comando stesso vale anche per le sue opzioni:
meno c'è da digitare, più veloce è.
Non per tutte le opzioni, ma per quelle che servono spesso, c'è quindi un modulo abbreviato oltre a quello lungo.
Anche se il modulo lungo è più intuitivo, soprattutto per i principianti (check_mk --list-hosts) rispetto al modulo abbreviato (cmk -l), useremo il modulo abbreviato nel manuale.
In caso di dubbio, puoi sempre consultare la guida del comando.
Dare un'occhiata più approfondita alla guida del comando è comunque una buona idea, dato che non presenteremo tutte le opzioni nel manuale.
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:
| Opzione | Funzione |
|---|---|
Nucleo di monitoraggio | |
|
|
|
|
|
|
|
|
Controlli | |
|
Esecuzione dei controlli sull'host |
Servizi | |
|
|
|
Esegue il discovery check sull'host, che verifica la presenza di servizi nuovi e scomparsi e di nuove etichette dell'host.
Quando si verifica una modifica, l'host viene "contrassegnato" creando un file con il nome host in |
Agenti | |
|
|
|
|
Diagnostica | |
|
|
|
|
|
|
Informazioni | |
|
Visualizza la versione di Checkmk installata nell'istanza. |
|
|
|
|
|
Visualizzazione della pagina di manuale del plug-in di controllo (in questo caso del plug-in |
Temi speciali | |
|
Cancella la cache DNS e la ricrea. Per i dettagli sulla cache DNS, vedi l'articolo sugli host. Di default, questo comando viene eseguito in un'istanza Checkmk una volta al giorno tramite cronjob. |
|
Elimina tutti i dati piggyback obsoleti nella directory |
|
|
|
Esecuzione di uno SNMP walk dall'host |
|
|
|
|
In alcune modalità sono disponibili ulteriori opzioni specifiche,
ad esempio puoi limitare la scoperta del servizio a determinati controlli, come il controllo df con il comando cmk -I --detect-plugins=df myserver123.
Alcune opzioni funzionano sempre, indipendentemente dalla modalità con cui viene eseguito il comando:
| Opzione | Funzione |
|---|---|
|
Richiede a |
|
Come sopra, ma con ancora più dettagli: "very verbose" |
|
Le informazioni vengono lette dai file di cache, anche se non sono aggiornati.
L'agente viene contattato solo se non esiste alcun file di cache.
I dati dell'agente memorizzati nella cache dell'host si trovano in |
|
Funziona come |
|
Le informazioni vengono sempre recuperate aggiornate, ovvero non vengono utilizzati file di cache. |
|
Per gli host SNMP: invece di accedere all'agente SNMP, questa opzione utilizza un walk SNMP memorizzato, che è stato precedentemente recuperato con |
|
Se si verifica un errore, questa opzione garantisce che non venga più intercettato, ma che venga visualizzata per intero l'eccezione Python originale.
Questa può essere un'informazione importante per lo sviluppatore, poiché mostra la posizione esatta del programma in cui si trova l'errore.
Sarà anche molto utile per individuare gli errori nei plug-in di controllo scritti autonomamente.
Se durante l'esecuzione di |
Nella sezione seguente mostreremo come utilizzare i comandi. Gli output di esempio sono per lo più riportati in forma abbreviata.
4.2. Comandi per il nucleo di monitoraggio
Le edizioni commerciali utilizzano il Checkmk Micro Core (CMC) come nucleo di monitoraggio, mentre la Comunità Checkmk utilizza Nagios.
Un compito importante dell'cmk è la generazione di un file di configurazione leggibile dal nucleo,
che contenga tutti gli host, i servizi, i contatti, i gruppi di contatti, i periodi di tempo, ecc. configurati.
Sulla base di queste informazioni, il nucleo sa quali controlli devono essere eseguiti e quali oggetti deve fornire alla GUI tramite Livestatus.
Sia per Nagios che per il CMC, è fondamentale che il numero di host, servizi e altri oggetti rimanga sempre statico durante il funzionamento, e che questo numero possa essere modificato solo tramite la generazione di una nuova configurazione, seguita da un ricaricamento del core. Con Nagios, questo richiede un riavvio del core. Il CMC dispone di una funzione molto efficiente per il ricaricamento della propria configurazione durante l'elaborazione attiva.
La tabella seguente evidenzia le differenze importanti tra le configurazioni dei due core:
| Nagios | CMC | |
|---|---|---|
File di configurazione |
|
|
Tipo di file |
File di testo con comandi |
Binary file compresso e ottimizzato |
Attivazione |
Riavvio del core |
Comando del core per ricaricare la configurazione |
Comando |
|
|
È sempre necessario rigenerare la configurazione
se sono stati modificati i contenuti dei file di configurazione in ~/etc/check_mk/conf.d o i servizi rilevati automaticamente in ~/var/check_mk/autochecks.
L'Setupe tiene traccia di tali modifiche e le evidenzia nella GUI come modifiche da attivare.
I seguenti comandi sono disponibili per l'attivazione tramite la riga di comando:
| Opzione | Funzione |
|---|---|
|
Genera una nuova configurazione per il core e riavvia il core (analogamente a |
|
Genera la configurazione per il core e la carica senza riavviare l'elaborazione attiva (analogo a |
|
Genera la configurazione per il core senza attivarla. |
|
A scopo diagnostico, questa opzione visualizza la configurazione da generare sull'output standard, senza modificare il file di configurazione effettivo.
Qui puoi inserire un nome host semplicemente per effettuare la visualizzazione della configurazione dell'host (ad es. |
4.3. Esecuzione dei checks
Una seconda modalità in Checkmk riguarda l'esecuzione dei controlli basati su Checkmk di un host. In questo modo puoi consentire che tutti i servizi rilevati automaticamente, e anche quelli configurati manualmente, vengano 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 (visualizza tutti i risultati).
Maggiori informazioni su questo nella descrizione delle opzioni qui sotto.
Altri consigli:
Non utilizzare questo comando su host di produzione monitorati che utilizzano il monitoraggio dei file di log. I messaggi di log vengono inviati una sola volta dagli agenti e può capitare che un comando manuale
cmk -nvli "intercetti", causandone la perdita dal monitoraggio. In tal caso, utilizza l'opzione--no-tcp.Se si utilizza Nagios per il core e si omette l'
-n, l'effetto sarà un aggiornamento immediato dei risultati dei check nel core e nella GUI.Il comando è utile quando sviluppi i tuoi plug-in di controllo, perché consente un test più rapido rispetto all'uso della GUI. Se il controllo fallisce e restituisce un SCONOSCIUTO, l'opzione
--debugpuò aiutarti a individuare il punto del codice in cui si trova il problema.
Le seguenti opzioni influenzano il comando:
| Opzione | Funzione |
|---|---|
|
Output dei risultati del check: Senza questa opzione vedrai solo l'output del servizio di check stesso, e non i risultati degli altri servizi. |
|
Simulazione: i risultati non vengono trasmessi al core, il contatore della performance non viene aggiornato. |
|
Limita l'esecuzione ai plug-in di controllo |
4.4. Recupero dell'output dell'agente
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é elaborati.
Pertanto, i dati mostrati hanno una corrispondenza esatta con quelli trasmessi all'Agent Controller (quando la crittografia TLS è abilitata) o a un programma di tunneling nel caso in cui siano configurati programmi di origine dati.
Puoi anche eseguire cmk -d utilizzando il nome o l'indirizzo IP di un host non configurato nel monitoraggio.
In questo caso verranno applicate le impostazioni legacy per l'host (connessione TCP alla porta 6556, nessun Agent Controller, nessuna crittografia, nessun programma di origine dati).
4.5. Creazione degli agenti
Nelle edizioni commerciali puoi anche eseguire il baking degli agenti dalla riga di comando, come faresti altrimenti tramite l'interfaccia web. Questo ti offre la possibilità, ad esempio, di aggiornare regolarmente gli agenti, ad esempio tramite un cronjob.
Per eseguire il baking degli agenti, usa l'opzione -A seguita dal nome di uno o più host:
L'output mostra che i pacchetti degli agenti disponibili per l'host myserver123 sono stati compilati con successo.
Se non specifichi un host, i pacchetti verranno compilati per tutti gli host.
Il comando esegue il baking solo quando necessario. Se i pacchetti sono ancora aggiornati, l'output sarà simile a questo:
Puoi comunque forzare la compilazione con l'opzione -f (force).
4.6. Elenco degli host
Il comando `cmk -l` crea semplicemente un elenco dei nomi degli host configurati nell'Setup:
Poiché i dati vengono forniti "nudi" e "non elaborati", è facile usarli negli script – ad esempio, puoi creare un ciclo su tutti i nomi host:
Se, invece di echo, inserisci un comando che esegue un'operazione significativa, questo può essere davvero utile.
Anche l'invocazione di cmk --list-tag restituisce i nomi degli host, ma offre anche la possibilità di filtrare in base ai tag host.
Basta inserire un tag host e riceverai tutti gli host che hanno questo tag.
L'esempio seguente fornisce un elenco di tutti gli host monitorati da SNMP:
Inserisci più tag e questi verranno collegati con AND. Il comando qui sotto mostra tutti gli host monitorati sia da SNMP che dall'agente Checkmk. Poiché nessun host soddisfa questa condizione, l'output rimane vuoto:
4.7. Visualizzazione della configurazione dell'host
Per uno o più host specificati, cmk -D visualizza i servizi configurati, i tag host, le etichette e altri attributi.
Poiché l'elenco dei servizi è molto esteso, può sembrare un po' confuso sul terminale.
Invia l'output tramite less -S per evitare un'interruzione:
4.8. Informazioni sui plug-in di controllo
Checkmk fornisce di serie un gran numero di plug-in di controllo pronti all’uso.
In ogni versione ne vengono aggiunti alcuni nuovi, e la versione 2.4.0 include già più di 2.000 plug-in.
Tre opzioni del comando cmk ti danno accesso alle informazioni su questi plug-in.
cmk -L genera un elenco di tutti i plug-in con il loro nome, tipo e una descrizione.
Allo stesso tempo, verranno elencati anche eventuali plug-in scritti da te e memorizzati in ~/local/.
Ecco i tipi disponibili:
|
Valuta i dati provenienti dai plug-in degli agenti o da special agents. L'agente viene (normalmente) recuperato tramite la porta TCP 6556. |
|
Si occupa del monitoraggio dei dispositivi tramite SNMP. |
|
Esegue un active check. Questo include plug-in di terze parti compatibili con Nagios per i quali Checkmk si limita ad adottare la configurazione. |
L'elenco può ovviamente essere filtrato semplicemente con grep se si sta cercando qualcosa di specifico:
Se vuoi maggiori informazioni su un determinato plug-in, puoi richiamare la documentazione sotto forma di pagina di manuale con cmk -M:
Questo produce il seguente output:
Usando cmk -m senza altre opzioni si accede a un catalogo completo di tutte le pagine di manuale dei plugin per i controlli.
Puoi navigare in modo interattivo in questo catalogo:
5. File di configurazione
Conoscere la posizione e la struttura dei file di configurazione può spesso aiutare a risolvere i problemi e a identificare gli errori, ad esempio nelle estensioni sottoposte a scaricamento da Checkmk Exchange o programmate autonomamente.
Il confronto tra Setup e i file di configurazione in questo capitolo non ha lo scopo di incoraggiare la modifica dei file di configurazione tramite script. Se è necessario automatizzare le modifiche alla configurazione, puoi farlo in modo sicuro e senza effetti collaterali utilizzando l'API REST.
|
Non apportare alcuna modifica ai file di configurazione a meno che non ti sia stato espressamente richiesto da un rappresentante dell'assistenza Checkmk, perché… Ci sono dei pericoli! |
5.1. Dove si trova la documentazione?
Non qui. I file di configurazione sono definiti dai componenti che li scrivono e li leggono. In definitiva, solo esaminando il codice sorgente e i test associati è possibile rivelare la struttura della configurazione memorizzata nel file system.
Tieni inoltre presente che i formati dei file di configurazione possono cambiare tra le versioni patch. In questo caso, le routine di migrazione garantiscono la conversione dei formati di dati modificati.
Inoltre, le unità utilizzate potrebbero differire tra la visualizzazione nell'Setupe e la memorizzazione nel file di configurazione. Questo vale, ad esempio, per la visualizzazione di periodi di tempo o temperature.
L'esempio seguente mostra un set completo di parametri per il plug-in di controllo che effettua il monitoraggio dei file system in Checkmk (qui in una versione precedente). A causa dell'elevato numero di parametri, lo screenshot è stato diviso in due parti e impostato con un carattere piccolo:
La sezione corrispondente nel file di configurazione vero e proprio ha questo aspetto (formattata in modo un po' più ordinato):
{ 'inodes_levels' : (10.0, 5.0),
'levels' : (80.0, 90.0),
'levels_low' : (50.0, 60.0),
'magic' : 0.8,
'magic_normsize' : 20,
'show_inodes' : 'onlow',
'show_levels' : 'onmagic',
'show_reserved' : True,
'subtract_reserved' : False,
'trend_mb' : (100, 200),
'trend_perc' : (5.0, 10.0),
'trend_perfdata' : True,
'trend_range' : 24,
'trend_showtimeleft' : True,
'trend_timeleft' : (12, 6)},Come puoi vedere, qui ci sono più di 10 parametri diversi, ognuno dei quali segue una propria logica.
Alcuni sono configurati usando numeri in virgola mobile (0.8), altri usando numeri interi (24), alcuni usando keyword ('onlow'), altri usando valori booleani (True) e infine alcuni usando tuple come ((5.0, 10.0)).
Questo esempio mostra solo uno degli oltre 2.000 plug-in di controllo. Inoltre, Checkmk riconosce 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.
|
Quando si tratta dei nomi delle directory dei file, dei file stessi o persino del contenuto dei file, troverai spesso l'abbreviazione |
5.2. Quale file di configurazione viene utilizzato attualmente?
C'è un comando molto utile per scoprire quale file Setup ha appena modificato: find.
Se lo chiami con i seguenti parametri, troverai tutti i file (-type f) in ~/etc/ che sono stati modificati nell'ultimo minuto (-mmin -1):
La base della configurazione è sempre la directory ~/etc/check_mk/.
Questa è suddivisa in vari domini, la maggior parte dei quali è correlata a una funzionalità specifica.
Ogni dominio ha una directory che termina con .d, da cui tutti i file che terminano con .mk vengono letti automaticamente in ordine alfanumerico.
5.3. File di Setup e configurazione
All’interno delle directory di configurazione .d/ c’è sempre una sottodirectory chiamata wato, ad esempio ~/etc/check_mk/conf.d/wato/.
Di solito, il servizio Setup legge e scrive solo in questa directory.
Tuttavia, il servizio responsabile della directory di configurazione legge anche gli altri file nella “propria” directory .d.
Se i file si trovano al di fuori della directory wato/, sono stati creati manualmente in passato con l'obiettivo di apportare modifiche effettive ma non visibili nell'Setup, oppure sono stati creati da altri componenti di Checkmk.
File e cartelle bloccati
Vari meccanismi di automazione che funzionano all’interno di Checkmk o accedono a Checkmk dall’esterno (ad es. tramite API REST) possono apportare modifiche alla configurazione. In alcuni casi, è auspicabile che gli host e le cartelle creati in questo modo siano visibili e verificabili in Setup, ma non è auspicabile che le modifiche vengano apportate da utenti “umani”. In questi casi, gli host o le cartelle possono essere bloccati.
Puoi riconoscere un file hosts.mk di un host bloccato dalla riga con l'attributo lock:
# Created by WATO
# encoding: utf-8
_lock = True
Quando apri una cartella del genere in Setup, sopra l'elenco degli host verrà visualizzato il seguente messaggio:
Tutte le azioni che richiederebbero una modifica al file hosts.mk vengono quindi bloccate nella GUI.
Questo, tra l'altro, non influisce sulla scoperta del servizio.
I servizi configurati di un host sono memorizzati sotto ~/var/check_mk/autochecks/.
Anche le proprietà delle cartelle possono essere bloccate.
Questo si ottiene tramite una voce nel file .wato della cartella. Nel dizionario del file, la chiave lock avrà quindi il valore True:
{'title': 'My folder',
'attributes': {},
'num_hosts': 1,
'lock': True,
'lock_subfolders': False,
'__id': '7f2a8906d3c3448fac8a379e2d1cec0e'}Se il valore della chiave lock_subfolders è impostato su True, la creazione e l'eliminazione delle sottocartelle viene impedita.
5.4. Contenuto e sintassi dei file
I file di configurazione possono essere file di testo per la visualizzazione con qualsiasi editor, oppure file binary che richiedono strumenti speciali. I file di testo seguono la sintassi Python, ma ci sono delle differenze nel modo in cui vengono handleati da Checkmk:
I file che contengono assegnazioni di variabili (
=) vengono eseguiti come uno script, ad esempiohosts.mk.I file che contengono solo valori semplici o dizionari Python vengono letti come variabili, ad esempio
.wato.
Per la codifica dei caratteri viene sempre utilizzato UTF-8. Se per qualsiasi motivo devi apportare modifiche, assicurati che il file modificato possa ancora essere analizzato da Python.
I file binari hanno l'estensione .pb, che sta per Protocol Buffers e talvolta viene anche chiamato Protobuf.
Questo formato, sviluppato da Google per serializzare configurazioni e messaggi, può essere scritto e letto con un overhead ridotto.
Tuttavia, per la visualizzazione sono necessari strumenti speciali.
Il pacchetto Checkmk include protoc, che esegue molte operazioni semplici.
Ad esempio, quanto segue fornisce una panoramica "grezza" dell'ultimo stato di un CMC arrestato:
Per un'analisi più dettagliata dei file Protobuf, puoi usare protoscope.
5.5. Verifica dei file di configurazione
Se sospetti che i file di configurazione possano essere danneggiati (ad es. a causa di un supporto dati difettoso), puoi farli checkare.
Checkmk fornisce a questo scopo il programma cmk-validate-config, che, a differenza di cmk-update-config, chiamato durante un aggiornamento del software, non apporta alcuna modifica, come la migrazione dei formati di dati.
cmk-validate-configcontrolla sia la sintassi (parentesi, assegnazioni corrette, ecc.) sia, in parte, la semantica (tipi di dati utilizzati e presenza di determinate chiavi). Se il programma rileva errori di sintassi, verrà visualizzato il primo file danneggiato:
Se i file checkati sono OK, verrà visualizzato un elenco di tutti i file esaminati: