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_statusist 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
statusoderstatehat im Namen nichts verloren, denn schließlich überwacht jedes Plugin einen Status. Gleiches gilt für das überflüssige Wortcurrent. Verwenden Sie also anstelle vonfoobar_current_temp_statuseinfach nurfoobar_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):
Dateiheader mit GPL-Hinweis
Name und E-Mail-Adresse des ursprünglichen Autors, falls das Plugins nicht vom Checkmk-Projekt selbst entwickelt wurde.
Eine kurze Beispielausgabe des Agenten
Defaultwerte für die Checkparameter (
factory_settings)Hilfsfunktionen, falls vorhanden
Die Parsefunktion, falls vorhanden
Die Discoveryfunktion
Die Checkfunktion
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/pluginsfür unixartige Systeme und setzen Sie die Ausführungsrechte auf755.Bei Windows heißt das Verzeichnis
share/check_mk/agents/windows/plugins.Shell- und Pythonskripte sollen keine Endung haben (
.shoder.pyweglassen).Verwenden Sie bei Shellskripten
!/bin/shin der ersten Zeilen. Verwenden Sie!/bin/bashnur 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_CONFDIRsuchen und die Datei soll den gleichen Namen wie das Plugin haben, nur mit der Endung.cfgund ohne ein möglichesmk_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
importin Ihrer Checkdatei. Alle erlaubten Pythonmodule sind bereits importiert.Verwenden Sie zum Parsen und zur Verrechnung von Zeitangaben nicht
datetimesonderntime. 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
paramsundinfo.Wenn Sie wirklich mit regulären Ausdrücken arbeiten wollen (diese sind langsam!), so holen Sie sich diese mit der Funktion
regex(). Verwenden Sie nichtredirekt.Selbtverständlich dürfen Sie nirgendwo
printverwenden, anderweitige Ausgaben nachstdoutmachen oder sonstirgendwie mit der Außenwelt kommunizieren!Die SNMP-Scanfunktion darf keine OIDs außer
.1.3.6.1.2.1.1.1.0und.1.3.6.1.2.1.1.2.0holen. 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: operationalZeigen 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 failedanstelle vonrouteMonitorFail.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_settingsdefiniert 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
intoderfloatzurückgegeben. Strings sind nicht erlaubt.Wenn Sie in dem Sechstupel von einem Metrikwert Felder auslassen möchten, dann verwenden Sie
Nonean 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
Noneam 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.
currentanstelle vonampereodersizeanstelle vonbytes.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"incheck_infonur genau dann aufTrue, 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
linuxoderlinux, windows, solarisSNMP: In diesem Fall gibt es nur den Eintrag
snmpAktive 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
/procunter 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:
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".