Home » Busy-Work, Networking, projects, Web » A quick look at the PRTG API

A quick look at the PRTG API

Paessler has made one of the most inviting Network Performance Monitoring tools I have used, PRTG.  Their API is also designed very well, and it’s nice that it’s self-documenting.

To get started with the API, you can navigate to your installed instance of PRTG (https://<servername>/api.htm).  If you don’t yet have it installed, you can check out Paessler’s public demo site which grants API access.

In this post, we are going to focus on filtering results based on how your HTTP request string is formatted.  From their example in their documentation, here is an HTTP query that will pull all ‘sensors that are not up (based on filter status codes) with their current state and downtime information (based on what columns you include in the query string)’.

https://<servername>/api/table.xml?content=sensors&columns=objid,downtimesince,device,sensor,lastvalue,status,message,priority&filter_status=5&filter_status=4&filter_status=10&filter_status=13&filter_status=14&sortby=priority

The current filter status codes are:

  1. Unknown
  2. Collecting
  3. Up
  4. Warning
  5. Down
  6. NoProbe
  7. PausedbyUser
  8. PausedbyDependency
  9. PausedbySchedule
  10. Unusual
  11. PausedbyLicense
  12. PausedUntil
  13. DownAcknowledged
  14. DownPartial

You can select the format of your return values as well.  The query listed above will return xml formatted results.


https://<servername>/api/table.xml?content=sensors&columns=objid,downtimesince,device,sensor,lastvalue,status,message,priority&filter_status=5&filter_status=4&filter_status=10&filter_status=13&filter_status=14&sortby=priority

 <sensors>
 <prtg-version>14.1.8.1370</prtg-version>
 <item>
 <objid>2031</objid>
 <downtimesince/>
 <device> IP_ADDRESS_REDACTED (BLANKNAME)</device>
 <sensor>(003) LAN (LAN)</sensor>
 <lastvalue>1,106 kbit/s</lastvalue>
 <lastvalue_raw>138260.0833</lastvalue_raw>
 <status>Unusual</status>
 <status_raw>10</status_raw>
 <message>
 <div>1 day interval average of 60 kbit/s (Traffic In) is unusually low for this weekday<div></div></div>
 </message>
 <message_raw>
 1 day interval average of 60 kbit/s (Traffic In) is unusually low for this weekday
 </message_raw>
 <priority>3</priority>
 </item>
 </sensors>


https://<servername>/api/table.json?content=sensors&columns=objid,downtimesince,device,sensor,lastvalue,status,message,priority&filter_status=5&filter_status=4&filter_status=10&filter_status=13&filter_status=14&sortby=priority

 {
 "prtg-version":"14.1.8.1370",
 "treesize":1,
 "sensors":[
 {
 "objid":2031,
 "downtimesince":"",
 "downtimesince_raw":"",
 "device":"IP_ADDRESS_REDACTED (BLANKNAME)",
 "sensor":"(003) LAN (LAN)",
 "lastvalue":"1,088 kbit/s",
 "lastvalue_raw":135970.3333,
 "status":"Unusual",
 "status_raw":10,
 "message":"<div class="status">1 day interval average of 60 kbit/s (Traffic In) is unusually low for this weekday<div class="moreicon"></div></div>",
 "message_raw":"1 day interval average of 60 kbit/s (Traffic In) is unusually low for this weekday",
 "priority":3
 }
 ]
 }

This is a very basic example of what you can do.  In my case, I wanted to trigger an alarm light when there were ‘down’ sensors.  I preferred to work with JSON strings since the built in processing.org JSON library was pretty easy to use.  There’s alot of strength and flexibility in this API though – you can craft these HTTP queries to do quite a bit.  This example focuses on ‘read only’.  They offer the ability to ‘rename’ sensors via HTTP API, but I’ve not had a need for that yet.