Sviluppo di estensioni per Checkmk

Probabilmente il modo più semplice per estendere Checkmk è l'uso di controlli locali. Un programma eseguito dall'agente script dell'host monitorato stampa il nome, lo stato e altre informazioni richieste in una sola riga. Per i controlli locali, Checkmk supporta la scoperta automatica del servizio. La programmazione è possibile in qualsiasi linguaggio di programmazione senza dover imparare un'API.

I plug-in dell'agente Checkmk valutano i dati forniti dall'agente Checkmk. Un plug-in dell'agente raccoglie i dati grezzi e li pre-filtra, ma non esegue un'analisi sui dati raccolti. La raccolta dei dati può essere eseguita in qualsiasi linguaggio di programmazione. Molto comune è l'output come file JSON o in formato CSV. Tuttavia, si vedono anche molti plug-in dell'agente che chiamano solo comandi grezzi del file system Linux.

La valutazione avviene poi sul server Checkmk tramite un plug-in di controllo scritto in Python, che utilizza le API di Checkmk. In questo modo è possibile determinare lo stato in modo molto flessibile. È possibile utilizzare valori di soglia inferiori e superiori. Inoltre, è possibile creare più servizi e verificare lo stato di un servizio tramite controlli multipli. È anche possibile determinare le tendenze e includere i valori più vecchi. I plug-in di controllo nativi supportano la creazione automatica di etichette e l'inventario HW/SW.

Un'estensione dei plug-in di controllo agent-based sono gli agenti speciali. In questo caso, nessun plug-in dell'agente raccoglie i dati grezzi, ma un programma in esecuzione sul server Checkmk che recupera i dati da un'altra fonte e li converte nel formato dell'agente Checkmk. Gli agenti speciali vengono utilizzati, ad esempio, quando un dispositivo da monitorare fornisce i dati rilevanti per il monitoraggio come JSON o XML tramite un'API REST. Per esempi di utilizzo degli agenti speciali forniti con Checkmk, vedi AWS, Azure o VMware.

Quando si programma, si accede a due API: Per la configurazione di porte o simili, Checkmk mette a disposizione un'API che ti permette di specificare tali impostazioni nella configurazione. Per l'interrogazione dei dati, utilizza l'API REST della fonte esterna. La valutazione sul server Checkmk viene eseguita come descritto nella sezione precedente sui plug-in di controllo nativi.

Una variante dei plug-in di controllo basati sull'agente sono i plug-in di controllo per SNMP. La differenza è che non viene richiesta e valutata alcuna sezione dell'agente, ma vengono richiesti esplicitamente alcuni OID SNMP dall'agente SNMP.

Poiché il protocollo SNMP è intrinsecamente molto inefficiente, ti consigliamo di utilizzare SNMP solo se non è possibile accedere in altro modo ai dati di monitoraggio. Ad esempio, se un dispositivo fornisce gli stessi dati anche tramite API REST, dovrai creare un agente di monitoraggio apposito.

I plug-in di controllo di Nagios sono presenti in due modi in Checkmk: come controlli attivi, per verificare l'accessibilità di determinati servizi dal server Checkmk, e come estensione MRPE degli agenti Checkmk o Linux per verificare tali servizi da un host, se l'host o i servizi non sono accessibili dal server Checkmk.

La programmazione è possibile in qualsiasi linguaggio.

A causa di una serie di svantaggi, come ad esempio la complicata risoluzione dei problemi, consigliamo la re-implementazione solo se è richiesta la piena compatibilità con Nagios. In tutti gli altri casi, utilizza i plug-in di controllo nativi o, per le query più semplici, i check locali. La documentazione dettagliata dei formati di output è disponibile su Monitoring-Plugins.org.

Checkmk offre un altro meccanismo per generare i dati dell'agente: fai in modo che un programma scriva direttamente un file di testo nel formato dell'agente Checkmk. Memorizzato nella directory di spool, l'agente Checkmk trasferisce il contenuto di questo file con il resto dell'output dell'agente.

Con la directory di spool puoi, ad esempio, fare in modo che gli script di backup scrivano lo stato e le statistiche di un check locale o di un plug-in di controllo direttamente al suo completamento, risparmiando così le deviazioni dovute alla valutazione dei file di log.

Quando sviluppi i tuoi plug-in di controllo, i file di spool ti aiutano a simulare particolari output del tuo plug-in dell'agente.

Il meccanismo del piggyback viene utilizzato quando un host ha informazioni su un altro host. Una sezione dell'agent formattata in modo speciale viene assegnata all'host in questione quando si valuta l'output dell'agent.

Per le macchine virtuali, il meccanismo del piggyback viene utilizzato per unire i dati raccolti dal software di virtualizzazione con i dati del monitoraggio all'interno della macchina virtuale.

Se hai programmato le tue estensioni e vuoi farne una versione e poi inoltrarle, hai la possibilità di raggruppare un'estensione con i suoi file associati in pacchetti di estensioni Checkmk (MKP). Devi utilizzare questo formato di pacchetto anche se vuoi offrire queste estensioni in Checkmk Exchange.

In molti casi, vorrai fornire ai plug-in dell'agente una configurazione aggiuntiva oppure potrai eseguire scriptlet di installazione specifici a seconda delle impostazioni effettuate nella configurazione di Checkmk.

Se utilizzi l'Agent Bakery per la distribuzione dei pacchetti di agenti, l'API bakery ti fornisce un'interfaccia di programmazione con cui le impostazioni effettuate in Checkmk possono essere facilmente trasferite ad altri agenti di monitoraggio.