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
L'inventario HW/SW ti aiuta a tenere traccia dell'hardware esistente e a mantenere il controllo sul software installato in ogni momento. Checkmk fornisce plug-in già pronti per molti scenari di utilizzo di base. Tuttavia, in molti casi vorrai ottenere informazioni più dettagliate su hardware e software specifici. È qui che entrano in gioco i plug-in personalizzati per l'inventario HW/SW.
Per questo articolo, daremo per scontato che tu abbia già una conoscenza di base della programmazione dei plug-in di controllo basati su agenti. Per gli aspetti in cui l'uso dell'API di inventario non differisce in modo significativo dall'uso dell'API di controllo, le spiegazioni in questo articolo sono quindi piuttosto succinte. Tuttavia, se necessario, segnaleremo eventuali differenze significative in modo ancora più chiaro.
Tieni presente la differenza tra plug-in di controllo e plug-in di inventario. I plug-in di controllo sono adatti principalmente per dati che cambiano rapidamente, mentre i plug-in di inventario sono adatti per dati che cambiano raramente. In questo articolo useremo un semplice esempio che coinvolge dispositivi USB per illustrare questo punto. Ad esempio, se vuoi assicurarti che nessuno effettui una connessione a nessun computer nel sistema di monitoraggio con dispositivi USB che non sono presenti in una whitelist, un plug-in di controllo sarà più adatto. |
1.1. La documentazione dell'API Check
L'API Inventory fa parte dell'API Check. Per accedere alla documentazione, segui gli stessi passaggi utilizzati per i plug-in di controllo basati su agente.
Puoi accedere alla documentazione fornita con la tua istanza Checkmk. Per farlo, vai su Help > Developer resources > Plug-in API references nella GUI di Checkmk. Nella nuova finestra del browser, seleziona Agent based ("Check API") > Version 2 nella barra di navigazione a sinistra. Anche senza una istanza Checkmk attualmente in esecuzione, puoi effettuare la visualizzazione della documentazione dell'API dei plug-in all'indirizzo docs.checkmk.com/plugin-api.
2. Preparazione
L'impostazione predefinita di Checkmk prevede l'aggiornamento dei dati di inventario solo una volta al giorno. Questo, ovviamente, è in contrasto con la necessità di avere risultati visibili rapidamente quando si testano i propri programmi. Consigliamo quindi due misure preparatorie per aumentare la velocità senza aumentare in modo significativo il carico di sistema:
Non utilizzare il plug-in "
mk_inventory", che genera un carico elevato sull'host che fornisce i dati per il nuovo plug-in da creare.Imposta l'intervallo di esecuzione dell'active check per questo host su uno o pochi minuti.
3. Il plug-in dell'agente
Se vuoi aggiungere funzionalità di inventario a un plug-in di controllo basato su agente, potresti riuscire a utilizzare una sezione agente scritta appositamente per il tuo plug-in di controllo.
Per il nostro esempio, creane una tu.
La base per farlo è il comando lsusb.
Quando viene chiamato senza parametri, restituisce un elenco di tutti i dispositivi USB collegati.
Potrebbe apparire così:
La versione breve utilizzata qui nei primi campi mostra a quale bus e porta è collegato un dispositivo. A questo segue, separato da due punti, prima l'ID del produttore, poi l'ID del dispositivo. Il resto della riga contiene un testo descrittivo.
3.1. Lo script risultante
Dato che Checkmk handle l'output riga per riga bene, bastano tre righe per il plug-in di controllo richiesto:
Non dimenticare di rendere il plug-in eseguibile:
Se l'host su cui stai testando il plug-in dell'agente è una macchina virtuale, o se non vuoi continuare a rimuovere e ricollegare dispositivi, salva semplicemente il seguente esempio in un file nella directory di spool. I file di spool sono inclusi nell'output dell'agente e vengono trasferiti insieme ad esso, quindi assicurati che il file finisca con un'interruzione di riga.
Puoi quindi simulare la connessione e la rimozione di dispositivi USB aggiungendo o rimuovendo righe dal file di testo.
3.2. Test dell'agente
Prova l'output dell'agente localmente con il seguente comando:
A seconda del numero di dispositivi USB collegati (o del numero di righe nel file di spool), ora dovresti vedere l'output di lsusb e alcune righe della seguente sezione dell'agente.
Assicurati che l'interruzione di riga alla fine della sezione dell'agente sia corretta.
4. Il plug-in di inventario
I plug-in di inventario risiedono nella normale struttura di directory insieme ai normali plug-in di controllo.
Puoi memorizzare i plug-in di inventario come file separati; in questo caso, ti consigliamo di usare il prefisso inventory_.
In alternativa, puoi integrare i plug-in di inventario negli stessi file dei plug-in di controllo; in questo caso, dovresti omettere completamente il prefisso.
La scelta del metodo dipende dalla chiarezza e dalla necessità di funzioni condivise.
Per creare un plug-in di inventario puro, devi quindi creare una directory adeguata:
4.1. Un plug-in di base
Ora puoi creare un plug-in di inventario di base, che puoi modificare utilizzando qualsiasi editor di testo:
La struttura è simile a quella dei plug-in di controllo.
Anche il plug-in di inventario importa dal namespace cmk.agent_based.v2.
Un oggetto CheckPlugin istanziato è collegato a una specifica funzione di controllo che restituisce uno o più oggetti Result tramite yield.
Allo stesso modo, un oggetto InventoryPlugin istanziato è collegato a una specifica funzione di inventario che restituisce un oggetto Attributes tramite yield.
L'Attributes restituito da yield implementa la foglia minima significativa di un albero di inventario:
L'
pathdescrive il nodo rilevante nella gerarchia dell'albero, in questo caso Hardware > Usb > General.Le coppie chiave-valore nell'oggetto
inventory_attributessono rappresentate come una tabella chiave-valore.
Per prima cosa, verifica che il plug-in sia sintatticamente corretto e che possa essere avviato durante l'inventario:
In questo caso, aggiorna la configurazione del nucleo di monitoraggio e poi riavvia l'istanza:
Dando un'occhiata all'inventario dell'host di prova, ora vedrai — non appena verrà eseguito il prossimo check regolare — una nuova foglia nell'albero dell'inventario.
4.2. Scrivere la funzione di analisi
Le sezioni dell'agente senza un separatore specificato vengono convertite in un elenco bidimensionale di token utilizzando il separatore predefinito (spazio) prima di essere passate alla funzione di inventario: Viene creato un elenco di token per ogni riga. Ciascuno di questi elenchi è a sua volta un elemento di un elenco di righe. Se viene specificato un separatore, questo definisce il confine tra i token. Ciò facilita l'elaborazione dei dati in formato CSV, ad esempio.
Una funzione di analisi come quella per i plug-in di controllo basati su agenti non è assolutamente necessaria. Tuttavia, l'uso di una funzione di analisi separata può presentare alcuni vantaggi. Ad esempio, aumenta la chiarezza e l'estensibilità. E se si deve riutilizzare un plug-in di controllo basato su agenti esistente, non c'è nemmeno bisogno di porsi la domanda: basta continuare a utilizzare la funzione di analisi esistente.
Nel nostro esempio, non importa dove sia effettuato il collegamento di un dispositivo USB. Per il plug-in, è necessario determinare gli ID del produttore e del dispositivo (sesta voce dell'elenco) e la descrizione (dalla settima voce alla fine dell'elenco).
Mentre la versione USB massima supportata era semplicemente hard-coded nel semplice esempio sopra, ti invitiamo a pensare a come puoi determinarla a medio termine utilizzando espressioni regolari dalla descrizione. Per farlo, è necessaria l'intera descrizione, ovvero tutto dal settimo all'ultimo termine dell'elenco:
4.3. Scrivere la funzione di inventario
Qui puoi prendere una scorciatoia: a differenza dei plug-in di controllo basati su agente, la funzione di analisi non viene integrata creando un oggetto AgentSection, ma deve essere chiamata dalla funzione di inventario stessa.
Conosci già il principio dell'yielde per il trasferimento continuo di elementi dai plug-in di controllo basati su agente:
Qui, per ogni riga dell'output di lsusb viene restituito un oggetto di tipo TableRow.
Questo contiene tre colonne: Vendor e Device ID fungono insieme da chiavi.
La terza colonna, che è puramente informativa, contiene la descrizione.
Le colonne chiave hanno la particolarità di essere utilizzate per rilevare le modifiche, che a loro volta possono portare a un cambiamento di stato del servizio HW/SW Inventory nel monitoraggio. Inoltre, le chiavi devono essere uniche. Le righe aggiuntive con la stessa combinazione di ID fornitore e dispositivo vengono quindi ignorate.
Oltre alle colonne chiave e di inventario, puoi anche descrivere le voci della tabella con status_columns e analoghi status_attributes , che rappresentano lo stato di un oggetto.
Per il valore dello stato sono disponibili i tipi di dati semplici (int , float , str , bool o None).
Ad esempio, se vuoi creare una tabella che elenchi quale connessione (Bus/Device) è occupata, puoi usare key_columns (Bus e Device) e status_columns (qui: bool).
4.4. Il plug-in finito
Il plug-in finito mette tutto insieme.
Anche la classe TableRow viene importata qui:
5. Set di regole per l'inventario
Dato che l'API Inventario fa parte dell'API Check, la creazione e l'applicazione dei set di regole è esattamente la stessa che si usa per lo sviluppo dei normali plug-in di controllo. Per questo motivo, qui ti mostreremo solo un semplice esempio.
5.1. Definizione di un set di regole
L'output di lsusb include diverse righe relative agli hub (hub esterni e hub root).
Questi dispositivi, che non hanno funzionalità proprie, rendono difficile mantenere una visione panoramica.
Gli utenti dovrebbero quindi poter decidere autonomamente se includere o meno gli hub. Dovrebbero poter configurare questa impostazione utilizzando una checkbox all'interno di una regola.
Per farlo, crea la cartella rulesets per la famiglia di plug-in:
Ora crea il set di regole in questa cartella:
Una volta salvato lo script per il set di regole, convalidalo con cmk-validate-plugins e poi riavvia l'istanza con omd restart.
A questo punto puoi ignorare eventuali segnalazioni da cmk-validate-plugins relative a set di regole esistenti ma non collegati.
Il collegamento verrà effettuato nella sezione successiva.
Ora puoi effettuare la visualizzazione e la personalizzazione della regola nell'interfaccia GUI all'indirizzo Setup > Hosts > HW/SW inventory rules. Se conosci il nome di una regola (in questo caso: Lsusb inventory demo), puoi digitarlo direttamente nel campo di ricerca. Con Add rule puoi creare la regola che hai appena preparato e applicarla come al solito alle cartelle o agli host con le proprietà che hai selezionato.
5.2. Applicazione del set di regole
Il set di regole non è ancora stato collegato.
Per applicarlo, aggiungi altri due named arguments durante la creazione della classe InventoryPlugin.
Inoltre, il dizionario dei parametri deve essere passato alla funzione inventory come primo argomento.
Qui aggiungi anche un'espressione regolare per identificare quali descrizioni dei dispositivi terminano con "hub".
Tieni presente che per farlo devi aggiungere un'altra riga import all'inizio dello script:
6. Opzioni di estensione
6.1. Iscrizione a più sezioni
Nell'esempio, finora hai seguito la procedura standard: Un plug-in di inventario si abbona a una sezione agente che ha lo stesso nome del plug-in di inventario. Ma cosa succede se vuoi utilizzare sezioni agente esistenti che sono già state valutate da un plug-in di inventario esistente? In questo caso, c'è un'alta probabilità che esista già un plug-in di inventario che utilizza lo stesso nome della sezione agente. Il seguente output fornisce una panoramica delle sezioni esistenti:
In questo caso, e nei casi in cui un plug-in di inventario deve valutare più sezioni dell'agente, puoi specificare le sezioni sottoscritte come un elenco. Ad esempio, supponiamo che tu voglia valutare due sezioni dell'agente che fanno riferimento a elementi fittizi:
In questo caso, le sezioni dell'agente sottoscritte devono essere specificate esplicitamente. Il nome del plug-in non deve più corrispondere alle sezioni dell'agente:
La funzione inventory riceve quindi le tabelle di stringhe come variabili basate sul modello section_sectionname:
Il plug-in completo, che include le versioni di Yoyodyne Gnomovision e Zorg ZF1 nell'albero dell'inventario, può quindi apparire così:
