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://helpdesk.paessler.com/en/support/solutions/articles/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>
Article Comments
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
}
]
}
}
Oct, 2020 - Permalink
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?
Oct, 2020 - Permalink
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.
Oct, 2020 - Permalink
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
Oct, 2020 - Permalink
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
Oct, 2020 - Permalink
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.
Oct, 2020 - Permalink
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
Oct, 2020 - Permalink
Vielen Dank für Ihr Verständnis bzgl. des Problems. Sollten Sie weitere Fragen haben, lassen Sie es uns bitte gerne wissen!
Oct, 2020 - Permalink
Das Problem liegt hier aber am Login, nicht an der Ausgabe selbst. Werden dem Sensor Zugangsdaten oder Header mitgegeben, um sich am System anzumelden?
Oct, 2020 - Permalink