Einen Custom-Script-Check konfigurieren

Ein Custom-Script-Check führt ein von dir geschriebenes Skript aus — PowerShell unter Windows, bash unter Linux und macOS — in einem festen Intervall und meldet ein Ergebnis an octoja zurück. Verwende ihn, wenn keiner der eingebauten Checks zu dem passt, was du überwachen möchtest. Du baust den Check einmal unter Konfiguration → Check-Bibliothek; danach erscheint er neben den eingebauten Checks, wenn du Checks einem agentenverwalteten Gerät zuweist. Für ein Netzwerkgerät braucht er einen zusätzlichen Parameter — siehe Den Check für Netzwerkgeräte verfügbar machen weiter unten.

Bevor du beginnst

• Du benötigst Monitoring-Check-Verwaltung für die Check-Bibliothek und zusätzlich Verwaltung benutzerdefinierter Checks, um einen eigenen Check anzulegen oder zu bearbeiten.
• Monitoring-Check-Verwaltung ist auch für die Live-Test-Leiste des Editors (Schritt 8) und das Zuweisen des Checks an ein Gerät (Schritt 10) erforderlich.
• Du brauchst ein Zielgerät, auf dem der Agent installiert und verbunden ist. Bei einem Netzwerkgerät — einem Switch, Router oder einer Firewall ohne eigenen Agenten — ist das sein Überwachungsgerät, also der Agent, der es für dich abfragt.
• Unter Linux benötigt der Skript-Wrapper des Agents jq zum Lesen der Parameter und zum Serialisieren der Ausgabe. Der Linux-Installer des Agents installiert jq für dich, auf einer aktuellen Installation ist es also bereits vorhanden; von Hand nachinstallieren musst du es nur auf Agents, die davor installiert wurden, oder wenn der Installer keinen unterstützten Paketmanager gefunden hat. Unter macOS nutzt der Wrapper das eingebaute osascript, dort ist also nichts zu installieren.
• Jedes weitere Tool, das dein Skript aufruft (zum Beispiel awk, bc), muss ebenfalls auf dem Zielgerät installiert sein — der Agent bringt skript-seitige Abhängigkeiten nicht selbst mit.

Schritte

1. Öffne Konfiguration → Check-Bibliothek in der Seitenleiste. Mit Nur eigene Checks findest du vorhandene eigene Checks; ein Klick öffnet ihren Editor. Repository-Verbindungen und Repository-Zugriffe verwaltest du unter Einstellungen, nicht im Check-Editor.
2. Klicke auf Neuer Check.
3. Gib einen Namen ein. octoja leitet daraus automatisch eine eindeutige Check-ID ab. Optional kannst du unter Klonen von einen bestehenden Check als Kopiervorlage wählen. Klicke auf Check erstellen.
4. Lasse im Tab Allgemein den Modus auf Erweitertes Skript (die Alternative Einfaches SNMP ersetzt die Skript-Tabs durch einen SNMP-Editor; siehe den Abschnitt unten). Setze Beschreibung, Symbol, Kategorie, Tags, das Check-Intervall in Minuten — Standard 5, erlaubter Bereich 5–1440 — und das Timeout in Minuten, also die maximale Dauer eines einzelnen Laufs (Standard 5, erlaubter Bereich 5 Sekunden bis 60 Minuten).
5. Öffne den Tab Skript. Füge für jede Plattform, die du unterstützen möchtest (Windows / Linux / macOS), dein Skript ein — Beispiele weiter unten. Plattformen ohne Skript stehen nicht zur Zuweisung bereit. Schreibe nur deine Check-Logik: Der Agent ergänzt die Ein-/Ausgabe-Behandlung automatisch.
6. Öffne den Tab Parameter und definiere alle Eingabeparameter, die dein Skript benötigt (Schlüssel, Typ, Beschriftungen, Pflichtfeld, Standardwert). Sie erscheinen als konfigurierbare Felder, sobald der Check einem Gerät zugewiesen wird. Soll der Check auch auf Netzwerkgeräten auswählbar sein, muss einer davon ein Host- oder Ziel-Parameter sein — siehe Den Check für Netzwerkgeräte verfügbar machen weiter unten.
7. Öffne den Tab Ausgabe-Schema und deklariere die Felder, die dein Skript schreibt — Schlüssel, Typ, Einheit und Label. Über die Tabs Detail-Layout und Verlaufs-Layout legst du fest, wie diese Felder auf dem Checks-Tab des Geräts angezeigt werden.
8. Nutze die Live-Test-Leiste oben im Editor: Wähle ein verbundenes Gerät aus und klicke auf Ausführen. Definiert der Check Parameter, öffnet sich zuerst der Dialog Testeingabe — fülle ihn aus und klicke auf Test starten. Anschließend zeigt ein Badge den Check-Status — OK, Warnung, Kritisch oder Fehlgeschlagen — samt Laufzeit in Millisekunden; klicke darauf, um die Details der Testausführung zu öffnen (Testausführung erfolgreich bzw. Testausführung fehlgeschlagen) — mit Prüfergebnis, der Rohausgabe des Skripts, etwaigen Fehlern und der Geparsten Ausgabe — ohne auf ein Check-Intervall zu warten.
9. Klicke auf Speichern.
10. Weise den Check zu: Gehe zu Geräte, öffne das Zielgerät, klicke auf den Tab Checks → Check hinzufügen, wähle deinen eigenen Check aus (er erscheint neben den eingebauten Checks — bei einem Netzwerkgerät nur, wenn er einen Host-Parameter deklariert), fülle die von dir definierten Parameter aus und klicke auf Check hinzufügen.

Alternative: SNMP-Werte ohne Alarmregeln erfassen

Wenn du nur SNMP-OIDs abfragen möchtest, wähle im Tab Allgemein den Modus Einfaches SNMP statt eines Skripts. Lege im SNMP-Editor die OIDs mit Ausgabefeld und Werttyp an. Warn- und Kritisch-Schwellen für Zahlen sowie Textmuster für Zeichenketten sind optional: Lasse sie leer, um einen Wert nur anzuzeigen oder in ein eigenes Feld zu schreiben, ohne ihn gegen Alarmregeln zu prüfen. Fehlende OIDs, Abfragefehler oder ein nicht numerischer Wert für eine numerische OID bleiben Fehler. Prüfe die Ausgabe mit Live-Test, speichere den Check und weise ihn dem Zielgerät zu.

Das Ergebnis setzen

Dein Skript meldet seinen Status, indem es checkResult in der Ausgabe setzt — $output.checkResult in PowerShell, set_result in bash. Der Startwert ist 0 (OK); ein Skript, das nichts setzt, meldet also OK. Der Agent ordnet den Wert so zu:

Hinweis: Du kannst den Status auch per Name statt per Zahl setzen: $output.checkResult = "Critical" (PowerShell) oder set_result Critical (bash) — der Agent akzeptiert die Statusnamen Success, Warning, Critical und Failure.

Wie der Agent dein Skript ausführt

Diese Details brauchst du nicht, um einen Check zu bauen — aber sie erklären, was dich erwartet:

• Der Agent lädt dein Skript inklusive des Ein-/Ausgabe-Wrappers vom Webservice herunter, speichert es als Datei und führt es mit powershell -ExecutionPolicy Bypass -File unter Windows bzw. bash unter Linux und macOS aus.
• Das Skript läuft mit den Rechten des Agent-Dienstes: als SYSTEM unter Windows und als root unter Linux und macOS.
• Die bei der Zuweisung konfigurierten Parameter werden dem Skript über die Standardeingabe übergeben; du liest sie über $checkInput (PowerShell) oder get_input (bash).
• Der Status kommt aus dem checkResult-Wert deiner Ausgabe — nicht aus Text, den dein Skript ausgibt, und nicht aus dem Exit-Code. Alles andere, was auf stdout landet, wird ignoriert.
• Ein Exit-Code ungleich Null lässt den Check Fehlgeschlagen melden und verwirft die gesamte strukturierte Ausgabe — unabhängig davon, welchen Status oder welche Felder das Skript zuvor gesetzt hat.
• Jeder Lauf wird gestoppt, sobald er das Timeout des Checks überschreitet (Tab Allgemein) — Standard 5 Minuten, bis auf 60 Minuten erhöhbar — und der Check meldet Fehlgeschlagen.
• Ausgaben bis 1 MB werden vollständig als aktuelles Ergebnis des Checks gespeichert, die aktuellen Werte werden also immer angezeigt. Begrenzt ist nur die historisierte Kopie: Ein Ergebnis, dessen Ausgabe größer als 16 KB ist, wird im Verlauf des Checks nur als Status abgelegt. Oberhalb von 1 MB behält das Ergebnis seinen Status, aber die Feldwerte werden verworfen und es wird als gekürzt markiert.

Der vollständige Eingabe-, Ausgabe- und Helper-Vertrag ist in der unten verlinkten Custom-Script-Check-Referenz dokumentiert.

PowerShell (Windows)

Der Wrapper stellt $checkInput (die geparsten Eingabeparameter) und $output (eine Hashtable, vorbelegt mit checkResult = 0) bereit. Schreibe deine Ergebnisse in $output. Achtung: Die Variable heißt $checkInput, nicht $input — $input ist eine reservierte automatische PowerShell-Variable.

# Einen Eingabeparameter lesen (im Tab Parameter definiert)
$threshold = $checkInput.threshold

# Arbeit erledigen
$cpuLoad = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue

# Ergebnisse in $output schreiben
$output["cpuLoad"] = [math]::Round($cpuLoad, 1)
if ($cpuLoad -ge $threshold) {
    $output["checkResult"] = 2  # Kritisch
    $output["message"] = "CPU-Auslastung $cpuLoad% überschreitet Schwellenwert $threshold%"
} elseif ($cpuLoad -ge ($threshold * 0.8)) {
    $output["checkResult"] = 1  # Warnung
} else {
    $output["checkResult"] = 0  # OK
}

Bash (Linux)

Der Wrapper stellt drei Helper bereit (alle benötigen jq auf dem Gerät):

• get_input "key" — einen Eingabeparameter lesen.
• set_output "key" value — ein Ausgabefeld setzen.
• set_result 0|1|2 — Kurzform für checkResult (0 = OK, 1 = Warnung, 2 = Kritisch).

THRESHOLD=$(get_input "threshold")
LOAD=$(uptime | awk -F'load average:' '{print $2}' | awk -F',' '{print $1}' | xargs)
set_output "loadAverage" "$LOAD"
if (( $(echo "$LOAD > $THRESHOLD" | bc -l) )); then
    set_result 2   # Kritisch
    set_output "message" "Load Average $LOAD überschreitet Schwellenwert $THRESHOLD"
else
    set_result 0   # OK
fi

Bash (macOS)

Unter macOS verwendet der Agent einen separaten Wrapper, der dieselben Helper bereitstellt — get_input, set_output, set_result —, aber auf dem in macOS eingebauten osascript statt auf jq aufbaut und bash-Funktionen vermeidet, die das mit macOS ausgelieferte bash 3.2 nicht unterstützt. Auf dem Mac muss dafür nichts zusätzlich installiert werden. Dein Skript-Code sieht genauso aus wie im Linux-Beispiel oben.

Wenn du kein macOS-spezifisches Skript hinterlegst, führt der Agent dein Linux-Skript auch auf macOS aus. Das funktioniert für portables bash, scheitert aber, sobald du auf ein Linux-spezifisches Tool angewiesen bist.

Den Check für Netzwerkgeräte verfügbar machen

Ein Netzwerkgerät, das du ohne Agent-Installation hinzugefügt hast — ein Switch, ein Router oder eine Firewall —, hat keinen eigenen Agenten. Seine Checks laufen auf dem Überwachungsgerät, das du beim Hinzufügen des Geräts ausgewählt hast: Dieser Agent fragt das Gerät über das Netzwerk ab, und Ergebnis und Verlauf bleiben beim Netzwerkgerät. Derselbe Filter gilt für die eingebauten Checks, weshalb der Katalog eines Netzwerkgeräts deutlich kürzer ist als der eines agentenverwalteten Geräts. Auch ein Custom-Script-Check kann ein Netzwerkgerät überwachen — aber nur, wenn du ihn dafür baust.

Einen Host- oder Ziel-Parameter deklarieren

octoja bietet einen eigenen Check für ein Netzwerkgerät nur dann an, wenn der Check einen Parameter vom Typ Text deklariert, dessen Schlüssel host, ip, ipaddress, target, url, endpoint oder address lautet. Die Groß- und Kleinschreibung des Schlüssels spielt keine Rolle, Host und ipAddress zählen also ebenfalls.

Der Schlüssel muss exakt passen — targetHost, firewallIp und andere Namen, die einen der Schlüssel nur enthalten, zählen nicht. Vorsicht bei der Hilfe des Editors selbst: Der Tab Skript nennt als Beispiel-Parameter $checkInput.targetHost — und ausgerechnet targetHost erkennt der Netzwerkgeräte-Filter nicht.

Kein anderer Typ zählt: nicht Number, nicht Password, nicht Dropdown, nicht Toggle und auch nicht Tag List. Ein hosts-Parameter vom Typ Tag List sieht so aus, als müsste er funktionieren, funktioniert aber nicht: Die Tag List des Editors hält nicht fest, dass ihre Einträge Text sind — und genau darauf achtet der Filter für Netzwerkgeräte. Nimm stattdessen einen einzelnen Text-Parameter.

Dieser Parameter ist das Signal, dass der Check ein entferntes Ziel abfragt. Ein Check ohne ihn erscheint im Dialog Check hinzufügen eines Netzwerkgeräts überhaupt nicht — er fehlt schlicht, ohne Meldung und ohne ausgegrauten Eintrag. Auch der Tab Parameter weist nicht darauf hin, dass der Schlüssel eine Rolle spielt. Denk deshalb zuerst an diese Regel, wenn sich ein gerade gebauter Check auf einer Firewall nicht auswählen lässt.

Den Parameter musst du nicht selbst ausfüllen. Auf einem Netzwerkgerät blendet octoja das Feld aus und trägt die IP-Adresse des Geräts ein, sobald der Check an den Agenten übergeben wird — wo sonst das Feld stünde, zeigt der Dialog Dieser Check läuft automatisch gegen die IP des Geräts. Dein Skript liest den Parameter wie jeden anderen, mit $checkInput.host oder get_input "host". Änderst du später die IP des Geräts, übernimmt der Check sie beim nächsten Abgleich der Zuweisungen, also innerhalb von etwa einer halben Stunde.

Über ein Konfigurationspaket läuft das anders. Der Katalog des Pakets wird überhaupt nicht gefiltert, ein Check ohne Host-Parameter lässt sich also auch einem Paket hinzufügen, das nur auf Firewalls passt — er wird zugewiesen und ausgeführt, und weil ihn nichts auf das Gerät richtet, meldet er unbemerkt das Überwachungsgerät. Dort bleibt der Host-Parameter sichtbar und ist als optional markiert: Lässt du ihn leer, trägt octoja die Adresse des jeweils passenden Netzwerkgeräts ein, sobald der Check an dessen Agenten übergeben wird. Bei einem agentenverwalteten Gerät, auf das dasselbe Paket passt, geschieht das nicht — dort bleibt ein leeres Host-Feld leer.

Einen Parameter ergänzen statt umbenennen

Wenn dein Check bereits einen Parameter für das Ziel hat — etwa firewallAddress —, benenne ihn nicht in ip um, nur damit die Regel erfüllt ist. octoja belegt jeden Parameter, der zugleich auf der Schlüsselliste steht und vom Typ Text ist: Auf einem Netzwerkgerät wird das Feld ausgeblendet und sein Wert durch die IP-Adresse des Geräts ersetzt — was du vorher darüber übergeben hast, geht damit verloren. Der Check läuft und meldet weiterhin, und genau das macht es leicht, den Fehler zu übersehen.

Lege stattdessen einen zusätzlichen host-Parameter neben deinen eigenen an. Der Check funktioniert dann auf beiden Gerätearten — bei einem Netzwerkgerät füllt octoja host für dich aus, bei einem agentenverwalteten Gerät füllst du ihn selbst aus.

Das Gerät aus deinem Skript heraus erreichen

octoja übergibt deinem Skript die Adresse des Geräts, nimmt dir den Zugriff darauf aber nicht ab. Alles, was der Check misst, muss dein Skript selbst über das Netzwerk von dieser Adresse holen. Die Beispiele weiter oben lesen die Maschine aus, auf der das Skript läuft — kopierst du eines davon in einen Check für ein Netzwerkgerät, meldet er die CPU-Auslastung oder die Last des Überwachungsgeräts unter dem Namen der Firewall. Der Check wird grün und sagt dir nichts über die Firewall. Nutze den Host-Parameter in jedem Befehl, der Werte abruft.

Ein Beispiel: einen Wert über SNMP lesen

Deklariere einen Text-Parameter host und einen Text-Parameter community — beide füllt octoja bei einem Netzwerkgerät für dich aus — und erreiche das Gerät dann über den Helper Get-Snmp des Wrappers, der die angefragten OIDs als Nachschlagetabelle zurückgibt:

# 1.3.6.1.2.1.1.3.0 ist sysUpTime, in Hundertstelsekunden
$oid  = '1.3.6.1.2.1.1.3.0'
$snmp = Get-Snmp -TargetHost $checkInput.host -Community $checkInput.community -Oid $oid
$uptimeHours = [math]::Round([double]$snmp[$oid] / 360000, 1)

$output["uptimeHours"] = $uptimeHours
if ($uptimeHours -lt 1) {
    $output["checkResult"] = 1  # Warnung — das Gerät ist in der letzten Stunde neu gestartet
    $output["message"] = "Firewall vor $uptimeHours h neu gestartet"
}

In bash lautet derselbe Aufruf snmp_get --host "$(get_input "host")" --community "$(get_input "community")" 1.3.6.1.2.1.1.3.0. Beide Helper laufen über den mitgelieferten SNMP-Worker des Agents; die vollständige Helper-Referenz steht in der unten verlinkten Custom-Script-Check-Referenz.

SNMP-Zugangsdaten kommen vom Gerät

Deklariert dein Check einen Parameter namens community, v3User, authPassword oder privPassword, übernimmt octoja seinen Wert aus den auf dem Netzwerkgerät hinterlegten SNMP-Einstellungen — zusammen mit jedem version-, snmpVersion-, authProtocol-, privProtocol-, port- oder snmpPort-Parameter, den der Check deklariert. So musst du die Zugangsdaten nicht für jedes Gerät erneut eingeben. Mindestens einer dieser vier Zugangsdaten-Schlüssel muss vorhanden sein: Ein Check, der nur port oder version deklariert, bleibt unangetastet.

Übernommen wird nur, was das Gerät tatsächlich gespeichert hat. Ein Gerät, das über TR-064 angebunden ist oder bei dem SNMP ausgeschaltet ist, liefert nichts — dort gelten deine eingetragenen Werte. Und auf einem v2c-Gerät, das nur eine Community speichert, behält ein deklariertes authPassword ebenfalls das, was du eingetragen hast.

Diese Felder verhalten sich anders als der Host-Parameter. Sie bleiben im Dialog Check hinzufügen sichtbar und bearbeitbar, und der Checks-Tab des Geräts zeigt weiterhin das an, was du eingetragen hast — der Lauf verwendet aber das, was auf dem Gerät gespeichert ist. Verwende diese Schlüsselnamen deshalb für nichts anderes.

Die Skript-Plattform auf das Überwachungsgerät abstimmen

Da das Skript auf dem Überwachungsgerät läuft, braucht der Check ein Skript für das Betriebssystem dieses Agenten — nicht für das Netzwerkgerät, das selbst nie etwas ausführt.

Der Katalog eines Netzwerkgeräts filtert nicht nach Plattform, denn das Gerät hat kein Betriebssystem, nach dem sich filtern ließe. Ein reiner Windows-Check wird deshalb auch für eine Firewall angeboten, deren Überwachungsgerät unter Linux läuft — und liefert nach der Zuweisung überhaupt kein Ergebnis: Der Agent verwirft die Zuweisung, sobald er seine Check-Liste lädt, und am Check selbst ist davon nichts zu sehen. Vergleiche die Plattform-Badges neben jedem Check im Katalog mit dem Betriebssystem des Überwachungsgeräts, bevor du ihn zuweist, und ergänze im Tab Skript ein Skript für diese Plattform.

Den Check auf dem Netzwerkgerät testen

Wähle in der Live-Test-Leiste des Editors das Netzwerkgerät selbst aus. octoja leitet das Skript an dessen Überwachungsgerät weiter, wählt die Skript-Variante nach dem Betriebssystem dieses Agenten und trägt in den Host-Parameter die IP-Adresse des Geräts ein — ein grüner Live-Test auf dem Netzwerkgerät bestätigt damit Parameter, Plattform und Skript in einem Schritt. Du brauchst dafür die Berechtigung, Skripte sowohl auf dem Netzwerkgerät als auch auf seinem Überwachungsgerät auszuführen. Die Auswahl listet nur Geräte, die online sind — ein Netzwerkgerät, dessen Online-Status-Check gerade fehlschlägt, taucht dort nicht auf.

Was du nicht tun solltest

Troubleshooting

Der Check zeigt Fehlgeschlagen mit einer Fehlermeldung. Das Skript hat sich mit einem Exit-Code ungleich Null beendet, einen Fehler geworfen, oder auf einem Linux-Gerät fehlt jq — der Check meldet dann, dass jq nicht installiert ist. Der Linux-Installer des Agents installiert jq automatisch; auf einem Agent, der davor installiert wurde, ergänzt du es mit apt install jq oder dnf install jq. Führe das Skript über die Live-Test-Leiste des Editors aus: Die Fehlerausgabe erscheint unter Fehler in den Details der Testausführung.

Der Check zeigt OK, obwohl du Warnung oder Kritisch erwartet hast. Wahrscheinlich hast du vergessen, $output["checkResult"] (PowerShell) zu setzen oder set_result (bash) aufzurufen — der Standard ist 0 / OK. Prüfe außerdem die Werte: 1 ist Warnung und 2 ist Kritisch.

Der Check meldet Fehlgeschlagen, nachdem er lange gelaufen ist. Das Skript hat das Timeout des Checks überschritten (Tab Allgemein, Standard 5 Minuten). Erhöhe das Timeout — auf bis zu 60 Minuten —, mache das Skript schneller oder teile es in mehrere kleinere Checks auf.

Das Dashboard zeigt den Status, aber keine Werte. Die Feldschlüssel, die dein Skript schreibt, müssen den im Tab Ausgabe-Schema deklarierten Schlüsseln entsprechen, und sehr große Ausgaben (über 1 MB) werden auf den Status gekürzt. Im Verlauf des Checks werden Ergebnisse über 16 KB nur als Status abgelegt, ein vergangener Lauf kann also einen Status ohne Werte anzeigen.

Der Check lässt sich auf einem Netzwerkgerät nicht auswählen. Der Check deklariert keinen Host- oder Ziel-Parameter und wird deshalb aus dem Dialog Check hinzufügen für Netzwerkgeräte herausgefiltert. Lege im Tab Parameter einen an: einen Parameter vom Typ Text mit dem Schlüssel host — exakt dieser Schlüssel, nicht eine Annäherung wie targetHost. Stimmt der Schlüssel bereits, prüfe den Typ — nur Text zählt, Tag List nicht.

Der Check ist einem Netzwerkgerät zugewiesen, liefert aber nie ein Ergebnis. Der Check hat kein Skript für das Betriebssystem, unter dem das Überwachungsgerät läuft — etwa ein reiner PowerShell-Check, der über ein Linux-Überwachungsgerät ausgeführt werden soll. Wie oben beschrieben verwirft der Agent die Zuweisung stillschweigend. Führe ihn zur Bestätigung direkt aus — über die Play-Schaltfläche neben dem Eintrag im Checks-Tab des Geräts; dafür brauchst du die Geräteaktion Wartung ausführen. Bei einer nicht unterstützten Plattform meldet er Dieser Check wird vom Betriebssystem des Zielgeräts nicht unterstützt. Ergänze im Tab Skript ein Skript für diese Plattform.

Der Check auf einem Netzwerkgerät meldet die Werte der falschen Maschine. Das Skript läuft auf dem Überwachungsgerät; jeder Befehl, der das lokale System ausliest, misst also diesen Agenten statt des Netzwerkgeräts. Hole jeden Wert stattdessen über das Netzwerk, mit der Adresse aus dem Host-Parameter.

Wie du prüfst, dass der Check läuft

Am schnellsten geht es über die Live-Test-Leiste des Editors: Wähle ein verbundenes Gerät aus und klicke auf Ausführen, um Status, Laufzeit, Ausgabe und geparste Felder sofort zu sehen. Nachdem du den Check einem Gerät zugewiesen hast, führt octoja ihn im konfigurierten Intervall aus — öffne den Checks-Tab des Geräts, um das Ergebnis im von dir definierten Layout zu sehen. Liefert der Check dort kein Ergebnis, prüfe das Agent-Log auf Skriptfehler — bei einem Netzwerkgerät liegt dieses Log auf seinem Überwachungsgerät, denn das Netzwerkgerät selbst führt nichts aus.

Verwandte Artikel

• Custom-Script-Check-Referenz — die vollständige Eingabe-, Ausgabe- und Helper-Referenz.
• Ein Netzwerkgerät ohne Agent hinzufügen — wie Netzwerkgeräte und Überwachungsgeräte zusammenspielen.