 |
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
Checkmk accede solitamente agli host monitorati in modalità pull tramite una connessione TCP alla porta 6556. A partire dalla versione 2.1.0, nella maggior parte dei casi l'Agent Controller si mette in ascolto su questa porta e inoltra l'output dell'agente su una connessione crittografata TLS. Checkmk 2.2.0 ha introdotto l'opzione alternativa di selezionare la direzione di trasmissione con la modalità push.
In questi casi si applica la modalità legacy in cui (x)inetd esegue lo script dell'agente dopo aver stabilito una connessione, l'output dell'agente viene trasferito come testo normale e la connessione viene chiusa immediatamente dopo.
In molte situazioni le policy di sicurezza potrebbero richiedere di evitare azioni come la trasmissione di dati in chiaro. Ad esempio, i livelli di riempimento dei file system potrebbero essere poco utili per un attaccante, ma le tabelle dei processi o gli elenchi degli aggiornamenti mancanti potrebbero essere utili per sferrare un attacco. Inoltre, la pratica di aprire porte aggiuntive dovrebbe essere evitata a favore dell'utilizzo dei canali di comunicazione esistenti.
I metodi universali per connettere tali procedure di trasferimento a Checkmk sono i programmi datasource. L'idea è molto semplice: si passa un comando come testo a Checkmk. Invece di connettersi alla porta 6556, Checkmk esegue il comando. Questo produce i dati dell'agente sullo standard output, che vengono poi elaborati da Checkmk esattamente come se provenissero da un agente "normale". Poiché le modifiche alle fonti di dati di solito influenzano solo i trasporti, è importante lasciare l'host a API integrations if configured, else Checkmk agent nella GUI di configurazione.
La modularità di Checkmk ti aiuta a soddisfare questi requisiti trasmettendo l'output dell'agente in testo semplice su mezzi di trasporto arbitrari. In definitiva, l'output in testo semplice dello script agente può essere trasportato con qualsiasi mezzo: diretto o indiretto, pull o push. Ecco alcuni esempi di come far arrivare i dati dell'agente al server Checkmk:
via e-mail
tramite accesso HTTP dal server
tramite caricamento HTTP dall'host
tramite accesso a un file che è stato copiato sul server usando
rsyncoppurescptramite uno script che utilizza HTTP per recuperare i dati da un servizio web.
Un'altra area di applicazione dei programmi datasource è rappresentata dai sistemi che non consentono l'installazione di agenti ma che forniscono dati di stato tramite API REST o un'interfaccia Telnet. In questi casi, puoi scrivere un programma datasource che interroga l'interfaccia esistente e genera l'output dell'agente dai dati ottenuti.
2. Scrivere programmi per le fonti di dati
2.1. Il programma più semplice possibile
La scrittura e l'installazione di un programma datasource non è difficile. È possibile utilizzare qualsiasi script e linguaggio di programma supportato da Linux. Il programma è meglio memorizzato nella directory ~/local/bin/, dove verrà sempre trovato automaticamente senza la necessità di specificare un percorso di dati.
Il primo esempio molto semplice che segue si chiama myds e genera dati di monitoraggio semplici e fittizi. Invece di integrare un nuovo percorso di trasporto, genera i dati di monitoraggio stessi. Questi consistono in una sezione <<<df>>>, che contiene le informazioni per un singolo file system, ha una dimensione di 100 kB e il nome My_Disk. È codificato come uno script di shell di tre righe:
#!/bin/sh
echo '<<<df>>>'
echo 'My_Disk foobar 100 70 30 70% /my_disk'Non dimenticare di rendere il programma eseguibile:
OMD[mysite]:~$ chmod +x local/bin/mydsOra crea un nome host di prova nel Setup - es. myserver125. Questo non richiede un indirizzo IP. Per evitare che Checkmk tenti di risolvere myserver125 tramite DNS, inserisci questo nome come un "indirizzo IP" esplicito.
Aggiungi quindi una regola nel set di regole Setup > Agents > Other integrations > Individual program call instead of agent access che si applica a questo host e inserisci myds come programma eseguibile:
Quando ora vai alla configurazione dei servizi dell'host nella GUI, dovrebbe essere elencato esattamente un servizio pronto ad avviare il monitoraggio:
Aggiungi questo servizio al monitoraggio, attiva le modifiche e il tuo primo programma datasource sarà in esecuzione. Per un test, non appena modificherai i dati generati dal programma, il controllo successivo del file system My_Disk lo mostrerà immediatamente.
2.2. Diagnosi degli errori
Se qualcosa non funziona correttamente, è possibile verificare la configurazione dell'host inserendo cmk -D nella riga di comando e vedere se la regola ha effetto:
OMD[mysite]:~$ cmk -D myserver125
myserver125
Addresses: myserver125
Tags: [address_family:ip-v4-only], [agent:cmk-agent], [criticality:prod], [ip-v4:ip-v4], [networking:lan], [piggyback:auto-piggyback], [site:mysite], [snmp_ds:no-snmp], [tcp:tcp]
Host groups: check_mk
Agent mode: Normal Checkmk agent, or special agent if configured
Type of agent:
Program: mydsCon cmk -d puoi attivare il recupero dei dati dell'agente e l'esecuzione del tuo programma:
OMD[mysite]:~$ cmk -d myserver125
<<<df>>>
My_Disk foobar 100 70 30 70% /my_diskUn -v duplicato dovrebbe generare un messaggio che indica che il tuo programma sarà invocato:
OMD[mysite]:~$ cmk -vvd myserver125
Calling: myds
<<<df>>>
My_Disk foobar 100 70 30 70% /my_disk2.3. Trasferire il nome di un host
Il programma del nostro esempio funziona, ma non è molto utile perché produce sempre gli stessi dati, indipendentemente dall'host per cui viene invocato.
Un programma reale che, ad esempio, recupera dati via HTTP da qualche parte, richiede almeno il nome dell'host da cui deve recuperare i dati. Codificando $HOSTNAME$ come segnaposto nella riga di comando, puoi consentire il trasferimento di questo dato:
In questo esempio, il programma myds riceve il nome del plug-in come primo argomento. L'esempio di programma che segue lo produce per i test sotto forma di check-in locale. Tramite $1 prende il primo argomento e lo salva per utilizzarlo come panoramica nella variabile $HOST_NAME. Questo verrà poi inserito nell'output del plug-in di controllo locale:
#!/bin/sh
HOST_NAME="$1"
echo '<<<local>>>'
echo "0 Hostname - My name is ${HOST_NAME}"La scoperta del servizio troverà quindi un nuovo servizio del tipo local, nel cui output sarà visibile il nome host:
Da qui il passo è breve per arrivare a un vero programma datasource che, ad esempio, recuperi i dati su HTTP utilizzando il comando curl. Nella riga di comando di un programma datasource sono ammessi i seguenti segnaposto:
|
Il nome host configurato nel Setup. |
|
L'indirizzo IP dell'host su cui verrà monitorato. |
|
L'elenco di tutti i tag degli host, separati da caratteri vuoti - racchiudi questo argomento tra virgolette per evitare che venga diviso dalla shell. |
Se hai un monitoraggio doppio che utilizza IPv4 e IPv6, le seguenti macro potrebbero essere interessanti per te:
|
Indirizzo IPv4 dell'host |
|
L'indirizzo IPv6 dell'host |
|
Il numero |
2.4. Gestione degli errori
Indipendentemente dalla tua professione nel settore informatico, gran parte del tuo tempo sarà dedicato alla gestione di errori e problemi. I programmi di gestione dei dati non ne sono esenti. Soprattutto per i programmi che forniscono dati in rete, non è realistico aspettarsi che siano privi di errori.
Affinché Checkmk possa comunicare un errore al tuo programma in modo ordinato, vale quanto segue:
Qualsiasi codice di uscita diverso da
0sarà considerato un errore.I messaggi di errore sono attesi sul canale di errore standard (
stderr).
Se un programma datasource fallisce,
Checkmk scarta i dati utente completi dell'uscita,
Checkmk imposta il servizio Checkmk su CRIT e identifica i dati di
stderrcome un errore,e i servizi reali rimangono nel loro vecchio stato (e diventeranno in stallo nel tempo).
Possiamo modificare l'esempio precedente in modo da simulare un errore: con il reindirizzamento >&2 il testo verrà deviato su stderr e exit 1 imposta il codice di uscita del programma su 1:
#!/bin/sh
HOST_NAME=$1
echo "<<<local>>>"
echo "0 Hostname - My name is $HOST_NAME"
echo "This didn't work out" >&2
exit 1Come servizio Checkmk si presenterà in questo modo:
Se stai scrivendo il tuo programma come uno shell script, all'inizio puoi inserire l'opzione set -e:
#!/bin/sh
set -eNon appena un'istruzione produce un errore (cioè un codice di uscita diverso da 0), la shell si ferma immediatamente ed emette il codice di uscita 1. In questo modo hai una gestione generica degli errori e non devi controllare che ogni singola istruzione abbia successo.
3. Agenti speciali
Con Checkmk vengono forniti alcuni programmi fonte di dati spesso richiesti. Questi generano gli output dell'agente non semplicemente chiamando un normale agente Checkmk in modo indiretto, ma sono stati concepiti appositamente per l'interrogazione di particolari hardware o software.
Poiché questi programmi a volte richiedono parametri piuttosto complessi, abbiamo definito dei set di regole speciali nella GUI che ti permettono di configurarli direttamente. Puoi trovare questi set di regole raggruppati per casi d'uso sotto Setup > Agents > VM, cloud, container e Setup > Agents > Other integrations.
 |
Coloro che sono passati da versioni precedenti di Checkmk potrebbero rimanere sorpresi dal nuovo raggruppamento: Checkmk 2.0.0 non raggruppa più in base alla tecnica di accesso, ma in base al tipo di oggetto monitorato. Questo è particolarmente utile perché in molti casi l'utente non è interessato alla tecnica utilizzata per recuperare i dati e, inoltre, le fonti di dati e i dati piggyback sono spesso combinati tra loro, quindi non è possibile fare una delimitazione chiara. |
Questi programmi sono noti anche come special agent, perché rappresentano un'alternativa speciale ai normali agenti Checkmk. A titolo di esempio, prendiamo il monitoraggio dei filer NetApp. Questi non consentono l'installazione di agenti Checkmk. L'interfaccia SNMP è lenta, lacunosa e incompleta. Esiste tuttavia un'interfaccia HTTP speciale che consente di accedere al sistema operativo NetApp Ontap e a tutti i dati di monitoraggio.
L'agente speciale agent_netapp_ontap accede a questa interfaccia tramite un'API REST e viene configurato come un programma di origine dati utilizzando il set di regole NetApp via Ontap REST API. I dati richiesti dall'agente speciale possono essere inseriti nel contenuto della regola. Si tratta quasi sempre di dati di accesso. Con l'agente speciale NetApp c'è anche un box aggiuntivo per la registrazione delle metriche (che in questo caso possono essere molto complete):
È importante lasciare l'host impostato su API integrations if configured, else Checkmk agent nella GUI.
Ci sono rare occasioni in cui si desidera interrogare sia un agente speciale che l'agente normale. Un esempio è il monitoraggio di VMware ESXi tramite il vCenter. Quest'ultimo è installato su una macchina Windows (di solito virtuale), sulla quale è ragionevolmente in esecuzione anche un agente Checkmk.
Gli special agent sono installati in ~/share/check_mk/agents/special/. Se vuoi modificare un agente, copia il file con lo stesso nome in ~/local/share/check_mk/agents/special/ e apporta le tue modifiche in questa nuova versione.
4. File e directory
| Percorso | Funzione |
|---|---|
|
Il repository per i programmi e gli script che devono essere presenti in un percorso di ricerca e che possono essere eseguiti direttamente senza specificare il percorso. Se un programma si trova sia in |
|
Gli agenti speciali forniti con Checkmk sono installati qui. |
|
Il repository per gli agenti speciali modificati da te. |
