 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Perché prendersi la briga di creare i propri checks?
Grazie al gran numero di plug-in di controllo forniti di serie, Checkmk è già in grado di monitorare una grande quantità di dati rilevanti. Tuttavia, ogni ambiente IT è unico, quindi spesso sorgono esigenze molto specifiche. Con i controlli locali, puoi creare i tuoi servizi in modo semplice e veloce apportando piccole estensioni all'agente sull'host di destinazione.
Questi plug-in locali si differenziano dagli altri controlli per un aspetto importante: il loro stato viene determinato direttamente sull'host da cui vengono recuperati i dati.
Questo elimina la necessità di creare controlli utilizzando Python e ti lascia completamente libero nella scelta del linguaggio di scripting. I controlli locali offrono inoltre una grande libertà agli amministratori di server. Gli amministratori del monitoraggio devono solo decidere se includere nuovi controlli locali come servizi.
 |
Puoi combinare il meccanismo fornito dai check locali con tutti i metodi supportati da Checkmk per il trasporto dei dati dell'agente: programmi di origine dati, special agents, dati piggyback e file di spool. I dati provenienti da tutte le fonti vengono uniti, ma si verificheranno conflitti se il nome del servizio viene (inavvertitamente) assegnato due volte — per questo motivo, assicurati che i nomi di ogni servizio siano univoci. |
2. Scrivere un semplice check locale
2.1. Creazione dello script
Un check locale può essere scritto in qualsiasi linguaggio di programmazione supportato dall'host di destinazione. Lo script deve essere strutturato in modo che ogni check produca una riga di stato composta da quattro parti. Ecco un esempio:
0 "My service" myvalue=73 My output text which may contain spacesLe quattro parti sono separate da spazi e hanno i seguenti significati:
| Valore di esempio | Significato | Descrizione |
|---|---|---|
|
Stato |
Lo stato del servizio è indicato da un numero: |
|
Nome del servizio |
Il nome del servizio come mostrato in Checkmk, nell'output del check tra virgolette doppie. |
|
Valore e metriche |
Valori delle metriche per i dati. Maggiori informazioni sulla struttura sono disponibili nel capitolo sulle metriche. In alternativa, è possibile inserire un segno meno se il check non produce metriche. |
|
Dettagli dello stato |
Dettagli dello stato così come verranno visualizzati in Checkmk nel campo "Summary". Questa parte può contenere anche spazi vuoti. |
|
Fino a Checkmk 2.4.0 p4 deve esserci sempre esattamente uno spazio ( |
Se non sei sicuro di un possibile output, puoi semplicemente testarlo scrivendo un piccolo script con il comando echo.
Inserisci l'output che vuoi testare nel comando echo.
Il nostro esempio usa le virgolette doppie all'esterno, poiché le variabili all'interno (variabili d'ambiente e quelle impostate nello script) vengono valutate.
Di conseguenza, devi racchiudere le virgolette del nome del servizio con \ in modo che questi caratteri non vengano interpretati dalla shell come l'inizio e la fine di una stringa (e quindi rimossi dall'output):
Per gli host Windows, uno script del genere sarà molto simile a questo:
@echo off
echo 0 "My 1st service" - This static service is always OKEntrambi gli script producono lo stesso risultato nell'output:
0 "My 1st service" - This static service is always OKPer Checkmk è rilevante solo questo output, non come l'hai creato.
A proposito: puoi scrivere un numero qualsiasi di output in uno script. Ogni riga di output avrà un proprio servizio creato in Checkmk. Pertanto, non sono ammessi caratteri di nuova riga nell'output, a meno che non siano mascherati, ad esempio per un output su più righe in Checkmk.
Come verificare se lo script locale verrà richiamato correttamente dall'agente è spiegato nell'Analisi degli errori.
|
Se si utilizza il Nagios core (sempre nella Comunità Checkmk), i seguenti caratteri speciali non sono ammessi nel nome
del servizio
:
|
2.2. Distribuzione dello script
Una volta scritto lo script, puoi distribuirlo agli host appropriati. Il percorso da usare dipenderà dal sistema operativo. Trovi un elenco dei nomi dei percorsi nella sezione File e directory qui sotto.
Non dimenticare di rendere lo script eseguibile sui sistemi Unix-like. Il percorso mostrato in questo esempio è per Linux (pacchetto agente con impostazioni predefinite):
Se utilizzi agent bakery, lo script può essere distribuito con una procedura rule-based. Maggiori informazioni sulla creazione di regole sono disponibili nel capitolo Distribuzione tramite agent bakery.
2.3. Aggiunta del servizio al monitoraggio
Ad ogni avvio dell’agente Checkmk, il check locale contenuto nello script verrà eseguito e aggiunto all’output dell’agente. Anche la scoperta del servizio funziona automaticamente come per gli altri servizi:
Una volta che il servizio è stato aggiunto al monitoraggio e le modifiche sono state attivate, l'implementazione del servizio creato autonomamente con l'aiuto di un check locale sarà completa. Se dovesse sorgere un problema durante la scoperta del servizio, l'Analisi degli errori può essere d'aiuto.
3. Metriche
3.1. Definizione delle metriche
Puoi definire le metriche anche in un check locale. La sintassi più breve possibile per i dati delle metriche è:
metricname=valuedove value è il valore corrente.
La sintassi completa per i dati delle metriche è:
metricname=value;warn;crit;min;maxQui, warn e crit definiscono i valori di threshold (superiori).
Affinché questi valori di threshold vengano visualizzati nel grafico, è necessario attivare il calcolo dinamico (stato P).
Lo stato viene quindi calcolato utilizzando Checkmk.
Gli ultimi parametri specificati per min e max fissano l'intervallo di valori.
Un esempio completo potrebbe quindi apparire così:
count=73;80;90;0;100I valori sono separati da punti e virgola.
Se un valore non è richiesto, il campo rimane vuoto o viene omesso alla fine, come nei seguenti casi per warn, crit e max:
count=42;;;0 |
Nelle edizioni commerciali
i valori per |
3.2. Nomi e unità utilizzati dalle metriche
Le definizioni delle metriche per i controlli locali non differiscono da quelle per altri tipi di controlli. In definitiva, hai tre opzioni per assegnare unità e nomi di facile comprensione alle metriche:
Accedi alle definizioni di metriche esistenti che "si adattano" allo scopo richiesto.
Creare le proprie metriche in modo ad hoc e univoco — questo è spesso sufficiente per i contatori puri.
Creare le proprie metriche e memorizzare una definizione di metrica: questo offre la massima flessibilità.
Utilizzo delle definizioni delle metriche esistenti
Il modo più semplice per ottenere unità adeguate, una legenda regolata automaticamente e spesso un Perf-O-Meter è utilizzare le definizioni delle metriche esistenti.
In questo articolo, alcuni esempi utilizzano gli identificatori humidity o temperature.
Esistono definizioni predefinite per entrambe (umidità e temperatura), che forniscono alle metriche le unità corrette.
In entrambi i casi, la definizione della metrica fornisce un Perf-O-Meter e le legende dei grafici mostrano quindi i gradi Celsius e l'umidità relativa in percentuale.
Le definizioni delle metriche più importanti si trovano su ~/lib/python3/cmk/plugins/collection/graphing (GitHub), altre su ~/lib/python3/cmk/plugins/*/graphing (GitHub) e le unità utilizzate su ~/lib/python3/cmk/gui/plugins/metrics/unit.py (GitHub).
Spesso vale la pena cercare definizioni di metriche che abbiano una corrispondenza esatta, poiché Checkmk fornisce anche grafici combinati per metriche correlate.
Definizione di metriche ad hoc
Nei primi esempi mostrati in questo articolo per le metriche abbiamo usato nomi come myvalue, count o metricname.
Senza una definizione di metrica adeguata, questi nomi vengono visualizzati con l'iniziale maiuscola nella legenda del grafico e i trattini bassi vengono sostituiti da spazi.
Così, outgoing_queue_size diventa il facilmente leggibile Outgoing queue size.
Poiché un semplice contatore non richiede un'unità, l'identificatore scelto in modo sensato soddisfa già il suo scopo in questo caso senza bisogno di una definizione metrica aggiuntiva.
Se le unità sono effettivamente necessarie, potresti doverle includere nel nome.
Diventa problematico se il tentativo di definire una metrica ad hoc ha inavvertitamente l'effetto spiegato nell'ultima sezione e assegna una definizione di metrica esistente.
La massima confusione può verificarsi soprattutto quando le unità non corrispondono, ad esempio, una metrica fornita utilizza una scala percentuale con numeri in virgola mobile tra 0 e 100 %, ma l'intervallo di valori del tuo check locale fornisce un numero aperto come numero in virgola fissa.
Oppure hai una coda per le richieste correnti (Current requests queue), che vuoi semplicemente chiamare current: il risultato sarebbe l'assegnazione della definizione della metrica per l'amperaggio.
Quindi, current_requests_queue sarebbe una scelta molto migliore in questo caso.
Puoi stare completamente tranquillo con un prefisso aggiuntivo, ad esempio: mycompany_current_requests_queue.
Scrivere le tue definizioni di metrica
Se hai requisiti particolari, ad esempio hai bisogno di grafici con una legenda e un Perf-O-Meter, ti serviranno le tue definizioni di metriche. Leggi il capitolo sulle metriche nell'articolo sulla programmazione dei plug-in di controllo basati su agenti
3.3. Metriche multiple
Puoi anche generare più metriche.
Nelle definizioni queste sono separate dal carattere "pipe" (|), ad esempio in questo modo:
count1=42|count2=23Sugli host Windows devi anteporre a queste pipe nello script un accento circonflesso (^) in modo che queste pipe compaiano anche nell'output:
@echo off
echo 0 "My 2nd service" count1=42^|count2=23 A service with 2 graphsUn output completo con due metriche avrà quindi un aspetto simile a questo:
Una volta aggiunto anche il nuovo servizio al monitoraggio, nell'elenco dei servizi vedrai il testo relativo ai dettagli dello stato nel campo Summary. Cliccando sul servizio verrà visualizzata la pagina con i dettagli del servizio. Le metriche sono mostrate nel campo Details, e sotto vedrai i grafici del servizio generati automaticamente da Checkmk:
|
Questo esempio utilizza una valutazione sull'host ( |
3.4. Calcolo dinamico dello stato
Nelle sezioni precedenti hai imparato come fornire valori per le metriche e usarli per generare grafici. Il passo logico successivo è ora quello di utilizzare i valori di soglia passati in aggiunta per un calcolo dinamico dello stato del servizio. Questo è esattamente ciò che Checkmk consente per rendere la preparazione dei dati ricevuti coerente con molti degli stati generati tramite i plug-in.
Se nel primo campo dell'output, che determina lo stato, inserisci la lettera P invece di un numero, lo stato del servizio verrà calcolato in base ai valori di soglia passati.
Oltre al valore effettivo, i valori di soglia trasferiti vengono quindi visualizzati anche come una linea gialla e una rossa nel grafico.
|
Questo calcolo dinamico non significa che i valori di soglia possano essere modificati tramite le regole di monitoraggio definite in Checkmk. Per il calcolo effettivo vengono sempre utilizzati i valori di soglia forniti nel check locale. |
L'output apparirà quindi così:
… e la visualizzazione in una visualizzazione di servizio come questa:
Questa visualizzazione differisce dalla precedente per due aspetti:
Per i servizi nello stato "WARN" o "CRIT", la scheda "Summary" del servizio mostra tutte le informazioni importanti relative alle metriche (nome, valore, thresholds). Ciò significa che puoi sempre vedere come questo stato è stato calcolato a partire da un valore. Per tutti gli altri stati, le informazioni sulle metriche vengono visualizzate solo nel campo "Details".
Se non vengono trasferite metriche, lo stato del servizio sarà sempre "OK".
Alternanza tra valutazione dinamica e statica dello stato
Può essere utile switchare dalla valutazione dinamica a quella statica dello stato nello script che fornisce il check locale.
Prendiamo ad esempio uno script di backup che scrive un file di spool nel formato di un check locale.
La valutazione dello stato in base alla durata del backup dovrebbe essere dinamica, e lo script dovrebbe quindi scrivere "P":
P "Backup stuff" duration=2342;1800;3600 Successfully created the backup. Good luck restoring.Tuttavia, se il backup fallisce dopo poco tempo, lo stato è determinato dal valore di ritorno dello script di backup e non dai valori di threshold. In questo caso, lo script deve impostare lo stato in modo statico con un numero:
2 "Backup stuff" duration=123;1800;3600 Backup failed. Nuff said.In questo caso, è semplicemente logico che nel grafico non vengano visualizzati valori di soglia, poiché non si tratta della durata richiesta fino al backup (fallito), ma del fatto che il backup non è andato a buon fine.
3.5. Valori di threshold superiori e inferiori
Alcuni parametri non hanno solo soglie superiori, ma anche soglie inferiori. Un esempio è la registrazione dell'umidità. In questi casi, il check locale offre la possibilità di inserire due valori di soglia per ciascuno degli stati "WARN" e "CRIT". Questi sono separati da due punti e rappresentano rispettivamente i valori di soglia inferiore e superiore.
Nella sintassi generale appare così:
metricname=value;warn_lower:warn_upper;crit_lower:crit_upper… nell'esempio come questo:
… e nella visualizzazione di una visualizzazione di servizio come questa:
Se ti interessano solo i valori di threshold inferiori, ometti i campi relativi ai valori di threshold superiori:
Con questo output, specifichi che il servizio deve diventare "WARN" se il valore è inferiore a 40 e "CRIT" se è inferiore a 30: il servizio riceverà quindi lo stato "WARN" se il valore specificato è 37.
|
Il sistema di metriche e grafici in Checkmk è limitato alle soglie superiori per motivi di semplicità. Ciò significa che, mentre la determinazione dello stato del servizio funziona come previsto, le informazioni visualizzate nel componente di metriche e grafici ignorano le soglie inferiori. Per questo motivo, elementi come le linee gialle e rosse nei grafici, i Perf-O-Meter e gli "Service performance data" sono completamente assenti nella GUI di Checkmk quando vengono utilizzate solo le soglie inferiori. |
3.6. Uscite su più righe
È disponibile anche l'opzione per distribuire un output su più righe.
Poiché Checkmk gira su Linux, puoi utilizzare la sequenza di escape '\n' per forzare un'interruzione di riga.
Anche se, a causa del linguaggio di scripting, la barra rovesciata stessa deve essere preceduta da un carattere di escape, verrà interpretata correttamente da Checkmk:
Nei dettagli del servizio queste righe aggiuntive saranno visibili sotto l'Summary:
4. Esecuzione asincrona
L'output dei controlli locali, come quello dei plug-in dell'agente, può essere memorizzato nella cache. Questo può essere necessario se uno script ha un tempo di elaborazione più lungo. Uno script di questo tipo viene quindi eseguito in modo asincrono e solo in un intervallo di tempo definito, e l'ultimo output viene memorizzato nella cache. Se l'agente viene interrogato nuovamente prima che scada il tempo, utilizza questa cache per il check locale e la restituisce nell'output dell'agente.
|
La memorizzazione nella cache è disponibile solo per AIX, FreeBSD, Linux, OpenWrt e Windows. Su altre piattaforme, usa i cronjob in combinazione con la directory spool. |
4.1. Configurazione di Linux
Su Linux o su un altro sistema operativo Unix-like, qualsiasi plug-in può essere eseguito in modo asincrono. Per un check locale, la configurazione necessaria è molto simile a quella di un plug-in. Per farlo, crea una sottodirectory con il nome corrispondente al numero di secondi per cui vuoi che l'output venga memorizzato nella cache e inserisci il tuo script in quella sottodirectory.
Nell'esempio seguente, il check locale verrà eseguito solo ogni 10 minuti (600 secondi):
I dati memorizzati nella cache vengono scritti in una directory di cache.
Per un servizio che fornisce dati memorizzati nella cache, le informazioni specifiche della cache vengono aggiunte alla visualizzazione del servizio:
4.2. Configurazione di Windows
Su Windows, la configurazione è analoga a quella di un plug-in dell'agente. Invece di utilizzare una sottodirectory speciale come su Linux & Co, le opzioni vengono impostate in un file di configurazione:
Come puoi vedere sopra, su Windows puoi configurare separatamente l'esecuzione asincrona (con async) e l'intervallo di tempo (con cache_age).
In alternativa, su Windows puoi anche effettuare la configurazione in agent bakery.
5. Distribuzione tramite agent bakery
Se stai già utilizzando Agent Bakery nelle edizioni commerciali, puoi distribuire gli script con i controlli locali a diversi host anche in questo modo.
Per farlo, crea prima la directory custom sul server Checkmk come utente dell’istanza sotto ~/local/share/check_mk/agents/ e al suo interno una struttura di sottodirectory per ogni pacchetto di check locali:
La directory del pacchetto nell'esempio sopra è mycustompackage.
Sotto di essa, la directory lib contrassegna lo script come plug-in di controllo o come check locale.
La directory successiva local assegna poi il file in modo esplicito.
Metti lo script con il check locale in questa directory.
|
Su Linux, puoi configurare l'esecuzione asincrona in modo analogo a quanto descritto nel capitolo precedente creando ora una directory sotto |
Nell'ambiente di configurazione di Checkmk, la directory dei pacchetti mycustompackage verrà visualizzata come nuova opzione:
Apri Setup > Agents > Windows, Linux, Solaris, AIX, crea una nuova regola con Agents > Agent rules > Generic agent options > Deploy custom files with agent e seleziona il pacchetto appena creato:
Checkmk integrerà quindi autonomamente il check locale nel pacchetto di installazione per il sistema operativo appropriato. Dopo che le modifiche sono state attivate e l'agente è stato aggiornato, la configurazione sarà completa. Ora basta solo distribuire gli agenti.
6. Analisi degli errori
6.1. Test dello script
Se riscontri dei problemi con uno script scritto da te, dovresti controllare le seguenti potenziali fonti di errore:
Lo script si trova nella directory corretta?
Lo script è eseguibile e i permessi di accesso sono corretti? Questo è particolarmente importante se non stai eseguendo l'agente o lo script con l'account root o LocalSystem.
-
L'output è conforme alla sintassi indicata? L'output del check locale deve essere conforme alla sintassi descritta nei capitoli Creazione dello script e Metriche. In caso contrario, non è possibile garantire un'esecuzione senza errori.
Possono sorgere problemi ed errori in particolare quando un check locale è destinato a eseguire un'attività che richiede un plug-in di controllo completo, ad esempio quando l'output del check locale stesso contiene un header di sezione o la definizione di un nome host come quello utilizzato durante il trasporto di dati piggyback.
|
Su Linux, quando lo script agente o il plug-in dell'agente viene chiamato direttamente in una shell, potrebbero essere disponibili variabili d'ambiente diverse rispetto a quando vengono chiamati dall'Agent Controller dell'agente Checkmk. Su Windows, l'Agent Controller viene eseguito anche con l'account LocalSystem, ma la chiamata nel terminale viene effettuata con un utente normale o un amministratore. Oltre all'ambiente diverso, ciò può significare che mancano alcuni permessi. Per poter analizzare l'output del script agente in modo il più possibile simile alle condizioni in cui viene chiamato l'agente Checkmk, dovresti utilizzare l'Agent Controller in modalità dump, se possibile. |
6.2. Testare l'output dell'agente sull'host di destinazione
Se lo script è corretto, l'agente può essere eseguito sull'host.
Con sistemi operativi Unix-like come Linux, BSD, ecc., è disponibile il comando riportato di seguito.
Con l'opzione -A è possibile specificare il numero di righe aggiuntive da visualizzare dopo un risultato positivo.
Questo numero può essere personalizzato in base al numero di righe di output previste:
Nell'ultima riga, puoi riconoscere un servizio memorizzato nella cache grazie alle informazioni "cached" che precedono, con il tempo Unix corrente e l'intervallo di esecuzione in secondi.
Su Windows, puoi ottenere un risultato molto simile con PowerShell e la Cmdlet Select-String, proprio come con il comando grep su Linux. Nel comando seguente, le due cifre dopo il parametro Context determinano quante righe devono essere visualizzate prima e dopo il risultato:
|
A seconda dell'ambiente, del linguaggio di programmazione utilizzato, della versione di Windows e di alcune altre condizioni, spesso ti trovi a dover gestire il set di caratteri UTF-16 in Windows. Inoltre, in questo ambiente si incontra spesso la combinazione di Carriage Return e Line Feed per le interruzioni di riga. Tuttavia, Checkmk, essendo un'applicazione Linux, si aspetta UTF-8 e semplici Line Feed senza se e senza ma. Il nostro articolo sulla directory spool include un capitolo che spiega come risolvere i problemi relativi al set di caratteri. |
6.3. Testare l'output dell'agente sul server Checkmk
Come ultimo passo, l'elaborazione dell'output dello script può essere testata anche sul server Checkmk con il comando `cmk` — una volta per la scoperta del servizio:
… e anche l'elaborazione dell'output del servizio con un comando simile:
Per entrambi i comandi abbiamo abbreviato l'output eliminando le righe non rilevanti per questo tema.
In alternativa, puoi aprire l'elenco dei servizi dell'host nel monitoraggio, andare all'Check_MKe del servizio e alla sua colonna "Icons". Lì puoi selezionare la voce di menu "Download agent output" per recuperare un file di testo contenente l'output completo dell'agente.
Se ci sono errori in un check locale, Checkmk li identificherà nell'output del servizio. Questo vale anche per metriche errate, per informazioni false o incomplete nell'output dello script o per uno stato non valido. Questi messaggi di errore dovrebbero aiutarti a identificare rapidamente gli errori in uno script.
7. File e directory
Tutti i percorsi specificati si riferiscono a pacchetti di installazione che sono stati creati con configurazioni standard. Se hai installato uno script agente non compresso o hai modificato le directory di installazione utilizzando una regola Bakery, cerca i percorsi nello script stesso o adatta i percorsi alla tua configurazione.
7.1. Directory dello script sull'host di destinazione
In queste directory si memorizzano i controlli locali. I controlli locali possono essere qualsiasi file eseguibile.
| Percorso | Sistema operativo |
|---|---|
|
AIX, Linux e Solaris |
|
Windows |
7.2. Directory della cache sull'host di destinazione
I dati memorizzati nella cache delle singole sezioni, inclusa la sezione "local", vengono salvati qui e ricollegati all'agente ad ogni esecuzione, purché i dati siano validi.
| Percorso | Sistema operativo |
|---|---|
|
AIX, Linux e Solaris |