 |
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. Ognuno di essi rappresenta un ingranaggio importante nel tuo complesso panorama informatico. L'utilità del monitoraggio completo dipende dall'accuratezza e dall'utilità con cui sono stati configurati i servizi. Infine, il monitoraggio deve notificare in modo affidabile ogni volta che si manifesta un problema, ma deve anche ridurre al minimo le notifiche false o inutili.
Checkmk dimostra la sua più grande forza nella configurazione dei servizi: possiede un sistema impareggiabile e molto potente per il rilevamento e la configurazione automatica dei servizi. Con Checkmk non è necessario definire ogni singolo servizio tramite modelli e allocazioni individuali: Checkmk è in grado di rilevare automaticamente e in modo affidabile l'elenco dei servizi da monitorare e, soprattutto, di tenerlo aggiornato. Questo non solo fa risparmiare molto tempo, ma rende anche il monitoraggio accurato, garantendo che i cambiamenti quotidiani in un data center siano sempre coperti tempestivamente e che nessun servizio importante rimanga non monitorato.
La scoperta del servizio in Checkmk si basa su un importante principio di base: la separazione del cosa dal come:
Cosa deve essere monitorato? → Il sistema
/varsull'host.myserver01Come deve essere monitorato? → al 90% di spazio utilizzato WARN, al 95% CRIT
Cosa viene rilevato automaticamente dalla scoperta del servizio. È una combinazione del nome del plug-in di controllo (myserver01), del plug-in di controllo (df: data system check 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 (es. il plug-in di controllo per l'utilizzo della CPU). I risultati della scoperta del servizio sono presentati in una tabella come mostrato di seguito:
| Host | Plug-in di controllo | Elemento |
|---|---|---|
|
|
|
|
|
|
|
|
|
... |
... |
... |
|
|
|
... |
... |
... |
Il come- e quindi i threshold/parametri del check per i singoli servizi - è configurato in modo indipendente tramite regole. Ad esempio, puoi definire una regola che monitora tutti i sistemi di dati con il mount point /var e le soglie del 90%/95%, senza dover pensare a quali host esistano tali sistemi di dati. Questo è ciò che rende la configurazione con Checkmk così chiara e semplice!
Alcuni servizi non possono essere installati tramite discovery check automatica. Tra questi ci sono, ad esempio, i check interrogati per siti web HTTP specificati. Questi vengono creati tramite regole, come puoi apprendere nell'articolo sui check attivi.
2. I servizi host nel Setup
2.1. Incorporare un nuovo host
Una volta aggiunto un nuovo host nel setup, il passo successivo è quello di richiamare l'elenco dei servizi. Con questa azione la ricerca automatica dei servizi avviene per la prima volta per questo host e, parallelamente, viene verificata l'accessibilità delle fonti di dati. Puoi richiamare questo elenco in qualsiasi momento successivo per riavviare la ricerca o per apportare modifiche alla configurazione. Ci sono diversi modi per aprire l'elenco dei servizi:
tramite il pulsante Save & run service discovery nella sezione Properties of host del setup
nella barra del menu di Properties of host via Host > Run service discovery
tramite il simbolo nell'elenco degli host di una cartella nel setup
tramite la voce Run service discovery nel menu azione del servizio Check_MK Discovery di un host
Quando un host è stato appena incorporato, i suoi servizi non sono ancora stati configurati e quindi tutti i servizi scoperti appaiono nella categoria Undecided services - currently not monitored:
Il metodo abituale per aggiungere i nuovi servizi scoperti è quello di premere semplicemente il pulsante Accept all. In questo modo anche tutte le etichette dell'host verranno aggiunte in un'unica volta. In seguito, premi rapidamente il pulsante Activate changes, dopodiché l'host verrà inserito nel monitoraggio.
2.2. Aggiungere i servizi mancanti
Se un host è già monitorato, l'elenco si presenta in modo diverso: invece di Undecided services - currently not monitored vedrai Monitored services. Se Checkmk rileva qualcosa su un host che non è monitorato, ma che dovrebbe essere monitorato, l'elenco si presenterà in questo modo:
Un clic su Monitor undecided services o su Accept all aggiunge semplicemente tutti i servizi mancanti in modo da completare il monitoraggio. Se vuoi aggiungere solo alcuni dei servizi mancanti, puoi cliccare sul pulsante Move to monitored services.
2.3. Servizi scomparsi
Nei data center le cose possono non solo apparire, ma anche scomparire: un'istanza di data base può essere interrotta, una LUN smontata, un file system rimosso, ecc. Nell'elenco dei servizi, ad es:
Il modo più semplice per liberarsi di questi servizi è cliccare su Accept all o cliccare sul pulsante in ogni singola riga, che sta per Remove vanished services.Attenzione: La scomparsa di un file system può anche significare che a causa di un errore non è stato possibile montarlo. Il monitoraggio è previsto proprio per questi casi! Dovresti rimuovere il servizio solo quando sai che non è più necessario monitorarlo.
2.4. Rimuovere i servizi indesiderati
Non vorrai necessariamente monitorare ogni aspetto trovato da Checkmk. 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 creata solo "per giocare" e non è in produzione? Esistono due modi per eliminare tali servizi:
Disabilitare temporaneamente i servizi
Per rimuovere temporaneamente alcuni servizi dal monitoraggio, puoi semplicemente cliccare sull'icona . In questo modo il servizio verrà spostato nell'elenco di Undecided services. Oppure puoi anche cliccare sull'icona all'inizio della riga, per disabilitare il servizio. E naturalmente non dimenticare il solito Activate changes.
Questo però è destinato solo ad azioni temporanee e di piccola entità, in quanto i servizi deselezionati in questo modo saranno evidenziati come missing da Checkmk e la scoperta del servizio (che ti mostreremo più avanti) sarà ugualmente infelice. In ogni caso, questo sarebbe semplicemente un lavoro eccessivo e poco pratico in un ambiente con x-mila servizi...
Disabilitare i servizi in modo permanente
È molto più elegante e duraturo ignorare permanentemente i servizi con l'aiuto del set di regole Disabled services. Qui puoi non solo escludere singoli servizi dal monitoraggio, ma anche formulare regole del tipo "Non voglio monitorare i servizi che iniziano con myservice sull'host myserver01."
Puoi accedere alle regole tramite Setup > Services > Discovery rules > Discovery and Checkmk settings > Disabled Services.
Una volta salvate le regole e tornando all'elenco dei servizi dell'host, vedrai i servizi disabilitati nella sezione Disabled Services, insieme a qualsiasi servizio che sia stato disabilitato manualmente.
2.5. Aggiornare i servizi
Ci sono diversi plug-in che fanno attenzione 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 cambiasse! Raramente è un buon segno quando un'interfaccia è impostata a volte su 10 Mbit/s e a volte su 1 Gbit/s: questo potrebbe essere un'indicazione di un difetto di auto-negoziazione.
Cosa succede quando si desidera una modifica che d'ora in poi deve essere accettata come OK? Rimuovi il servizio tramite il simbolo , che sta per Move to undecided services e reinseriscilo 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 i singoli servizi in uno stato di errore.
2.6. Aggiornare le etichette dell'host e dei servizi
L'aggiornamento delle sole etichette può essere facilmente effettuato rispettivamente tramite Actions > Host labels > Update host labels e Actions > Services > Update service labels nella barra del menu. Se è necessario aggiungere o aggiornare solo singole etichette di servizio (nuove), questo può essere fatto nella riga del rispettivo servizio nel box Changed services cliccando su .
3. Bulk Discovery - ricerca simultanea su più host
Se vuoi eseguire la ricerca di più host con un'unica azione, puoi semplificare il lavoro con leazioni massive di Checkmk. Innanzitutto, scegli gli host su cui eseguire la ricerca. A tal fine hai a disposizione diverse opzioni:
In una cartella, seleziona le caselle di controllo per i singoli host e poi tramiteHosts > On selected hosts > Run bulk service discovery nella barra del menu.
Cerca gli host con la ricerca host, seleziona tutti gli host nel risultato della ricerca cliccando sul pulsante e poi ancora 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 la scoperta del servizio in modo ricorsivo in tutte le sottocartelle. In tutte e tre le opzioni precedenti, il passo successivo ti porterà alla finestra di dialogo seguente:
Nel menu a discesa Parameters è preselezionata l'opzione Custom service configuration update. I quattro checkbox sottostanti offrono esattamente le stesse opzioni che hai nell'elenco dei servizi nella configurazione e che abbiamo già spiegato in precedenza. Nel menu a discesa hai anche la possibilità di selezionare Refresh all services (tabula rasa).
Alla voce Selection puoi ancora una volta controllare la selezione dell'host. Questo ha senso soprattutto se hai selezionato queste cartelle piuttosto che le check box. La maggior parte delle opzioni ha lo scopo di accelerare la ricerca:
Include all subfolders |
Se hai avviato la ricerca di massa per tutti gli host di 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 del servizio tramite operazioni di massa è fallito (es. perché l'host non era accessibile in quel momento), sono contrassegnati dal simbolo. Questa opzione permette di ripetere la ricerca solo per questi host. |
Only include hosts with a failed discovery check |
Questo limita la ricerca agli host per i quali il discovery check è fallito. Quando lavori con il discovery check questo è un buon metodo per accelerare notevolmente la ricerca di molti host. In questo caso, però, la combinazione con l'opzione Refresh all services (tabula rasa) ha meno senso perché può distorcere lo stato del servizio esistente. |
Exclude hosts where the agent is unreachable |
Gli host che non sono accessibili causano lunghi ritardi durante la ricerca a causa dei timeout di connessione. Questo può ostacolare notevolmente le prestazioni di una ricerca su un numero elevato di host. Se gli host sono già in fase di monitoraggio e il sistema sa che sono DOWN, puoi bypassarli ed evitare i timeout. |
Il sito Performance Options è predefinito in modo che venga eseguito un full service scan. Se non sei interessato a nuovi plug-in, la ricerca può essere notevolmente accelerata se non scegli questa opzione.
L'opzione 10 impostata in Number of hosts to handle at once significa che dieci host vengono sempre processati in un'unica azione. Questo avviene internamente con una richiesta HTTP. Se dovessi riscontrare problemi di timeout a causa di alcuni host che richiedono molto tempo per essere scoperti, puoi provare a impostare questo numero più basso (a scapito del tempo totale richiesto).
Non appena confermi la finestra di dialogo, la procedura inizierà e potrai 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 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 la ricerca (vedi sopra).
I parametri possono essere impostati tramite regole.
I parametri delle regole hanno la priorità rispetto a quelli impostati da una ricerca e questi ultimi hanno a loro volta la priorità rispetto ai valori predefiniti. Per i parametri complessi in cui i singoli sotto-parametri sono impostati tramite dei parametri del check (come ad esempio la temperatura), queste regole di priorità si applicano separatamente per ogni sotto-parametro. Quindi, se imposti solo un sotto-parametro tramite regole, gli altri mantengono i rispettivi valori predefiniti. In questo modo puoi, ad esempio, attivare il calcolo del trend delle temperature con una regola e con un'altra impostare il valore di threshold della temperatura per un sensore fisico. Il set completo di regole sarà quindi composto da entrambe le regole.
I parametri esatti di un servizio si trovano nella pagina dei parametri del servizio stesso. Puoi accedervi tramite il simbolo nell'elenco dei servizi dell'host. Se vuoi vedere i parametri di tutti i servizi direttamente nella tabella dei servizi, puoi visualizzarla cliccando suDisplay > Details > Show check parameters nella barra del menu. L'aspetto sarà simile a questo:
5. Personalizzare la scoperta del servizio
In precedenza abbiamo mostrato come è possibile configurare la scoperta del servizio per sopprimere la visualizzazione di servizi non desiderati. Inoltre, esistono ulteriori set di regole per una serie di plug-in che influenzano il comportamento della scoperta del servizio con questi plug-in. Non ci sono solo impostazioni per l'omissione di elementi, ma anche per la ricerca attiva di elementi o per la loro raccolta in gruppi. A volte anche la denominazione degli elementi è un problema: ad es. per le switchport è possibile decidere una descrizione o un alias da utilizzare come elemento (che sarà usato nel nome del servizio) invece dell'ID dell'interfaccia.
Tutti i set di regole rilevanti per la scoperta del servizio si trovano sotto Setup > Services > Discovery rules. Non confondere questi set di regole con quelli destinati alla parametrizzazione dei servizi veri e propri. Alcuni plug-in hanno infatti 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 un servizio che monitori ogni processo trovato su un host. La maggior parte dei processi non è di interesse o è presente solo temporaneamente. Come minimo ci sono centinaia di processi in esecuzione su un tipico server Linux.
Per monitorare i servizi devi quindi lavorare con iservizi forzati oppure, cosa molto più elegante, utilizzare il set di regole Process discovery per indicare alla scoperta del servizio quali processi deve tenere d'occhio. In questo modo puoi sempre consentire l'avvio automatico di un monitoraggio quando viene trovato un processodecisamente interessante su un host.
L'immagine seguente mostra una regola del 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 cui viene trovato un processo di questo tipo. Il nome del servizio sarà Apache %u, dove %usarà sostituito dal nome dell'utente. Per la soglia, il numero di istanze di processo sarà impostato rispettivamente a 1/1 (minimo) e 30/60 (massimo):
Nota che le soglie predefinite sono indicate comeDefault parameters for detected services. Puoi assegnare questi servizi, e allo stesso modo tutti gli altri, tramite delle regole. Come promemoria: le regole di cui sopra configurano la scopertadel 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 che tu possa impostare le soglie durante la ricerca è un aiuto alla comodità. C'è però un problema: le modifiche alla regola di ricerca hanno effetto solo con la ricerca successiva. Se cambi le soglie, dovrai eseguire una nuova ricerca. Tuttavia, se utilizzi la regola solo per scoprire i servizi (il cosa) e il set di regoleState and count of processes per il come, allora non avrai questo problema.
Per monitorare alcuni o singoli processi su un host Windows, basta indicare il nome del file (compresa l'estensione) senza alcun percorso nel campoExecutable. Puoi trovare tutti questi nomi nella scheda dettagli del Task Manager di Windows, ad esempio. Nella regola Process discovery questo potrebbe apparire come segue per il processo svchost:
Ulteriori informazioni sulla ricerca dei processi sono disponibili nell'aiuto inline di questo set di regole. Come sempre, puoi attivarla tramite Help > Show inline help nella barra del menu.
5.2. Servizi di monitoraggio in Windows
La scoperta e la parametrizzazione del monitoraggio dei servizi di Windows è analoga a quella dei processi e viene controllata tramite i set di regoleWindows service discovery (cosa) e Windows services (come) rispettivamente. Ecco un esempio di regola che controlla due servizi:
Esattamente come per i processi, anche in questo caso la scoperta del servizio è una sola opzione. Se, sulla base delle caratteristiche dell'host e delle cartelle, puoi formulare regole precise per gli host su cui sono attesi servizi specifici, allora puoi anche lavorare con servizi forzati. Ciò è indipendente dalla situazione effettivamente riscontrata; tuttavia può richiedere uno sforzo considerevole, poiché in queste circostanze sono necessarie molte regole per descrivere esattamente quale servizio è atteso su quale host.
5.3. Monitoraggio delle porte dello switch
Checkmk utilizza la stessa logica per il monitoraggio delle interfacce di rete dei server e delle porte degli switch Ethernet. Per quanto riguarda le porte dello 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 funziona inizialmente senza regole. In altre parole, per impostazione predefinita Checkmk effettua il port monitoring automatico di tutte le porte fisiche che attualmente hanno uno stato di monitoraggio UP. Il set di regole applicabile si chiama Network interface and switch port discovery e offre numerose opzioni di impostazione che qui vengono descritte solo brevemente:
Le opzioni più importanti sono le seguenti:
Nella sezione Appearance of network interface puoi stabilire come deve apparire l'interfaccia nel nome del servizio. Puoi scegliere traUse description, Use alias e Use index.
La restrizione o l'espansione dei tipi o dei nomi delle interfacce da monitorare.
6. Impostazione dei servizi forzati
Ci sono situazioni in cui la scoperta automatica del servizio non ha senso. Questo è sempre il caso in cui vuoi imporre il rispetto di una linea guida specifica. Come abbiamo visto nel capitolo precedente, puoi permettere che il monitoraggio dei servizi di Windows si attivi automaticamente quando questi vengono trovati. Cosa succede quando l'assenza di un servizio rappresenta un problema? Ad esempio:
Un particolare antivirus deve essere installato su ogni host Windows.
NTP deve essere configurato su ogni host Linux.
In questi casi puoi semplicemente imporre questi servizi. Il punto di partenza è Setup > Services > Enforced services. Alla base c'è una raccolta di set di regole che hanno esattamente gli stessi nomi dei set di regole utilizzati per configurare i parametri del check.
Le regole differiscono però in due punti:
Si tratta di regole per gli host, non per i servizi. I servizi saranno creati dalle regole.
Poiché non avviene alcuna ricerca, devi selezionare il plug-in di controllo da utilizzare per la verifica.
L'esempio seguente mostra il corpo della regola State of NTP time synchronisationsotto Enforced services:
Oltre alle soglie, qui devi impostare il plug-in di controllo (es. chronyo ntp_time). Per i plug-in di controllo che richiedono un elemento, devi specificare anche questo. Ad esempio, questo è necessario per il plug-in oracle_processes, che richiede i dettagli del SID del database da monitorare:
Un servizio manuale così definito verrà installato su tutti gli host a cui si applicano queste regole. A questo punto, le condizioni possibili per il monitoraggio effettivo sono tre:
L'host è installato correttamente e il servizio è OK.
L'agente notifica che il servizio richiesto non funziona o ha un problema. Il servizio viene segnalato come CRIT o SCONOSCIUTO.
L'agente non fornisce alcuna informazione, ad es. perché NTP non è nemmeno installato. Il servizio rimane in SOSP. e l'agente Checkmk entra in WARN con l'avviso che la sezione pertinente nei dati dell'agente è mancante.
La maggior parte dei set di regole del modulo Enforced servicesnon ti serviranno, 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 abbiamo promesso che Checkmk non solo rileva automaticamente l'elenco dei servizi, ma può anche tenerlo aggiornato. Sarebbe anche naturale avere la possibilità di eseguire manualmente una ricerca di massa per tutti gli host di tanto in tanto.
7.1. Controllo automatico dei servizi non monitorati
Molto meglio è un discovery check regolare, che viene impostato automaticamente sui nuovi siti. Questo servizio Check_MK Discovery esiste per ogni host e logga 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:
L'elenco dei servizi dell'host nel Setup è facilmente accessibile tramite il menu azione del servizio Check_MK Discovery e la voce Run service discovery.
La parametrizzazione del discovery check avviene in modo molto semplice utilizzando il set di regole Periodic service discovery. In un sito appena uscito dal box, troverai già una regola definita per essere applicata a tutti gli host:
Oltre all'intervallo in cui deve essere eseguito il controllo, 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 di 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 altre opzioni.
Oltre alle aggiunte, in Parameters puoi anche scegliere di eliminare i servizi scomparsi o di cancellare tutti i servizi esistenti ed eseguire una nuova scoperta completa. Quest'ultima opzione si trova nel menu a discesa con il nome Refresh all services and host labels (tabula rasa). Entrambe le opzioni devono essere usate con attenzione: un servizio scomparso può indicare un problema! Il discovery check cancellerà semplicemente tale servizio e ti farà credere che tutto sia in ordine. L'aggiornamento è particolarmente rischioso. Ad esempio, il controllo delle switchport prenderà in considerazione solo le porte che sono UP nel monitoraggio. Le porte con uno stato del servizio DOWN saranno percepite come scomparse e cancellate rapidamente dal discovery check!
È necessario considerare un altro problema: l'aggiunta di servizi o anche il sito Activate Changes automatico possono distrarre l'amministratore durante la configurazione. In teoria può accadere che mentre stai lavorando su regole e impostazioni, in quel momento un discovery check attivi le tue modifiche. In Checkmk è possibile attivare tutte le modifiche in una sola volta! 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 gestire separatamente i servizi in cluster. La particolarità è che in questo caso: Se un servizio del cluster si sposta da un nodo all'altro, potrebbe essere brevemente considerato come scomparso e quindi cancellato involontariamente. Se rinunci a questa opzione, i servizi che sono effettivamente scomparsi non saranno mai cancellati.
L'impostazione Group discovery and activation for up to fa sì che non ogni singolo servizio appena trovato attivi immediatamente unActivate Changes- piuttosto ci sarà un tempo di attesa specificato in modo da poter attivare più modifiche 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 simultaneamente per ogni host, il che è positivo perché un discovery check richiede molte più risorse di un normale controllo.
8. Servizi passivi
I servizi passivi sono quelli che non vengono avviati attivamente da Checkmk, ma piuttosto dai risultati dei controlli regolarmente canalizzati da fonti esterne. Questo avviene generalmente tramite la pipe di comando del core. Ecco una procedura passo passo per creare un servizio passivo:
Per prima cosa, devi notificare al core l'esistenza del servizio. Questo avviene con lo stesso set di regole dei tuoi active check, ad eccezione dell'omissione di Command line:
L'immagine mostra anche come puoi verificare se i risultati dei controlli vengono ricevuti regolarmente. Se questi non vengono visualizzati per più di dieci minuti, il servizio verrà automaticamente contrassegnato come SCONOSCIUTO.
Dopo un Activate Changes il nuovo servizio inizierà la sua vita nello statoIN SOSP:
L'invio del risultato della verifica avviene ora sulla linea di comando tramite unecho del comando PROCESS_SERVICE_CHECK_RESULT nella pipe del comando~/tmp/run/nagios.cmd.
La sintassi è conforme alle consuete convenzioni di Nagios, compresa l'indicazione dell'ora corrente tra parentesi quadre. Come argomenti del comando sono necessari il nome host (ad esempio, myhost) e il nome del servizio selezionato (ad esempio, BAR). I due argomenti successivi sono ancora una volta lo stato (0... 3) e l'output del plug-in. La marca temporale viene creata con $(date +%s):
OMD[mysite]:~$ echo "[$(date +%s)] PROCESS_SERVICE_CHECK_RESULT;myhost;BAR;2;Something bad has happened" > ~/tmp/run/nagios.cmdIl servizio ora mostra immediatamente il suo nuovo stato:
9. Scoperta del servizio tramite linea di comando
La GUI va bene, ma la buona vecchia linea di comando a volte è ancora pratica, sia per l'automazione che per consentire a un utente esperto di lavorare rapidamente. La scoperta del servizio può essere avviata con il comando cmk
-I da linea di comando. Ci sono un paio di variabili in questo processo. Per tutte queste si raccomanda 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' cerca tutti gli host in base ai 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 -I puoi anche inserire uno o più nomi host per scoprire solo questi. Questo ha anche un secondo effetto: mentre -I su tutti gli host funziona fondamentalmente solo con i dati in cache, Checkmk funziona sempre con i dati freschi di un host esplicitamente nominato!
OMD[mysite]:~$ cmk -vI myserver01In alternativa, puoi filtrare utilizzando i tag:
OMD[mysite]:~$ cmk -vI @mytagIn questo modo la ricerca verrebbe eseguita per tutti gli host con il tag degli host mytag. Il filtro con i tag è disponibile per tutte le opzioni di cmk che accettano più host.
Con le opzioni --cache e --no-cache puoi determinare esplicitamente l'uso della cache.
Ulteriori output possono essere ricevuti con un secondo -v. Con i dispositivi basati su SNMP puoi anche vedere 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.Un rinnovo completo dei servizi (tabula rasa) può essere eseguito 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 labelsPuoi anche limitare tutto questo a un singolo plug-in di controllo. Per questo l'opzione è --detect-plugins= e deve essere anteposta al 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 labelsQuando hai finito puoi 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 la 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 puoi produrre una traccia dettagliata dello stack di Python sulla posizione dell'errore:
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
Riassumendo, tutte le opzioni in un colpo d'occhio:
|
Scoprire nuovi servizi |
|
Eliminare e riscoprire tutti i servizi (tabula rasa) |
|
Verboso: visualizza gli host e i servizi rilevati |
|
Molto prolisso: visualizza un protocollo preciso di tutti gli operatori. |
|
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 |
|
Forzare l'uso dei dati della cache (normalmente l'impostazione predefinita è solo quando non è specificato alcun host) |
|
Recupera i dati di pertinenza (normalmente l'impostazione predefinita è solo quando è specificato il nome host) |
|
Elimina in caso di errore e visualizza lo stack trace completo di 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 della scoperta del servizio - quindi, come spiegato in precedenza, le tabelle dei nomi del servizio, 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 archivia i servizi scoperti automaticamente. Se non danneggi la sintassi Python di questo set di dati, puoi modificare o cancellare manualmente le singole righe. L'eliminazione del set di dati rimuove tutti i servizi e li segnala 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 dei gruppi di servizi?
Finora hai imparato come includere i servizi nel monitoraggio. Ora non ha più senso dover consultare elenchi di migliaia di servizi e/o dover sempre passare attraverso le visualizzazioni degli host. Ad esempio, se vuoi visualizzare tutti i servizi di file system o di aggiornamento insieme, puoi semplicemente creare dei gruppi in modo simile a quello che puoi fare con i gruppi di host.
I gruppi di servizi ti permettono di mettere molto più ordine nel monitoraggio attraverso levisualizzazioni e le mappe di NagVis e di switcharenotifiche mirate e gestori di avvisi. A proposito, potresti quasi sempre costruire le visualizzazioni corrispondenti utilizzando esclusivamente i filtri di visualizzazione, ma i gruppi di servizi sono organizzati in modo più chiaro e più facile da utilizzare.
10.2. Creare i gruppi di servizi
I gruppi di servizi si trovano all'indirizzo Setup > Services > Service groups.
Creare un gruppo di servizi è semplice: crea un gruppo tramite Add group e assegnagli un nome che non può essere modificato in seguito e un alias significativo:
10.3. Aggiungere servizi a un gruppo di servizi
Per assegnare i servizi ai gruppi di servizi hai bisogno del set di regole Assignment of services to service groups. Il modo più veloce per arrivarci è attraverso la panoramica dei gruppi di servizi (Setup > Services > Service Groups). Qui devi semplicemente fare clic su Service Groups > Assign to group > Rules nella barra del menu. In alternativa, puoi ovviamente trovare la regola attraverso la ricerca delle regole nel menu Setup o cercare in Setup > Services > Service monitoring rules > Various > Assignment of services to service groups. Ora usa Create rule in folder per farlo. Per prima cosa, specifica a quale gruppo di servizi assegnare i servizi, ad esempio myservicegroup o il suo alias My service group 1.
La parte più interessante è quella che segue nella sezione Conditions. Da un lato, puoi usare cartelle, tag degli host e nomi di host espliciti per creare restrizioni al di fuori dei servizi. Dall'altro, devi dare un nome ai servizi che vuoi raggruppare, come ad esempio Filesystem e myservice per creare un gruppo di file system. La specificazione dei servizi avviene qui sotto forma di espressioni regolari. Questo ti permette di definire i gruppi in modo preciso.
10.4. Controllare i gruppi di servizi per un servizio
Puoi verificare l'assegnazione dei servizi nella pagina dei dettagli di un particolare servizio. In basso, per impostazione predefinita, si trova la riga Service groups the service is member of.
10.5. Usare i gruppi di servizi
Come già accennato, i gruppi di servizi vengono utilizzati in diversi punti: visualizzazioni, mappe NagVis, notifiche e gestori di avvisi.Per le nuove visualizzazioni è importante utilizzare Service groups come fonte di dati. Naturalmente, il widget Views contiene anche visualizzazioni predefinite per i gruppi di servizi, ad esempio un chiaro riepilogo:
Cliccando sui nomi del gruppo di servizi riceverai una visualizzazione completa di tutti i servizi del rispettivo gruppo.
Se utilizzi i gruppi di servizi nelle mappe di NagVis, riceverai un riepilogo dei gruppi di servizi aperti in un menu a icone:
Quando utilizzi i gruppi di servizi nelle notifiche e neigestori di avvisi, questi sono disponibili comecondizioni/filtri, di cui puoi utilizzare uno o più:
11. Ulteriori informazioni sui plug-in di controllo
11.1. Breve descrizione della 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 suo stato, creare/mantenere le 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 al massimo un servizio per host, ad esempioCPU utilization), l'elemento è vuoto e non viene mostrato.
11.2. Plug-in di controllo disponibili
L'elenco di tutti i plug-in di controllo disponibili è disponibile all'indirizzo Setup > Services > Catalog of check plugins. Qui è possibile cercare i singoli plug-in, filtrati in varie categorie:
Per ogni plug-in vengono mostrate tre colonne di informazioni: una descrizione del servizio (Tipo di controllo), il nome del plug-in di controllo (Nome del plug-in) e le fonti di dati compatibili (Agenti):
