In the previous articles in this series, I’ve talked about the PRTG Network Monitor and how you can customize it by building your own sensors and notifications. In this article, I’m going to look at the API that you can use to automate some of the manual tasks you would likely have to do on a day to day basis.
The API documentation is available within the product. By clicking on the “Setup” menu and then clicking on “PRTG API”, you’ll see get to the API overview. If you don’t have the product installed, you can get to it through the demo site setup by PRTG.
PRTG exposes a RESTful interface that enables you to access and manipulate information from the monitoring database inside of PRTG. The API covers the following functional areas:
Live Data - You can get properties, settings, and status information of an object.
Live Graphs - Graphs are rendered as PNG files and can be used in other webpages.
Historic Data - You can download the historic monitoring data for one sensor in XML or CSV format.
Object Manipulation - Manipulate existing objects in the system.
How Are Calls Made?
The interface is HTTP/HTTPs based, and since it only utilizes GET requests, all you need is a browser to be able to make method calls. But, for the sake of automation, I’ll use the command line web client cURL in the examples below.
The format of the URL to the API is the following:
http(s) - In most cases, http will work. But, if you have configured it outside your DMZ, then you’ll want to setup SSL.
prtg_server_address - the address and port of your PRTG instance. We have ours running on port 8080.
function - the function you are trying to access. I’ll discuss some of them below:
uid - The PRTG User account to authenticate the request
hash - The Password Hash is shown on the user account settings page in the PRTG Administration settings.
params - for methods passing in data, you will have to append query string parameters for those settings.
The Live Data APIs are used to query the objects in the system. The table.xml function is used to access data in tables.
Possible values for content are:
sensortree - A Tree-like structure of groups, devices, and sensors
groups - A list of all groups
devices - A list of all devices
sensors - A list of all sensors
values - A list of most recent results of a sensor (sensor ID parameter required)
channels - A list of the channels of a sensor (sensor ID parameter required)
reports - A list of reports
storedreports - A list of most recent PDF reports (report ID required)
todos - A list of most recent todo notification items.
There are a LOT of column types, and the values you pass in are dependent on the what you select as your content. I’ll leave it as an exercise of the reader to review all those values either in your own PRTG instance (or at the online reference).
Armed with a handy command line, you can easily build a procedure to automate control of your PRTG configuration. There is a lot more functionality exposed in the PRTG API than I was able to cover in this article. I’m working on a PowerShell wrapper library for their entire API set so be on the look out in the next few weeks for it’s public appearance.