Make PRTG's XML sensor interface parse real-world XML reliably and consistently
As a Systems Engineer who builds custom integrations (e.g., wrapping NRPE/Nagios plugin output for PRTG via a web server),
I want the XML processing of the HTTP Data Advanced sensor (and related advanced custom sensors) to behave like a real, standards-compliant XML parser — accepting comments, matching values to channels by name rather than position, and letting me explicitly designate the primary channel —
so that I can generate sensor output from any standard tool or library (hash tables, XSLT, alphabetically sorted REST responses) without fragile ordering hacks, and get consistent results regardless of which sensor type consumes the data.
Background:
Trying to write a sensor that outputs XML demonstrated how badly designed the whole XML-processing really is:
1) the parser does not recognize XML comments, so actually I would not call it XML parser at all
2) the XML data model is just terrible (I named it "tag soup", because it doesn't really have a well-designed structure)
3) Depending on the sensor being used, the same XML output is interpreted differently; for example only the HTTP Data Advanced can deduce the actual channel names without needing a mapfile on the server
4) Even if the HTTP Data Advanced sensor can assign a name to a channel's value, the actual values are retrieved by position (it seems to me). So the order has to be the same all the time (bad if you collect your valuers in a hash table, for example)
5) The HTTP Data Advanced sensor always assumes the first value is the most important one; bad if your sensor (REST server) sorts the labels alphabetically, just for example)
Here's an example of some XML output that PRTG cannot handle:
<?xml version="1.0" encoding="UTF-8"?>
<!--MonitoringOutput v0.2 id=NRPE@local:checkload (PRTG.xsl v0.0.11)-->
<Prtg>
<!--Description: "/usr/lib/nagios/plugins/checknrpe" "-4" "-H" "localhost" "-c" "check_load"-->
<!--Exit Code: 0-->
<!--Info String: OK - load average: 0.21, 0.11, 0.04-->
<!--Perf String: load1=0.210;10.000;15.000;0; load5=0.110;6.000;10.000;0; load15=0.040;5.000;8.000;0; -->
<Text/>
<Result>
<Channel>load1</Channel>
<Value>0.210</Value>
<Float>1</Float>
<!--DEBUG(1): (:10.000)-->
<LimitMaxWarning>10.000</LimitMaxWarning>
<!--DEBUG(1): (:15.000)-->
<LimitMaxError>15.000</LimitMaxError>
</Result>
<Result>
<Channel>load5</Channel>
<Value>0.110</Value>
<Float>1</Float>
<!--DEBUG(1): (:6.000)-->
<LimitMaxWarning>6.000</LimitMaxWarning>
<!--DEBUG(1): (:10.000)-->
<LimitMaxError>10.000</LimitMaxError>
</Result>
<Result>
<Channel>load15</Channel>
<Value>0.040</Value>
<Float>1</Float>
<!--DEBUG(1): (:5.000)-->
<LimitMaxWarning>5.000</LimitMaxWarning>
<!--DEBUG(1): (:8.000)-->
<LimitMaxError>8.000</LimitMaxError>
</Result>
</Prtg>
(As you can see I converted the output of an NRPE plugin to PTRG (using a HTTP server))