Checkmk
DeutschEnglish
master2.3.0
to checkmk.com
Important

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

I plug-in di controllo compatibili con SNMP sono sviluppati in modo simile ai loro omologhi basati su agente. La differenza sta sia nel processo di individuazione dei servizi che nel controllo stesso. Con i plug-in di controllo basati su agente, il plug-in agente viene utilizzato per determinare quali dati vengono inviati al sito Checkmk, e spesso il pre-filtraggio (ma non la valutazione) avviene già sull'host. Al contrario, con SNMP devi specificare esattamente quali campi di dati ti servono e richiederli in modo esplicito. Con SNMP, queste aree (rami di un albero) o singoli campi di dati (foglie) sono identificati dagli OID (identificatori di oggetto).

In teoria sarebbe possibile un trasferimento completo di tutti i dati (utilizzando il cosiddetto SNMP walk), tuttavia, anche con dispositivi veloci ciò richiede alcuni minuti e, con switch complessi, può richiedere più di un'ora. Questo rappresenta quindi già un problema durante la scoperta e lo è ancora di più durante il controllo stesso. In questo caso Checkmk adotta un approccio più mirato. Ciononostante, gli SNMP walk sono disponibili in Checkmk per il debug dei controlli esistenti e lo sviluppo di controlli personalizzati.

Se non hai ancora esperienza con SNMP, ti consigliamo di leggere l'articolo sul monitoraggio tramite SNMP.

1.1. Cosa funziona in modo diverso con SNMP?

Rispetto a un plug-in di controllo per l'agente Checkmk, ci sono alcune caratteristiche particolari da tenere in considerazione con SNMP. Con un plug-in di controllo per SNMP, la scoperta dei servizi è suddivisa in due fasi.

Come primo passo, la funzione di rilevamento SNMP viene utilizzata per individuare il dispositivo. Questo serve a determinare se il plug-in di controllo è di qualche interesse per il dispositivo in questione e viene eseguito per ogni dispositivo monitorato tramite SNMP. A questo scopo vengono recuperati alcuni OID — singoli, senza uno SNMP walk. Il più importante di questi è l’sysDescr (OID: 1.3.6.1.2.1.1.1.0). Sotto questo OID, ogni dispositivo SNMP fornisce una descrizione di sé stesso, ad esempio Flintstones, Inc. Fred Router rev23.

Nella seconda fase, vengono recuperati i dati di monitoraggio necessari per ciascuno di questi candidati utilizzando gli SNMP walk. Questi vengono poi riassunti in una tabella e forniti alla funzione di rilevamento del plug-in di controllo nell’argomento section, che determina quindi gli elementi da monitorare. Viene quindi generato un servizio per ciascuno di questi elementi.

Durante il controllo si sa già se il plug-in deve essere eseguito per il dispositivo e quindi non è necessario un nuovo rilevamento SNMP. I dati di monitoraggio attuali richiesti per il plug-in vengono recuperati qui tramite SNMP walk.

Cosa devi fare di diverso con un plug-in di controllo per SNMP rispetto a uno basato su agente?

  1. Non hai bisogno di un plug-in agente.

  2. Si definiscono gli OID necessari per il rilevamento SNMP e i testi che devono contenere.

  3. Decidi quali rami e foglie dell'albero SNMP devono essere recuperati per il monitoraggio.

1.2. Non aver paura delle MIB!

In questa breve introduzione vorremmo parlare dei famigerati MIB SNMP, sui quali esistono molti pregiudizi. La buona notizia: Checkmk non ha bisogno dei MIB! Tuttavia, possono essere un aiuto importante quando si sviluppa un plug-in di controllo o si risolvono i problemi di quelli esistenti.

Cosa sono le MIB? MIB significa letteralmente Management Information Base, che contiene poche informazioni in più rispetto alla stessa abbreviazione. Fondamentalmente, una MIB è un file di testo leggibile dall'uomo che descrive i rami e le foglie in un albero di dati SNMP.

Gli OID possono identificare rami o foglie. La descrizione del ramo contiene informazioni sul sistema e sul sottosistema fornite dal ramo stesso. Se un OID fa riferimento a una foglia, le informazioni nel MIB contengono dettagli sul tipo di dati (stringa di caratteri, numero a virgola fissa, stringa esadecimale, …​), l’intervallo di valori e la rappresentazione. Ad esempio, le temperature possono essere memorizzate come numero a virgola fissa con segno sulla scala Celsius con una risoluzione di 0,1° o senza segno con incrementi di 1,0° sulla scala Kelvin.

Checkmk fornisce una serie di file MIB liberamente accessibili. Questi descrivono campi molto generici nell'albero OID globale, ma non contengono campi specifici del produttore. Non sono quindi di grande aiuto per i plug-in di controllo sviluppati autonomamente.

Cerca quindi i file MIB rilevanti per il tuo dispositivo specifico sul sito web del produttore o anche nell’interfaccia di gestione del dispositivo. Installa questi file nel sito Checkmk nella directory ~/local/share/snmp/mibs/. Potrai quindi tradurre i numeri OID in nomi utilizzando gli SNMP walk e trovare così più rapidamente i dati di interesse ai fini del monitoraggio. Come già accennato, le MIB ben curate contengono anche informazioni interessanti nei loro commenti. Puoi visualizzare facilmente un file MIB con un editor di testo o con il pager less.

2. Individuare gli OID corretti

Il prerequisito fondamentale per sviluppare un plug-in di controllo basato su SNMP è sapere quali OID contengono le informazioni rilevanti. Per lo scenario di esempio presentato, abbiamo ipotizzato che tu abbia appena messo in servizio un lotto di router del tipo Flintstones, Inc. Fred Router rev23. Ti capiterà spesso di imbatterti in questo dispositivo fittizio nella documentazione del produttore e nei commenti MIB. Tuttavia, hai dimenticato di inserire le informazioni di contatto e di ubicazione per alcuni dispositivi. Un plug-in di controllo scritto da te per Checkmk dovrebbe ora aiutarti a identificare questi dispositivi.

Tip

Il plug-in di esempio che abbiamo preparato è scritto in modo tale da poter essere eseguito con quasi tutti i dispositivi compatibili con SNMP. Devi solo adattare la stringa di caratteri da confrontare. Se non hai un dispositivo a portata di mano, troverai varie opzioni di simulazione nel capitolo dedicato alla risoluzione dei problemi.

Il primo passo è eseguire un SNMP walk completo. Ciò comporta il recupero di tutti i dati disponibili tramite SNMP. Con Checkmk puoi farlo molto facilmente. Per prima cosa includi nel monitoraggio il dispositivo per il quale vuoi sviluppare un plug-in di controllo. Assicurati che possa essere monitorato nelle funzioni di base. Come minimo, devono essere individuati i servizi SNMP Info e Uptime e probabilmente anche almeno un Interface. Questo garantirà che l'accesso SNMP funzioni correttamente.

Passa quindi alla riga di comando del sito Checkmk. Qui puoi eseguire un walk completo con il seguente comando — nell'esempio seguente per il dispositivo con il nome host mydevice01. Ti consigliamo di utilizzare anche l'opzione -v (per la modalità verbosa):

OMD[mysite]:~$ cmk -v --snmpwalk mydevice01
mydevice01:
Walk on ".1.3.6.1.2.1"...3898 variables.
Walk on ".1.3.6.1.4.1"...6025 variables.
Wrote fetched data to /omd/sites/mysite/var/check_mk/snmpwalks/mydevice01.
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Come già accennato, un walk SNMP completo può richiedere minuti o addirittura ore (anche se quest’ultimo caso è piuttosto raro), quindi non preoccuparti se ci vuole un po’ di tempo per completarlo. I risultati del walk vengono salvati nel file ~/var/check_mk/snmpwalks/mydevice01. Si tratta di un file di testo di facile lettura che inizia così:

~/var/check_mk/snmpwalks/mydevice01
.1.3.6.1.2.1.1.1.0 Flintstones, Inc. Fred Router rev23
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.424242.2.3
.1.3.6.1.2.1.1.3.0 546522419
.1.3.6.1.2.1.1.4.0 barney@example.com
.1.3.6.1.2.1.1.5.0 big-router-01
.1.3.6.1.2.1.1.6.0 Server room 23, Stonestreet 52, Munich
.1.3.6.1.2.1.1.7.0 72
.1.3.6.1.2.1.1.8.0 0

Ogni riga contiene un OID e il relativo valore. Troverai quello più importante nella primissima riga, ovvero sysDescr. Questo dovrebbe essere un identificatore univoco per un modello hardware.

Anche la seconda riga è interessante: Sotto 1.3.6.1.4.1 ci sono dei rami che i produttori di hardware possono assegnarsi da soli; in questo caso Flintstones, Inc. ha l'ID produttore fittizio 424242. Sotto questo, l'azienda ha assegnato 2 per i router e 3 per lo stesso modello. All'interno di questo ramo troverai poi gli OID specifici per i dispositivi.

Questi OID non sono però molto significativi. Se sono installati i MIB corretti, puoi tradurli in nomi in un secondo momento. È meglio reindirizzare l'output del comando seguente, che altrimenti verrebbe visualizzato nel terminale, in un file:

OMD[mysite]:~$ cmk --snmptranslate mydevice01 > /tmp/translated
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Una volta che questo file è stato translated, si legge come il walk originale, ma mostra in più il nome dell'OID in ogni riga dopo l'-->e:

/tmp/translated
.1.3.6.1.2.1.1.1.0 Flintstones, Inc. Fred Router rev23 --> SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.424242.2.3 --> SNMPv2-MIB::sysObjectID.0
.1.3.6.1.2.1.1.3.0 546522419 --> DISMAN-EVENT-MIB::sysUpTimeInstance
.1.3.6.1.2.1.1.4.0 barney@example.com --> SNMPv2-MIB::sysContact.0
.1.3.6.1.2.1.1.5.0 big-router-01 --> SNMPv2-MIB::sysName.0
.1.3.6.1.2.1.1.6.0 Server room 23, Stonestreet 52, Munich --> SNMPv2-MIB::sysLocation.0
.1.3.6.1.2.1.1.7.0 42 --> SNMPv2-MIB::sysServices.0
.1.3.6.1.2.1.1.8.0 27 --> SNMPv2-MIB::sysORLastChange.0

Nell'output sopra riportato, ad esempio, l'OID 1.3.6.1.2.1.1.4.0 ha il valore barney@example.com e il nome SNMPv2-MIB::sysContact.0. Le informazioni aggiuntive che mostrano i nomi degli OID forniscono dati importanti per identificare gli OID di interesse. Per l'esempio presentato, sono sufficienti gli OID da 1.3.6.1.2.1.1.4.0 a 1.3.6.1.2.1.1.6.0.

3. Scrivere un semplice plug-in di verifica

Hai completato il lavoro preparatorio: Ora hai un elenco degli OID che vuoi leggere e valutare. Il compito ora è usare queste note per insegnare a Checkmk quali servizi vengono generati e quando devono andare su WARN o CRIT. La programmazione di un plug-in di controllo in Python usato per questo ha molte analogie con un plug-in di controllo basato su agente. Dato che ci sono alcune sottigliezze da considerare, mostreremo la struttura completa con tutte le funzioni che vengono usate.

3.1. Preparazione del file

Per i tuoi plug-in di controllo troverai la directory di base già pronta nella gerarchia local della directory del sito. Si tratta di ~/local/lib/python3/cmk_addons/plugins/. La directory appartiene all'utente del sito ed è quindi scrivibile per te.

In questa directory, i plug-in sono organizzati in famiglie di plug-in, i cui nomi delle directory possono essere scelti liberamente. Ad esempio, tutti i plug-in relativi ai dispositivi Cisco sono memorizzati nella cartella cisco — oppure tutti i plug-in relativi ai router del produttore Flintstones, Inc. sono memorizzati nella cartella flintstone.

In questa sottodirectory <plug-in_family> vengono poi create ulteriori sottodirectory con nomi predefiniti, a seconda delle diverse API, ad esempio agent_based per l’API Check dei plug-in basati su agente, inclusi i plug-in di controllo basati su SNMP.

Crea le due sottodirectory per il nuovo plug-in di controllo e poi passa a esse per lavorare:

OMD[mysite]:~$ mkdir -p ~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based
OMD[mysite]:~$ cd ~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Crea qui il file flintstone_setup_check.py per il plug-in di controllo. La convenzione prevede che il nome del file rifletta il nome del plug-in di controllo così come definito quando il plug-in viene creato come istanza della classe CheckPlugin. È obbligatorio che il file termini con .py, poiché a partire dalla versione 2.0.0 di Checkmk i plug-in di controllo sono sempre veri e propri moduli Python.

Un framework di base eseguibile (scaricabile da GitHub), che amplierai passo dopo passo di seguito, ha questo aspetto:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
#!/usr/bin/env python3

from cmk.agent_based.v2 import (
    CheckPlugin,
    CheckResult,
    startswith,
    DiscoveryResult,
    Result,
    Service,
    SimpleSNMPSection,
    SNMPTree,
    State,
    StringTable,
)

def parse_flintstone(string_table):
    return {}

def discover_flintstone(section):
    yield Service()

def check_flintstone(section):
    yield Result(state=State.OK, summary="Everything is fine")

snmp_section_flintstone_setup = SimpleSNMPSection(
    name = "flintstone_base_config",
    parse_function = parse_flintstone,
    detect = startswith(".1.3.6.1.2.1.1.1.0", "Flintstone"),
    fetch = SNMPTree(base='.1.3.6.1.2.1.1', oids=['4.0']),
)

check_plugin_flintstone_setup = CheckPlugin(
    name = "flintstone_setup_check",
    sections = [ "flintstone_base_config" ],
    service_name = "Flintstone setup check",
    discovery_function = discover_flintstone,
    check_function = check_flintstone,
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Per prima cosa dovrai importare le funzioni e le classi necessarie per i plug-in di controllo dai moduli Python. Ti sconsigliamo di usare l'import *, che viene usato occasionalmente, poiché consuma memoria inutilmente e rende poco chiaro quali spazi dei nomi siano effettivamente disponibili. Per il nostro esempio, importeremo solo ciò che sarà necessario o potrebbe essere utile nel resto di questo articolo:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
from cmk.agent_based.v2 import (
    CheckPlugin,
    CheckResult,
    startswith,
    DiscoveryResult,
    Result,
    Service,
    SimpleSNMPSection,
    SNMPTree,
    State,
    StringTable,
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Rispetto al plug-in di controllo basato su agente, spiccano le nuove funzioni e classi specifiche per SNMP: SNMPTree, SimpleSNMPSection e startswith. Si spiega da sé SNMPTree, che è una classe per visualizzare gli alberi SNMP. La classe SimpleSNMPSection viene utilizzata per creare una sezione SNMP. La funzione startswith() confronta il contenuto di una foglia SNMP con una stringa di caratteri. Ne parleremo più avanti.

3.2. Creazione della sezione SNMP

Dopo aver identificato gli OID corretti, è il momento di sviluppare effettivamente il plug-in di controllo. Quando crei la sezione SNMP, devi specificare due cose:

  1. Identifichi i dispositivi per i quali deve essere eseguito il plug-in di controllo.
    Nell'esempio seguente, questo viene fatto con la funzione startswith(), che confronta una stringa di caratteri con l'inizio del contenuto di una foglia OID. Ulteriori opzioni di assegnazione sono mostrate di seguito.

  2. Dichiari quali rami o foglie OID devono essere recuperati per il monitoraggio.
    Questo viene fatto con il costruttore della classe SNMPTree.

Estendi il file di esempio preparato in modo che il plug-in venga eseguito solo per un numero limitato di dispositivi, in questo caso i modelli Flintstones, Inc. Fred Router. Vengono quindi recuperati gli OID relativi a contatto, nome del dispositivo e posizione per questi dispositivi. Questi tre OID sono forniti da ciascun dispositivo. Se vuoi testare l'esempio con dispositivi reali compatibili con SNMP, è quindi sufficiente personalizzare il nome del modello da riconoscere.

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
snmp_section_flintstone_setup_check = SimpleSNMPSection(
    name = "flintstone_base_config",
    parse_function = parse_flintstone,
    detect = startswith(
        ".1.3.6.1.2.1.1.1.0",
        "Flintstones, Inc. Fred Router",
    ),
    fetch = SNMPTree(
        base = '.1.3.6.1.2.1.1',
        oids = ['4.0', '5.0', '6.0'],
    ),
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

L'esempio contiene anche il parametro name, con cui viene identificata la sezione SNMP generata, e una funzione di analisi, di cui parleremo più avanti.

Il rilevamento SNMP

Usa il parametro detect per specificare le condizioni in cui deve essere eseguita la funzione di rilevamento. Nel nostro esempio, questo avviene se il valore dell'OID 1.3.6.1.2.1.1.1.0 (cioè l'sysDescr) inizia con il testo Flintstones, Inc. Fred Router (senza distinzione tra maiuscole e minuscole). Oltre a startswith, c'è tutta una serie di altre possibili funzioni per l'identificazione. Esiste anche una forma negata di ciascuna, che inizia con not_. Tieni presente che ogni funzione deve essere specificata separatamente nell'istruzione import.

Attributo Funzione Negazione

equals(oid, "needle")

Il valore dell'OID corrisponde al testo needle.

not_equals(oid, "needle")

contains(oid, "needle")

Il valore dell'OID contiene il testo needle in qualche punto.

not_contains(oid, "needle")

startswith(oid, "needle")

Il valore dell'OID inizia con il testo needle.

not_startswith(oid, "needle")

endswith(oid, "needle")

Il valore dell'OID termina con il testo needle.

not_endswith(oid, "needle")

matches(oid, regex)

Il valore dell'OID corrisponde all'espressione regolare regex, ancorata prima e dopo, cioè con una corrispondenza esatta. Se ti serve solo una sottostringa, basta aggiungere un .* all'inizio o alla fine.

not_matches(oid, regex).

exists(oid)

L'OID è disponibile sul dispositivo. Il suo valore può essere vuoto.

not_exists(oid)

C'è anche la possibilità di collegare diversi attributi con all_of o any_of.

all_of Richiede diversi controlli riusciti per un riconoscimento positivo. L'esempio seguente assegna il tuo plug-in di controllo a un dispositivo se il testo nell'sysDescr inizia con foo (o FOO o Foo) e l'OID 1.3.6.1.2.1.1.2.0 contiene il testo .4.1.11863.:

detect = all_of(
    startswith(".1.3.6.1.2.1.1.1.0", "foo"),
    contains(".1.3.6.1.2.1.1.2.0", ".4.1.11863.")
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Al contrario, any_of è soddisfatto se è stato soddisfatto anche solo uno dei criteri. Ecco un esempio in cui sono consentiti valori diversi per l'sysDescr:

detect = any_of(
    startswith(".1.3.6.1.2.1.1.1.0", "foo version 3 system"),
    startswith(".1.3.6.1.2.1.1.1.0", "foo version 4 system"),
    startswith(".1.3.6.1.2.1.1.1.0", "foo version 4.1 system"),
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

A proposito: hai familiarità con le espressioni regolari? Se sì, probabilmente potresti semplificare questo esempio e cavartela con una sola riga:

detect = matches(".1.3.6.1.2.1.1.1.0", "FOO Version (3|4|4.1) .*")
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

E un'altra nota importante: Gli OID che passi al rilevamento SNMP per un plug-in di controllo vengono recuperati da ogni dispositivo monitorato tramite SNMP. Questo è l'unico modo in cui Checkmk può determinare a quali dispositivi applicare il plug-in di controllo.

Dovresti quindi prestare molta attenzione quando utilizzi OID specifici del produttore. Cerca di progettare il tuo rilevamento SNMP in modo da dare priorità al controllo dell'sysDescr (1.3.6.1.2.1.1.1.0) e dell'sysObjectID (1.3.6.1.2.1.1.2.0).

Se hai ancora bisogno di un OID diverso per un'identificazione esatta, usa all_of() e procedi come segue:

  1. Controlla prima sysDescr o sysObjectID.

  2. Negli argomenti successivi, puoi quindi restringere ulteriormente il gruppo di dispositivi per i quali deve essere eseguito il tuo plug-in.

detect = all_of(
    startswith(".1.3.6.1.2.1.1.1.0", "Flintstone"),   # first check sysDescr
    contains(".1.3.6.1.4.1.424242.2.3.37.0", "foo"),  # fetch vendor specific OID
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Questo funziona grazie al principio della valutazione pigra: non appena uno dei controlli precedenti fallisce, non verranno eseguiti ulteriori controlli. Nell'esempio sopra, l'OID 1.3.6.1.4.1.424242.2.3.37.0 viene recuperato solo dai dispositivi che hanno anche Flintstone nel loro sysDescr.

3.3. Scrivere la funzione di analisi

Come per i plug-in basati su agenti, anche la funzione di analisi nel plug-in di controllo basato su SNMP ha il compito di convertire i dati dell'agente ricevuti in una forma che possa essere elaborata facilmente e, soprattutto, con prestazioni elevate.

Anche qui ricevi i dati sotto forma di lista. Tuttavia, ci sono alcune sottigliezze da considerare, poiché fa differenza se stai interrogando foglie o rami. Come promemoria: nel nostro esempio sopra riportato, vengono richieste le foglie:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
    fetch = SNMPTree(
        base = '.1.3.6.1.2.1.1',
        oids = ['4.0', '5.0', '6.0'],
    )
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Se estendi temporaneamente la funzione parse con la funzione print(), puoi visualizzare i dati che Checkmk fornisce da questa query durante il test del plug-in di controllo:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def parse_flintstone(string_table):
    print(string_table)
    return {}
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Riceverai una lista annidata che contiene un solo elemento al primo livello, ovvero una lista dei valori recuperati:

[
    ['barney@example.com', 'big-router-01', 'Server room 23, Stonestreet 52, Munich']
]
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Il risultato appare leggermente diverso se recuperi rami che contengono più foglie. Supponiamo che il router possa essere dotato di un numero variabile di schede di rete, il cui nome, stato di connessione e velocità possono essere letti qui sotto 1.3.6.1.4.1.424242.2.3.23 …

    fetch = SNMPTree(
        base = '.1.3.6.1.4.1.424242.2.3.23',
        oids = [
            '6', # all names
            '7', # all states
            '8', # all speeds
        ],
    )
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

… quindi l'elenco bidimensionale potrebbe apparire così:

[
    # Name, State, Speed
    ['net0', '1', '1000'],
    ['net1', '0', '100'],
    ['net2', '1', '10000'],
    ['net3', '1', '1000'],
]
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Tutte le foglie disponibili sotto un OID vengono scritte in una colonna della tabella. Dovrebbe quindi essere ovvio che, ai fini della visualizzazione dei dati, è possibile interrogare solo gli OID corrispondenti.

Tip

L'ultimo esempio mostrato per il recupero dei rami OID fa anche parte del nostro SNMP walk disponibile su GitHub, che puoi utilizzare per le simulazioni.

Ma torniamo ora all'esempio in cui vengono interrogate le foglie OID relative a contatto, nome del dispositivo e posizione: La seguente funzione di analisi copia semplicemente ogni elemento della lista interna in una coppia chiave-valore nel dizionario restituito:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def parse_flintstone(string_table):
    # print(string_table)
    result = {}
    result["contact"] = string_table[0][0]
    result["name"] = string_table[0][1]
    result["location"] = string_table[0][2]
    # print(result)
    return result
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Il risultato della funzione di analisi sarà quindi simile a questo:

{
    'contact': 'barney@example.com',
    'name': 'big-router-01',
    'location': 'Server room 23, Stonestreet 52, Munich'
}
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

3.4. Creazione del plug-in di controllo

Un plug-in di controllo viene creato esattamente come descritto nei plug-in di controllo basati su agente.

Dato che nella maggior parte dei casi interrogherai diversi rami SNMP e questo comporterà diverse sezioni SNMP, di solito è necessario il parametro `sections` con l'elenco delle sezioni da valutare:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
check_plugin_flintstone_setup = CheckPlugin(
    name = "flintstone_setup_check",
    sections = [ "flintstone_base_config" ],
    service_name = "Flintstone setup check",
    discovery_function = discover_flintstone,
    check_function = check_flintstone,
)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

3.5. Scrivere la funzione di rilevamento

Anche la funzione di rilevamento corrisponde all'esempio per i plug-in di controllo basati su agente. Per i plug-in di controllo che generano un solo servizio per host, è sufficiente un unico `yield()`:

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def discover_flintstone(section):
    yield Service()
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

3.6. Scrivere la funzione di controllo

Nell'esempio, vogliamo verificare se le informazioni relative al contatto, al nome del dispositivo e alla posizione sono disponibili. È quindi sufficiente controllare quali campi sono vuoti nella funzione di controllo e impostare di conseguenza lo stato su "CRIT" (se manca qualcosa) o su "OK" (se tutto è disponibile):

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def check_flintstone(section):
    missing = 0
    for e in ["contact", "name", "location"]:
        if section[e] == "":
            missing += 1
            yield Result(state=State.CRIT, summary=f"Missing information: {e}!")
    if missing > 0:
        yield Result(state=State.CRIT, summary=f"Missing fields: {missing}!")
    else:
        yield Result(state=State.OK, summary="All required information is available.")
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Una volta creata la funzione di controllo, il plug-in di controllo sarà pronto per l'uso.

Abbiamo reso disponibile questo plug-in di controllo completo su GitHub.

3.7. Test e attivazione del plug-in di controllo

Il test e l'attivazione vengono eseguiti allo stesso modo di un plug-in di controllo basato su agente. Per prima cosa, assicurati che il tuo plug-in sia sintatticamente corretto:

OMD[mysite]:~$ cmk-validate-plugins
Agent based plugins loading succeeded, Active checks loading succeeded, Special agents
loading succeeded, Rule specs loading succeeded, Rule specs forms creation succeeded,
Referenced rule specs validation succeeded, Loaded rule specs usage succeeded
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Il passo successivo è il rilevamento del servizio del plug-in:

OMD[mysite]:~$ cmk -vI --detect-plugins=flintstone_setup_check mydevice01
Discovering services and host labels on: mydevice01
mydevice01:
+ FETCHING DATA
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
Get piggybacked data
+ ANALYSE DISCOVERED HOST LABELS
SUCCESS - Found no new host labels
+ ANALYSE DISCOVERED SERVICES
+ EXECUTING DISCOVERY PLUGINS (1)
  1 flintstone_setup_check
SUCCESS - Found 1 services
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Come previsto, il rilevamento del servizio è andato a buon fine. Ora puoi testare il controllo contenuto nel plug-in di controllo:

OMD[mysite]:~$ cmk -v --detect-plugins=flintstone_setup_check mydevice01
+ FETCHING DATA
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
Get piggybacked data
Flintstone setup check All required information is available.
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[snmp] Success, [piggyback] Success ...
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Dopo aver riavviato il core di monitoraggio …

OMD[mysite]:~$ cmk -R
Generating configuration for core (type nagios)...
Precompiling host checks...OK
Validating Nagios configuration...OK
Restarting monitoring core...OK
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

… il nuovo servizio sarà quindi visibile nel monitoraggio:

The new service created by the check plug-in in the monitoring.
Poiché tutti i campi delle tre foglie SNMP sono compilati, il servizio èOK

4. Risoluzione dei problemi

Poiché la risoluzione dei problemi nei plug-in di controllo basati su agenti si applica essenzialmente anche ai plug-in di controllo basati su SNMP, qui tratteremo solo le specifiche relative a SNMP.

4.1. Opzioni di simulazione

Utilizzo dei walk SNMP salvati in Checkmk

Nell'articolo sul monitoraggio tramite SNMP mostriamo in dettaglio come creare SNMP walk dalla GUI e come utilizzarli per la simulazione. Questo permette anche di sviluppare plug-in di controllo su sistemi di test che non possono accedere agli host SNMP per i quali stai sviluppando un plug-in. Nel nostro repository GitHub troverai un esempio di SNMP walk, che utilizziamo in questo articolo e che puoi usare per sviluppare e testare il plug-in di controllo.

Il daemon SNMP fittizio

Se vuoi assicurarti che specifici OID cambino in base l'uno all'altro, può essere utile programmare un daemon SNMP fittizio che fornisca dati coerenti. Il modulo Python snmp-agent può essere d'aiuto nella programmazione di un daemon fittizio di questo tipo.

4.2. Hardware non cooperativo

Prima che un dispositivo possa essere monitorato con un nuovo plug-in di controllo basato su SNMP, deve prima essere monitorabile tramite SNMP. Puoi quindi trovare una panoramica dei problemi noti con le soluzioni suggerite nell'articolo sul monitoraggio tramite SNMP.

5. File e cartelle

Percorso del file Descrizione

~/local/lib/python3/cmk_addons/plugins/

Directory di base per l'archiviazione dei file dei plug-in.

~/local/lib/python3/cmk_addons/plugins/<plug-in_family>/agent_based/

Posizione di archiviazione per i plug-in di controllo scritti secondo l'API Check V2.

~/local/share/snmp/mibs/

Metti qui i file MIB SNMP che devono essere caricati automaticamente.
Last modified: Wed, 01 Apr 2026 14:25:53 GMT via commit 0903c1786
In questa pagina