 |
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 "sostanza" di un sistema di monitoraggio. Ciascuno di essi rappresenta un importante ingranaggio nel complesso panorama IT. L'utilità del monitoraggio completo dipende dalla precisione e dall'utilità con cui sono stati configurati i servizi. Infine, il monitoraggio dovrebbe notificare in modo affidabile ogni volta che si verifica un problema, ma dovrebbe anche ridurre al minimo le notifiche false o inutili.
Checkmk dimostra forse il suo punto di forza maggiore 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 è necessario definire ogni singolo servizio tramite modelli e assegnazioni individuali. Checkmk è in grado di rilevare automaticamente e in modo affidabile l'elenco dei servizi da monitorare e, soprattutto, di mantenerlo aggiornato. Ciò non solo consente di risparmiare molto tempo, ma rende anche accurato il monitoraggio. Garantisce che le modifiche quotidiane in un data center siano sempre prontamente coperte 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? → L'
/vare del sistema sull'hostmyserver01Come deve essere monitorato? → al 90% dello 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 un massimo di un servizio su un
host non richiedono un elemento (ad esempio, il plug-in di controllo per l'utilizzo della CPU). I
risultati di una scoperta del servizio sono presentati in una tabella come mostrato di seguito:
| Host | Plug-in di controllo | Elemento |
|---|---|---|
|
|
|
|
|
|
|
|
|
… |
… |
… |
|
|
|
… |
… |
… |
Il come, ovveroi threshold/parametri del check per i singoli
servizi, viene configurato in modo indipendente tramite regole. È possibile
ad esempio definire una regola che monitora tutti i sistemi di dati con il mount point /var e i threshold 90 % / 95 %, senza doversi preoccupare di
su quali host esista un tale sistema di dati. Questo è ciò che rende la configurazione
con Checkmk così chiara e semplice!
Alcuni servizi non possono essere installati utilizzando una scoperta automatica. Tra questi vi sono, ad esempio, i controlli richiesti tramite siti web specificati in HTTP. Questi vengono creati tramite regole, come potete apprendere nell'articolo sui controlli attivi.
2. Servizi host nel Setup
2.1. Incorporare un nuovo host
Dopo aver aggiunto un nuovo host nella configurazione, il passo successivo è richiamare l'elenco dei servizi. Con questa azione viene eseguita per la prima volta la scoperta automatica dei servizi per questo host e viene verificata parallelamente l'accessibilità delle sorgenti dati. È possibile richiamare questo elenco in qualsiasi momento anche in un secondo momento per riavviare la ricerca o per apportare modifiche alla configurazione. Esistono diversi modi per aprire l'elenco dei servizi:
tramite il pulsante " Save & run service discovery " nella finestra " Properties of host " nella configurazione
nella barra del menu dell'Properties of host tramite Host > Run service discovery
tramite il simbolo nell'elenco degli host in una cartella nel setup
tramite la voce " Run service discovery " nel menu "Azioni" del servizio Check_MK Discovery di un host
Quando un host è stato appena integrato, i suoi servizi non sono ancora stati configurati e quindi tutti i servizi rilevati vengono visualizzati nella categoria Undecided services - currently not monitored:
Il metodo usuale per aggiungere i servizi appena rilevati è semplicemente quello di premere il pulsante " Accept all ". In questo modo anche tutte le etichette dell'host verranno aggiunte in una sola volta. Successivamente, selezionare rapidamente " Activate changes", dopodiché l'host sarà nel monitoraggio.
2.2. Aggiunta di servizi mancanti
Per un host già monitorato, questo elenco appare diverso. Invece di " Undecided services - currently not monitored " vedrete " Monitored services". Se Checkmk rileva qualcosa su un host che non è monitorato, ma che dovrebbe esserlo, l'elenco apparirà simile a questo:
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 si desidera aggiungere solo alcuni dei servizi mancanti, è possibile cliccare sul pulsante " Move to monitored services".
2.3. Servizi scomparsi
Nei data center non solo possono comparire nuovi elementi, ma anche scomparire. Un'istanza di database può essere interrotta, 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 liberarsi di questi servizi è ancora una volta cliccare su " Accept all " o sul pulsante in ogni singola riga, che sta per " Remove vanished services" (Elimina servizi non utilizzati). Attenzione: il motivo della scomparsa può naturalmente 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! Si dovrebbe rimuovere il servizio solo quando si è veramente sicuri che non è più necessario monitorarlo.
2.4. Rimozione di servizi indesiderati
Non è necessario monitorare tutto ciò che Checkmk trova. La ricerca funziona 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 creata solo "per fare pratica" e non è in produzione? Esistono due modi per eliminare tali servizi:
Disabilitare temporaneamente i servizi
Per rimuovere temporaneamente determinati servizi dal monitoraggio, è sufficiente fare clic sul simbolo . In questo modo il servizio verrà spostato nell'elenco " Undecided services" (Servizi disabilitati). Oppure è possibile fare clic sul simbolo all'inizio della riga per disabilitare il servizio. Naturalmente non dimenticare il consueto " Activate changes" (Salva le impostazioni).
Tuttavia, questa operazione è pensata solo per azioni temporanee e di minore entità, poiché i servizi deselezionati in questo modo saranno evidenziati come " missing " da Checkmk e il discovery check (che vi mostreremo più avanti) non sarà soddisfatto. In ogni caso, sarebbe semplicemente troppo lavoro e non molto pratico in un ambiente con migliaia di servizi...
Disabilitare i servizi in modo permanente
È molto più elegante e duraturo ignorare definitivamente i servizi con l' aiuto del set di regole Disabled services. Qui non solo è possibile escludere singoli servizi dal monitoraggio, ma anche formulare regole come "Non desidero monitorare i servizi che iniziano con myservice sull' host myserver01."
È possibile accedere alla regola tramite Setup > Services > Discovery rules > Discovery and Checkmk settings > Disabled Services.
Una volta salvate le regole e tornati all'elenco dei servizi dell'host, vedrete 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 alcuni elementi durante la ricerca. Ad esempio, il plug-in per le interfacce di rete controlla la velocità impostata sull'interfaccia durante la ricerca. Perché? Per poterla avvisare in caso di modifiche. Raramente è un buon segno quando un'interfaccia è talvolta impostata su 10 Mbit/s e talvolta su 1 Gbit/s: potrebbe piuttosto essere un'indicazione di un'auto-negoziazione difettosa. Cosa succede quando questa modifica è desiderata e deve essere accettata come OK da ora in poi? Rimuova il servizio tramite l'icona , che rappresenta l'[email protected], e
Cosa succede quando questa modifica è desiderata e deve essere accettata come OK da ora in poi? Oppure rimuovere il servizio tramite l'icona , che sta per " Move to undecided services " (disattivato), e aggiungerlo nuovamente subito dopo. Oppure aggiornare tutti i servizi dell'host cliccando su " Actions > Remove all and find new " (aggiornare tutti i servizi) nella barra del menu. Questo è naturalmente molto più semplice, ma solo se non si desidera mantenere singoli servizi in uno stato di errore.
2.6. Aggiornare le etichette dell'host e del servizio
L'aggiornamento delle sole etichette 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, è possibile farlo nella riga del rispettivo servizio nel box " Changed services " cliccando su .
2.7. Condizioni speciali con SNMP
Esistono alcune caratteristiche speciali per i dispositivi monitorati tramite SNMP. Per ulteriori informazioni, consultare l'articolo relativo a SNMP.
3. Rilevamento massivo: rilevamento simultaneo su più host
Se desiderate eseguire una ricerca su più host con un'unica azione, potete semplificare il lavoro conle azioni massive di Checkmk. Innanzitutto, selezionate gli host su cui deve essere eseguita la ricerca. A tal fine avete diverse opzioni:
In una cartella, selezionare le caselle di controllo per i singoli host e quindi tramiteHosts > On selected hosts > Run bulk service discovery nella barra del menu.
Cercare gli host con la ricerca host, selezionare 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, fare clic su Hosts > In this folder > Run bulk service discovery nella barra del menu.
Con la terza variante è possibile eseguire la ricerca del servizio in modo ricorsivo in tutte le sottocartelle. In tutte e tre le opzioni sopra indicate, il passo successivo porta 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 disponibili nell'elenco dei servizi nella configurazione e che abbiamo già spiegato sopra. Nel menu a discesa è inoltre possibile selezionare " Refresh all services (tabula rasa)".
In " Selection " è possibile controllare nuovamente la selezione degli host. Ciò è utile soprattutto se questi sono stati selezionati tramite la cartella anziché tramite le caselle di controllo. La maggior parte delle opzioni serve ad accelerare la ricerca:
Include all subfolders |
Se avete avviato il rilevamento massivo per tutti gli host in una cartella, questa opzione sarà attiva per impostazione predefinita. La ricerca verrà eseguita anche su tutti gli host di tutte le sottocartelle. |
Only include hosts that failed on previous discovery |
Gli host per i quali un precedente rilevamento dei servizi tramite azioni massive non è riuscito (ad esempio perché l'host non era accessibile in quel momento) sono contrassegnati con il simbolo . Questa opzione consente di ripetere la ricerca solo per questi host. |
Only include hosts with a failed discovery check |
In questo modo la ricerca viene limitata agli host per i quali il discovery check non è riuscito. Quando si lavora 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. Ciò può rallentare notevolmente le prestazioni della ricerca su un numero elevato di host. Se gli host sono già in monitoraggio e si sa che sono DOWN, è possibile ignorarli qui ed evitare così i timeout. |
Performance Options Gli host non monitorati sono predefiniti in modo che venga eseguita una ricerca ( full service scan ). Se non siete interessati a nuovi plug-in, è possibile accelerare notevolmente la ricerca non selezionando questa opzione.
L'10 e impostato in Number of hosts to handle at once significa che
dieci host vengono sempre processati in un'unica azione. Ciò viene ottenuto internamente
con una richiesta HTTP. Se si riscontrano problemi di timeout dovuti al fatto che alcuni host
richiedono molto tempo per essere scoperti, è possibile provare a impostare questo numero su un valore inferiore
(a scapito del tempo totale richiesto).
Non appena si conferma il dialogo, la procedura avrà inizio e sarà possibile osservarne l'avanzamento:
4. Parametri del check nei servizi
Molti dei plug-in di controllo possono essere configurati utilizzando dei parametri. La pratica più comune è l'impostazione di threshold per l'WARN e e l'CRIT e. I parametri possono essere strutturati in modo molto più complesso, come mostrato in 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 la 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 sono impostati tramite caselle di controllo (come ad esempio la temperatura), queste regole di priorità si applicano separatamente per ogni sottoparametro. Pertanto, se si imposta un solo sottoparametro tramite regole, gli altri mantengono i rispettivi valori predefiniti. In questo modo è possibile, ad esempio, attivare il calcolo dell'andamento delle temperature con una regola e con un altro set di regole impostare il valore di soglia della temperatura per un dispositivo sensore fisico. Il set completo di parametri sarà quindi composto da entrambe le regole.
I parametri esatti di un servizio sono riportati nella pagina dei parametri del servizio. È possibile accedervi tramite il simbolo nell'elenco dei servizi dell'host. Se si desidera visualizzare i parametri di tutti i servizi direttamente nella tabella dei servizi, è possibile visualizzarli facendo clic suDisplay > Details > Show check parameters nella barra del menu. Avrà un aspetto simile a questo:
5. Personalizzazione della scoperta del servizio
Abbiamo già mostrato in precedenza come configurare la ricerca dei servizi per sopprimere la visualizzazione dei servizi indesiderati. Inoltre, esistono ulteriori set di regole per una serie di plug-in che influenzano il comportamento della ricerca con questi plug-in. Non solo sono disponibili impostazioni per omettere elementi, ma anche per trovarli attivamente o raccoglierli in gruppi. A volte anche la denominazione degli elementi può rappresentare un problema, ad esempio per quelle switchport interfacce di rete in cui è possibile decidere una descrizione o un alias da utilizzare come elemento (che verrà utilizzato nel nome del servizio) invece del suo ID di interfaccia.
Tutti i set di regole rilevanti per la scoperta del servizio si trovano in Setup > Services > Discovery rules. Non confondere questi set di regole con quelli destinati alla parametrizzazione dei servizi effettivi. Alcuni plug-in hanno infatti due set di regole: uno per la scoperta e uno per i parametri. Ecco alcuni esempi.
5.1. Monitoraggio dei processi
Non avrebbe molto senso per Checkmk definire semplicemente un servizio per monitorare ogni processo trovato su un host. La maggior parte dei processi non sono di alcun interesse o sono presenti solo temporaneamente. Come minimo, su un tipico server Linux sono in esecuzione centinaia di processi.
Per monitorare i servizi è quindi necessario lavorare con servizi forzati o, cosa molto più elegante, utilizzando il set di regole Process discovery per indicare alla scoperta del servizio quali processi deve cercare. In questo modo è sempre possibile consentire l'avvio automatico di un monitoraggio quando su un host viene trovato un processosicuramente interessante. L'immagine seguente mostra una regola nel set di regole
L'immagine seguente mostra una regola nel set di regole Process 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 verrà denominato Apache %u, dove %uverrà sostituito dal nome utente. Per la soglia, il numero di istanze di processo
sarà impostato rispettivamente su 1/1 (minimo) e 30/60 (massimo):
Si prega di notare che i threshold predefiniti sono indicati comeDefault parameters for detected services. È possibile assegnarli, così come tutti gli altri servizi, tramite regole. Ricordiamo che le regole sopra riportate configurano la scoperta del servizio, ovvero il "cosa". Se i servizi sono presenti per la prima volta, la catena di regole State and count of processes è responsabile dei threshold.
La possibilità di impostare le soglie durante una ricerca è un'ulteriore comodità. Tuttavia, c'è un inconveniente: le modifiche alla regola di ricerca diventano effettive solo con la ricerca successiva. Se si modificano le soglie, è necessario eseguire una nuova ricerca. Se, invece, si utilizza la regola solo per rilevare i servizi (il cosa) e il set di regoleState and count of processes per il come, non si avrà questo problema.
Per monitorare determinati o singoli processi su un host Windows, è sufficiente
indicare il nome del file (inclusa l'estensione) senza alcun percorso nel campoExecutable. Tutti questi nomi sono disponibili nella scheda Dettagli del
Task Manager di Windows, ad esempio. Nella regola Process discovery potrebbe apparire come
segue per il processo svchost:
Ulteriori informazioni sulla ricerca dei processi sono disponibili nell'aiuto in linea per questo set di regole. Come sempre, è possibile attivarlo tramite " Help > Show inline help " nella barra del menu.
5.2. Monitoraggio dei servizi in Windows
La ricerca e la parametrizzazione del monitoraggio dei servizi di Windows è analoga a quella dei processi ed è controllata tramite i set di regoleWindows service discovery (cosa) e Windows services (come) rispettivamente. Ecco un esempio di una regola che controlla due servizi:
Esattamente come per i processi, anche qui la scoperta del servizio è solo un'opzione. Se, sulla base delle caratteristiche dell'host e delle cartelle, è possibile formulare regole precise per gli host su cui sono previsti servizi specifici, è possibile lavorare anche con servizi forzati. Ciò è indipendente dalla situazione effettivamente riscontrata, ma può richiedere uno sforzo notevolmente maggiore, poiché in queste circostanze sono necessarie molte regole per descrivere esattamente quale servizio è previsto su quale host.
5.3. Monitoraggio delle porte dello switch
Checkmk utilizza la stessa logica per il monitoraggio delle interfacce di rete sui server e delle porte sugli switch Ethernet. Con le porte dello switch, le opzioni esistenti per il controllo della 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 hanno attualmente uno stato UP. Il set di regole applicabile si chiama " Network interface and switch port discovery " e offre numerose opzioni di impostazione che vengono qui descritte solo brevemente:
Le opzioni più importanti sono le seguenti:
Nella sezione " Appearance of network interface " è possibile determinare come deve apparire l'interfaccia nel nome del servizio. È possibile scegliere tra "Use description", " Use alias " e " Use index".
La restrizione o l'espansione dei tipi o dei nomi delle interfacce monitorate.
6. Impostazione dei servizi forzati
Esistono alcune situazioni in cui la scoperta automatica dei servizi non avrebbe senso. Questo è sempre il caso se si desidera imporre il rispetto di una linea guida specifica. Come abbiamo visto nel capitolo precedente, è possibile consentire il monitoraggio dei servizi Windows in modo che si avvii automaticamente quando questi vengono rilevati. Cosa succede quando l'assenza di un servizio di questo tipo rappresenta un problema? Ad esempio:
Un particolare scanner antivirus deve essere installato su ogni host Windows.
NTP dovrebbe essere configurato su ogni host Linux.
In questi casi è possibile semplicemente imporre tali servizi. Il punto di partenza per farlo si trova in 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 utilizzati per configurare i parametri per questi check.
Le regole differiscono tuttavia in due punti:
Si tratta di regole per host, non per servizi. I servizi vengono creati dalle regole.
Poiché non viene eseguita alcuna ricerca, è necessario 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 ai threshold, qui è possibile impostare il plug-in di controllo (ad es. chrony
o ntp_time). Per i plug-in di controllo che richiedono un elemento, è necessario specificare anche questi.
Ciò è necessario, ad esempio, per il plug-in oracle_processes,
che richiede i dettagli del SID del database da monitorare:
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 è [email protected]
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 UNKNOWN.
L'agente non fornisce alcuna informazione, ad esempio perché NTP non è nemmeno installato. Il servizio rimane quindi in SOSP. e il servizio Check_MK passa a WARN con l'avviso che la sezione pertinente nei dati dell'agente è mancante.
La maggior parte dei set di regole nel modulo Enforced servicesnon è necessaria, ma è presente 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 abbiamo promesso che Checkmk non solo rileva automaticamente l'elenco dei servizi, ma è anche in grado di mantenerlo aggiornato. Sarebbe inoltre naturale avere la possibilità di eseguire manualmente un rilevamento massivo di tutti gli host di tanto in tanto.
7.1. Controllo automatico dei servizi non monitorati
Molto meglio è però un discovery check regolare, che viene impostato automaticamente sulle nuove istanze. Questo servizio Check_MK Discovery esiste per ogni host e registra un avviso ogni volta che trova elementi non monitorati:
I dettagli dei servizi non monitorati o scomparsi sono disponibili nella pagina dei dettagli del servizio Check_MK Discovery nel campo Details:
È possibile accedere facilmente all'elenco dei servizi dell'host in Setup tramite il menu azione del servizio Check_MK Discovery e la voce Run service discovery.
La parametrizzazione del discovery check è molto semplice grazie al set di regole Periodic service discovery. In un'istanza appena creata, troverete già una regola definita per tutti gli host:
Accanto all'intervallo in cui deve essere eseguito il check, è possibile 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 di servizi
È possibile fare in modo che il discovery check aggiunga automaticamente i servizi mancanti. A tal fine, attivare l'opzione " Automatically update service configuration ", che renderà disponibili ulteriori opzioni.
Oltre alle aggiunte, in " Parameters " è possibile scegliere di eliminare i servizi scomparsi o anche di eliminare tutti i servizi esistenti ed eseguire una nuova ricerca completa. Quest'ultima opzione si trova nel menu a discesa con il nome " Refresh all services and host labels (tabula rasa)". Entrambe queste opzioni devono essere utilizzate con cautela. Un servizio scomparso può indicare un problema. Il discovery check eliminerà semplicemente tale servizio e vi indurrà a pensare che tutto sia in ordine. L'aggiornamento è particolarmente rischioso. Ad esempio, il controllo delle porte switch includerà nel monitoraggio solo le porte che sono UP. Le porte con lo stato DOWN saranno percepite come scomparse e rapidamente eliminate dal discovery check!
È necessario considerare un ulteriore problema: l'aggiunta di servizi o anche l'Activate Changes e automatica può distrarre l'amministratore durante l' esecuzione di una configurazione. In teoria, può accadere che mentre si lavora sulle regole e sulle impostazioni, in quel momento un discovery check attivi le modifiche. In Checkmk tutte le modifiche possono essere attivate solo contemporaneamente! Per escludere tali situazioni è possibile ripianificare l'ora di questa funzione, ad esempio durante la notte. L'immagine sopra mostra un esempio di ciò.
In " Vanished clustered services " è possibile gestire separatamente i servizi in cluster. La particolarità: se un servizio in cluster si sposta da un nodo all'altro, potrebbe essere considerato momentaneamente scomparso e quindi cancellato involontariamente. Se si rinuncia a questa opzione, invece, i servizi effettivamente scomparsi non verrebbero mai cancellati.
L'impostazione " Group discovery and activation for up to " garantisce che non tutti i servizi appena trovati attivino immediatamente unActivate Changes, ma che venga invece specificato un tempo di attesa in modo che più modifiche possano essere attivate in un'unica azione. Anche se il discovery check è impostato su un intervallo di due ore o più, questo vale solo per ogni host separatamente. I controlli non vengono eseguiti contemporaneamente per ogni host, il che è positivo, poiché 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 dai risultati dei check regolarmente convogliati da fonti esterne. Questo avviene generalmente tramite il comando pipe del core. Di seguito è riportata una procedura dettagliata per creare un servizio passivo:
In primo luogo, è necessario notificare il core del servizio. Ciò avviene con lo stesso set di regole utilizzato per i propri active check, tranne per il fatto che si omette l'Command line:
L'immagine mostra anche come 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 e, il nuovo servizio inizierà il suo ciclo di vita nello statoIN SOSP.
L'invio del risultato del check avviene ora sulla riga di comando tramite unecho e del comando PROCESS_SERVICE_CHECK_RESULT nel~/tmp/run/nagios.cmd.
La sintassi è conforme alle consuete convenzioni Nagios, compreso un
timestamp corrente tra parentesi quadre. Come argomento del comando è necessario
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):
OMD[mysite]:~$ echo "[$(date +%s)] PROCESS_SERVICE_CHECK_RESULT;myhost;BAR;2;Something bad has happened" > ~/tmp/run/nagios.cmdIl servizio mostra immediatamente il suo nuovo stato:
9. Scoperta del servizio dalla riga di comando
Una GUI è utile, ma la buona vecchia riga di comando è talvolta ancora
pratica, sia per l'automazione che per consentire semplicemente a un utente esperto
di lavorare rapidamente. Una scoperta del servizio può essere attivata con il comando " cmk
-I " sulla riga di comando. Ci sono un paio di variabili in
questo processo. Per tutte queste variabili si consiglia l'opzione " -v ", in modo da
poter vedere cosa succede. Senza " -v ", Checkmk si comporta come il buon
vecchio Unix tradizionale: finché tutto è OK, non dice nulla.
Con un semplice "-I" si cercano tutti gli host per i nuovi servizi:
OMD[mysite]:~$ cmk -vI
Discovering services and host labels on all hosts
myserver01:
+ FETCHING DATA
Using data from cache file /omd/sites/mysite/tmp/check_mk/cache/myserver01
[TCPFetcher] Use cached data
No piggyback files for 'myserver01'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (42)
SUCCESS - Found no new services, 2 host labels
myserver02:
+ FETCHING DATA
Using data from cache file /omd/sites/mysite/tmp/check_mk/cache/myserver02
[TCPFetcher] Use cached data
No piggyback files for 'myserver02'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (1900)
SUCCESS - Found no new services, 2 host labelsCon l'-I è anche possibile inserire uno o più nomi host per
individuare solo questi. Ciò ha anche un secondo effetto: mentre
un'-I su tutti gli host funziona fondamentalmente solo con i dati memorizzati nella cache,
Checkmk funziona sempre con dati aggiornati provenienti da un host esplicitamente nominato!
OMD[mysite]:~$ cmk -vI myserver01In alternativa, è possibile filtrare utilizzando i tag:
OMD[mysite]:~$ cmk -vI @mytagIn questo modo la ricerca verrebbe eseguita per tutti gli host con il tag host mytag.
Il filtraggio con tag è disponibile per tutte le opzioni cmk che accettano più host.
Con le opzioni --cache e --no-cache è possibile
determinare esplicitamente l'uso della cache.
È possibile ricevere ulteriori output con un secondo -v. Con i dispositivi basati su SNMP
è anche possibile visualizzare ogni singolo OID recuperato dal dispositivo:
OMD[mysite]:~$ cmk -vvI myswitch01
Discovering services on myswitch01:
myswitch01:
SNMP scan:
Getting OID .1.3.6.1.2.1.1.1.0: Executing SNMP GET of .1.3.6.1.2.1.1.1.0 on switch
=> ['24G Managed Switch'] OCTETSTR
24G Managed Switch
Getting OID .1.3.6.1.2.1.1.2.0: Executing SNMP GET of .1.3.6.1.2.1.1.2.0 on switch
=> ['.1.3.6.1.4.1.11863.1.1.3'] OBJECTID
.1.3.6.1.4.1.11863.1.1.3
Getting OID .1.3.6.1.4.1.231.2.10.2.1.1.0: Executing SNMP GET of .1.3.6.1.4.1.231.2.10.2.1.1.0 on switch
=> [None] NOSUCHOBJECT
failed.
Getting OID .1.3.6.1.4.1.232.2.2.4.2.0: Executing SNMP GET of .1.3.6.1.4.1.232.2.2.4.2.0 on switch
=> [None] NOSUCHOBJECT
failed.È possibile eseguire un rinnovo completo dei servizi (tabula rasa) con un doppio -II:
OMD[mysite]:~$ cmk -vII myserver01
Discovering services and host labels on: myserver01
myserver01:
+ FETCHING DATA
Using data from cache file /omd/sites/mysite/tmp/check_mk/cache/myserver01
[TCPFetcher] Use cached data
No piggyback files for 'myserver01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (10)
1 cpu.loads
1 cpu.threads
6 cups_queues
3 df
1 diskstat
3 kernel
1 kernel.util
3 livestatus_status
1 lnx_if
1 lnx_thermal
SUCCESS - Found 21 services, 2 host labelsÈ inoltre possibile limitare tutto questo a un singolo plug-in di controllo. A tal fine, l'opzione
è --detect-plugins= e deve essere inserita prima del nome host:
cmk -vII --detect-plugins=df myserver01
Discovering services and host labels on: myserver01
myserver01:
+ FETCHING DATA
[TCPFetcher] Execute data source
No piggyback files for 'myserver01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (1)
3 df
SUCCESS - Found 3 services, no host labelsUna volta terminato, è possibile attivare le modifiche con cmk -O
(cmk -R con Nagios Core):
OMD[mysite]:~$ cmk -O
Generating configuration for core (type cmc)...OK
Creating helper config...OK
Reloading monitoring core...OKE quando si verifica un errore durante una ricerca...
OMD[mysite]:~$ cmk -vII --detect-plugins=df myserver01
WARNING: Exception in discovery function of check type 'df': global name 'bar' is not defined
nothing... con un ulteriore --debug è possibile produrre una traccia dettagliata Python
della posizione del guasto:
OMD[mysite]:~$ cmk --debug -vII --detect-plugins=df myserver01
Discovering services and host labels on myserver01:
myserver01:
Traceback (most recent call last):
File "/omd/sites/heute/share/check_mk/modules/check_mk.py", line 5252, in <module>
do_discovery(hostnames, check_types, seen_I == 1)
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 76, in do_discovery
do_discovery_for(hostname, check_types, only_new, use_caches, on_error)
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 96, in do_discovery_for
new_items = discover_services(hostname, check_types, use_caches, do_snmp_scan, on_error)
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 677, in discover_services
for item, paramstring in discover_check_type(hostname, ipaddress, check_type, use_caches, on_error):
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 833, in discover_check_type
discovered_items = discovery_function(info)
File "/omd/sites/heute/share/check_mk/checks/df", line 91, in inventory_df
foo = bar
NameError: global name 'bar' is not defined9.1. Panoramica delle opzioni
Per ricapitolare, ecco tutte le opzioni a colpo d'occhio:
|
Rileva nuovi servizi |
|
Elimina e riscopri tutti i servizi (tabula rasa) |
|
Verbose: visualizza host e servizi rilevati |
|
Molto dettagliato: visualizza un protocollo preciso di tutte le operazioni |
|
Eseguire 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 nella cache (normalmente l'impostazione predefinita solo quando non è specificato alcun host) |
|
Recupera dati recenti (normalmente 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 (Checkmk Raw con Nagios come core) |
9.2. Salvataggio in file
Il risultato di una scoperta del servizio, ovvero, come spiegato in precedenza, le
tabelle dei nomi host, i plug-in di controllo, gli elementi e i parametri identificati, si trova
nella cartella " var/check_mk/autochecks ". Qui, per ogni
host è presente un set di dati che memorizza i servizi scoperti automaticamente.
Finché non si danneggia la sintassi Python di questo set di dati, è possibile modificare o
eliminare singole righe manualmente. L'eliminazione del set di dati rimuove tutti i servizi
e li contrassegna nuovamente come "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é utilizzare i gruppi di servizi?
Finora avete appreso 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 degli host. Ad esempio, se desiderate visualizzare tutti i servizi del file system o di aggiornamento insieme, potete semplicemente raggrupparli in modo simile a come si fa con i gruppi di host.
I gruppi di servizi consentono di mettere ordine nel monitoraggio tramite visualizzazioni e mappe NagVis e di attivare notifiche e gestori di avvisi mirati.
A proposito, è quasi sempre possibile costruire visualizzazioni corrispondenti utilizzando esclusivamente i filtri di visualizzazione, ma i gruppi di servizi sono organizzati in modo più chiaro e più facili da utilizzare.
10.2. Creazione di gruppi di servizi
I gruppi di servizi si trovano tramite Setup > Services > Service groups.
Creare un gruppo di servizi è semplice: creare un gruppo tramite Add group e assegnargli un nome che non potrà essere modificato in seguito, nonché un alias significativo:
10.3. Aggiunta di servizi a un gruppo di servizi
Per assegnare servizi a gruppi di servizi è necessario il set di regole Assignment of services to service groups. Il modo più veloce per accedervi è tramite la panoramica dei gruppi di servizi (Setup > Services > Service Groups). Qui è sufficiente cliccare su Service Groups > Assign to group > Rules nella barra del menu. In alternativa, è possibile trovare la regola tramite la ricerca delle regole nel menu " Setup " o cercando in " Setup > Services > Service monitoring rules > Various > Assignment of services to service groups". Ora utilizzare " Create rule in folder " per fare proprio questo. Per prima cosa specificare 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, è possibile utilizzare cartelle, tag host e nomi host espliciti per applicare restrizioni al di fuori dei servizi.
In secondo luogo, è necessario assegnare un nome ai servizi che si desidera raggruppare, ad esempio " Filesystem " e " myservice " per creare un insieme di file system.
La specifica dei servizi avviene qui sotto forma di espressioni regolari. Ciò consente di definire i gruppi con precisione.
10.4. Check dei gruppi di servizi per un servizio
È possibile verificare l'assegnazione dei servizi nella pagina dei dettagli di un determinato servizio. Di seguito, per impostazione predefinita, è presente la riga " Service groups the service is member of ".
10.5. Utilizzo dei gruppi di servizi
Service groups Come già accennato, i gruppi di servizi vengono utilizzati in diversi punti, ad esempio visualizzazioni, mappe NagVis, notifiche e gestori di avvisi. Per le nuove visualizzazioni è importante utilizzare il gruppo di servizi 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 si ottiene una visualizzazione completa di tutti i servizi del rispettivo gruppo.
Se si utilizzano gruppi di servizi nelle mappe NagVis, si riceve un riepilogo dei gruppi di servizi aperti in un menu passando con il mouse su un singolo simbolo:
Quando si utilizzano gruppi di servizi nelle notifiche e nei gestori di avvisi, notifiche, sono disponibili come condizioni/filtri, di cui è possibile utilizzare uno o più:
11. Ulteriori informazioni sui plug-in di controllo
11.1. 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/mantenere metriche, ecc.
In questo modo, un plug-in può creare uno o più servizi per host.
Per poter distinguere più servizi dello 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 solo un massimo di 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 alla voce Setup > Services > Catalog of check plugins. Qui è possibile cercare i singoli plug-in e filtrarli in diverse 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 sorgenti dati compatibili (Agenti):
