 |
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
Con oltre 2000 plug-in di controllo già pronti e diversi metodi per il monitoraggio di file e contenuti di cartelle, la valutazione dei messaggi di log e il monitoraggio delle attività ricorrenti, Checkmk è la soluzione ideale e out-of-the-box per una vasta gamma di attività di monitoraggio. Se non fosse disponibile un plug-in per un uso molto specifico, la comunità Checkmk sarà felice di aiutarti con sviluppi personalizzati forniti tramite Checkmk Exchange.
Tuttavia, ci sono sempre situazioni in cui un componente hardware è troppo nuovo, un software è troppo particolare o uno sviluppo interno all’organizzazione è troppo specifico perché qualcuno abbia già riconosciuto la necessità di integrarlo in Checkmk. Se sei arrivato a questo punto, è ora di iniziare a programmare le tue estensioni.
Questo articolo offre una panoramica delle opzioni disponibili.
Queste opzioni sono molteplici: In alcuni casi, ad esempio, è sufficiente estendere uno script di backup di poche righe per visualizzare il successo o il fallimento in un formato facilmente visualizzabile in Checkmk — questo significa che lo "sviluppo interno" a volte può essere completato in pochi minuti. In altri casi dovrai visualizzare le situazioni di carico con grafici dettagliati — in una situazione del genere vale la pena investire qualche ora in più.
2. Possibilità di estensione tramite programmi personalizzati
Le sezioni seguenti mostrano quali procedure sono disponibili per integrare le tue estensioni in Checkmk e dove avviene la raccolta e la valutazione dei dati in ciascun caso.
2.1. Check locali
Probabilmente il modo più semplice per estendere Checkmk è attraverso l'uso dei controlli locali. Un programma eseguito dallo script agente dell'host monitorato stampa nome, stato e altre informazioni richieste in una riga. Per i controlli locali, Checkmk supporta la scoperta automatica dei servizi. La programmazione è possibile in qualsiasi linguaggio di programmazione senza dover imparare un'API.
Esecuzione: interamente sull'host monitorato. Devi assicurarti che l'interprete appropriato sia disponibile su tutti gli host che ricevono un check locale, quando applicabile.
Soglie: una coppia di soglie inferiori e superiori (rispettivamente per le transizioni a WARN e CRIT) può essere gestita dall'istanza Checkmk.
Metriche: sono possibili più metriche per servizio. Le unità non possono essere gestite esplicitamente, ma vengono assegnate o omesse automaticamente.
2.2. Plug-in di controllo nativi basati su agente
I plug-in di controllo basati su agenti 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. Questa raccolta di dati può essere eseguita in qualsiasi linguaggio di programmazione. Molto comune è l'output come file JSON o in formato CSV. Tuttavia, vedrai anche molti plug-in dell'agente che richiamano solo comandi di sistema Linux grezzi.
La valutazione avviene poi sul server Checkmk utilizzando un plug-in di controllo scritto in Python, che fa uso delle API di Checkmk. È quindi possibile determinare lo stato in modo molto flessibile. È possibile utilizzare valori di soglia minimi e massimi. Inoltre, è possibile creare più servizi e verificare lo stato di un servizio tramite più controlli. È anche possibile determinare le tendenze e includere valori precedenti. I plug-in di controllo nativi supportano la creazione automatica di etichette e l'inventario HW/SW.
Esecuzione: plug-in dell'agente per la raccolta dei dati in qualsiasi linguaggio di programmazione sull'host monitorato, ulteriore valutazione tramite un plug-in di controllo sul server Checkmk utilizzando l'API Check.
Soglie: qualsiasi combinazione di valori di soglia per ogni servizio.
Metriche: qualsiasi numero di metriche per servizio con unità.
2.3. Special agents
Un'estensione dei plug-in di controllo basati su agenti sono gli agenti speciali. In questo caso, non è un plug-in dell'agente a raccogliere i dati grezzi, ma un programma in esecuzione sul server Checkmk che recupera i dati da un'altra fonte e li converte nel formato agente di Checkmk. Gli agenti speciali vengono utilizzati, ad esempio, quando un dispositivo da monitorare fornisce dati rilevanti per il monitoraggio in formato JSON o XML tramite un'API REST. Per esempi sull'uso degli agenti speciali forniti con Checkmk, vedi AWS, Azure o VMware.
Durante la programmazione, accedi a due API: per la configurazione delle porte o simili, Checkmk fornisce un'API che ti permette di specificare tali impostazioni nella configurazione. Per la query dei dati stessa, usa l'API REST presso la sorgente dati esterna. La valutazione sul server Checkmk viene eseguita come descritto nella sezione precedente sui plug-in di controllo nativi.
Esecuzione: programma/script per la raccolta dei dati e l'ulteriore valutazione sul server Checkmk.
Soglie: qualsiasi combinazione di valori di soglia per ciascun servizio.
Metriche: qualsiasi numero di metriche per servizio con unità.
2.4. Plug-in di controllo nativi basati su SNMP
Una variante dei plug-in di controllo basati su agente sono i plug-in di controllo per SNMP. La differenza in questo caso è che non viene richiesta e valutata alcuna sezione dell'agente, ma alcuni OID SNMP vengono richiesti esplicitamente dall'agente SNMP.
Esecuzione: raccolta dei dati e ulteriore valutazione da parte di un plug-in di controllo sul server Checkmk utilizzando l'API Check.
Soglie: qualsiasi combinazione di valori di soglia per ogni servizio.
Metriche: qualsiasi numero di metriche per servizio con unità.
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 un'API REST, dovresti creare un special agent per questo.
2.5. Plug-in di controllo Nagios legacy
I plug-in di controllo Nagios si trovano in due posti in Checkmk: Come active checks, per verificare l'accessibilità di determinati servizi dal server Checkmk, e come estensione MRPE degli agenti Windows o Linux per controllare tali servizi da un host — se l'host/i servizi non sono accessibili dal server Checkmk.
La programmazione è possibile in qualsiasi linguaggio.
Esecuzione: completamente sull'host monitorato (tramite MRPE) o completamente sul server Checkmk (active check).
Thresholds: valori di soglia solo se usato come active check.
Metriche: Metriche solo se usato come active check.
A causa di una serie di svantaggi, come la complessità della risoluzione dei problemi, consigliamo la reimplementazione solo se è richiesta la piena compatibilità con Nagios. In tutti gli altri casi, usa i plug-in di controllo nativi o — per query semplici — usa i controlli locali. La documentazione dettagliata dei formati di output è disponibile su Monitoring-Plugins.org.
3. Altri articoli
3.1. La directory spool
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 spool, l'agente Checkmk trasferisce il contenuto di questo file insieme al resto dell'output dell'agente.
Con la directory spool puoi, ad esempio, far sì che gli script di backup scrivano lo stato e le statistiche di un check locale o di un plug-in di controllo direttamente al termine dell'operazione. Questo evita di dover passare attraverso la valutazione dei file di log.
Quando sviluppi i tuoi plug-in di controllo, i file di spool aiutano a simulare particolari output dal tuo plug-in dell'agente.
3.2. Il meccanismo piggyback
Il meccanismo piggyback viene utilizzato quando un host dispone di informazioni su un altro. Una sezione dell'agente appositamente formattata viene quindi assegnata all'host pertinente durante la valutazione dell'output dell'agente.
Per le macchine virtuali, il meccanismo piggyback viene utilizzato per unire i dati raccolti dal software di virtualizzazione con i dati provenienti dal monitoraggio all'interno della macchina virtuale.
3.3. Pacchetti di estensioni Checkmk (MKP)
Se hai programmato le tue estensioni e desideri crearne una versione e poi distribuirla, hai la possibilità di raggruppare un'estensione con i file associati in pacchetti di estensione Checkmk (MKP). Devi utilizzare questo formato di pacchetto anche se desideri offrire queste estensioni nel Checkmk Exchange.
3.4. API bakery
In molti casi, vorrai fornire ai plug-in degli agenti una configurazione aggiuntiva. Oppure potresti voler eseguire scriptlet di installazione specifici a seconda delle impostazioni effettuate nella configurazione di Checkmk.
Se utilizzi agent bakery per la distribuzione dei pacchetti degli agenti, l'API bakery ti fornisce un'interfaccia di programmazione con cui le impostazioni effettuate in Checkmk possono essere facilmente trasferite ad altri host monitorati.
4. Contribuire a Checkmk
Se programmi le tue estensioni, ti consigliamo di inviarle prima su Checkmk Exchange. Qui rimani il proprietario e il contatto e puoi facilmente fornire nuove versioni. Dato che i requisiti di qualità del codice per l'Exchange non sono così elevati come per i plug-in di controllo forniti con Checkmk, puoi facilmente sperimentare nuove idee con un vasto pubblico tramite l'Exchange.
Se a un certo punto ritieni che il tuo plug-in di controllo debba diventare parte integrante di Checkmk, leggi prima il documento Contribuire a Checkmk.