Checkmk
English
masterlatest (2.3.0)2.2.02.0.01.6.0
to checkmk.com

1. Einleitung

Ein großer Vorteil von Checkmk gegenüber vielen anderen Monitoringsystemen ist die große Zahl von gut gepflegten mitgelieferten Check-Plugins. 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 Checkmk 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 Check-Plugins, die offiziell Teil von Checkmk 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 Check-Plugins

Jedes Check-Plugin muss mindestens folgende Komponenten umfassen:

  • Das Check-Plugin 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 Check-Plugins

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 werden im Plural (z.B. user_logins, printer_pages) benannt.

  • Produktspezifische Checks sollen den Produktnamen als Präfix haben (z.B. oracle_tablespace).

  • Herstellerspezifische Check-Plugins, die sich nicht auf ein bestimmtes Produkt beziehen, sollen mit einem Präfix versehen werden, das den Hersteller wiedergibt (z.B. fsc_ für Fujitsu Siemens Computers).

  • SNMP-basierte Check-Plugins, die einen allgemeinen Teil der MIB verwenden, der womöglich von mehr als einem Hersteller unterstützt wird, sollen nach der MIB benannt werden, nicht nach dem Hersteller (z.B. die hr_*-Check-Plugins)

3.2. Name des Services

  • Benutzen Sie bekannte, gut abgegrenzte Abkürzungen (z.B. CPU, DB, VPN, IO,…).

  • Schreiben Sie Abkürzungen in Großbuchstaben.

  • Verwenden Sie Groß- und Kleinschreibung wie in natürlichen englischen Sätzen (z.B. CPU utilization, nicht Cpu Utilization) — Eigennamen sind eine Ausnahme.

  • Verwenden Sie für Produktnamen die Schreibweise des Herstellers (z.B. vSphere).

  • Nutzen Sie amerikanisches Englisch (z.B. utilization, nicht utilisation).

  • Folgen Sie Namenskonventionen, sofern diese existieren. So sollten alle Services für Interfaces das Template "Interface %s" nutzen.

  • Halten Sie Beschreibungen kurz, denn Service-Namen werden in Dashboards, Views und Reports abgeschnitten, wenn diese zu lang sind.

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 Check-Plugins (produktspezifisch, herstellerspezifisch, etc.)

3.4. Name der WATO-Regelgruppe

  • Hier gilt das gleiche wie bei den Metriken.

4. Aufbau des Check-Plugins

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 E-Mail-Adresse des ursprünglichen Autors, falls das Plugins nicht vom Checkmk-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

Autor

  • Wenn das Plugin nicht vom Checkmk-Team entwickelt wurde, kann der Name und die E-Mail-Adresse 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 Check-Plugin 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 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 liefern, 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 Check-Plugin ein Agentenplugin benötigt, dann beachten Sie folgende Regeln:

  • Legen Sie das Plugin nach share/check_mk/agents/plugins für unixartige Systeme 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 Checkmk-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 gar nicht 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. Dieses 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 zur 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 wirklich 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 von einer eng eingegrenzten Zahl von Geräten geholten werden.

5. Verhalten des Check-Plugins

5.1. Exceptions

Ihr Check-Plugin 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 Fehlersituationen in der Ausgabe selbst zu behandeln!

Warum? Checkmk 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. einfach 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() konvertieren 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. Checkmk wird in diesem Fall eine standardisierte konsistente Fehlermeldung ausgeben und den Service auf UNKNOWN setzen.

5.4. Schwellwerte

Viele Check-Plugins 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 Checkmk 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 Check-Plugins

Jeder 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 geschrieben, 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 erwarten! 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. Default-Schwellwerte

Jedes Plugin, 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 Check-Plugin 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 Check-Plugins kurz aber spezifisch benannt sein. Metriken, die von mehreren Plugins verwendet werden, sollen generische Namen haben.

  • Vermeiden Sie 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! Checkmk 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 Definitionen für PNP-Graphen. Auch in der Raw Edition werden diese anhand der Metrikdefinition in Checkmk selbst erzeugt.

7. WATO-Definition

7.1. Name der Checkgruppe

Check-Plugins 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 eigene 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 Parameterdefinitionen (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 vorhandene Includedateien nur dann, wenn diese für den jeweiligen Zweck auch gedacht sind und nicht, wenn diese nur so ungefähr passen!

9. Manpages

Jedes Check-Plugin muss eine Manpage haben. Falls Sie in einer Checkdatei mehrere Plugins programmiert haben (Subchecks) muss natürlich jedes davon eine eigene Manpage 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!

Eine Manpage besteht aus mehreren, teilweise optionalen, Bereichen:

9.1. Titel

mit dem Makro title: bestimmen Sie die Überschrift. Sie besteht aus:

  • Dem exakten Gerätenamen oder der Gerätegruppe, für welche der Check geschrieben ist

  • Was der Check überwacht (z.B. System Health)

Diese beiden Teile werden mit einem Doppelpunkt voneinander getrennt. Nur auf diese Weise können bestehende Checks leicht durchsucht und vor allem auch gefunden werden.

9.2. Agenten-Kategorien

Das Makro agents: kann verschiedene Kategorien haben. Grundsätzlich werden drei Bereiche unterschieden:

  • Agenten: In diesem Fall werden die Betriebssysteme angegeben, für welche der Check gebaut wurde und zur Verfügung steht. Zum Beispiel linux oder linux, windows, solaris

  • SNMP: In diesem Fall gibt es nur den Eintrag snmp

  • Aktive Checks: Wenn ein aktiver Check in die Oberfläche von Checkmk integriert wurde, nehmen Sie die Kategorie active

9.3. 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 — bzw. seit Version 1.6.0 in der Datei cmk/utils/man_pages.py.

Aktuell kann diese Datei nicht über Plugins in local/ erweitert werden, so dass Änderungen hier nur die Entwickler von Checkmk machen können.

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, in denen diese vorkommen. Beispiel: NetApp wird immer NetApp geschrieben und nicht netapp, NETAPP, Netapp, oder dergleichen. Google hilft, die richtige Schreibung zu finden!

9.4. Beschreibung des Plugins

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

  • Welche Hard- oder Software überwacht der Check genau? Gibt es Besonderheiten 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 Agent Bakery 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.5. 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. Wenn das Checkplugin kein Item benutzt, können Sie diese Zeile komplett auslassen.

9.6. Service-Erkennung

Schreiben Sie unter inventory: unter welchen Bedingungen der Service bzw. die Services dieses Checks automatisch gefunden werden, also wie sich die "Service Discovery" verhält. Beispiel aus nfsmounts:

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

Achten Sie darauf, dass der Text ohne tiefere Kenntnisse einer MIB oder des Codes verständlich ist. Schreiben Sie also nicht:

One service is created for each temperature sensor, if the state is 1.

Stattdessen ist es besser, möglichst alles zu übersetzen:

One service is created for each temperature sensor, if the state is "active".
Auf dieser Seite