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 ha una struttura molto modulare e chi ha conoscenze di programmazione in Python può estenderla in molti punti. Tra le altre cose, è possibile estendere Checkmk con i seguenti elementi:
Controlli personalizzati e plug-in dell'agente, comprese le maschere di input per l'ambiente di configurazione.
Plug-in personalizzati per l'inventario HW/SW di Checkmk
Estensioni per la GUI (visualizzazioni, dashboard, colonne, simboli, ecc.).
Definizioni di grafici o Perf-O-Meter
Script di gestione delle notifiche e dei gestori di avvisi (anche in shell o altri linguaggi di scripting).
Tutte queste estensioni possono essere implementate inserendo file aggiuntivi nella directory ~/local all'interno dell'istanza Checkmk.
Per la gestione di queste estensioni, la loro distribuzione in ambienti distribuiti e la condivisione con altri utenti, Checkmk fornisce un proprio formato di pacchetto: il pacchetto di estensione di Checkmk (MKP).
Un MKP può includere qualsiasi insieme di estensioni desiderato — ad esempio, un insieme di plug-in di controllo che include pagine di manuale associate, ambienti di configurazione delle soglie e definizioni delle metriche associate. Può inoltre contenere impostazioni per la distribuzione tramite l’agent bakery. Un MKP ha un nome, un numero di versione e può essere installato o rimosso con una semplice azione.
|
Usa un sito di test per creare e personalizzare gli MKP, quindi copia gli MKP sul sito di produzione per il deployment. Questo ti eviterà due potenziali problemi principali che sorgono quando i file modificati non vengono impacchettati negli MKP in modo tempestivo:
|
1.1. The Checkmk Exchange
Su Checkmk Exchange, i programmatori di plug-in possono fornire pacchetti per altri utenti Checkmk e scambiarseli tra loro. Da Exchange puoi effettuare lo scaricamento di estensioni gratuitamente. Tieni presente che i pacchetti di Exchange sono condivisi volontariamente da altri utenti e sono privi di qualsiasi garanzia.
Plug-in programmati in modo errato possono causare un aumento del carico della CPU/del sistema e dei requisiti di memoria. Inoltre, è possibile che un MKP sia stato sviluppato per versioni precedenti di Checkmk e quindi non sia completamente compatibile (ad es. con l'aggiornamento dalla versione 1.6.0 alla versione 2.0.0 Checkmk è passato da Python 2 a Python 3). In casi estremi può esserci il rischio di perdita di dati. Ti consigliamo quindi vivamente, prima di utilizzare MKP di terze parti in un ambiente di produzione, di effettuare l'installazione su un sito di prova.
1.2. Strumenti per gli MKP
Ci sono due strumenti per la gestione degli MKP:
Il comando "
mkp"Nel menu di configurazione, l'elemento Extension Packages (solo edizioni commerciali)
Ora presenteremo entrambi questi strumenti di gestione in modo più dettagliato. Sono compatibili tra loro, quindi puoi usare sia il comando che Extension Packages senza "creare confusione".
2. Gestione dei pacchetti di estensione tramite il menu di configurazione
La possibilità di gestire gli MKP tramite la GUI è disponibile esclusivamente nelle edizioni commerciali di Checkmk.
Nel menu "Setup" accedi alla gestione degli MKP tramite "Setup > Maintenance > Extension packages".
Qui puoi installare, modificare o creare MKP:

Gli MKP obsoleti possono essere installati solo tramite la riga di comando. Da Extension packages puoi installare (abilitare e attivare) solo gli MKP che soddisfano i requisiti di versione. Gli altri MKP saranno abilitati ma non installati (verrà visualizzato un messaggio di errore corrispondente). |
2.1. Aggiungere un MKP
Un MKP che hai scaricato dall'Exchange, ad esempio, può essere caricato su Checkmk cliccando sul pulsante Upload package e sarà quindi reso disponibile per l'installazione.
Per farlo, il file deve essere presente sul computer su cui è in esecuzione il tuo browser web.
Il nome del file del pacchetto deve includere l'estensione .mkp.

Dopo l'installazione, il pacchetto di estensione è inizialmente disponibile, ma non attivo. Si trova in All packages (enabled or disabled):

2.2. Attivazione di un MKP
Solo cliccando sul simbolo a forma di spina in
il pacchetto disponibile verrà attivato.
Durante l'attivazione, i file vengono installati in una gerarchia di cartelle sotto ~/local/.
Anche il file di descrizione del pacchetto viene inserito in ~/var/check_mk/packages/.
Dopo l'attivazione, il pacchetto apparirà anche nell'elenco degli MKP abilitati e attivi — Enabled (active on this site):

Ora attiva le modifiche, dopodiché tutte le funzioni del pacchetto saranno integrate nel sistema e pronte all'uso.
2.3. Disattivazione e rimozione dei pacchetti
Anche la rimozione completa di un pacchetto avviene in due fasi.
Con il pulsante "
" (Disattiva) si disattiva prima un pacchetto nell'elenco dei pacchetti attivi.
In questa fase i file installati vengono rimossi, ma l'MKP viene comunque mantenuto: questa operazione annulla solo l'attivazione.
Utilizzando il simbolo "
" nell'elenco di tutti i pacchetti, puoi eliminare definitivamente i pacchetti installati e inutilizzati.
Durante l'eliminazione, il pacchetto viene cancellato e con esso l'estensione viene rimossa completamente — ovvero l'opposto dell'aggiunta di un pacchetto.
2.4. MKP in ambienti distribuiti
Nel caso di un monitoraggio distribuito con configurazione centrale, è sufficiente rendere disponibili i pacchetti sull'istanza centrale.
Per ogni istanza remota associata all'istanza centrale, puoi quindi determinare separatamente se le personalizzazioni devono essere propagate a quell'istanza remota.
Tutto quello che devi fare è attivare l'opzione "Replicate extensions".
Dopodiché, gli MKP e tutte le altre modifiche all'interno della directory ~/local verranno trasferiti anche durante una sincronizzazione.

Se non desideri un determinato trasferimento, disattiva semplicemente l'opzione per questa o per tutte le istanze.
Importante: le personalizzazioni per il Setup centrale verranno trasferite solo se l'opzione "Enable replication" è impostata su "Push configuration to this site".
2.5. Un caso speciale: pacchetti abilitati ma inattivi
Una situazione particolare è il tentativo di attivazione di un pacchetto che non corrisponde alla versione di Checkmk utilizzata. Un pacchetto di questo tipo, che è abilitato ma la cui attivazione fallisce a causa di una versione di Checkmk incompatibile, finirà nell'elenco Enabled (inactive on this site).

Ma perché effettuare l'installazione di pacchetti che non corrispondono alla versione di Checkmk che stai utilizzando? Ci sono due possibili ragioni valide:
Un aggiornamento della versione di Checkmk: Hai la possibilità di memorizzare pacchetti sia per la versione vecchia che per quella nuova — quando effettuerai il prossimo aggiornamento, il pacchetto più recente verrà attivato automaticamente.
Monitoraggio distribuito: Per facilitare gli aggiornamenti, la versione principale di Checkmk delle istanze remote potrebbe essere superiore di una rispetto a quella dell’istanza centrale. Tuttavia, in passato questo rendeva difficile distribuire gli MKP perché dovevano essere compatibili con entrambe le versioni principali. Con la possibilità di sbloccare i pacchetti non corrispondenti, puoi mantenere sull’istanza centrale pacchetti che corrispondono sia alla versione di origine che a quella di destinazione. La versione più recente verrà quindi attivata automaticamente durante un aggiornamento.
Dai numeri di versione mostrati nella schermata sopra, puoi vedere che si tratta di un'istanza centrale Checkmk 2.1.0 che fornisce pacchetti per le istanze remote che sono già state aggiornate a 2.2.0.
3. Gestione dei pacchetti di estensione tramite la riga di comando
Puoi eseguire tutte le azioni sopra descritte anche dalla riga di comando.
A questo scopo si utilizza il comando `mkp`.
Se lo esegui senza specificare alcun sottocomando, ti mostrerà dei suggerimenti su come utilizzarlo.
Per maggiore chiarezza, abbiamo abbreviato l'output, che è lungo circa 50 righe, riducendolo a meno della metà:
Nelle sezioni seguenti presenteremo i comandi più importanti per la gestione degli MKP. Alla fine di questo articolo troverai una tabella con un utile riferimento ai comandi.
3.1. Aggiungere un MKP
L'aggiunta di un pacchetto si esegue con mkp add.
Per farlo, ovviamente, devi prima trasferire il file MKP sul server Checkmk (ad es. con scp).
Quindi esegui il seguente comando:
Richiedi un elenco dei pacchetti disponibili con mkp list.
Dopo l'installazione, il pacchetto di estensione è inizialmente disponibile, ma non attivo — nell'elenco avrà lo stato Disabled:
3.2. Attivazione di un MKP
Solo con il sottocomando enable un pacchetto disponibile verrà anche attivato.
Specificare il numero di versione è necessario solo nell'evento in cui il nome da solo non sia univoco:
In linea di principio, puoi attivare solo gli MKP che corrispondono alla versione della tua installazione di Checkmk, anche dalla riga di comando.
Se vuoi bypassare le restrizioni di versione e installare (abilitare e attivare) l'MKP in qualsiasi condizione, usa --force-install.
Questo è rilevante soprattutto per gli sviluppatori che devono adattare gradualmente i pacchetti alle nuove versioni di Checkmk in ambienti distribuiti.
Una volta attivato — indipendentemente dall'uso di force-install —, i file vengono installati in una gerarchia di directory all'interno di ~/local/ e il file di descrizione del pacchetto viene inserito in ~/var/check_mk/packages/.
Questo fa sì che il pacchetto assuma lo stato "Enabled (active on this site)":
Puoi ottenere i dettagli su un singolo pacchetto con mkp show, indipendentemente dal suo stato di attivazione attuale:
3.3. Disattivazione e rimozione dei pacchetti
La disinstallazione di un pacchetto avviene in due fasi.
Per prima cosa, il pacchetto viene disabilitato con mkp disable.
Questo elimina i file di installazione, ma mantiene comunque il pacchetto — ad esempio, per una possibile riattivazione successiva.
Anche in questo caso, specificare il numero di versione è necessario solo nell’evento in cui il nome del pacchetto da solo non sia univoco:
Nell'elenco dei pacchetti vedrai ora lo stato "Disabled" quando richiami nuovamente mkp list:
Solo "mkp remove" eliminerà il pacchetto in modo definitivo:
3.4. Un caso speciale: pacchetti abilitati ma inattivi
Una situazione particolare si verifica durante l'installazione di un pacchetto che non corrisponde alla versione di Checkmk in uso:
Puoi attivare un pacchetto di questo tipo, ma l'attivazione fallirà a causa della versione incompatibile di Checkmk e il pacchetto assumerà lo stato "Enabled (inactive on this site)".
Abbiamo spiegato le possibili circostanze per cui si potrebbe scegliere di effettuare l'installazione di pacchetti incompatibili — ad esempio con gli aggiornamenti in ambienti distribuiti — più sopra nella sezione corrispondente dedicata alla Setup.
Analogamente alla procedura di Setup, usa mkp enable packagename version per abilitare un pacchetto, oppure mkp disable packagename version per disabilitare un'abilitazione esistente.
4. MKP per sviluppatori
La maggior parte di noi che conosce o sta imparando a programmare è "come dei nani sulle spalle dei giganti, in grado di vedere sempre più lontano di loro": È nell'open source che possiamo davvero trarre beneficio dal lavoro svolto in precedenza da altri. Nel caso di Checkmk, questo vale soprattutto per le estensioni, che, nel contesto della GPL, sono opere derivate da Checkmk stesso, a sua volta soggetto alla GPL (versione 2.0). In pratica, questo significa che puoi personalizzare i pacchetti di scaricamento da Checkmk Exchange come meglio credi (o semplicemente in base alle tue esigenze attuali).
Nelle sezioni seguenti mostriamo — a partire dal repackaging con modifiche minori, alla risoluzione di un pacchetto esistente (esempio), fino alla compilazione di file non impacchettati — tutti i passaggi rilevanti presentati nella sequenza tipica in cui vengono eseguiti.
Se stai programmando o modificando i tuoi plug-in per Checkmk, consulta gli articoli sulle interfacce di programmazione esistenti e sull'integrazione nell'agent bakery.
4.1. Modifica dei pacchetti
La correzione di piccoli errori spesso rende necessario adattare un pacchetto esistente senza modificarne la struttura o il nome. In questo caso, è consigliabile non solo adattare i file esistenti memorizzati nel file system, ma anche aggiornare almeno il numero di versione del pacchetto. Se le modifiche alle API di Checkmk richiedono modifiche a un pacchetto, adegua anche i numeri di versione memorizzati nel pacchetto per le versioni minime e massime supportate. Inoltre, quando si utilizza l’agent bakery, la presenza di nuovi MKP attiva la ricompilazione dei pacchetti degli agenti.
Nelle edizioni commerciali usa il simbolo
per accedere alla finestra di dialogo delle modifiche.

4.2. Decompressione dei pacchetti
Il menu di configurazione
La decompressione di un pacchetto in
"libera", per così dire, i file contenuti all'interno di ~/local/ e rimuove solo la descrizione del pacchetto.
Di conseguenza, i file saranno decompressi e le estensioni rimarranno attive.
Questo è l'opposto della creazione di un pacchetto da file precedentemente decompressi.
In pratica, molto probabilmente avrai bisogno di decomprimere quando vorrai personalizzare un'estensione e successivamente ricomprimerla per includere eventuali modifiche. Ad esempio, puoi iniziare con il nostro esempio Hello world!, che in realtà non fa nulla di utile ma può servire come modello per il tuo primo pacchetto personalizzato.
La riga di comando
Dalla riga di comando, puoi rilasciare un pacchetto con il comando `mkp release`.
Affinché funzioni, il pacchetto da decomprimere deve avere lo stato `Enabled (active on this site)`.
I file dell'estensione vengono mantenuti e viene eliminata solo la descrizione del pacchetto:
Il pacchetto originale rimane intatto e cambia il suo stato in "Enabled (inactive on this site)". Può quindi fungere anche da backup nel caso in cui qualcosa vada storto durante la personalizzazione. A quel punto basta eliminare i file "superflui", riattivare il pacchetto e ricominciare da capo.
4.3. Trovare i file non inclusi nel pacchetto
Il menu di configurazione
Una volta completato il lavoro di programmazione o personalizzazione, sarà necessario ritrovare i file esistenti e quelli aggiunti. Poiché questi file attualmente non appartengono a nessun pacchetto, sono elencati nel Setup sotto "Unpackaged files":

La riga di comando
L'equivalente da riga di comando è mkp find:
Elimina i file che non servono o prendi nota di quali file non devono essere inclusi nel nuovo pacchetto. Nel passaggio successivo, i file non inclusi nel pacchetto verranno (di nuovo) combinati in un pacchetto.
4.4. Creazione dei pacchetti
Il menu di configurazione
Il pulsante "
" (Create package) nella panoramica dei file non impacchettati ti porta alla finestra di dialogo per la creazione di un nuovo pacchetto:

Oltre ai dettagli ovvi, è importante selezionare almeno un file da includere nel pacchetto.
La creazione di un pacchetto genera anche una descrizione del pacchetto in ~/var/check_mk/packages/,
che contiene informazioni generali e l'elenco dei file inclusi.
La versione massima supportata di Checkmk è ovviamente difficile da prevedere senza una sfera di cristallo.
Le estensioni che utilizzano le nuove API introdotte in Checkmk 2.3.0 sono future-proof e funzioneranno anche fino a Checkmk 2.5.0 senza alcuna modifica. In questo caso puoi inserire 2.5.99 per Valid until Checkmk version come versione massima supportata di Checkmk. Al momento della revisione di questo articolo non è possibile fare alcuna previsione per il futuro oltre a questa data. |
Ora puoi effettuare lo scaricamento di questo pacchetto appena creato come file MKP tramite l'elenco dei pacchetti con il simbolo
— per trasferirlo su un altro sistema o caricarlo su Exchange, ad esempio.
La riga di comando
La procedura per creare MKP dalla riga di comando è analoga a quella del menu di configurazione.
Per prima cosa, usa mkp template per creare una configurazione del pacchetto che (per ora) contenga tutti questi file.
Specifica il nome desiderato per il nuovo pacchetto come parametro:
Ora modifica le proprietà del pacchetto con un editor di testo:
{'author': 'Add your name here',
'description': 'Please add a description here',
'download_url': 'https://example.com/hello_world_ng/',
'files': {'agents': ['plugins/hello_world', 'windows/plugins/hello_world.cmd'],
'cmk_addons_plugins': ['hello_world/agent_based/hello_world.py',
'hello_world/checkman/hello_world',
'hello_world/graphing/helloworld_perfometer_graphing.py',
'hello_world/rulesets/ruleset_hello_world.py',
'hello_world/rulesets/ruleset_hello_world_bakery.py'],
'lib': ['python3/cmk/base/cee/plugins/bakery/hello_world.py']},
'name': 'hello_world_ng',
'title': 'Title of hello_world_ng',
'version': '1.0.0',
'version.min_required': '2.3.0p27',
'version.packaged': 'cmk-mkp-tool 0.2.0',
'version.usable_until': None}Modifica questo file in base alle tue esigenze.
Presta attenzione alla sintassi Python corretta: le stringhe Unicode (testi contenenti caratteri non ASCII come le dieresi) devono essere precedute da una piccola u, ad esempio.
Sotto la voce files, puoi rimuovere i file che non devono essere inclusi nel pacchetto.
In version.min_required inserisci la versione minima di Checkmk richiesta per poter utilizzare il pacchetto.
Una volta fatto, puoi creare un file MKP con mkp package:
I pacchetti sono memorizzati in ~/var/check_mk/packages_local:
5. Il formato dei pacchetti MKP
Potresti voler programmare e creare nuovi pacchetti di estensione su una macchina di sviluppo, per poi trasferire il pacchetto finito sul server Checkmk per testarlo.
È piuttosto facile da fare, dato che il formato MKP è semplicemente un file .tar.gz, che a sua volta contiene file .tar e file manifest.
Esaminando il file `hello_world-0.2.5.mkp` effettuato si scopre il primo livello della sua struttura:
Decomprimi il pacchetto in una directory temporanea, dove potrai effettuare la visualizzazione del contenuto degli archivi tar inclusi. I percorsi dei file sono relativi alla directory che contiene i rispettivi componenti:
E che dire dei due file di manifesto info e info.json?
Hai già visto il file info e i suoi campi contenuti nel formato Python Dict sopra.
L'equivalente JSON info.json contiene esattamente gli stessi campi e valori, ma è stato serializzato nel formato JSON.
Se vuoi compilare il pacchetto come parte di uno script, dovresti inserire il file Python dict info e generare il file JSON info.json da questo prima di creare il pacchetto.
Quando ricompili gli archivi, fai attenzione a non includere percorsi di file che non fanno parte della gerarchia di cartelle sotto ~/local.
Il livello superiore deve contenere solo i manifesti e i file tar.
6. Riferimento ai comandi
6.1. Gestione
| Sottocomando | Parametro | Funzione |
|---|---|---|
|
Nome del file del pacchetto da aggiungere |
Rende disponibile un pacchetto, ma non lo attiva ancora. |
|
Nome del pacchetto (e numero di versione, se applicabile) |
Attiva un pacchetto per l'uso locale o per la distribuzione a istanze remote, a seconda della compatibilità delle versioni. |
|
Nome del pacchetto (e numero di versione, se applicabile) |
Attiva un pacchetto anche se non c'è compatibilità di versione. |
|
Nome del pacchetto e numero di versione |
Disabilita un pacchetto, che rimane disponibile nel file system. |
|
Nome del pacchetto e numero di versione |
Rimuove completamente un pacchetto precedentemente disabilitato. |
|
Nome del file del pacchetto da aggiungere |
Questo sottocomando è deprecato e verrà rimosso a breve! |
|
nessuno |
Elenca tutti i pacchetti disponibili e il loro stato di attivazione. |
|
Nome del file del pacchetto da esaminare |
Mostra informazioni sulla disinstallazione di un MKP. |
|
Nome del pacchetto (e numero di versione, se applicabile) |
Visualizza informazioni su un MKP disponibile. |
|
nessuno |
Mostra informazioni su tutti gli MKP disponibili. |
|
Nome del pacchetto (e numero di versione, se applicabile) |
Elenca tutti i file appartenenti a un pacchetto. |
6.2. Sviluppo
| Sottocomando | Parametro | Funzione |
|---|---|---|
|
Nome del pacchetto |
Risolve un pacchetto attivo. |
|
nessuno |
Elenca tutti i file che non appartengono a nessun pacchetto. |
|
Nome del nuovo pacchetto da creare |
Crea un file manifest come base per un nuovo pacchetto. |
|
Percorso del file manifest |
Crea un MKP basato sul contenuto di un file manifest. |
6.3. Aggiornamenti
| Sottocomando | Parametro | Funzione |
|---|---|---|
|
nessuno |
Disabilita i pacchetti che non corrispondono più alla versione di Checkmk dopo un aggiornamento. |
|
nessuno |
Attiva i pacchetti che corrispondono alla versione di Checkmk dopo un aggiornamento. |
