 |
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. Introduzione
I servizi sono la vera "essenza" di un sistema di monitoraggio. Ognuno di essi rappresenta un ingranaggio fondamentale nel tuo complesso panorama IT. L'utilità del monitoraggio complessivo dipende interamente dall'accuratezza e dall'efficacia con cui i servizi sono stati configurati. Infine, il monitoraggio dovrebbe avvisarti in modo affidabile ogni volta che si presenta un problema, ma dovrebbe anche ridurre al minimo le notifiche false o inutili.
Checkmk dimostra forse il suo punto di forza maggiore proprio nella configurazione dei servizi: dispone di un sistema senza pari e molto potente per il rilevamento e la configurazione automatica dei servizi. Con Checkmk non c'è bisogno di definire ogni singolo servizio tramite modelli e assegnazioni individuali. Checkmk è in grado di rilevare in modo automatico e affidabile l'elenco dei servizi da monitorare e, soprattutto, di mantenerlo aggiornato. Questo non solo fa risparmiare un sacco di tempo, ma rende anche il monitoraggio accurato. Assicura che i cambiamenti quotidiani in un data center siano sempre prontamente catturati e che nessun servizio importante rimanga senza monitoraggio.
La scoperta del servizio in Checkmk si basa su un principio fondamentale: la separazione tra "cosa" e "come":
Cosa deve essere monitorato? → Il sistema
/varsull'hostmyserver01Come dovrebbe essere effettuato il monitoraggio? → al 90% di spazio utilizzato WARN, al 95% CRIT
Cosa
viene rilevato automaticamente dalla scoperta del servizio. Si tratta di
una combinazione del nome
host
(myserver01
), del plug-in di controllo
(df:
controllo del sistema dati in Linux) e dell'elemento
(/var
). I plug-in di controllo che possono creare al massimo un servizio su un
host non richiedono un elemento (ad es. il plug-in di controllo per l'utilizzo della CPU). I
risultati di una scoperta del servizio vengono presentati in una tabella come mostrato di seguito:
| Host | Plug-in di controllo | Elemento |
|---|---|---|
|
|
|
|
|
|
|
|
|
… |
… |
… |
|
|
|
… |
… |
… |
Il come — quindi le soglie/i parametri del check per i singoli
servizi — viene configurato in modo indipendente tramite regole. Puoi
ad esempio definire una regola che effettua il monitoraggio di tutti i sistemi di dati con il mount point /var ,
e le soglie del 90% / 95%, senza dover pensare su
quali host esista effettivamente un tale sistema di dati. Questo è ciò che rende la configurazione
con Checkmk così chiara e semplice!
Alcuni servizi non possono essere installati tramite la ricerca automatica. Tra questi ci sono, ad esempio, i controlli interrogati tramite siti web specificati via HTTP. Questi vengono creati tramite regole, come puoi scoprire nell'articolo sui controlli attivi.
L'elenco delle possibilità che Checkmk ha di effettuare il monitoraggio di se stesso è riportato nell'articolo Monitoraggio del proprio sistema.
2. Servizi host nel Setup
2.1. Aggiunta di un nuovo host
Una volta aggiunto un nuovo host nel Setup, il passo successivo è richiamare l'elenco dei servizi. Con questa azione viene eseguita per la prima volta la scoperta del servizio per questo host e, parallelamente, viene verificata l'accessibilità delle sorgenti dati. Puoi richiamare questo elenco in qualsiasi momento anche in seguito, per riavviare la scoperta o per apportare modifiche alla configurazione. Esistono diversi modi per aprire l'elenco dei servizi:
tramite il pulsante
Save & run service discovery nell'Properties of hoste nel Setupnella barra del menu di Properties of host tramite Host > Run service discovery
tramite il simbolo
nell'elenco degli host in una cartella nel Setuptramite la voce
Run service discovery nel menu azione dell'Check_MK Discoverye del servizio di un host
Quando un host è stato appena aggiunto, i suoi servizi non sono ancora stati configurati e quindi tutti i servizi rilevati compaiono nella categoria "Undecided services - currently not monitored":
Il metodo più comune per aggiungere i servizi appena rilevati è semplicemente cliccare sul pulsante "
" (Aggiungi servizi).
In questo modo verranno aggiunte anche tutte le etichette dell'host in un colpo solo.
Dopodiché clicca rapidamente su "Activate changes" (Aggiungi host) — dopodiché l'host sarà sottoposto al monitoraggio.
2.2. Aggiungere i servizi mancanti
Per un host già sottoposto a monitoraggio, questo elenco appare diverso. Al posto di Undecided services - currently not monitored vedrai Monitored services. Se Checkmk rileva qualcosa su un host che non è sottoposto a monitoraggio, ma che invece dovrebbe esserlo, l'elenco apparirà più o meno così:
Cliccando su 
Monitor undecided services o su Accept all si aggiungono semplicemente tutti i servizi mancanti, in modo che il monitoraggio sia nuovamente completo.
Se vuoi aggiungere solo alcuni dei servizi mancanti, puoi in alternativa cliccare sul pulsante per Move to monitored services.
2.3. Servizi scomparsi
Nei data center le cose non solo possono apparire, ma anche scomparire. Un'istanza di database può essere dismessa, un LUN smontato, un file system rimosso, ecc. Checkmk riconosce automaticamente tali servizi come scomparsi. Nell'elenco dei servizi, ad esempio, apparirà così:
Il modo più semplice per liberarti di questi servizi è di nuovo cliccando su Accept all oppure cliccando sul pulsante 
in ogni singola riga,
che sta per Remove vanished services.
Attenzione: il motivo della scomparsa può ovviamente essere dovuto a un problema!
La scomparsa di un file system può anche significare che, a causa di un errore, non è stato possibile montarlo.
Il monitoraggio serve proprio per questi casi!
Dovresti rimuovere il servizio solo quando sei davvero sicuro che non abbia più bisogno di monitoraggio.
2.4. Rimuovere i servizi indesiderati
Non vorrai necessariamente monitorare tutto ciò che Checkmk trova. La ricerca funziona ovviamente in modo mirato e può escludere in anticipo molti dati non necessari. Tuttavia, come può Checkmk sapere, ad esempio, che una particolare istanza di database è stata configurata solo "per giocare", e non è in produzione? Ci sono due modi per eliminare tali servizi:
Disattivazione temporanea dei servizi
Per rimuovere temporaneamente determinati servizi dal monitoraggio, puoi semplicemente cliccare sul simbolo 
.
In questo modo il servizio verrà spostato nell'elenco dei Undecided services.
Oppure puoi anche cliccare sul simbolo 
all'inizio della riga, per disabilitare il servizio.
E naturalmente, non dimenticare il solito Activate changes.
Questo però è pensato solo per azioni temporanee e di piccola entità, poiché i servizi deselezionati in questo modo verranno evidenziati da Checkmk come missing, e anche il discovery check (che ti mostreremo più avanti) darà esito negativo. In ogni caso, sarebbe semplicemente troppo lavoro e non proprio pratico in un ambiente con migliaia di servizi …
Disabilitare i servizi in modo permanente
È molto più elegante e duraturo ignorare in modo permanente i servizi con l’ aiuto del set di regole Disabled services. Qui puoi non solo escludere singoli servizi dal monitoraggio, ma anche formulare regole come “Non voglio monitorare i servizi che iniziano con myservice sull’ host myserver01."
Puoi accedere alla regola tramite Setup > Services > Discovery rules > Discovery and Checkmk settings > Disabled Services.
Una volta salvate le regole e tornato all’elenco dei servizi dell’host, vedrai i servizi disabilitati nella sezione Disabled Services, insieme a qualsiasi servizio che potrebbe essere stato disabilitato manualmente.
2.5. Aggiornamento dei servizi
Esistono diversi plug-in che rilevano determinati aspetti durante la ricerca. Ad esempio, il plug-in per le interfacce di rete controlla la velocità impostata sull' interfaccia durante la ricerca. Perché? Per poterti avvisare nel caso in cui cambi! Raramente è un buon segno quando un'interfaccia è a volte impostata a 10 Mbit/s e a volte a 1 Gbit/s — questo potrebbe piuttosto essere un'indicazione di un'auto-negoziazione difettosa.
Cosa succede quando questa modifica è voluta e deve essere accettata come OK d’
ora in poi?
O — rimuovi il servizio tramite il simbolo , che
sta per Move to undecided services e aggiungilo nuovamente subito
dopo.
Oppure aggiorna tutti i servizi dell’host cliccando su Actions > Remove all
and find new nella barra del menu. Questo è naturalmente molto più semplice, ma solo quando
non vuoi mantenere singoli servizi in uno stato di errore.
2.6. Aggiornamento delle etichette dell'host e delle etichette di servizio
L'aggiornamento delle sole etichette di servizio può essere facilmente effettuato tramite Actions > Host labels > Update host labels e Actions > Services > Update service labels rispettivamente nella barra del menu.
Se è necessario solo aggiungere o aggiornare singole (nuove) etichette di servizio, puoi farlo nella riga del rispettivo servizio nella box Changed services cliccando su 
.
2.7. Condizioni speciali con SNMP
Esistono alcune caratteristiche speciali per i dispositivi monitorati tramite SNMP. Puoi scoprirle nell'articolo dedicato a SNMP.
3. Rilevamento massivo — Rilevamento simultaneo su più host
Se vuoi eseguire una ricerca su più host con un'unica azione, puoi semplificarti il lavoro con le azioni massive di Checkmk. Per prima cosa, scegli gli host su cui eseguire la ricerca. Hai diverse opzioni a disposizione:
In una cartella, seleziona le caselle di controllo dei singoli host e poi clicca su “ Hosts > On selected hosts > Run bulk service discovery” nella barra del menu.
Cerca gli host con la funzione di ricerca host, seleziona tutti gli host nei risultati della ricerca cliccando su "
" e poi di nuovo
su "Hosts > On selected hosts > Run bulk service discovery" nella barra del menu.In una cartella, clicca su "Hosts > In this folder > Run bulk service discovery" nella barra del menu.
Con la terza variante puoi anche eseguire l'operazione di scoperta del servizio in modo ricorsivo in tutte le sottocartelle. In tutte e tre le opzioni sopra indicate, il passo successivo ti porterà alla seguente finestra di dialogo:
Nel menu a discesa "Parameters", l'opzione "Custom service configuration update" è preselezionata. Le quattro checkbox sottostanti offrono esattamente le stesse opzioni che hai nell'elenco dei servizi nel Setup e che abbiamo già spiegato sopra. Nel menu a discesa hai anche la possibilità di selezionare "Refresh all services (tabula rasa)".
In "Selection" puoi nuovamente controllare la selezione degli host. Questo è utile soprattutto se li hai selezionati tramite la cartella anziché tramite le caselle di controllo. La maggior parte delle opzioni ha lo scopo di accelerare la ricerca:
Include all subfolders |
Se hai avviato il rilevamento massivo per tutti gli host in una cartella, questa opzione sarà attiva per impostazione predefinita. La ricerca verrà eseguita su tutti gli host di tutte le sottocartelle. |
Only include hosts that failed on previous discovery |
Gli host per i quali una precedente scoperta del servizio tramite azioni massive è fallita (ad esempio perché l'host non era accessibile in quel momento) vengono contrassegnati con il simbolo |
Only include hosts with a failed discovery check |
Questo limita la ricerca agli host per i quali il discovery check ha dato esito negativo. Quando lavori con il discovery check, questo è un buon metodo per accelerare notevolmente la ricerca su molti host. La combinazione con l'opzione "Refresh all services (tabula rasa)" ha però meno senso in questo caso, poiché può distorcere lo stato dei servizi esistenti. |
Exclude hosts where the agent is unreachable |
Gli host non accessibili causano lunghi ritardi durante la ricerca a causa dei timeout di connessione. Questo può ostacolare notevolmente la performance della ricerca su un numero elevato di host. Se gli host sono già in monitoraggio — e si sa che sono DOWN — puoi bypassarli qui ed evitare così i timeout. |
I Performance Options sono predefiniti in modo da eseguire un'full service scan. Se non sei interessato a nuovi plug-in, puoi accelerare notevolmente la ricerca non selezionando questa opzione.
L'impostazione "10" in "Number of hosts to handle at once" significa che
vengono sempre processati dieci host in un'unica operazione. Ciò viene realizzato internamente
con una richiesta HTTP. Se riscontri problemi di timeout dovuti al fatto che alcuni host
richiedono molto tempo per essere rilevati, puoi provare a impostare un numero inferiore
(a scapito del tempo totale richiesto).
Non appena confermi la finestra di dialogo, la procedura avrà inizio e potrai osservarne l'avanzamento:
4. Controlla i parametri nei servizi
Molti dei plug-in di controllo possono essere configurati tramite parametri. La pratica più comune è l'impostazione di soglie per WARN e CRIT. I parametri possono essere strutturati in modo molto più complesso, come mostra questo esempio di monitoraggio della temperatura con Checkmk:
Il parametro del check per un servizio è composto da tre parti:
Ogni plug-in ha un valore predefinito per il parametro.
Alcuni plug-in impostano i valori durante una ricerca (vedi sopra).
I parametri possono essere impostati tramite regole.
I parametri delle regole hanno la priorità su quelli impostati da una ricerca, e questi a loro volta hanno la priorità sui valori predefiniti. Per i parametri complessi in cui i singoli sottoparametri vengono impostati tramite caselle di controllo (come ad esempio la temperatura ), queste regole di priorità si applicano separatamente per ogni sottoparametro. Quindi, se imposti un solo sottoparametro tramite regole, gli altri mantengono i rispettivi valori predefiniti. In questo modo puoi, ad esempio, attivare il calcolo dell'andamento delle temperature con una regola e, con un'altra regola, impostare il valore di threshold della temperatura per un dispositivo sensore fisico. L'insieme completo di parametri sarà quindi composto da entrambi i set di regole.
I parametri esatti di cui un servizio dispone sono riportati nella pagina dei
parametri del servizio. Puoi accedervi tramite il simbolo
nell'elenco dei servizi dell'host. Se desideri visualizzare i parametri
di tutti i servizi direttamente nella tabella dei servizi, puoi visualizzarli cliccando su
Display > Details > Show check parameters
nella barra del menu. Apparirà
più o meno così:
5. Personalizzazione della scoperta del servizio
Abbiamo già mostrato in precedenza come configurare la scoperta del servizio per nascondere i servizi indesiderati. Inoltre, ci sono ulteriori set di regole per diversi plug-in che influenzano il comportamento della scoperta del servizio con questi plug-in. Non solo ci sono impostazioni per omettere elementi, ma anche quelle che cercano attivamente gli elementi o li raccolgono in gruppi. A volte anche la denominazione degli elementi può essere un problema, ad esempio per quelle porte di commutazione interfacce di rete in cui puoi decidere una descrizione o un alias da utilizzare come elemento (che verrà utilizzato nel nome del servizio) al posto del suo ID di interfaccia.
Tutti i set di regole rilevanti per l’ scoperta del servizio sono disponibili alla voce Setup > Services > Discovery rules. Non confondere questi set di regole con quelli destinati alla parametrizzazione dei servizi effettivi. Diversi plug-in dispongono infatti di due set di regole: uno per la ricerca e uno per i parametri. Ecco alcuni esempi.
5.1. Monitoraggio dei processi
Non avrebbe molto senso per Checkmk definire semplicemente un servizio per il monitoraggio di ogni processo trovato su un host. La maggior parte dei processi non è di alcun interesse o è presente solo temporaneamente. Come minimo ci sono centinaia di processi in esecuzione su un tipico server Linux.
Per i servizi di monitoraggio devi quindi lavorare con i servizi forzati oppure — e questa è una soluzione molto più elegante — utilizzare il set di regole Process discovery per indicare al servizio di scoperta del servizio quali processi deve cercare. In questo modo puoi sempre consentire l’attivazione automatica del monitoraggio quando viene trovato un processo decisamente interessante su un host.
L'immagine seguente mostra una regola nel set di regoleProcess discovery
che
cerca i processi che eseguono il programma/usr/sbin/apache2
.
In questo esempio verrà creato un servizio (Grab user from found processes
)
per ogni utente del sistema operativo per il quale viene trovato un processo di questo tipo.
Il servizio si chiameràApache %u
, dove%u
verrà sostituito dal nome utente. Per la soglia, il numero di istanze del processo
sarà impostato rispettivamente su 1/1 (minimo) e 30/60 (massimo):
Tieni presente che le soglie predefinite sono indicate come Default parameters for detected services. Puoi assegnarle — e allo stesso modo tutti gli altri servizi — tramite regole. Ricorda: le regole sopra riportate configurano la scoperta del servizio — il "cosa". Se i servizi sono presenti per la prima volta, la catena di regole State and count of processes è responsabile delle soglie.
Il fatto di poter impostare le soglie durante una ricerca è un aiuto per maggiore comodità. C'è però un inconveniente: le modifiche alla regola di ricerca hanno effetto solo dal prossimo rilevamento. Se modifichi le soglie, dovrai eseguire un nuovo rilevamento. Se, invece, utilizzi la regola solo per rilevare i servizi (il "cosa") e il set di regole " State and count of processes" per il "come", allora non avrai questo problema.
Per effettuare il monitoraggio di determinati processi o singoli processi su un host Windows, devi semplicemente
indicare il nome del file (compresa l'estensione) senza alcun percorso nel campo "
Executable". Puoi trovare tutti questi nomi nella scheda "Dettagli" del
Task Manager di Windows, ad esempio. Nella regola Process discovery questo potrebbe apparire
così per il processo svchost:
Ulteriori informazioni sulla ricerca dei processi sono disponibili nell'aiuto in linea di questo set di regole. Come sempre, puoi attivarla tramite "Help > Show inline help" nella barra del menu.
5.2. Monitoraggio dei servizi in Windows
L'individuazione e la configurazione del monitoraggio dei servizi Windows è analoga a quella dei processi ed è controllata rispettivamente tramite i set di regole Windows service discovery(cosa) e Windows services (come) . Ecco un esempio di una regola che tiene d'occhio due servizi:
Esattamente come per i processi, anche qui l'individuazione del servizio è solo una delle opzioni. Se, sulla base delle caratteristiche dell'host e delle cartelle, riesci a formulare regole precise per gli host su cui sono previsti servizi specifici, allora puoi anche lavorare con servizi imposti. Questo è indipendente dalla situazione effettivamente riscontrata — può tuttavia richiedere uno sforzo notevolmente maggiore, poiché in queste circostanze sono necessarie molte regole per descrivere esattamente quale servizio ci si deve aspettare su quale host.
5.3. Monitoraggio delle porte degli switch
Checkmk utilizza la stessa logica per il monitoraggio delle interfacce di rete sui server e delle porte sugli switch Ethernet. Con le porte degli switch, le opzioni esistenti per controllare la scoperta del servizio sono particolarmente interessanti, anche se (a differenza dei processi e dei servizi Windows) la scoperta inizialmente funziona senza regole. Ciò significa che, per impostazione predefinita, Checkmk monitora automaticamente tutte le porte fisiche che attualmente hanno uno stato UP. Il set di regole applicabile si chiama "Network interface and switch port discovery" e offre numerose opzioni di configurazione che qui vengono descritte solo brevemente:
Le seguenti opzioni sono le più importanti:
Nella sezione "Appearance of network interface" puoi determinare come deve apparire l'interfaccia nel nome del servizio. Puoi scegliere tra Use description, Use alias e Use index.
La limitazione o l'espansione dei tipi o dei nomi delle interfacce sottoposte a monitoraggio.
6. Configurazione dei servizi obbligatori
Ci sono alcune situazioni in cui la scoperta automatica del servizio non avrebbe alcun senso. Questo è sempre il caso se vuoi imporre il rispetto di una linea guida specifica. Come abbiamo visto nel capitolo precedente, puoi consentire al monitoraggio dei servizi Windows di configurarsi automaticamente quando questi vengono rilevati. Cosa succede quando l'assenza di un servizio di questo tipo rappresenta un problema? Ad esempio:
Un particolare antivirus dovrebbe essere installato su ogni host Windows.
NTP dovrebbe essere configurato su ogni host Linux.
In questi casi puoi semplicemente imporre questi servizi. Trovi il punto di partenza per farlo su Setup > Services > Enforced services. Alla base di questo c'è una raccolta di set di regole che hanno esattamente gli stessi nomi dei set di regole usati per configurare i parametri di questi controlli.
Le regole differiscono tuttavia in due punti:
Si tratta di regole per gli host, non per i servizi. I servizi verranno creati dalle regole.
Poiché non viene effettuato alcun rilevamento, devi selezionare il plug-in di controllo da utilizzare per il controllo.
L'esempio seguente mostra il corpo della regola State of NTP time synchronisation in Enforced services:
Oltre alle soglie, qui si imposta il plug-in di controllo (ad es.chrony
ontp_time
). Per i plug-in di controllo che richiedono un elemento è necessario
specificare anche questi. Ad esempio, ciò è necessario per il plug-inoracle_processes
, che richiede i dettagli del SID del database da sottoporre a monitoraggio:
Un servizio manuale definito in questo modo verrà installato su tutti gli host a cui si applicano queste regole. Ora ci saranno tre possibili condizioni per il monitoraggio effettivo:
L'host è installato correttamente e il servizio è OK.
L'agente segnala che il servizio richiesto non è in esecuzione o presenta un problema. Il servizio viene quindi contrassegnato come "CRIT" o "SCONOSCIUTO".
L'agente non fornisce alcuna informazione, ad esempio perché NTP non è nemmeno installato. Il servizio rimane quindi in IN SOSP e il servizio "Check_MK" passa a "WARN" con l'avviso che manca la sezione pertinente nei dati dell'agente.
Non avrai bisogno della maggior parte dei set di regole nel moduloEnforced services , sono presenti solo per completezza. I casi più comuni di controlli manuali sono:
Monitoraggio dei servizi Windows (Set di regole: Windows Services)
Monitoraggio dei processi (Set di regole: State and count of processes)
7. Il discovery check
Nell'introduzione ti abbiamo promesso che Checkmk non solo rileva automaticamente l'elenco dei servizi, ma è anche in grado di mantenerlo aggiornato. Sarebbe inoltre logico avere la possibilità di eseguire manualmente un rilevamento massivo per tutti gli host di tanto in tanto.
7.1. Check automatico dei servizi non monitorati
Molto meglio per questo, però, è un discovery check regolare, che viene impostato automaticamente sulle nuove istanze. Questo servizio Check_MK Discovery esiste per ogni host e registrerà un avviso ogni volta che trova elementi non monitorati:
I dettagli dei servizi non monitorati o scomparsi si trovano nella pagina dei dettagli del servizio "Check_MK Discovery" nel campo "Details":
Puoi accedere facilmente all'elenco dei servizi dell'host nella configurazione tramite il menu azione di 
del servizio Check_MK Discovery
e la voce Run service discovery.
La configurazione del discovery check si effettua in modo molto semplice utilizzando il set di regole "Periodic service discovery". In un'istanza appena installata, troverai già una regola definita per essere applicata a tutti gli host:
Oltre all'intervallo in cui deve essere eseguito il check, puoi impostare lo stato di monitoraggio per i casi di servizi non monitorati, servizi scomparsi, etichette di servizio modificate e nuove etichette dell'host.
7.2. Aggiunta automatica dei servizi
Puoi fare in modo che il discovery check aggiunga automaticamente i servizi mancanti. A tal fine, attiva l'opzione "Automatically update service configuration", che renderà disponibili ulteriori opzioni.
Oltre alle aggiunte, in "Parameters" puoi anche scegliere di eliminare i servizi scomparsi, o addirittura di eliminare tutti i servizi esistenti ed eseguire una nuova ricerca completa. Quest'ultima opzione si trova nel menu a discesa sotto il nome "Refresh all services and host labels (tabula rasa)". Entrambe queste opzioni devono essere usate con cautela! Un servizio scomparso può indicare un problema! Il discovery check si limiterà a eliminare tale servizio, inducendoti a credere che tutto sia in ordine. L'aggiornamento è particolarmente rischioso. Ad esempio, il controllo delle porte switch includerà nel monitoraggio solo le porte con stato "UP". Le porte con stato "DOWN" saranno considerate scomparse e rapidamente eliminate dal discovery check!
C'è un altro problema da considerare: l'aggiunta di servizi o anche l' Activate Changese automatica può distrarre te — l'amministratore — mentre stai effettuando una configurazione. Teoricamente può succedere che mentre stai lavorando su regole e impostazioni, in quel momento un discovery check attivi le tue modifiche. In Checkmk tutte le modifiche possono essere attivate solo in una volta sola! Per evitare situazioni del genere puoi ripianificare l'orario di questa funzione, ad esempio durante la notte. L'immagine qui sopra ne mostra un esempio.
In "Vanished clustered services" puoi handle separatamente i servizi in cluster. La particolarità qui è che se un servizio in cluster si sposta da un nodo all'altro, potrebbe essere considerato temporaneamente scomparso e quindi cancellato involontariamente. Se invece disattivi questa opzione, i servizi che sono effettivamente scomparsi non verrebbero mai cancellati.
L'impostazione "Group discovery and activation for up to" garantisce che non ogni singolo servizio appena rilevato attivi immediatamente un discovery check di Activate Changes, ma che ci sia un tempo di attesa specificato in modo che più modifiche possano essere attivate in un'unica azione. Anche se il discovery check è impostato su un intervallo di tempo di due ore o più, questo vale solo per ogni host separatamente. I controlli non vengono eseguiti contemporaneamente per ogni host — il che è un bene, dato che un discovery check richiede molte più risorse rispetto a un controllo normale.
8. Servizi passivi
I servizi passivi sono quelli che non vengono avviati attivamente da Checkmk, ma piuttosto dai risultati dei controlli che arrivano regolarmente da fonti esterne. Questo avviene generalmente tramite il comando pipe del core. Ecco una procedura passo passo per creare un servizio passivo:
Per prima cosa, devi notificare il servizio al core. Questo si fa con lo stesso set di regole dei tuoi active checks, tranne che devi omettere l'Command line:
L'immagine mostra anche come puoi verificare se i risultati dei check vengono ricevuti regolarmente. Se questi non compaiono per più di dieci minuti, il servizio verrà automaticamente contrassegnato come SCONOSCIUTO.
Dopo un'Activate Changes, il nuovo servizio inizierà la sua vita nello stato IN SOSP.
L'invio del risultato del check avviene ora dalla riga di comando tramite un'
echoe del comando PROCESS_SERVICE_CHECK_RESULT nel
canale di comando ~/tmp/run/nagios.cmd.
La sintassi è conforme alle consuete convenzioni di Nagios, compreso un
timestamp attuale tra parentesi quadre. Come argomento del comando ti servono
il nome host (ad es. myhost) e il nome del servizio selezionato
(ad es. BAR). I due argomenti successivi sono nuovamente lo stato
(0 … 3) e l'output del plug-in. Il timestamp viene
creato con $(date +%s):
Il servizio ora mostra immediatamente il suo nuovo stato:
9. Scoperta del servizio dalla riga di comando
Una GUI va bene, ma la buona vecchia riga di comando a volte è ancora
pratica, sia che si tratti di automazione o semplicemente perché permette a un utente esperto
di lavorare velocemente. Puoi avviare la scoperta del servizio con il comando cmk
-I dalla riga di comando. Ci sono un paio di variabili in
questo processo. Per tutte queste è consigliata l'opzione -v, così
puoi vedere cosa succede. Senza -v Checkmk si comporta come il buon
vecchio Unix tradizionale: finché tutto va bene, non dice nulla.
Con un semplice "-I" cerca tutti gli host in base ai nuovi servizi:
Con l’-I puoi anche inserire uno o più nomi host per
rilevare solo quelli. Questo ha anche un secondo effetto: mentre
un “-I” su tutti gli host funziona fondamentalmente solo con dati memorizzati nella cache,
Checkmk lavora sempre con dati aggiornati provenienti da un host specificato esplicitamente!
In alternativa, puoi filtrare utilizzando i tag:
Questo eseguirebbe la ricerca per tutti gli host con il tag host mytag.
Il filtraggio con i tag host è disponibile per tutte le opzioni cmk che accettano più host.
Con le opzioni --cache e rispettivamente --no-cache puoi
determinare esplicitamente l'uso della cache.
È possibile ricevere ulteriori output con un secondo -v. Con i dispositivi SNMP
puoi persino vedere ogni singolo OID recuperato dal dispositivo:
È possibile eseguire un rinnovo completo dei servizi (tabula rasa) con un
doppio -II:
Puoi anche limitare tutto questo a un singolo plug-in di controllo. Per farlo, l'
opzione è --detect-plugins= e deve essere inserita prima del nome host:
Quando hai finito, puoi attivare le modifiche concmk -O
(cmk -R
con Nagios Core):
E quando si verifica un errore durante una ricerca…
… con un ulteriore comando `--debug` puoi generare una traccia dettagliata dello stack Python
relativa alla posizione dell'errore:
9.1. Panoramica delle opzioni
Ricapitolando — tutte le opzioni in sintesi:
|
Scopri nuovi servizi |
|
Elimina e rileva nuovamente tutti i servizi (tabula rasa) |
|
Verbose: visualizza host e servizi rilevati |
|
Molto dettagliato: visualizza un protocollo preciso di tutte le operazioni |
|
Esegui una ricerca (e anche una tabula rasa) solo per il plug-in di controllo specificato |
|
Esegui una ricerca (e anche una tabula rasa) solo per gli host con il tag specificato |
|
Forza l'uso dei dati della cache (normalmente l'impostazione predefinita solo quando non è specificato alcun host) |
|
Recupera dati aggiornati (di solito l'impostazione predefinita solo quando è specificato un nome host) |
|
Elimina in caso di errore e visualizza la traccia completa dello stack Python |
|
Attiva le modifiche (edizioni commerciali con CMC come core) |
|
Attiva le modifiche (Comunità Checkmk con Nagios come core) |
9.2. Salvataggio in file
Il risultato della scoperta del servizio — quindi, come spiegato in precedenza, le
tabelle dei nomi host, dei plug-in di controllo, degli elementi e dei parametri identificati — si
trova nella cartella var/check_mk/autochecks. Qui, per ogni
host c'è un set di dati che memorizza i servizi rilevati automaticamente.
Finché non danneggi la sintassi Python di questo set di dati, puoi modificare o
eliminare singole righe manualmente. L'eliminazione del set di dati rimuove tutti i servizi
e li contrassegna nuovamente come quasi "non monitorati".
[
{'check_plugin_name': 'cpu_loads', 'item': None, 'parameters': (5.0, 10.0), 'service_labels': {}},
{'check_plugin_name': 'cpu_threads', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'diskstat', 'item': 'SUMMARY', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'kernel_performance', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'kernel_util', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'livestatus_status', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'lnx_thermal', 'item': 'Zone 0', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mem_linux', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mknotifyd', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mknotifyd', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mounts', 'item': '/', 'parameters': ['errors=remount-ro', 'relatime', 'rw'], 'service_labels': {}},
{'check_plugin_name': 'omd_apache', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'omd_apache', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'tcp_conn_stats', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'timesyncd', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'uptime', 'item': None, 'parameters': {}, 'service_labels': {}},
]10. Gruppi di servizi
10.1. Perché avere i gruppi di servizi?
Finora hai imparato come includere i servizi nel monitoraggio. Ora non ha molto senso dover consultare elenchi di migliaia di servizi e/o dover sempre passare attraverso le visualizzazioni di host. Ad esempio, se vuoi visualizzare tutti i servizi del file system o di aggiornamento insieme, puoi semplicemente creare dei gruppi in modo simile a come fai con i gruppi di host.
I gruppi di servizi ti consentono di mettere più ordine nel monitoraggio tramite le visualizzazioni e le mappe di NagVis, e di attivare notifiche mirate e gestori di avvisi.
A proposito: potresti quasi sempre costruire le visualizzazioni corrispondenti utilizzando esclusivamente i filtri delle visualizzazioni, ma i gruppi di servizi sono organizzati in modo più chiaro e più facili da utilizzare.
10.2. Creazione di gruppi di servizi
Trovi i gruppi di servizi su Setup > Services > Service groups.
Creare un gruppo di servizi è semplice:
Crea un gruppo tramite 
Add group e assegna un nome che non potrà essere modificato in seguito, oltre a un alias significativo:
10.3. Aggiungere servizi a un gruppo di servizi
Per assegnare servizi ai gruppi di servizi hai bisogno del set di regole Assignment of services to service groups. Il modo più veloce per arrivarci è tramite la panoramica dei gruppi di servizi (Setup > Services > Service Groups). Qui basta cliccare su Service Groups > Assign to group > Rules nella barra del menu. In alternativa, puoi ovviamente trovare la regola tramite la ricerca delle regole nel menu Setup, oppure sfogliare Setup > Services > Service monitoring rules > Various > Assignment of services to service groups. Ora usa Create rule in folder per farlo. Per prima cosa specifichi a quale gruppo di servizi assegnare i servizi, ad esempio myservicegroup o il suo alias My service group 1.
La parte interessante segue ora nella sezione "Conditions".
Da un lato, puoi utilizzare cartelle, tag host e nomi host espliciti per impostare restrizioni al di fuori dei servizi.
In secondo luogo, dai un nome ai servizi che desideri raggruppare, come Filesystem e myservice per creare un insieme di file system.
La specificazione dei servizi avviene qui sotto forma di espressioni regolari. Questo ti permette di definire i gruppi con precisione.
10.4. Check dei gruppi di servizi per un servizio
Puoi controllare l'assegnazione dei servizi nella pagina dei dettagli di un particolare servizio. Di seguito, per impostazione predefinita, c'è la riga Service groups the service is member of.
10.5. Utilizzo dei gruppi di servizi
Come già accennato, i gruppi di servizi vengono utilizzati in diversi contesti, come le visualizzazioni, le mappe NagVis, le notifiche e i gestori di avvisi. Per le nuove visualizzazioni è importante utilizzare l'Service groups come sorgente dati. Naturalmente, il widget Views contiene anche visualizzazioni predefinite per i gruppi di servizi, ad esempio un riepilogo chiaro:
Cliccando sui nomi dei gruppi di servizi otterrai una visualizzazione completa di tutti i servizi del rispettivo gruppo.
Se utilizzi i gruppi di servizi nelle mappe di NagVis, otterrai un riepilogo dei gruppi di servizi aperti in un menu passando il mouse su una singola icona:
Quando utilizzi i gruppi di servizi nelle notifiche e nei gestori di avvisi, questi sono disponibili come condizioni/filtri, di cui puoi utilizzare uno o più:
11. Maggiori informazioni sui plug-in di controllo
11.1. Una breve descrizione delle loro funzionalità
I plug-in di controllo sono necessari per generare servizi in Checkmk.
Ogni servizio utilizza un plug-in di controllo per determinare il proprio stato, creare/gestire metriche, ecc.
In questo modo, un plug-in può creare uno o più servizi per ogni host.
Per poter distinguere più servizi provenienti dallo stesso plug-in, è necessario un elemento.
Ad esempio, per il servizio Filesystem /var l'elemento è il testo /var.
Nel caso di plug-in che possono generare al massimo un servizio per host (
CPU utilization, ad esempio), l'elemento è vuoto e non viene visualizzato.
11.2. Plug-in di controllo disponibili
Un elenco di tutti i plug-in di controllo disponibili è disponibile all'indirizzo Setup > Services > Catalog of check plugins. Qui puoi cercare i singoli plug-in e filtrarli in varie categorie:
Per ogni plug-in vengono visualizzate tre colonne di informazioni: una descrizione del servizio (Tipo di controllo), il nome del plug-in di controllo (Nome plug-in) e le sue sorgenti dati compatibili (Agenti):
