Richtlinien für Checkplugins


Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

1. Einleitung

Ein großer Vorteil von Check_MK gegenüber vielen anderen Monitoringsystemen ist die große Zahl von gut gepflegten mitgelieferten Checkplugins. Damit diese eine einheitlich hohe Qualität haben, gibt es standardisierte Kriterien, die jedes Plugin erfüllen muss, welche wir hier vorstellen.

Dazu ein wichtiger Hinweis: gehen Sie nicht davon aus, dass alle mit Check_MK mitgelieferten Plugins sich bereits an alle aktuellen Richtlinien halten. Vergessen Sie Copy & Paste. Orientieren Sie sich lieber an den Hinweisen in diesem Artikel.

Wenn Sie Plugins nur für Ihren eigenen Bedarf entwickeln, sind Sie natürlich völlig frei und nicht daran gebunden.

2. Allgemeines

2.1. Qualität

Für Checkplugins, die offiziell Teil von Check_MK sind oder es werden wollen, gelten viel höhere Ansprüche an Qualität, als für solche, die man nur „für sich selbst“ schreibt. Dabei geht es sowohl um äußere Qualität (also Verhalten aus Sicht des Anwenders) als auch um innere Qualität (Lesbarkeit des Codes, etc.).

Schreiben Sie das Plugin so gut und hochwertig wie Sie können.

2.2. Umfang eines Checkpugins

Jedes Checkplugin muss mindestens folgende Komponenten umfassen:

  • Das Checkplugin selbst
  • Eine Manpage
  • Bei Plugins mit Checkparametern eine WATO-Definition für den zugehörigen Regelsatz
  • Metrikdefinitionen für Graphen und Perf-O-Meter, falls der Check Metrikdaten ausgibt
  • Eine Definition für die Agentenbäckerei, falls es ein Agentenplugin gibt
  • Mehrere vollständige unterschiedliche Beispielausgaben des Agenten bzw. SNMP-Walks

3. Benennung

3.1. Name des Checkplugins

Die Wahl des Namens für das Plugin ist besonders kritisch, da dieser später nicht geändert werden kann.

  • Der Name des Plugins muss kurz, spezifisch genug und verständlich sein.

Beispiel: firewall_status ist nur dann ein guter Name, wenn das Plugin für alle oder zumindest viele Firewalls funktioniert.

  • Der Name besteht aus Kleinbuchstaben und Ziffern. Als Trenner ist der Unterstrich erlaubt.
  • Das Wort status oder state hat im Namen nichts verloren, denn schließlich überwacht jedes Plugin einen Status. Gleiches gilt für das überflüssige Wort current. Verwenden Sie also anstelle von foobar_current_temp_status einfach nur foobar_temp.
  • Checks, bei denen das Item ein Ding repräsentiert (z. B. Fan, Power supply), sollen im Singular benannt werden (z. B. casa_fan, oracle_tablespace). Checks bei denen jedes Item eine Anzahl oder Menge darstellt hingegen im Plural (z. B. user_logins, printer_pages).
  • Produktspezifische Checks sollen den Produktnamen als Präfix haben (z. B. oracle_tablespace).
  • Herstellerspezifische Checkplugins, die sich nicht auf ein bestimmtes Produkt beziehen, sollen mit einem Präfix versehen werden, der den Hersteller wiedergibt (z. B. fsc_ für Fujitsu Siemens Computers).
  • SNMP-basierte Checkplugins, die einen allgemeinen Teil der MIB verwenden, der wohlmöglich von mehr als einem Hersteller unterstützt wird, sollen nach der MIB benannt werden, nicht nach dem Hersteller (z. B. die hr_*-Checkplugins)

3.2. Name des Services

  • Der Name des Services von verschiedenen Checkplugins, die inhaltlich das Gleiche machen, sollen gleich sein, also z. B. immer Interface, wenn es um ein Netzwerkinterfacce geht. Das mach auch das Anlegen von Regeln für den Benutzer einfacher.
  • Für bestimmte Checktypen sind bereits Namensschemata etabliert. Diese müssen verwendet werden.
  • Schreiben Sie nicht FAN sondern Fan. Es ist keine Abkürzung.
  • Abkürzungen werden immer groß geschrieben, also zB. "CPU".
  • Grundsätzlich gilt: Erster Buchstabe groß, der Rest klein, zB. "Bonding interface %s". Ausnahmen sind Eigennamen oder Items.

3.3. Name von Metriken

  • Metriken, für die schon eine sinnvolle Definition existiert, sollen wiederverwendet werden.
  • Ansonsten gelten analoge Regeln wie bei den Namen von Checkplugins (produktspezifisch, herstellerspezifisch, etc.)

3.4. Name der WATO-Regelgruppe

  • Hier gilt das gleiche wie bei den Metriken.

4. Aufbau des Checkplugins

4.1. Genereller Aufbau

Die eigentliche Pythondatei unter share/check_mk/checks/ soll folgenden Aufbau haben (Reihenfolge einhalten):

  1. Dateiheader mit GPL-Hinweis
  2. Name und Emailadresse des ursprünglichen Autors, falls das Plugins nicht vom Check_MK-Projekt selbst entwickelt wurde.
  3. Eine kurze Beispielausgabe des Agenten
  4. Defaultwerte für die Checkparameter (factory_settings)
  5. Hilfsfunktionen, falls vorhanden
  6. Die Parsefunktion, falls vorhanden
  7. Die Discoveryfunktion
  8. Die Checkfunktion
  9. Die check_info-Deklaration

4.2. Coding-Richtlinien

Author

  • Wenn das Plugin nicht vom Check_MK-Team entwickelt wurde, kann der Name und die Emailadresse des Autors hinterlegt werden, direkt nach dem GPL-Header.

Lesbarkeit

  • Vermeiden Sie lange Zeilen. Die maximale erlaubte Länge sind 100 Zeichen.
  • Die Einrückung erfolgt durch jeweil vier Spaces. Verwenden Sie kein Tabulatorzeichen.
  • Orientieren Sie sich am Python-Standard PEP 8

Beispielausgabe des Agenten

Das Hinzufügen einer Beispielausgabe vom Agenten erleichtert das Lesen des Codes ungemein. Dabei ist es wichtig, dass auch verschiedene mögliche Varianten der Ausgabe im Beispiel vorkommen. Machen Sie das Beispiel nicht länger als notwendig. Bei SNMP-basierten Checks geben Sie einen SNMP-Walk an:

# Example excerpt from SNMP data:
# .1.3.6.1.4.1.2.3.51.2.2.7.1.0  255
# .1.3.6.1.4.1.2.3.51.2.2.7.2.1.1.1  1
# .1.3.6.1.4.1.2.3.51.2.2.7.2.1.2.1  "Good"
# .1.3.6.1.4.1.2.3.51.2.2.7.2.1.3.1  "No critical or warning events"
# .1.3.6.1.4.1.2.3.51.2.2.7.2.1.4.1  "No timestamp"

Wenn es z. B. aufgrund verschiedener Firmwarestände des Zielgerätes verschiedene Ausgabeformate gibt, dann geben Sie für jeden ein Beispiel an, mit einem Hinweis auf die Version. Ein gutes Beispiel dafür finden Sie im Checkplugin multipath.

SNMP-MIBs

Bei der Definition des snmp_info soll in Kommentaren der lesbare Pfad zur OID angegeben werden. Beispiel:

    'snmp_info' : [(".1.3.6.1.2.1.47.1.1.1.1", [
        OID_END,
        "2",    # ENTITY-MIB::entPhysicalDescription
        "5",    # ENTITY-MIB::entPhysicalClass
        "7",    # ENTITY-MIB::entPhysicalName
    ]),

Verwendung von lambda

Vermeiden Sie komplizierte Ausdrücke mit lambda. Erlaubt ist lambda bei der Scanfunktion lambda oid: ... und wenn man bestehende Funktionen lediglich mit einem bestimmten geänderten Argument aufrufen möchte, z. B.:

     "inventory_function" : lambda info: inventory_foobar_generic(info, "temperature")

Schleifen über SNMP-Agentendaten

Bei Checks, die in einer Schleife über SNMP-Daten, gehen sollen Sie keine Indizes verwenden wie hier...

    for line in info:
        if line[1] != '' and line[0] ...

Besser ist es, jede Zeile gleich in sinnvolle Variablen auszupacken:

    for sensor_id, state_state, foo, bar in info:
        if sensor_state != '1' and sensor_id ...

Parsefunktionen

Verwenden Sie Parsefunktionen wann immer das Parsen der Agentenausgabe nicht trivial ist. Das Argument der Parsefunktion soll dann immer info heißen und bei der Discovery- und Checkfunktion dann nicht mehr info, sondern parsed. Somit wird dem Leser deutlich, dass dies das Ergebnis der Parsefunktion ist.

Checks mit mehreren Teilresultaten

Ein Check, der in einem Service mehrere Teilzustände liefert (z. B. aktuelle Belegung und Wachstum), muss diese mit yield zurückgeben. Checks, die nur ein Resultat liefert, müssen dies mit return tun.

    if "abs_levels" in params:
        warn, crit = params["abs_levels"]
        if value >= crit:
            yield 2, "...."
        elif value >= warn:
            yield 1, "...."
        else:
            yield 0, "..."

    if "perc_levels" in params:
        warn, crit = params["perc_levels"]
        if percentage >= crit:
            yield 2, "...."
        elif percentage >= warn:
            yield 1, "...."
        else:
            yield 0, "..."

Die Markierungen (!) und (!!) sind veraltet und dürfen nicht mehr verwendet werden. Diese sollen durch yield ersetzt werden.

Schlüssel in check_info[...]

Legen Sie in Ihrem Eintrag in check_info nur solche Schlüssel an, die verwendet werden. Die einzigen verpflichtenden Einträge sind "service_description" und "check_function". Fügen Sie "has_perfdata" und andere Schlüssel mit boolschen Werten nur dann ein, wenn der Wert True ist.

4.3. Agentenplugins

Wenn Ihr Checkplugin ein Agentenplugin benötigt, dann beachten Sie folgende Regeln:

  • Legen Sie das Plugin nach share/check_mk/agents/plugins für Unixartige System und setzen Sie die Ausführungsrechte auf 755.
  • Bei Windows heißt das Verzeichnis share/check_mk/agents/windows/plugins.
  • Shell- und Pythonskripte sollen keine Endung haben (.sh oder .py weglassen).
  • Verwenden Sie bei Shellskripten #!/bin/sh in der ersten Zeilen. Verwenden Sie #!/bin/bash nur dann, wenn Sie Features der BASH brauchen.
  • Fügen Sie den Standard Check_MK-Dateikopf mit dem GPL-Hinweis ein.
  • Ihr Plugin darf auf dem Zielsystem keinerlei Schaden verursachen, vor allem auch dann nicht, wenn das Plugin von dem System eigentlich nicht unterstützt wird.
  • Vergessen Sie den Hinweis auf das Plugin nicht in der Manpage des Checks.
  • Wenn die Komponente, die das Plugin überwacht, auf einem System garnicht existiert, darf das Plugin auch keinen Sektionskopf ausgeben.
  • Wenn das Plugin eine Konfigurationsdatei benötigt, soll es diese (bei Linux) im Verzeichnis $MK_CONFDIR suchen und die Datei soll den gleichen Namen wie das Plugin haben, nur mit der Endung .cfg und ohne ein mögliches mk_ am Anfang. Bei Windows gilt das analog. Das Verzeichnis ist hier %MK_CONFDIR%.
  • Schreiben Sie unter Windows keine Plugins in Powershell. Diese ist nicht portabel und außerdem sehr ressourcenhungrig. Verwenden Sie VBS.
  • Schreiben Sie keine Plugins in Java.

4.4. Verbotene Dinge

  • Verwenden Sie kein import in ihrer Checkdatei. Alle erlaubten Pythonmodule sind bereits importiert.
  • Verwenden Sie zum Parsen und Verrechnung von Zeitangaben nicht datetime sondern time. Das kann alles, was Sie brauchen. Wirklich!
  • Argumente, die eine Ihrer Funktionen übergeben bekommt, darf diese auf keinen Fall modifizieren. Dies gilt insbesondere für params und info.
  • Wenn Sie wirkich mit regulären Ausdrücken arbeiten wollen (diese sind langsam!), so holen Sie sich diese mit der Funktion regex(). Verwenden Sie nicht re direkt.
  • Selbtverständlich dürfen Sie nirgendwo print verwenden, anderweitige Ausgaben nach stdout machen oder sonstirgendwie mit der Außenwelt kommunizieren!
  • Die SNMP-Scanfunktion darf keine OIDs außer .1.3.6.1.2.1.1.1.0 und .1.3.6.1.2.1.1.2.0 holen. Ausnahme: sie hat vorher durch Check einer dieser beiden OIDs sichergestellt, dass weitere OIDs nur einer eng eingegrenzten Zahl von Geräten geholten werden.

5. Verhalten des Checkplugins

5.1. Exceptions

Ihr Checkplugin darf nicht nur sondern soll sogar stets davon ausgehen, dass die Ausgabe des Agenten syntaktisch valide ist. Das Plugin darf auf keinen Fall versuchen, etwaige unbekannte Fehlersituation in der Ausgabe selbst zu behandeln!

Warum? Check_MK hat eine sehr ausgefeilte automatische Behandlung von solchen Fehlern. Es kann für den Benutzer ausführliche Crashreports erzeugen und setzt auch den Zustand des Plugins zuverlässig auf UNKNOWN. Dies ist viel hilfreicher, als wenn der Check z. B. einfacher nur unknown SNMP code 17 ausgibt.

Generell soll die Discovery-, Parse- und/oder Checkfunktion in eine Exception laufen, wenn die Ausgabe des Agenten nicht in dem definierten bekannten Format ist, aufgrund dessen das Plugin entwickelt wurde.

5.2. saveint() und savefloat()

Die Funktionen saveint() und savefloat() konverierten einen String in eine int bzw. float und ergeben eine 0, falls der String nicht konvertierbar ist (z. B. leerer String).

Verwenden Sie diese Funktionen nur dann, wenn der leere bzw. ungültige Wert ein bekannter und erwartbarer Fall ist. Ansonsten würden Sie wichtige Fehlermeldungen damit unterdrücken (siehe oben).

5.3. Nicht gefundenes Item

Ein Check, der das überwachte Item nicht findet, soll einfach None zurückgeben und nicht eine eigene Fehlermeldung dafür generieren. Check_MK wird in diesem Fall eine standardisierte konsistente Fehlermeldung ausgeben und den Service auf UNKNOWN setzen.

5.4. Schwellwerte

Viele Checkplugins haben Parameter, die Schwellwerte für bestimmte Metriken definieren und so festlegen, wann der Check WARN bzw. CRIT annimmt. Bitte beachten Sie dabei die folgenden Regeln, die dafür sorgen, dass sich Check_MK konsistent verhält.

  • Die Schwellen für WARN und CRIT sollen immer mit >= und <= überprüft werden. Beispiel: ein Plugin überwacht die Länge einer Mailqueue. Die kritische obere Schwelle ist 100. Das bedeutet, dass der Wert 100 bereits kritisch ist!
  • Wenn es nur obere oder nur untere Schwellwerte gibt (häufigster Fall), dann sollen die Eingabefelder in WATO mit Warning at ______ und Critical at ______ beschriftet werden.
  • Wenn es obere und untere Schwellwerte gibt, soll die Beschriftung wie folgt lauten: Warning at or above ___, Critical at or above ___, Warning at or below ___ and Critical at or below ___.

5.5. Ausgabe des Checkplugins

Jede Check gibt eine Zeile Text aus - den Pluginoutput. Um ein konsistenten Verhalten von allen Plugins zu erreichen, gelten folgende Regeln:

  • Bei der Anzeige von Messwerten steht genau ein Leerzeichen zwischen dem Wert und der Einheit (z. B. 17.4 V). Die einzige Ausnahme: bei % steht kein Leerzeichen: 89.5%.
  • Bei der Anzeige von Messwerten ist die Bezeichnung des Wertes in Großbuchstaben gefolgt von einem Doppelpunkt. Beispiel: Voltage: 24.5 V, Phase: negative, Flux-Compensator: operational
  • Zeigen Sie im Pluginoutput keine internen Schlüssel, Codewörter, SNMP-Interna oder anderen Müll an, mit dem der Benutzer nichts anfangen kann. Verwenden Sie sinnvolle menschenlesbare Begriffe. Verwenden Sie die Begriffe, die Benutzer üblicherweise erwartet! Beispiel: Verwenden Sie route monitor has failed anstelle von routeMonitorFail.
  • Wenn das Checkitem eine zusätzliche Spezifikation hat, dann setzen Sie diese in eckige Klammern an den Anfang der Ausgabe (z. B. Interface 2 - [eth0] ...)
  • Bei Aufzählungen wird mit einem Komma getrennt und danach mit einem Großbuchstaben fortgesetzt: Swap used: ..., Total virtual memory used: ...

5.6. Defaut-Schwellwerte

Jedes Plugins, das mit Schwellwerten arbeitet, soll sinnvolle Defaultschwellwerte definieren. Dabei gelten folgende Regeln:

  • Die im Check verwendeten Defaultschwellen sollen auch 1:1 in der zugehörigen WATO-Regel als Defaultparameter definiert sein.
  • Die Defaultschwellwerte sollen in factory_settings definiert werden (falls der Check ein Dictionary als Parameter hat).
  • Die Defaultschwellwerte sollen fachlich fundiert gewählt werden. Gibt es vom Hersteller eine Vorgabe? Gibt es best Practices?
  • Im Check muss unbedingt dokumentiert sein woher die Schwellwerte kommen.

5.7. Nagios vs. CMC

Stellen Sie sicher, dass ihr Check auch mit Nagios als Core funktioniert. Meist ist das automatisch der Fall, aber nicht immer.

6. Metriken

6.1. Format der Metriken

  • Die Metrikdaten werden vom Checkplugin immer als int oder float zurückgegeben. Strings sind nicht erlaubt.
  • Wenn Sie in dem Sechstupel von einem Metrikwert Felder auslassen möchten, dann verwenden Sie None an deren Stelle. Beispiel: [("taple_util", utilization, None, None, 0, size)]
  • Wenn Sie Einträge am Ende nicht benötigen, dann kürzen Sie einfach das Tupel. Verwenden Sie kein None am Ende.

6.2. Benennung der Metriken

  • Die Namen von Metriken bestehen aus Kleinbuchstaben und Unterstrichen. Ziffern sind erlaubt, allerdings nicht am Anfang.
  • Die Namen von Metriken sollen analog zu den Checkplugins kurz aber spezifisch benannt sein. Metriken, die von mehreren Plugins verwendet werden, sollen generische Namen haben.
  • Vermeiden das sinnlose Füllwort current. Der Messwert ist ja immer der gerade aktuelle.
  • Die Metrik soll nach dem „Ding“ benannt werden, nicht nach der Einheit. Also z. B. current anstelle von ampere oder size anstelle von bytes.
  • Wichtig verwenden Sie immer die kanonische Größenordnung. Wirklich! Check_MK skaliert die Daten von sich aus sinnvoll. Beispiele:

Domäne kanonische Einheit
Dauer Sekunde
Dateigröße Byte
Temperatur Celsius
Netzwerkdurchsatz Oktette pro Sekunde (nicht Bits/sec!)
Prozentwert Wert von 0 bis 100 (nicht 0.0 bis 1.0)
Ereignisse pro Zeit 1 pro Sekunde
Elektrische Leistung Watt (nicht mW)

6.3. Flag für Metrikdaten

  • Setzen Sie "has_perfdata" in check_info nur genau dann auf True, wenn der Check wirklich Metrikdaten ausgibt (oder ausgeben kann)

6.4. Definition für Graph und Perf-O-Meter

Die Definition für Graphen soll analog zu den Definitionen in web/plugins/metrics/check_mk.py erfolgen. Erzeugen Sie keine Definition für PNP-Graphen. Auch in der Raw Edition werden diese anhand der Metrikdefinition in Check_MK selbst erzeugt.

7. WATO-Definition

7.1. Name der Checkgruppe

Checkplugins mit Parametern erfordern zwingend eine WATO-Regeldefinition. Die Verbindung zwischen Plugin und Regel geht über die Checkgruppe (Eintrag "group" in check_info). Über die Gruppe werden alle Checks zusammengefasst, welche über den gleichen Regelsatz konfiguriert werden.

Falls Ihr Plugin sinnvollerweise mit einem bestehenden Regelsatz konfiguriert werden soll, dann verwenden Sie eine bestehende Gruppe.

Falls Ihr Plugin so spezifisch ist, dass es auf jeden Fall eine eigene Gruppe benötigt, dann legen Sie eine eigenen Gruppe an, wobei der Name der Gruppe einen Bezug zum Plugin haben soll.

Falls abzusehen ist, dass es später noch weitere Plugins mit dem gleichen Regelsatz geben kann, verwenden Sie entsprechend einen generischen Namen.

7.2. Defaultwerte von ValueSpecs

Definieren Sie bei Ihren Parameterdefinition (ValueSpecs) die Defaultwerte genau so, wie die wirklichen Defaults des Checks sind (falls das geht). Beispiel: Wenn der Check ohne Regel die Schwellwerte (5, 10) für WARN und CRIT annimmt, dann soll das ValueSpec so definiert sein, dass automatisch auch 5 und 10 als Schwellen angeboten werden.

7.3. Wahl der ValueSpecs

Für manche Arten von Daten gibt es spezialisierte ValueSpecs. Ein Beispiel ist Age für eine Anzahl von Sekunden. Diese müssen überall da verwendet werden, wo sie sinnvoll sind. Verwenden Sie z. B. nicht Integer in so einem Fall.

8. Include-Dateien

Für etliche Arten von Checks gibt es bereits fertige Implementierungen in Includedateien, die Sie nicht nur verwenden können, sondern sollen. Wichtige Includedateien sind:

temperature.include Überwachung von Temperaturen
elphase.include Elektrische Wechelstromphase (z. B. bei USV)
fan.include Lüfter
if.include Netzwerkschnittstellen
df.include Füllstände von Dateisystemen
mem.include Überwachung von RAM (Hauptspeicher)
ps.include Prozesse eines Betriebssystems

Wichtig: verwenden Sie vorhanden Includedateien nur dann, wenn diese für den jeweiligen Zweck auch gedacht sind und nicht nur wenn diese so ungefähr passen!

9. Manpages

Jedes Checkplugin muss eine Manpage haben. Falls Sie in einer Checkdatei mehrere Plugins programmiert haben (Subchecks) muss natürlich jedes davon eine eigene Mangpage haben.

Die Manpage ist für den Anwender gedacht! Schreiben Sie Informationen, die diesem helfen. Es geht nicht darum, zu dokumentieren, was Sie programmiert haben, sondern darum, dass der Anwender die für ihn wichtigen nützlichen Informationen bekommt.

Die Manpage muss sein:

  • vollständig
  • präzise
  • knapp
  • hilfreich!

9.1. Katalogeintrag

Über den Header catalog: legen Sie fest, wo im Katalog der Checkmanpages das Plugin einsortiert wird. Falls eine Kategorie fehlt (z. B. ein neuer Hersteller) so muss dieser in der Datei cmk/man_pages.py in der Variable catalog_titles definiert werden.

Beachten Sie die genaue Groß-/Kleinschreibung von Produkt- und Firmennamen! Das gilt nicht nur für den Katalogeintrag, sondern auch für alle anderen Texte, wo diese vorkommen. Beispiel: NetApp wird immer NetApp geschrieben und nicht netapp, NETAPP, Netapp, oder dergleichen. Google hilft, die richtige Schreibung zu finden!

9.2. Description

Folgende Informationen müssen in der description: der Manpage enthalten sein:

  • Welche Hard- oder Software überwacht der Check genau? Gibt es Sonderheiten von bestimmten Firmware- oder Produktversionen der Geräte? Beziehen Sie sich dabei nicht auf eine MIB, sondern auf Produktbezeichnungen. Beispiel: Dem Nutzer ist nicht geholfen, wenn Sie schreiben „Dieser Check funktioniert bei allen Geräten, welche die Wrdpfrmpft-17.11-MIB unterstützen". Schreiben Sie, welche Produktlinien oder dergleichen unterstützt werden.
  • Welcher Aspekt davon wird überwacht? Was macht der Check?
  • Unter welchen Bedingungen wird der Check OK, WARN oder CRIT?
  • Wird für den Check ein Agentenplugin benötigt? Falls ja: wie wird dieses installiert? Das muss auch ohne Agentbakery gehen.
  • Gibt es weitere Voraussetzungen, damit der Check funktioniert (Vorbereitung des Zielsystems, Installation von Treibern, etc.). Diese sollen nur dann aufgeführt werden, wenn Sie nicht sowieso normalerweise erfüllt sind (z. B. Mounten von /proc unter Linux).

Schreiben Sie nichts, was alle Checks ingesamt betrifft. Wiederholen Sie z. B. nicht generelle Dinge, wie man SNMP-basierte Checks einrichtet.

9.3. Discovery

Schreiben Sie unter inventory: unter welchen Bedingungen der Service bzw. die Services dieses Checks automatisch gefunden werden. Beispiel aus nfsmounts:

nfsmounts
inventory:
  All NFS mounts are found automatically. This is done
  by scanning {/proc/mounts}. The file {/etc/fstab} is irrelevant.

9.4. Item

Bei Checks, die ein Item haben (also auch ein %s im Servicenamen), muss in der Manpage unter item: beschrieben sein, wie dieses gebildet wird.