Scrittura di plug-in di controllo basati su agente

Dalla versione di Checkmk 2.0.0, è stata sviluppata una nuova Check API per la programmazione dei plug-in di controllo. Nella versione di Checkmk 2.3.0, la Check API V2 è la versione attuale. In questo articolo ti mostreremo come utilizzare la Check API versione 2 per la programmazione dei plug-in. Puoi trovare informazioni sulla migrazione alla Check API versione 2 alla fine di questo articolo nel capitolo Migrazione.

Puoi accedere alla documentazione di Check API in qualsiasi momento tramite l'interfaccia utente di Checkmk: Help > Developer resources > Plugin API references. Nella nuova finestra del browser, seleziona Agent based ("Check API") > Version 2 nella barra di navigazione a sinistra:

Qui non troverai solo la documentazione della Check API in tutte le versioni supportate, ma anche quella di tutte le altre API rilevanti per la creazione di plug-in di controllo. In questo articolo non utilizzeremo solo la Check API, ma anche la Rulesets API V1 per la creazione di un set di regole e la Graphing API V1 per la creazione di definizioni di metriche.

Se sei interessato a programmare i plug-in di controllo, devi avere i seguenti requisiti:

Il primo passo da fare prima di scrivere un programma plug-in è la ricerca: ciò significa che bisogna scoprire come ottenere le informazioni necessarie per il monitoraggio.

Per l'esempio scelto, utilizziamo il fatto che il server Checkmk è anche l'host. Questo significa che inizialmente è sufficiente recuperare i dati di stato tramite Livestatus, cioè i dati organizzati in tabelle che Checkmk conserva nella memoria volatile sugli host e i servizi monitorati.

Accedi come utente dell'istanza e interroga le informazioni sui gruppi di host con il seguente comando:

La prima riga dell'output contiene i nomi delle colonne della tabella hostgroups interrogata. Il punto e virgola funge da separatore. Le righe successive contengono il contenuto di tutte le colonne, anch'esse separate dal punto e virgola.

L'output è già relativamente confuso in questo piccolo esempio e contiene informazioni che non sono rilevanti per il nostro esempio. In generale, dovresti lasciare l'interpretazione dei dati a Checkmk. Tuttavia, il pre-filtraggio sull'host può ridurre il volume di dati da trasferire se non tutti sono effettivamente necessari. Quindi, in questo caso, limita la query alle colonne rilevanti (Columns), ai nomi dei gruppi di host (name) e agli host in questi gruppi (members):

L'interfaccia Livestatus si aspetta di ricevere tutti i comandi e le intestazioni in una riga separata. Le interruzioni di riga necessarie sono indicate da \n.

In questo esempio, ci sono attualmente tre gruppi di host: due gruppi per le sedi e uno per il gruppo check_mk, che contiene un host chiamato localhost.

Il gruppo di host check_mk è una caratteristica speciale dei gruppi di host, non è stato creato da te e non puoi aggiungere attivamente un host a questo gruppo. Da dove viene questo gruppo di host? Poiché per definizione ogni host in Checkmk deve appartenere a un gruppo, Checkmk assegna ogni host che non è stato specificamente assegnato a un gruppo al gruppo "speciale" check_mk come impostazione predefinita. Non appena avrai assegnato un host a uno dei tuoi gruppi di host, verrà rimosso da Checkmk dal gruppo check_mk. Non c'è nemmeno modo di riassegnare un host al gruppo di host check_mk.

Per il nostro esempio utilizziamo esattamente queste proprietà del gruppo check_mk: poiché ogni host deve essere assegnato a una posizione, il gruppo di host check_mk deve essere vuoto. Se non è vuoto, è necessario agire, cioè gli host in esso contenuti devono essere assegnati ai gruppi di host e quindi alle posizioni appropriate.

Finora, come utente dell'istanza, hai utilizzato il comando lq per visualizzare le informazioni, il che è utile per comprendere i dati.

Tuttavia, per recuperare questi dati dal server Checkmk, il nuovo comando deve entrare a far parte dell'agente Checkmk sull'host monitorato. In teoria, potresti modificare direttamente l'agente Checkmk nel file /usr/bin/check_mk_agent e includere questa parte. Questo metodo, tuttavia, avrebbe lo svantaggio di far scomparire il nuovo comando quando il software dell'agente viene aggiornato perché questo verrà sovrascritto durante l'aggiornamento.

Per questo motivo è meglio creare un plug-in dell'agente: tutto ciò di cui hai bisogno è un file eseguibile che contenga il comando e che si trovi nella directory /usr/lib/check_mk_agent/plugins/.

Un'altra cosa è importante: i dati non possono essere semplicemente inviati. Avrai bisogno di un'intestazione di sezione. Si tratta di una riga formattata in modo speciale che contiene il nome del nuovo plug-in dell'agente. Questa intestazione di sezione permette a Checkmk di riconoscere in seguito dove iniziano i dati del nuovo plug-in dell'agente e dove finiscono quelli del plug-in precedente. È più facile se il plug-in dell'agente, l'intestazione di sezione e il plug-in di controllo hanno lo stesso nome, anche se questo non è obbligatorio.

Quindi, prima di tutto, dovrai trovare un nome significativo per il tuo nuovo plug-in di controllo. Questo nome può contenere solo lettere minuscole (solo a-z, niente dieresi, niente accenti), trattini bassi e cifre e deve essere unico. Evita i conflitti di nome con i plug-in di controllo esistenti. Se sei curioso di sapere quali nomi esistono già, in un'istanza Checkmk alla riga di comando puoi elencarli con cmk -L:

L'output qui mostra solo le prime righe del lunghissimo elenco. Grazie all'uso dei prefissi, l'assegnazione di molti plug-in di controllo è già facilmente riconoscibile. L'uso dei prefissi è quindi consigliato anche per i tuoi plug-in di controllo. Tra l'altro, la seconda colonna mostra come il rispettivo plug-in di controllo ottiene i suoi dati.

Un nome adatto per il nuovo plug-in di controllo del nostro esempio è myhostgroups.

root Ora hai tutte le informazioni necessarie per creare lo script per il plug-in dell'agente. Crea un nuovo file myhostgroups come user agent nella directory /usr/lib/check_mk_agent/plugins/:

Cosa significa in dettaglio?

La prima riga contiene lo "shebang" (abbreviazione di sharp e bang, quest'ultimo abbreviazione del punto esclamativo), grazie al quale Linux riconosce che deve eseguire lo script con la shell specificata.

Per rendere lo script adattabile, vengono introdotte due variabili:

Utilizza il comando echo per produrre l'header sezioni. Poiché le colonne della tabella sono separate da un punto e virgola, utilizza l'aggiunta sep(59) per specificare che il punto e virgola viene utilizzato come separatore per i dati nell'output dell'agente. 59 sta per il codice ASCII 59, il punto e virgola. Senza questa aggiunta, il carattere spazio (carattere ASCII 32) verrebbe utilizzato come separatore per impostazione predefinita.

Per poter utilizzare il comando lq, che è a tua disposizione come utente dell'istanza, in uno script eseguito dall'utente root, devi anteporre il prefisso su.

Una volta creato il file, è importante renderlo eseguibile:

Puoi provare il plug-in dell'agente direttamente a mano inserendo il percorso completo come comando:

I gruppi di host che non contengono host non vengono elencati.

I test e la risoluzione dei problemi sono le attività più importanti quando si crea un plug-in dell'agente funzionante. È meglio procedere in tre fasi:

Testare l'agente localmente è molto semplice. Come root, chiama il comando check_mk_agent:

La nuova sezione deve apparire da qualche parte nel lunghissimo output. I plug-in dell'agente vengono emessi dall'agente alla fine del processo.

Puoi scorrere l'output aggiungendo less (premi la barra spaziatrice per scorrere, / per cercare e q per uscire):

In alternativa, puoi cercare le righe interessanti nell'output. Ad esempio, grep con -A ha un'opzione che consente di emettere alcune righe in più dopo ogni risposta. Questo ti permette di cercare ed emettere comodamente la sezione:

Il terzo e ultimo test viene effettuato direttamente dal sito Checkmk. Includi l'host nel monitoraggio (ad esempio come localhost), effettua il login come user dell'istanza e recupera i dati dell'agente con cmk -d:

Questo dovrebbe produrre lo stesso risultato del comando precedente.

Se funziona, il tuo agente è pronto. Hai creato un breve script nel percorso /usr/lib/check_mk_agent/plugins/myhostgroups e lo hai reso eseguibile.

Ora tutto ciò che segue avviene solo sul server Checkmk: lì scrivi il plug-in di controllo.

Per i tuoi plug-in di controllo troverai la directory di base già pronta nella gerarchia local della directory del sito. Si tratta di ~/local/lib/python3/cmk_addons/plugins/. La directory appartiene all'utente dell'istanza e quindi è scrivibile per te.

In questa directory, i plug-in sono organizzati in famiglie di plug-in, i cui nomi del plug-in possono essere definiti liberamente. Ad esempio, tutti i plug-in relativi ai dispositivi Cisco sono archiviati nella cartella cisco, mentre tutti i plug-in relativi ai gruppi di host sono archiviati nella cartella myhostgroups. Questa convenzione permette a tutti i plug-in appartenenti alla stessa famiglia di condividere il codice ed è utilizzata esattamente nello stesso modo dai plug-in forniti con Checkmk.

In questa sottocartella <plug-in_family>, vengono poi create altre sottocartelle con nomi predefiniti a seconda delle necessità per le varie API, ad esempio agent_based per l'API Check dei plug-in dell'agente di controllo. A sua volta, in seguito introdurremo altre sottocartelle per l'API Rulesets e l'API Graphing.

Crea le due sottodirectory per il nuovo plug-in dell'agente di controllo e poi passa ad esse per lavorare:

Puoi modificare il plug-in di controllo con qualsiasi editor di testo installato sul sistema Linux.

Crea qui il file myhostgroups.py per il plug-in di controllo. La convenzione vuole che il nome del file rifletta il nome della sezione dell'agente Checkmk. È obbligatorio che il file finisca con .py, perché dalla versione Checkmk 2.0.0 i plug-in di controllo sono sempre dei veri e propri moduli Python.

Un framework di base eseguibile(scaricabile da GitHub), che verrà ampliato passo dopo passo nel seguito, ha il seguente aspetto:

Per prima cosa, è necessario importare le funzioni e le classi necessarie per i plug-in di controllo dai moduli Python. Per il nostro esempio, importeremo solo ciò che sarà necessario o potrà essere utile nel resto dell'articolo. In questo caso, cmk.agent_based.v2 è utilizzato per specificare che i moduli della Check API V2 sono importati:

La funzione parse ha il compito di "analizzare" i dati "grezzi" dell'agente, cioè di analizzarli e suddividerli, e di inserirli in un modulo logicamente strutturato che sia facile da processare per tutti i passaggi successivi.

Come mostrato nella sezione dedicata al test dell'agente, la sezione fornita dal plug-in dell'agente ha la seguente struttura:

Checkmk divide già le righe della sezione fornita dal plug-in dell'agente in un elenco di righe in base al separatore presente nell'intestazione della sezione (nell'esempio ;); queste righe sono a loro volta elenchi di parole. La seguente struttura di dati è quindi disponibile in Checkmk al posto dei dati grezzi del plug-in dell'agente:

Nell'elenco interno, il primo elemento contiene il nome del gruppo di host e il secondo i nomi degli host appartenenti al gruppo.

È possibile indirizzare tutte queste informazioni, ma solo attraverso la loro posizione nel set di dati. Pertanto, dovrai sempre specificare il numero di parentesi quadre e il numero di "sequenza" del contenuto desiderato all'interno di ogni parentesi. Con volumi di dati più grandi, questo diventa sempre più complesso e diventa sempre più difficile mantenere una panoramica.

A questo punto, una funzione di parsing offre chiari vantaggi grazie alla struttura che crea: rende il codice più facile da leggere, gli accessi sono più performanti ed è molto più semplice mantenere una panoramica. Trasforma la struttura dei dati fornita da Checkmk in modo tale da poter indirizzare a piacimento ogni singolo valore per nome (o chiave), senza dover cercare ripetutamente nell'array per trovare quello che stai cercando:

La convenzione prevede che la funzione di parsing prenda il nome della sezione agente e inizi con parse_. Riceve string_table come unico argomento. Nota che non sei libero di scegliere l'argomento: deve essere chiamata esattamente così.

Con def specifichi in Python che una funzione deve essere definita di seguito.parsed = {} crea il dizionario con la struttura dei dati migliorata. Nel nostro esempio, esamineremo ogni riga, elemento per elemento. Il gruppo di host seguito dai membri del gruppo di host viene preso da ogni riga e assemblato in una voce per il dizionario.

Il dizionario viene poi restituito con return parsed.

Affinché l'intera procedura abbia effetto, devi creare la nuova sezione agente con la nuova funzione di parsing. Solo così sarà riconosciuta e presa in considerazione da Checkmk. Per farlo, crea la sezione agente come istanza della classe AgentSection:

È importante che il nome della sezione corrisponda esattamente all'header sezioni nell'output dell'agente. Da questo momento in poi, ogni plug-in di controllo che utilizza la sezione myhostgroups riceve il valore restituito dalla funzione di parse. Di regola, si tratta dell'omonimo plug-in di controllo, ma anche altri plug-in di controllo possono sottoscrivere questa sezione, come mostreremo nell'estensione del plug-in di controllo.

A proposito: Se vuoi saperlo con precisione, puoi dare un'occhiata alla documentazione dell'API Check, dove troverai una descrizione dettagliata di questa classe e anche delle classi, delle funzioni e degli oggetti che verranno utilizzati più avanti in questo articolo.

Affinché Checkmk riconosca l'esistenza di un nuovo plug-in di controllo, è necessario crearlo. Ciò avviene creando un'istanza della classe CheckPlugin.

Devi sempre specificare almeno quattro cose:

Il nome dell'istanza deve iniziare con check_plugin_. L'aspetto è quindi il seguente:

È meglio non provarlo ancora, perché è necessario scrivere le funzioni discover_myhostgroups e check_myhostgroups. Queste devono comparire nel codice sorgente prima della creazione della sezione agente e del plug-in dell'agente come descritto sopra.

Una caratteristica speciale di Checkmk è la scoperta automatica dei servizi da monitorare. Affinché questo funzioni, ogni plug-in di controllo deve definire una funzione che utilizza l'output dell'agente per riconoscere se un servizio di questo tipo o quali servizi di questo tipo devono essere creati per l'host in questione.

La funzione di scoperta viene sempre chiamata quando viene effettuata una scoperta del servizio per un host e decide se e quali servizi devono essere creati. Nel caso standard, riceve esattamente un argomento con il nome section che contiene i dati della sezione dell'agente in un formato preparato dalla funzione parse.

Pertanto, implementa la seguente semplice logica:se la sezione dell'agente myhostgroups esiste, crea anche un servizio adatto, che apparirà automaticamente su tutti gli host su cui è stato distribuito il plug-in dell'agente.

Per i plug-in di controllo che creano solo un servizio per host, non sono necessarie altre informazioni:

La funzione di scoperta deve restituire un oggetto del tipo service per ogni servizio da creare utilizzando yield (non con return). In Python, yield ha la stessa funzione di return- entrambi restituiscono un valore alla funzione chiamante. La differenza decisiva è che yield ricorda a che punto è la funzione nell'elaborazione dei dati. La chiamata successiva continua dopo l' ultima istruzione di yield e non ricomincia dall'inizio. Ciò significa che non viene letto solo il primo risultato (come nel caso di return), ma tutti i risultati in sequenza (questo vantaggio diventerà rilevante più avanti nel nostro esempio di scoperta del servizio).

Ora puoi passare alla funzione di controllo vera e propria, che utilizza l'output dell'agente corrente per decidere quale stato deve assumere il servizio e può fornire ulteriori informazioni.

L'obiettivo della funzione di controllo è quello di impostare un controllo che possa essere utilizzato per verificare se è stato assegnato un gruppo di host a un qualsiasi host. A tal fine, controlla se il gruppo di host di check_mk contiene host. In questo caso, il servizio dovrebbe ricevere lo stato CRIT. In caso contrario, tutto è OK e anche lo stato del servizio.

Ecco l'implementazione:

E ora la spiegazione: la funzione check_myhostgroups() recupera innanzitutto il valore appartenente alla chiave check_mk nella variabile attr. Poi la variabile hosts viene collegata al valore members se esiste. Se non ci sono members, hosts rimane vuota.

Segue un'interrogazione di if per la valutazione vera e propria:

Una volta creata la funzione di controllo, il plug-in di controllo è pronto.

Il plug-in di controlloe il plug-in dell'agentesono stati resi disponibili su GitHub.

Il test e l'attivazione vengono eseguiti alla riga di comando con il comando cmk.

Per prima cosa prova la scoperta del servizio con l'opzione -I. Aggiungendo l'opzione v (per verbose), viene richiesto un output dettagliato. --detect-plugins limita l'esecuzione del comando a questo plug-in di controllo e, tramite localhost, a questo host:

Come previsto, la scoperta del servizio riconosce un nuovo servizio nel plug-in di controllo myhostgroups.

Ora puoi provare il controllo contenuto nel plug-in di controllo:

Eseguendo il controllo, verrà determinato lo stato del servizio trovato in precedenza.

Se tutto è andato come previsto, puoi attivare le modifiche; in caso contrario, troverai informazioni utili nel capitolo sulla risoluzione dei problemi.

Infine, attiva le modifiche riavviando il nucleo di monitoraggio:

Nel monitoraggio di Checkmk, ora troverai il nuovo servizio Host group check_mk presso l'host localhost:

Congratulazioni per aver creato con successo il tuo primo plug-in di controllo!

Il primo plug-in di controllo, completato di recente, deve essere esteso passo dopo passo. Finora, il plug-in dell'agente ha fornito solo informazioni sui nomi e sui membri dei gruppi di host. Per poter valutare lo stato dell'host e dei servizi in esecuzione su di esso, ad esempio, sono necessari altri dati.

Nel capitolo precedente hai realizzato un controllo molto semplice che crea un servizio su un host. Tuttavia, è molto comune che ci siano più servizi da un singolo controllo su un host.

L'esempio più comune è quello di un servizio per un file system su un host. Il plug-in di controllo con il nome df crea un servizio per ogni file system sull'host. Per distinguere questi servizi, il mount point del file system (ad esempio /var) o la lettera dell'unità (ad esempio C:) viene incorporato nel nome del servizio. Questo si traduce in un nome del servizio come Filesystem /var o Filesystem C:. La parola /var o C: viene qui indicata come un elemento. Stiamo quindi parlando anche di un controllo con elementi.

Se vuoi creare un controllo con elementi, devi implementare le seguenti funzioni:

Per testare questa funzione nella pratica, dovrai creare un servizio separato per ogni gruppo di servizi esistente.

Dato che il plug-in di controllo myhostgroups creato nel capitolo precedente per controllare il gruppo standard check_mk dovrebbe continuare a funzionare, questo plug-in di controllo rimane così com'è. Per l'estensione, crea il nuovo plug-in di controllo myhostgroups_advanced nel file esistente myhostgroups.py.- Nel primo passo, come in precedenza, crea un'istanza della classe CheckPlugin.

Qui puoi trovare il vecchio codice e il nuovo codice evidenziato:

Affinché il nuovo plug-in di controllo possa essere distinto dal vecchio, gli viene assegnato un nome univoco con myhostgroups_advanced. Il parametro sections determina le sezioni dell'output dell'agente a cui il plug-in di controllo si iscrive. In questo caso, myhostgroups viene utilizzato per specificare che il nuovo plug-in di controllo utilizza gli stessi dati del vecchio: la sezione del plug-in dell'agente preparata dalla funzione di parsing. Il nome del servizio contiene ora il segnaposto %s. Il nome dell'elemento viene inserito in seguito da Checkmk. Nelle ultime due righe, vengono definiti i nomi della nuova funzione di discovery e della nuova funzione di check, entrambe ancora da scrivere.

Prima la funzione di ricerca, che ora ha il compito di determinare gli elementi da monitorare: anche questa viene inserita in aggiunta a quella esistente:

Come in precedenza, la funzione di ricerca riceve l'argomento section. I singoli gruppi di host vengono esaminati in un ciclo. Tutti i gruppi di host sono di interesse in questo caso, ad eccezione di check_mk, poiché questo gruppo di host speciale è già stato preso in considerazione dal plug-in di controllo esistente myhostgroups. Ogni volta che viene trovato un elemento, questo viene restituito con yield, che crea un oggetto del tipo Service, che a sua volta riceve il nome del gruppo di host come elemento.

Se l'host viene monitorato in seguito, la funzione di controllo viene richiamata separatamente per ogni servizio e quindi per ogni elemento. Questo ti porta alla definizione della funzione di controllo per il nuovo plug-in di controllo myhostgroups_advanced. La funzione di controllo riceve l'argomento item oltre alla sezione. La prima riga della funzione si presenta quindi come segue:

L'algoritmo della funzione di controllo è semplice: se il gruppo di host esiste, il servizio viene impostato su OK e vengono elencati il numero e i nomi degli host del gruppo. La funzione completa è questa:

Il risultato del controllo viene fornito restituendo un oggetto della classe Result tramite yield. Questo richiede i parametri state e summary. Qui, state definisce lo stato del servizio (nell'esempio OK) e summary il testo che viene visualizzato nella sezione Summary del servizio. Questi dati sono puramente informativi e non vengono valutati ulteriormente da Checkmk. Puoi trovare maggiori informazioni a riguardo nella prossima sezione.

Fin qui tutto bene, ma cosa succede se l'elemento che stai cercando non viene trovato? Questo può accadere se in passato è già stato creato un servizio per un gruppo di host, ma ora questo gruppo di host è scomparso: o perché il gruppo di host esiste ancora in Checkmk ma non contiene più un host, o perché è stato completamente cancellato. In entrambi i casi, questo gruppo di host non sarà più presente nell'output dell'agente.

Se un elemento ricercato non viene trovato, Checkmk genera automaticamente il risultato UNKNOWN - Item not found in monitoring data per il servizio. Questo è intenzionale e positivo: se un elemento ricercato non viene trovato, puoi semplicemente eseguire Python dalla funzione e lasciare che Checkmk faccia il suo lavoro.

Checkmk sa solo che l'elemento che c'era prima ora non c'è più. Checkmk non ne conosce il motivo, ma tu sì. È quindi opportuno non tenere per sé questa conoscenza e intercettare questa condizione nella funzione check e visualizzare un messaggio utile.

Cosa è cambiato? La condizione di errore viene ora gestita per prima. Pertanto, controlla nel ramo if se l'elemento non esiste davvero, imposta lo stato a CRIT ed esci dalla funzione con return. In tutti gli altri casi, restituisci OK come prima.

Questo significa che hai adottato la situazione della scomparsa dei gruppi di servizi nella funzione di controllo: invece di SCONOSCIUTO, il servizio associato sarà ora CRIT e conterrà informazioni sulla causa dello stato critico.

Il plug-in dell'agenteesteso e il file esteso per i plug-in di controllosi trovano ancora una volta su GitHub. Quest'ultimo contiene il semplice plug-in di controllo myhostgroups del capitolo precedente, la funzione di parse avanzata e i componenti del nuovo plug-in di controllo myhostgroups_advanced con la creazione del plug-in di controllo, la funzione di ricerca e la funzione di controllo. Nota che le funzioni devono essere sempre definite prima della creazione dei plug-in di controllo o delle sezioni dell'agente, in modo che non si verifichino errori dovuti a nomi di funzioni non definiti.

Poiché il nuovo plug-in di controllo myhostgroups_advanced fornisce nuovi servizi, devi eseguire una scoperta del servizio per questo plug-in di controllo e attivare le modifiche per poter vedere questi servizi nel monitoraggio:

Procedi come descritto nel capitolo sui plug-in di controllo semplici. Non eseguire i primi due comandi per myhostgroups, ma eseguili per il nuovo plug-in di controllo myhostgroups_advanced.

Nello stato di monitoraggio di Checkmk, ogni servizio ha uno stato -OK, WARN, ecc. - e una riga di testo. Questo testo si trova nella colonna Summary - come si può vedere nella schermata precedente - e ha il compito di fornire un breve riassunto dello stato dell'attività del servizio. Il concetto è che questo testo non deve superare la lunghezza di 60 caratteri. Questo garantisce una visualizzazione concisa della tabella senza fastidiose interruzioni di riga.

Esiste anche il campo Details, in cui vengono visualizzati tutti i dettagli sullo stato del servizio, che include anche tutte le informazioni di riepilogo. Cliccando sul servizio si apre la pagina del servizio, in cui si possono vedere i due campi Summary e Details e molti altri.

Quando chiami yield Result(...), puoi stabilire quali informazioni sono così importanti da dover essere visualizzate nel riepilogo e per quali è sufficiente che appaiano nei dettagli.

Nel nostro esempio, hai sempre utilizzato una chiamata del tipo seguente:

Ciò significa che il testo definito con summary appare sempre nel riquadro Summary- e anche nel riquadro Details. Dovresti quindi utilizzarlo solo per le informazioni importanti. Se un gruppo di host contiene molti host, l'elenco riassuntivo può diventare molto lungo, più dei 60 caratteri raccomandati. Se un'informazione è di secondaria importanza, puoi utilizzare details per specificare che il suo testo appare solo nei dettagli:

Nell'esempio precedente, l'elenco degli host viene quindi visualizzato solo nel sito Details. Il sito Summary mostra quindi solo il numero di host del gruppo:

Oltre a summary e details, c'è un terzo parametro. Con notice puoi specificare che un testo per un servizio in OK viene visualizzato solo nei dettagli, ma anche nel riepilogo per tutti gli altri stati. In questo modo è immediatamente chiaro dal riepilogo perché il servizio non è OK. Il parametro notice non è particolarmente utile se i testi sono permanentemente legati agli stati, come nel nostro esempio.

In sintesi, questo significa che:

Per evitare che il numero di servizi su un host aumenti eccessivamente, spesso si combinano diversi risultati parziali in un unico servizio. Ad esempio, il servizio Memory di Linux controlla non solo l'utilizzo della RAM e dello swap, ma anche della memoria condivisa, delle tabelle di pagine e di ogni altra cosa.

L'API Check fornisce un'interfaccia molto comoda per questo. Una funzione di controllo può semplicemente generare un risultato con yield tutte le volte che è necessario. Lo stato generale del servizio si basa quindi sul peggior risultato parziale nell'ordine OK → WARN → SCONOSCIUTO → CRIT.

Nell'esempio, utilizza questa opzione per definire due risultati aggiuntivi per ogni servizio dei gruppi di servizi host oltre al risultato esistente. Questi valutano la percentuale di host nello stato UP e i servizi nello stato OK. Utilizzi le colonne aggiuntive della tabella dei gruppi di host precedentemente definite nell'output dell'agente e nella funzione di parsing.

Ora espandi la funzione di controllo per gradi dall'alto verso il basso:

Il ramo if rimane invariato, cioè i nuovi risultati parziali si applicano solo ai gruppi di host che esistono. Definisci quindi cinque variabili per le colonne della tabella dei gruppi di host contenuta nella sezione. Da un lato, questo aumenta la leggibilità e, dall'altro, puoi convertire le stringhe lette in numeri con int() per le quattro colonne che devono ancora essere utilizzate per il calcolo.

L'unico risultato esistente rimane (quasi) invariato:

Solo l'accesso nella "F-String" di Python all'espressione che restituisce il valore è ora più semplice che in precedenza, poiché attr è già presente nelle definizioni delle variabili.

Passiamo ora al vero e proprio core dell'estensione, la definizione di un risultato che implementa la seguente affermazione: "Il servizio del gruppo di host è WARN quando il 90% degli host è UP e CRIT quando l'80% degli host è UP". La convenzione è che il controllo passa a WARN o CRIT non appena viene raggiunta la soglia e non solo quando viene superata. L'API Check fornisce la funzione ausiliaria check_levels per confrontare un valore determinato con i valori soglia.

Nella prima riga, la percentuale viene calcolata dal numero totale e dal numero di host nello stato UP e viene memorizzata nella variabile hosts_up_perc. La barra singola (/) esegue una divisione in virgola mobile, assicurando che il risultato sia un valore float. Questo è utile perché alcune delle funzioni utilizzate in seguito prevedono un valore float come input.

Nella seconda riga, il risultato della funzione check_levels viene restituito come oggetto del tipo Result, che può essere trovato nella documentazione dell'API. Questa funzione viene alimentata con la percentuale appena calcolata come valore (hosts_up_perc), i due valori di soglia inferiori (levels_lower), un'etichetta che precede l'uscita (label) e infine con notice_only=True.

Quest'ultimo parametro utilizza il parametro notice già introdotto nella sezione precedente per l'oggetto Result(). Con notice_only=True specifichi che il testo del servizio viene visualizzato in Summary solo se lo stato non è OK. Tuttavia, i risultati parziali che portano a un WARN o a un CRIT saranno sempre visibili nel riepilogo, indipendentemente dal valore di notice_only.

Infine, definisci il terzo risultato nello stesso modo del secondo, che valuta la percentuale di servizi in stato OK:

Questo completa la funzione di controllo.

Il servizio per un gruppo di host ora valuta tre risultati e visualizza lo stato peggiore di questi nel monitoraggio, come nell'esempio seguente:

Non sempre, ma spesso i controlli hanno a che fare con i numeri e questi numeri sono spesso valori misurati o calcolati. Nel nostro esempio, il numero di host nel gruppo di host (num_hosts) e il numero di host nello stato UP (num_hosts_up) sono i valori misurati. La percentuale di host nello stato UP (hosts_up_perc) è un valore calcolato a partire da questi valori. Se questo valore può essere visualizzato in un periodo di tempo, si parla anche di metrica.

Con il suo sistema integrato di grafici, Checkmk dispone di un componente per la memorizzazione, la valutazione e la visualizzazione di tali valori, completamente indipendente dal calcolo degli stati OK, WARN e CRIT.

In questo esempio, definirai i due valori calcolati, hosts_up_perc e services_ok_perc, come metriche. Le metriche saranno immediatamente visibili nell'interfaccia utente di Checkmk senza che tu debba fare nulla. Per ogni metrica viene generato automaticamente un grafico.

Le metriche vengono determinate dalla funzione di controllo e restituite come risultato aggiuntivo. Il modo più semplice è quello di aggiungere le informazioni sulle metriche alla funzione check_levels() durante la chiamata.

Come promemoria, le righe con la chiamata alla funzione check_levels() della sezione precedente sono riportate qui:

I due nuovi argomenti per la metrica sono metric_name e boundaries:

Per mantenere le cose semplici e significative, per il nome della metrica usa il nome della variabile in cui la percentuale è memorizzata come valore.

Puoi utilizzare boundaries per fornire al sistema grafico informazioni sull'intervallo di valori possibili. Questo si riferisce al valore più piccolo e più grande possibile. Nel caso di una percentuale, i limiti di 0.0 e 100.0 non sono troppo difficili da determinare. Sono consentiti sia i numeri in virgola mobile che i numeri interi (che vengono convertiti internamente in numeri in virgola mobile), ma non le stringhe. Se viene definito solo un limite dell'intervallo di valori, è sufficiente inserire None per l'altro, ad esempio boundaries = (0.0, None).

Con questa estensione, la funzione check_levels ora restituisce anche un oggetto del tipo Metric tramite yield oltre a Result.

Ora puoi definire la metrica services_ok_perc nello stesso modo. Le ultime righe della funzione di controllo saranno quindi come queste:

Con la funzione di controllo estesa, entrambi i grafici sono visibili nel monitoraggio. Nell'elenco dei servizi, l'icona mostra ora che ci sono dei grafici per il servizio. Se punti l'icona con il mouse, i grafici verranno visualizzati in anteprima.

Una panoramica di tutti i grafici, con le relative legende e altro ancora, si trova nei dettagli del servizio.

Ma cosa fare se il valore della metrica desiderata non è stato definito con la funzione check_levels()? Naturalmente puoi definire una metrica indipendentemente da una chiamata di funzione. A questo scopo viene utilizzato l'oggetto Metric(), che puoi anche creare direttamente tramite il suo costruttore. La definizione alternativa di una metrica per il valore hosts_up_perc si presenta così:

Gli argomenti di Metric() sono molto simili a quelli della chiamata di funzione mostrata sopra: sono obbligatori i primi due argomenti per il nome della metrica e il valore. Inoltre, ci sono due argomenti opzionali: levels per i valori di threshold WARN e CRIT e boundaries per l'intervallo di valori.

Ora usa l'opzione di definire non solo i due valori calcolati, ma anche tutti i valori misurati come metriche usando Metric()- nel nostro esempio, i quattro valori misurati dalla tabella del gruppo di host. Limitati alle due specifiche obbligatorie di nome e valore della metrica. Le quattro nuove righe completano l'estensione della funzione di controllo delle metriche:

Questo aumenta il numero di grafici per servizio, ma ti dà anche la possibilità di combinare più metriche in un unico grafico, ad esempio. Mostriamo queste e altre opzioni nella sezione Personalizzare la visualizzazione delle metriche.

Nel file di esempio suGitHubpuoi ritrovare l'intera funzione di controllo.

Per creare un nuovo set di regole, crea innanzitutto una nuova sottodirectory nella directory della famiglia del plug-in ~/local/lib/python3/cmk_addons/plugins/myhostgroups/. Il nome rulesets è predefinito per questa sottodirectory:

In questa directory, crea un file per la definizione del set di regole. Il nome del file deve essere basato su quello del plug-in di controllo e, come tutti i file del plug-in, deve avere l'estensione py. Per il nostro esempio, il nome del file ruleset_myhostgroups.py è adatto.

Vediamo passo dopo passo la struttura di questo file. Innanzitutto ci sono alcuni comandi di importazione:

Per prima cosa, vengono importate le classi dei testi.

La seconda riga effettua una selezione dalle specifiche del modulo, cioè gli elementi di base per l'interfaccia grafica che vengono utilizzati nel set di regole, ad esempio la selezione binary (BooleanChoice), la selezione multipla (Dictionary, DictElement), la definizione dei threshold (SimpleLevel, LevelDirection, DefaultValue) e l'inserimento di numeri in virgola mobile (Float). Qui richiedi solo gli elementi logici del modulo e lascia a Checkmk la progettazione dell'interfaccia grafica.

L'ultima riga importa le specifiche della regola, che determinano l'area di applicazione della regola in Checkmk, cioè la definizione dei parametri del check, l'assegnazione agli host e agli elementi e la memorizzazione in un tema. Se il tuo plug-in di controllo myhostgroups_advanced genera diversi servizi, importa qui HostAndItemCondition. Se il tuo controllo non genera un servizio, in altre parole non ha un elemento, importa invece HostCondition.

L'utente deve poter definire separatamente i due valori soglia per WARN e CRIT sia per il numero di host nello stato UP che per il numero di servizi nello stato OK:

Per fare ciò, crea una funzione che generi il dizionario. Puoi scegliere liberamente il nome della funzione; è necessario solo per la creazione della regola sottostante. Il nome dovrebbe iniziare con un trattino basso in modo che la funzione non sia visibile oltre il confine del modulo.

Il modulo return Dictionary() è obbligatorio. All'interno di esso, utilizza elements={} per creare gli elementi del dizionario, nell'esempio hosts_up_lower e services_ok_lower. Il modulo dei parametri SimpleLevels viene utilizzato per inserire dei valori di soglia fissi. Nel modulo, devi prima definire i title e i numeri in virgola mobile per i valori da inserire (form_spec_template). Utilizza LevelDirection.LOWER per specificare che il livello cambierà se i valori scendono al di sotto di questo livello.

Infine, puoi utilizzare prefill_fixed_levels per fornire agli utenti del set di regole dei valori invece che dei semplici campi di input vuoti. Nota che questi valori visualizzati nella GUI non sono i valori predefiniti impostati più avanti nella creazione del plug-in di controllo tramite check_default_parameters. Se vuoi visualizzare gli stessi valori predefiniti nella GUI che si applicano anche alla funzione di controllo, devi mantenere i valori coerenti in entrambi i luoghi.

Infine, crea il nuovo set di regole utilizzando gli elementi importati e quelli autodefiniti, creando una nuova istanza della classe CheckParameters. Il nome di questa istanza deve iniziare con rule_spec_:

Le spiegazioni sono le seguenti:

Una volta creato il file per il set di regole, devi verificare che tutto funzioni fino a questo momento, sempre senza una connessione al plug-in di controllo. Per farlo, devi prima riavviare Apache del sito in modo che il nuovo file possa essere letto. Questa operazione viene eseguita con il comando:

Il set di regole si trova in Setup nella pagina citata sopra. Puoi trovare il set di regole anche utilizzando la funzione di ricerca nel menu di configurazione, ma solo dopo aver riavviato Redis:

Il set di regole appena definito avrà il seguente aspetto nella GUI:

Nel box Conditions troverai il campo di input Host group name definito tramite HostAndItemCondition per limitare la regola ai gruppi di host.

Crea una regola e prova diversi valori, come mostrato nella schermata qui sopra. Se funziona senza errori, ora puoi utilizzare i parametri del check nella funzione di controllo.

Il set di regole appena creato è ora connesso al plug-in di controllo completato in via provvisoria nel capitolo precedente. Affinché la regola abbia effetto, devi permettere al plug-in di controllo di accettare i parametri del check e dirgli quale regola deve essere utilizzata. Per farlo, aggiungi due nuove righe al file del plug-in di controllo quando crei il plug-in di controllo myhostgroups_advanced:

Con la voce check_default_parameters puoi definire i valori predefiniti che si applicano finché non viene creata alcuna regola. Quando converti il plug-in di controllo per i parametri del check, questa riga deve essere presente. Nel caso più semplice, passa un dizionario vuoto {}.

In secondo luogo, inserisci check_ruleset_name, cioè il nome del set di regole. In questo modo Checkmk sa da quale set di regole devono essere determinati i parametri.

Ora Checkmk cercherà di passare i parametri del check. Affinché questo funzioni, devi estendere la funzione check in modo che si aspetti l'argomento params, inserito tra item e section:

Se stai creando un controllo senza elementi, item viene omesso e params si trova all'inizio.

Si consiglia vivamente di far uscire il contenuto della variabile params con un print come primo test:

Quando il plug-in di controllo viene eseguito, le righe stampate (una per ogni servizio) con i valori definiti da una regola avranno un aspetto simile a questo:

Ora personalizza ulteriormente la funzione del check in modo che i parametri passati possano avere effetto. Ottieni i due elementi del dizionario definiti nella regola con il nome selezionato dai parametri:

Più avanti nella funzione di controllo, i valori di soglia precedentemente codificati "fixed", (90.0, 80.0) vengono sostituiti dalle variabili hosts_up_lower e services_ok_lower:

Se è stata configurata una regola, ora puoi monitorare i gruppi di host dell'esempio con i valori di soglia impostati tramite la GUI. Tuttavia, se non è stata definita alcuna regola, questa funzione di controllo andrà in crash, poiché i parametri predefiniti del plug-in di controllo non saranno stati compilati e il plug-in genererà un KeyError in assenza di una regola.

Tuttavia, questo problema può essere risolto se i valori predefiniti vengono definiti al momento della creazione del plug-in di controllo:

Dovresti sempre passare i valori predefiniti in questo modo (e non intercettare il caso di parametri mancanti nel plug-in di controllo), poiché questi valori predefiniti possono essere visualizzati anche nell'interfaccia Setup. Ad esempio, nella scoperta del servizio di un host, nella pagina Services of host, nel menu Display, c'è lo switch Show check parameters.

Le procedure per la creazione dei set di regole e delle definizioni metriche sono molto simili. Innanzitutto crea una nuova sottodirectory con il nome predefinito graphing nella directory della famiglia del plug-in ~/local/lib/python3/cmk_addons/plugins/myhostgroups/.

Quindi crea un file grafico in questa directory, ad es. graphing_myhostgroups.py.

Per prima cosa, devi eseguire alcuni comandi di importazione:

Per il nostro esempio, ora devi definire la tua metrica per la percentuale di servizi in stato OK, creando un'istanza della classe Metric. Il nome di questa istanza deve iniziare con metric_

Ecco la spiegazione:

Questa definizione nel file grafico assicura che il titolo, l'unità e il colore della metrica siano visualizzati in modo appropriato.

Come per la creazione di un file di set di regole, il file grafico deve essere letto prima che la modifica sia visibile nella GUI, riavviando Apache del sito:

Il grafico della metrica avrà l'aspetto seguente nella GUI di Checkmk:

Se vuoi combinare più metriche in un unico grafico (cosa spesso molto utile), avrai bisogno di una definizione di grafico che potrai aggiungere al file di grafici creato nella sezione precedente.

Nel nostro esempio, le due metriche num_services e num_services_ok devono essere visualizzate in un unico grafico. Le definizioni di metrica sono create nello stesso modo della sezione precedente per services_ok_perc e hanno il seguente aspetto:

Ora aggiungiamo un grafico che disegni queste due metriche sotto forma di linee. Questo avviene tramite un'istanza della classe Graph, il cui nome deve iniziare con un prefisso predefinito (graph_):

Il parametro minimal_range descrive l'intervallo minimo coperto dall'asse verticale del grafico, indipendentemente dai valori effettivi della metrica. L'asse verticale sarà esteso se i valori superano l'intervallo minimo, ma non sarà mai più piccolo.

Il risultato è il grafico combinato nella GUI di Checkmk:

Vuoi visualizzare un Perf-O-Meter per una metrica nella riga dell'elenco dei servizi? Ad esempio, potrebbe apparire così:

Per creare un Perf-O-Meter di questo tipo, avrai bisogno di un'altra istanza, questa volta della classe Perfometer, il cui nome inizia con il prefisso perfometer_:

I Perf-O-Meter sono un po' più complicati dei grafici, poiché non hanno una legenda. È quindi difficile visualizzare un intervallo di valori, soprattutto se si tratta di valori assoluti. È più facile visualizzare una percentuale. Questo è anche il caso dell'esempio precedente:

Altre opzioni ancora più sofisticate per implementare le metriche nei Perf-O-Meter si trovano nella documentazione dell'API di Grafica, ad esempio con le classi Bidirectional e Stacked, che permettono di visualizzare più Perf-O-Meter in uno.

Il file grafico di questo capitolo è disponibile su GitHub e contiene, tra le altre cose, le definizioni delle metriche per i quattro valori misurati e i due valori calcolati.

Le specifiche temporali assolute (timestamp) sono formattate con render.date() o render.datetime(). Le informazioni sono sempre fornite come tempo Unix, cioè in secondi dal 1 gennaio 1970, 00:00:00 UTC - l'inizio dell'epoca Unix. Questo è anche il formato utilizzato dalla funzione Python time.time().

Il vantaggio di questa rappresentazione è che è molto facile da calcolare, ad esempio il calcolo di un periodo di tempo, quando si conoscono gli orari di inizio e fine. La formula è quindi semplicemente duration = end - start. Questi calcoli funzionano indipendentemente dal fuso orario, dal cambio dell'ora legale o dagli anni bisestili.

render.date() render.datetime() aggiunge l'ora. L'output è conforme al fuso orario in cui si trova il server Checkmk che sta eseguendo il controllo. Esempi:

Non sorprenderti se render.datetime(0) non riporta l'ora di 00:00, ma quella di 01:00. Questo perché stiamo scrivendo questo manuale d'uso con il fuso orario della Germania, che è un'ora avanti rispetto all'ora standard UTC (almeno durante l'ora solare, perché il 1° gennaio non c'è l'ora legale).

Per i periodi di tempo (o intervalli di tempo) c'è anche la funzione render.timespan(). Questa funzione riceve una durata in secondi e la restituisce in un modulo leggibile. Per intervalli di tempo più ampi, i secondi o i minuti vengono omessi. Se hai un intervallo di tempo in un oggetto TimeDelta, usa la funzione total_seconds() per leggere il numero di secondi come numero in virgola mobile.

Una frequenza è di fatto il reciproco del tempo. L'unità canonica è l'Hz, che equivale a 1 / sec (il reciproco di un secondo). Un esempio di utilizzo è la frequenza di clock di una CPU:

Per quanto riguarda la memoria di lavoro, i file, i dischi rigidi, i file system e simili, l'unità di misura canonica è il byte. Poiché i computer di solito organizzano queste cose in potenze di due, ad esempio in unità di 512, 1024 o 65.536 byte, si è stabilito fin dall'inizio che un kilobyte non è 1000, e quindi mille volte l'unità, ma 1024 (2 alla potenza di 10) byte. Si tratta di una scelta illogica, ma molto pratica perché di solito si ottengono numeri tondi: il leggendario Commodore C64 aveva 64 kilobyte di memoria e non 65,536.

Sfortunatamente, a un certo punto i produttori di dischi rigidi hanno avuto l'idea di specificare le dimensioni dei loro dischi in unità di 1000. Poiché la differenza tra 1000 e 1024 è del 2,4% per ogni dimensione, moltiplicando questi valori, un disco di dimensioni pari a 1 GB (1024 per 1024 per 1024) diventa improvvisamente 1,07 GB.

Per ovviare a questa fastidiosa confusione, la Commissione Elettrotecnica Internazionale (IEC) ha definito nuovi prefissi basati sul sistema binario. Di conseguenza, oggi un kilobyte è ufficialmente 1000 byte e un kibibyte è 1024 byte (2 alla potenza di 10). Inoltre, si dovrebbe dire mebibyte, gibibyte e tebibyte. Le abbreviazioni sono quindi KiB, MiB, GiB e TiB.

Checkmk rispetta questo standard e ti aiuta con una serie di funzioni di rendering personalizzate per assicurarti di produrre sempre l'output corretto. Ad esempio, c'è la funzione render.disksize() specifica per i dischi rigidi e i file system, che produce il suo output in potenze di 1000.

Quando si parla di dimensioni dei file, spesso è consuetudine specificare le dimensioni esatte in byte senza arrotondare. Questo ha il vantaggio di poter vedere molto rapidamente se un file è cambiato anche solo in minima parte o se due file sono (probabilmente) uguali. A questo scopo si usa la funzione render.filesize():

Se vuoi ottenere un valore che non sia la dimensione di un disco rigido o di un file, usa semplicemente la funzione generica render.bytes(). In questo modo otterrai l'output nella notazione ufficiale "classica" di 1024 potenze:

Gli utenti della rete hanno i loro termini e modi di esprimersi e, come sempre, Checkmk si sforza di adottare il modo convenzionale di comunicare in ogni ambito. Per questo motivo esistono tre diverse funzioni di rendering per le velocità di trasmissione dei dati. Ciò che hanno in comune è che le velocità sono espresse in byte al secondo, anche se l'output effettivo è in bit!

render.nicspeed() rappresenta la velocità massima di una scheda di rete o di una porta dello switch. Poiché non si tratta di valori misurati, non è necessario arrotondare. Anche se nessuna porta può inviare singoli bit, i dati sono espressi in bit per motivi storici.

Importante: tuttavia, è necessario passare anche i byte al secondo!

render.networkbandwidth() è destinata a una velocità di trasmissione effettivamente misurata nella rete. Il valore inserito è di nuovo byte al secondo:

Quando non è coinvolta una rete e la velocità di trasmissione dei dati è ancora una volta il byte. Il caso più evidente è quello della velocità di trasmissione dei dischi rigidi. A questo scopo si utilizza la funzione render.iobandwidth(), che in Checkmk lavora con potenze di 1000:

La funzione render.percent() rappresenta una percentuale, arrotondata a due cifre decimali. Fa eccezione alle altre funzioni in quanto non passa il valore naturale effettivo, cioè il rapporto, ma la percentuale reale. Ad esempio, se qualcosa è pieno a metà, non devi passare 0.5 ma 50.

Poiché a volte può essere interessante sapere se un valore è quasi zero o esattamente zero, i valori sono contrassegnati dall'aggiunta del carattere "<" per i valori superiori a zero ma inferiori allo 0,01%.

Per concludere, ecco una panoramica di tutte le funzioni di rendering:

Se si verifica un'eccezione durante il monitoraggio o la scoperta del servizio nel sito Setup, il sito Summary contiene i riferimenti al report sui crash appena creato. L'aspetto è il seguente, ad esempio:

Facendo clic sul simbolo viene visualizzata una pagina con i dettagli in cui è possibile:

Il traceback ti aiuta come sviluppatore a decidere se c'è un errore nel programma (ad es. la chiamata di una funzione inesistente) o se i dati dell'agente non hanno potuto essere processati come previsto. Nel primo caso vorrai correggere l'errore, nel secondo caso spesso ha senso non fare nulla.

L'invio del report è ovviamente utile solo per i plug-in di controllo che fanno ufficialmente parte di Checkmk. Se metti a disposizione di terzi i tuoi plug-in, puoi chiedere ai tuoi utenti di inviarti i dati.

Se esegui il plug-in di controllo tramite la linea di comando, non riceverai alcuna indicazione sull'ID dei report sui crash generati, ma vedrai solo il messaggio di errore riassunto:

Se aggiungi l'opzione --debug come parametro di chiamata aggiuntivo, riceverai il traceback dall'interprete Python:

Se l'errore non si ripresenta alla prossima chiamata a --debug, ad esempio perché è disponibile un nuovo output dell'agente, puoi anche visualizzare gli ultimi report sui crash nel file system:

In ognuna di queste cartelle sono presenti due file:

Negli esempi mostrati in precedenza, abbiamo utilizzato la funzione print() per visualizzare il contenuto delle variabili o la struttura degli oggetti per gli sviluppatori. Queste funzioni di debug devono essere rimosse dal plug-in di controllo finito.

In alternativa alla rimozione, puoi anche fare in modo che l'output di debug venga visualizzato solo quando il plug-in di controllo viene richiamato dalla console in modalità di debug. Per fare ciò, importa l'oggetto di debug dalla casella degli strumenti Checkmk e, se necessario, l'aiuto alla formattazione pprint(). Ora puoi produrre l'output di debug in base al valore dell'oggetto di debug:

Gli errori evidenti e prevedibili dell'utente (ad esempio, il contenuto della sezione agent indica che il plug-in dell'agente è stato configurato in modo errato) dovrebbero essere risolti con lo stato SCONOSCIUTO e includere note esplicative nel riepilogo.

La questione è come reagire se l'output dell'agente non ha il modulo che ti aspetti, sia che provenga dall'agente Checkmk sia che venga ricevuto tramite SNMP. Supponiamo che ti aspetti sempre tre parole per riga, cosa dovresti fare se ne ricevi solo due?

Se si tratta di un comportamento consentito e conosciuto dall'agente, allora è ovvio che devi intercettarlo e lavorare con una distinzione di casi. Tuttavia, se questo non è consentito, allora è meglio agire come se la riga fosse sempre composta da tre parole, ad esempio con la seguente funzione di parsing:

Se c'è una riga che non è composta esattamente da tre parole, viene generata un'eccezione e si riceve l'utilissimo report sui crash appena citato.

Se si accede a chiavi di un dizionario che si prevede possano essere occasionalmente mancanti, può avere senso reagire di conseguenza, impostando il servizio su CRIT o SCONOSCIUTO e inserendo una nota nel riepilogo sull'output dell'agente che non può essere valutato. In ogni caso, è meglio utilizzare la funzione get() del dizionario piuttosto che cogliere l'eccezione KeyError. Questo perché get() restituisce un oggetto di tipo None o un sostituto opzionale da passare come secondo parametro se la chiave non è disponibile:

Cosa succede se l'agente fornisce i dati corretti, ma l'elemento da controllare è mancante? Ad esempio, questo è il caso:

Se l'elemento che stai cercando non è incluso, il ciclo viene eseguito e Python si ferma semplicemente alla fine della funzione senza restituire un risultato tramite yield. E questo è esattamente l'approccio giusto! Perché Checkmk riconosce che l'elemento da monitorare è mancante e genera lo stato corretto e un testo standard adeguato con SCONOSCIUTO.

Se vuoi simulare particolari output dell'agente, i file di spool nella directory sono molto utili. Puoi usarli per testare casi limite che sono altrimenti difficili da ricreare. Oppure puoi usare direttamente l'output dell'agente che ha portato a un report sui crash per testare le modifiche a un plug-in di controllo.

Per prima cosa disattiva il tuo normale plug-in dell'agente, ad esempio revocando la sua autorizzazione all'esecuzione. Poi crea un file nella directory /var/lib/check_mk_agent/spool/ che contenga la sezione dell'agente (o le sezioni previste dell'agente) che il tuo plug-in di controllo si aspetta, compresa l'header sezioni, e che termini con Newline. La prossima volta che l'agente viene chiamato, il contenuto del file di spool verrà trasferito al posto dell'output del plug-in dell'agente.

Con alcuni plug-in di controllo che utilizzano gli elementi, è possibile che sui server più grandi vengano generate diverse centinaia di servizi. Se non viene utilizzata una funzione di parse separata, ciò significa che l'intero elenco di centinaia di righe deve essere esaminato per ognuna delle centinaia di elementi. Il tempo necessario per la ricerca aumenta quindi del quadrato del numero di elementi elencati, il che significa decine di migliaia di confronti per centinaia di servizi. Se invece l'elenco annidato viene trasferito in un dizionario, il tempo necessario per la ricerca di un elemento aumenta solo linearmente con la dimensione del dizionario.

Nel wiki di Python troverai una panoramica dei costi per la ricerca in diversi tipi di dati, compresa una spiegazione e la notazione O. L'utilizzo della funzione parse riduce la complessità della ricerca da O(n) a O(1).

Poiché le versioni precedenti di questo articolo non facevano uso della funzione di parsing, dovresti identificare tali plug-in di controllo e riscriverli in modo da utilizzare una funzione di parsing.