What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

REST CUSTOM Sensor, Template für Text, "UP" und "DOWN"

Votes:

0

Your Vote:

Up

Down

Mit Hilfe des REST Custom BETA Sensor möchte ich den Status von id 0 bis 5 monitoren. Der Statuswert wird mit "UP" bzw. "DOWN" zurückgegeben. Mit dem Template, abgeleitet aus https://kb.paessler.com/en/topic/81363-create-custom-configuration-template-file-for-rest-custom-sensor soll der Rückgabewert übersetzt werden.

Dies scheint auch zu funktionieren, solange alle Werte auf "UP" stehen. Ist der Wert von Index 2 wie im Beispiel auf "DOWN", erscheint im Sensor-Resultat "502 Service Unavailable" und der gesammte Sensor geht auf Fehler. Wie hat das Template auszusehen, damit "UP" als OK und "DOWN" als ERROR dargestellt werden kann - oder noch besser - "UP" als OK und alle anders lauteneden Werte als ERROR?

Abfrage URL - status der id 2 ist "DOWN"
{
	"checks": [{
		"id": "Osv",
		"status": "UP",
		"data": {
			"Enabled": true,
			"Cron": "0 0 4 1/1 * ? *",
			"Server1": "http://172.18.250.20:8767/cgi-bin/soapServer",
			"Server2": "http://172.18.253.20:8767/cgi-bin/soapServer",
			"Running": false
		}
	}, {
		"id": "KMS_NEDI",
		"status": "UP",
		"data": {
			"Enabled": true,
			"Cron": "0 44 5 1/1 * ? *",
			"IpRegex": "(?i)\\b172\\.18\\..*?\\b",
			"UrlKms": "https://www.zi.uzh.ch/cl/dl/dn/exports/tas/kms.csv",
			"UrlNedi": "https://www.zi.uzh.ch/cl/dl/dn/exports/tas/nedi.csv",
			"RunningKms": false,
			"RunningNedi": false
		}
	}, {
		"id": "Events",
		"status": "DOWN",
		"data": {
			"Queued": "#Events 3",
			"Enabled": true,
			"Cron": "0 5,35 9,10,11,12,13,14,15 1/1 * ? *"
		}
	}, {
		"id": "Database",
		"status": "UP",
		"data": {
			"URL": "jdbc:mysql://mariadb.uzh.ch:3312/tas?autoReconnect=true&useSSL=false&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=Europe/Zurich",
			"Connection": "#DB rows 11"
		}
	}, {
		"id": "Xpression",
		"status": "UP",
		"data": {
			"Enabled": true,
			"Cron": "0 30 4 1/1 * ? *",
			"ImportPath": "/data/import/xpression",
			"DonePath": "/data/import/xpression/done",
			"PhonePrefix": "+414463",
			"Running": false
		}
	}, {
		"id": "Application",
		"status": "UP",
		"data": {
			"Version": "1.4.1",
			"Revision": "be0f6d1751a1da94baa19ac92a880567731ddfab",
			"BuildTime": "12-12-2019 16:56:43",
			"Port": 15200,
			"API": "ORDER/V1"
		}
	}],
	"outcome": "DOWN"
}
Result Sensor
{
	"prtg": {
		"Error": "1",
		"Text": "Cannot load endpoint http://idtasappl1.uzh.ch:15200/health: expected status 200 OK but got 503 Service Unavailable."
	}
}
Abfrage URL - status aller ids sind "UP"
{
	"checks": [{
		"id": "Osv",
		"status": "UP",
		"data": {
			"Enabled": true,
			"Cron": "0 5 4 1/1 * ? *",
			"Server1": "http://172.18.250.20:8767/cgi-bin/soapServer",
			"Server2": "http://172.18.253.20:8767/cgi-bin/soapServer",
			"Running": false
		}
	}, {
		"id": "KMS_NEDI",
		"status": "UP",
		"data": {
			"Enabled": true,
			"Cron": "0 49 5 1/1 * ? *",
			"IpRegex": "(?i)\\b172\\.18\\..*?\\b",
			"UrlKms": "https://www.zi.uzh.ch/cl/dl/dn/exports/tas/kms.csv",
			"UrlNedi": "https://www.zi.uzh.ch/cl/dl/dn/exports/tas/nedi.csv",
			"RunningKms": false,
			"RunningNedi": false
		}
	}, {
		"id": "Events",
		"status": "UP",
		"data": {
			"Queued": "#Events 0",
			"Enabled": true,
			"Cron": "0 7,37 9,10,11,12,13,14,15 1/1 * ? *"
		}
	}, {
		"id": "Database",
		"status": "UP",
		"data": {
			"URL": "jdbc:mysql://mariadb.uzh.ch:3312/tas_test?autoReconnect=true&useSSL=false&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=Europe/Zurich",
			"Connection": "#DB rows 11"
		}
	}, {
		"id": "Xpression",
		"status": "UP",
		"data": {
			"Enabled": true,
			"Cron": "0 35 4 1/1 * ? *",
			"ImportPath": "/data/import/xpression",
			"DonePath": "/data/import/xpression/done",
			"PhonePrefix": "+414463",
			"Running": false
		}
	}, {
		"id": "Application",
		"status": "UP",
		"data": {
			"Version": "1.4.1",
			"Revision": "4225963007b4c3928f6180a165a11ad107992daa",
			"BuildTime": "19-12-2019 18:59:59",
			"Port": 15200,
			"API": "ORDER/V1"
		}
	}],
	"outcome": "UP"
}
Result Sensor
{
  "prtg": {
    "result": [
      {
        "channelid": 0,
        "Value": 5,
        "Unit": "TimeResponse",
        "ShowChart": 0,
        "ShowTable": 0
      },
      {
        "channel": "OSV",
        "Value": 0,
        "LimitMinError": 0,
        "LimitErrorMsg": "The value for 'node' is not 'Up'!",
        "LimitMode": 1
      },
      {
        "channel": "KMS_Nedi",
        "Value": 0,
        "LimitMinError": 0,
        "LimitErrorMsg": "The value for 'node' is not 'Up'!",
        "LimitMode": 1
      },
      {
        "channel": "Events",
        "Value": 0,
        "LimitMinError": 0,
        "LimitErrorMsg": "The value for 'node' is not 'Up'!",
        "LimitMode": 1
      },
      {
        "channel": "Database",
        "Value": 0,
        "LimitMinError": 0,
        "LimitErrorMsg": "The value for 'node' is not 'Up'!",
        "LimitMode": 1
      },
      {
        "channel": "Xpression",
        "Value": 0,
        "LimitMinError": 0,
        "LimitErrorMsg": "The value for 'node' is not 'Up'!",
        "LimitMode": 1
      },
      {
        "channel": "Application",
        "Value": 0,
        "LimitMinError": 0,
        "LimitErrorMsg": "The value for 'node' is not 'Up'!",
        "LimitMode": 1
      }
    ]
  }
}
Verwendetes Template (ageleitet von Topic 81363)
{
   "prtg": {
     "result": [
       {
         "channel": "OSV" ,
         "value": lookup ($.checks[0].status, "UP"),
	 "limitmode": 1,
	 "LimitMinError": 0,
	 "LimitErrorMsg": "The value for 'node' is not 'Up'!"
       },
{
         "channel": "KMS_Nedi" ,
         "value": lookup ($.checks[1].status, "UP"),
	 "limitmode": 1,
	 "LimitMinError": 0,
	 "LimitErrorMsg": "The value for 'node' is not 'Up'!"
       },
{
         "channel": "Events" ,
         "value": lookup ($.checks[2].status, "UP","DOWN"),
	 "limitmode": 1,
	 "LimitMinError": 0,
	 "LimitErrorMsg": "The value for 'node' is not 'Up'!"
       },
{
         "channel": "Database" ,
         "value": lookup ($.checks[3].status, "UP"),
	 "limitmode": 1,
	 "LimitMinError": 0,
	 "LimitErrorMsg": "The value for 'node' is not 'Up'!"
       },
{
         "channel": "Xpression" ,
         "value": lookup ($.checks[4].status, "UP"),
	 "limitmode": 1,
	 "LimitMinError": 0,
	 "LimitErrorMsg": "The value for 'node' is not 'Up'!"
       },
{
         "channel": "Application" ,
         "value": lookup ($.checks[5].status, "UP"),
	 "limitmode": 1,
	 "LimitMinError": 0,
	 "LimitErrorMsg": "The value for 'node' is not 'Up'!"
       }
     ]
   }
 }
Kanal Werte-Lookup -> prtg.standardlookups.aws.status.ovl

<?xml version="1.0" encoding="UTF-8"?> <ValueLookup id="prtg.standardlookups.aws.status" desiredValue="0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PaeValueLookup.xsd"> <Lookups> <Boolean state="Ok" value="0"> Ok </Boolean> <Boolean state="Error" value="1"> Failed </Boolean> </Lookups> </ValueLookup>

custom-sensor json rest template text

Created on Oct 7, 2020 9:14:15 AM by  agrube (0) 1

Last change on Oct 8, 2020 8:34:29 AM by  Stephan Linke [Paessler Support]



9 Replies

Votes:

0

Your Vote:

Up

Down

Das Problem liegt hier aber am Login, nicht an der Ausgabe selbst. Werden dem Sensor Zugangsdaten oder Header mitgegeben, um sich am System anzumelden?

Created on Oct 8, 2020 2:28:27 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Der Sensor wird mit Abfragemethode = GET, Protokoll = HTTP, Methode für die Authentifizierung = Keine Authentifizierung, HTTP Header = Keine eigenen HTTP Header verwenden betrieben.

Wenn alle abgefragen IDs mit dem Status = UP zurückgegeben werden, sieht das Sensor Resultat wie untenstehend aus, die Kanäle werden in der Sensorübersicht mit dem Zustand OK dargestellt.

Wenn der Wert von Index 2 wie im Beispiel auf "DOWN", erscheint im Sensor-Resultat "502 Service Unavailable" und der gesamte Sensor geht auf Fehler. Das Sensor Resultat für diesen Fall befindet sich oben in der Fehlerbeschreibung.

Ich vermute, dass das von mir erstellte Template den "DOWN" bzw. ungleich "UP" Status nicht korrekt berücksichtigt. Leider habe ich dazu nicht genügend Infos gefunden, daher diese Anfrage.

Sensor Resultat wenn alle Stati "UP" { "prtg": { "result": [ { "channelid": 0, "Value": 6, "Unit": "TimeResponse", "ShowChart": 0, "ShowTable": 0 }, { "channel": "OSV", "Value": 0, "LimitMinError": 0, "LimitErrorMsg": "The value for 'node' is not 'Up'!", "LimitMode": 1 }, { "channel": "KMS_Nedi", "Value": 0, "LimitMinError": 0, "LimitErrorMsg": "The value for 'node' is not 'Up'!", "LimitMode": 1 }, { "channel": "Events", "Value": 0, "LimitMinError": 0, "LimitErrorMsg": "The value for 'node' is not 'Up'!", "LimitMode": 1 }, { "channel": "Database", "Value": 0, "LimitMinError": 0, "LimitErrorMsg": "The value for 'node' is not 'Up'!", "LimitMode": 1 }, { "channel": "Xpression", "Value": 0, "LimitMinError": 0, "LimitErrorMsg": "The value for 'node' is not 'Up'!", "LimitMode": 1 }, { "channel": "Application", "Value": 0, "LimitMinError": 0, "LimitErrorMsg": "The value for 'node' is not 'Up'!", "LimitMode": 1 } ] } }

Created on Oct 8, 2020 4:55:55 PM by  agrube (0) 1

Last change on Oct 9, 2020 9:31:09 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Aber im Sensor-Ergebnis steht eine Fehlermeldung, die mit dem Ergebnis (was erwartet wird) so erstmal nichts zu tun hat: Cannot load endpoint http://idtasappl1.uzh.ch:15200/health: Expected status 200 OK but got 503 Service Unavailable." Bedeutet, PRTG bzw. der Sensor versucht die URL zu öffnen, bekommt aber einen HTTP/503 Fehler zurück, sprich es kommt garnicht erst zu einem Ergebnis. Das kann so sicherlich nicht gewollt sein?

Created on Oct 9, 2020 9:33:37 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Danke für die Diagnose. Wireshark zeigt trotz der Rückgabe des vollständigen Objekts den Statuswert 503 Service unavailable. Dies verhält sich bei der Abfrage des Links mit einem Browser identisch, irritierend ist, dass der Browser trotz dem Fehlerstatus ein scheinbar gültiges Ergebnis zeigt. Als nächsten Schritt werde ich bei dem Integrator der Applikation ein Fehlerticket absetzen.

Created on Oct 13, 2020 6:20:52 AM by  agrube (0) 1



Votes:

0

Your Vote:

Up

Down

Das wäre der korrekte Weg, richtig :) Der Sensor kann leider mit Fehlercodes nicht so gut umgehen und erwartet immer 200 oder 302, wenn ich mich korrekt entsinne. Lassen Sie uns wissen, falls wir hier weiterhelfen können.


Mit freundlichen Grüßen,
Stephan Linke, Technical Support Team

Created on Oct 13, 2020 8:10:41 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Von unserem Integrator habe ich die Diagnose bekommen, dass es in dieser Implementation wirklich so gewollt ist, dass sobald ein Check DOWN ist der http Status auf 503 gesetzt wird. Siehe dazu: https://vertx.io/docs/vertx-health-check/java/

Daraus scheint es legitim zu sein, mit Status 503 zu antworten - daher stelle ich die Anfrage, ob der REST Sensor (der ja noch im BETA Zustand ist) nicht mit dem Status 503 umgehen können müsste.

Mit bestem Dank für ein Feedback Andreas Gruber

Created on Oct 16, 2020 9:07:25 AM by  agrube (0) 1



Votes:

0

Your Vote:

Up

Down

Der Sensor wird in seiner jetzigen Form nicht mehr weiterentwickelt, da wir aktuell am Nachfolger, basierend auf einem neuen Sensor-Framework arbeiten. Dessen ungeachtet ist diese Art der Implementierung meiner Meinung nach seltsam. 503 bezieht sich auf den eigentlichen Server-Zustand, nicht das zurückgelieferte Ergebnis. HTTP/202 wäre hier richtiger:

10.2.3 202 Accepted
The request has been accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might be disallowed when 
processing actually takes place. There is no facility for re-sending a status code 
from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server 
to accept a request for some other process (perhaps a batch-oriented process 
that is only run once per day) without requiring that the user agent's connection 
to the server persist until the process is completed. The entity returned with this 
response SHOULD include an indication of the request's current status and either 
a pointer to a status monitor or some estimate of when the user can expect the 
request to be fulfilled.

Der Fehlercode ist hier schlichtweg falsch angewendet, aber das ist wohl Auslegungssache. Ich kann das allerdings gerne als Feature-Request für den neuen Sensor mit anbringen. Ob es technisch möglich ist, ist wahrscheinlich ein andere Geschichte. Ggf. kann man sich derweil mit einem PowerShell-Script aushelfen, welches die API abfragt?

edit
Wahrscheinlich klappt das auch nicht:

When Invoke-WebRequest encounters a non-success HTTP message (404, 500, etc.), it returns no output and throws a terminating error. To catch the error and view the StatusCode you can enclose execution in a try/catch block.

Created on Oct 16, 2020 10:32:52 AM by  Stephan Linke [Paessler Support]

Last change on Oct 16, 2020 10:34:24 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Was die Behandlung von Status 503 betrifft, scheint es sich um einen Expertenstreit zwischen Pässler und vert.x zu handeln. Ich kann nicht beurteilen, welche Interpretation korrekt ist. Ich werde die Zustände vorerst weiterhin mit dem API-Sensor überwachen, mit dem Schönheitsfehler, dass ein einzelner DOWN-Zustand nicht explizit angezeigt wird, sondern immer der ganze Sensor auf DOWN geht. Falls sich dies nicht bewährt, werde ich wie vorgeschlagen PRTG umstellen und die Stati über ein Powershell-Script auslesen, da von Pässler keine zeitnahe Lösung für den API-Sensor zu erwarten ist.

Ich danke für die Diagnose und die Hilfe Andreas Gruber

Created on Oct 21, 2020 10:07:46 AM by  agrube (0) 1



Votes:

0

Your Vote:

Up

Down

Vielen Dank für Ihr Verständnis bzgl. des Problems. Sollten Sie weitere Fragen haben, lassen Sie es uns bitte gerne wissen!

Created on Oct 21, 2020 12:18:31 PM by  Stephan Linke [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.