What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

How can I use the PRTG Application Programming Interface (API)?

Votes:

4

I want to write my own scripts or programs using the PRTG RESTful API, custom sensors, custom notifications, and website styling.

  • What are the provided functionalities?
  • Where can I get a full description of the API?
  • What can I do with it and how can I use the API?

api css custom-notification custom-script-exe custom-sensor important mini-probe prtg script web-interface

Created on Feb 5, 2010 2:47:46 PM by  Daniel Zobel [Product Manager]

Last change on May 6, 2019 12:10:04 PM by  Maike Guba [Paessler Support] (2,404) 2 1



23 Replies

Accepted Answer

Votes:

4

This article applies as of PRTG 22

Introduction to the PRTG API interface

Users can customize and expand the functionality of PRTG via the following options:

  • HTTP API: Access monitoring data and manipulate monitoring objects via HTTP requests.
  • Custom Sensors: Create your own sensors for customized monitoring.
  • Custom Notifications: Create your own notifications to send alarms to external systems.
  • Mini Probe API: Create your own mini probes to get monitoring data from any platform.

Technical support for API features

All API features mentioned here are not covered by our usual next-business-day support. Therefore, it may take a few days before you receive an answer. Note that we can neither provide support for web design issues that involve your own CSS and HTML nor for implementing or adjusting mini probes.


HTTP API

This section gives you a brief overview over the functionalities of the API interface. The HTTP API offers the following functionality:

  • Authentication, error handling, and optional encryption.
  • Functions for getting live object and status data and live graphs.
  • Functions for getting historic sensor data and graphs.
  • Functions for manipulating objects (for example edit, add, delete).

You can use it via simple HTTP GET requests (either HTTP or HTTPS). Sample call:

http://yourserver/api/table.xml?content=sensortree

Detailed HTTP API documentation

Find a detailed documentation of all HTTP API functions in the PRTG Manual: Application Programming Interface (API) Definition. There, you also find information about the interactive query builder.


Custom sensors

Custom sensors allow a number of monitoring tasks that go far beyond the capabilities of standard sensors. Apart from parameterized versions of SNMP, packet sniffer sensors, and NetFlow sensors, you can create your own sensors via WQL (WMI Query Language) and by compiling an .exe file, with any Windows software development tool.

Learn more about custom sensors:

Note: With custom sensors, you can use placeholders.


Custom notifications

Custom notifications allow you to run any script or program as a notification. When connected to a sensor, you can trigger not only notifications, but also other actions. This is a powerful tool to react to specific situations in your network.

Learn more about what you can do with custom notifications:

Note: With PRTG notifications, you can use placeholders.


Mini Probe API

Mini probes gather monitoring data from platforms where it is not possible or not suitable to use the common local and remote probes. This gives you a broad range of possibilities to implement amazing functions.

See the following article for a collection of mini probe implementations:


Share your script/program

Write your own Knowledge Base article and provide your script. See this article for more information: How can i share my self-written PRTG script/program with other PRTG users?

Created on Feb 5, 2010 3:01:46 PM by  Daniel Zobel [Product Manager]

Last change on Jun 29, 2022 12:00:04 PM by  Brandy Greger [Paessler Support]



Votes:

0

hello,

i search the api doku for the map-designer. For example i want to know something about "filter_tags" or "filter_status" in the htm files

thx

Created on Feb 5, 2014 7:26:51 AM



Votes:

0

These are not documented portions of the API but are used internally in PRTG. If you want to use them you can but you will need to figure out what they mean specifically.

Created on Feb 5, 2014 2:25:36 PM by  Greg Campion [Paessler Support]



Votes:

0

is it possible to get these documantation?

Created on Feb 6, 2014 12:51:32 PM



Votes:

0

If you look through the API documentation you will see a tab called Live Data where you will see the filtering capabilities documented under Sorting and Advanced Filtering.

Created on Feb 7, 2014 1:54:27 PM by  Greg Campion [Paessler Support]



Votes:

0

I notice that when pulling data for a specific sensor, the values are outdated and does not currently reflect the most recent data. Is this expected?

Created on Apr 27, 2015 10:40:52 PM



Votes:

0

Hi,

Could you please forward the used query and some screenshots to [email protected] to illustrate the issue? Please refer to this knowledge base article.

Best regards

Created on Apr 29, 2015 12:46:09 PM by  Felix Saure [Paessler Support]



Votes:

0

I'm a JS developer with NodeJS/Meteor and have experience with the PRGT API (json/rest) if anyone needs assistance or paid work done.

Specifically experience with extracting historical and realtime data to integrate directly with another web application.

I would also love to chat with any other prtg api devs to discuss ideas and experience. Thanks!

Created on Oct 25, 2015 4:27:53 PM



Votes:

0

I use the API extensively. I have 15,000 wifi access points spread across 190 location that are managed using a central web based application from the vendor, Aerohive. The management application only really does a good job of managing device configurations and maintaining device firmware - so essentially pushing config and software to the devices. It is very poor as regards other aspects of device management, such as availability, load, performance, long term history ( such as when the device was out of service ), reporting etc.

I use PRTG for this. I used python scripts and the API to created the groups that I need ( corresponding to each physical site ) and then the devices at each location. There would be no way to manually create thousands of devices. I read device information using a RESTful API from my main management system and then use it to create parallel device objects in PRTG. I have a script that checks for differences between what is in the main system and PRTG and will add, delete and modify devices and their properties in PRTG to match the current data in the main system.

MY MAJOR TAKEAWAY IS THAT REST CALLS USE RAM. My system was constantly slowing down and then crashing when making a lot of REST API requests. I recently realized that each API call seems to result in a new process being created on the core server and that my server was falling over because of memory starvation. When I went from 16GB to 24GB my stuff was transformed. I have a script running now to re-sort the devices in a group and I am running at 85% of available memory ( 21GB ).

I have a python module with a growing set of methods that wrap the standard API calls. I would have no problem sharing the code with any interested party. The next thing I am going to work on is generating standard reports for each of my physical location based on some Master Reports that will act as templates ( clone sources ).

Created on Mar 8, 2019 8:05:52 PM



Votes:

0

Did you already test this with the latest PRTG version (19.1.48.2929)? There were some major performance improvements. Are you also aware of PRTGapi (see my signature)? Perhaps you can optimize your workflow with it :)


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 11, 2019 9:30:06 AM by  Stephan Linke [Paessler Support]



Votes:

0

Hi Stephan:

I am seeing major improvements and I am upgrading as soon as I see a new version. I am pushing the system very hard. I have 26,000 sensors, but with most of them on a Remote Probe. They are SNMP sensors so quite lightweight but still a lot of load. I have 12 cores, 24GB on a VMware virtual server. The upgrade was contemporaneous with me realizing that I needed more memory. Previously I was seeing the system lose track of sensor status ( thousands in unknown state ) and even completely crash when I pushed hard with API calls.

Now I am able to send API commands at the system quite aggressively and it isn't skipping a beat. I see memory usage jump and I seem to need about 8GB of extra RAM to cope with API calls but the web interface remains completely responsive and no sensor status is lost.

My biggest issue now is load time on a restart but that seems to be down to poor disk performance on my VMware infrastructure ( and I am not restarting as often now that the performance has improved ). When I look at performance on loading, memory and CPU are low but the disk is working hard.

I only have about 1/3 of my total devices in this one PRTG instance and I am going to have to deploy another couple of instances. I don't want to push harder on one core server than I am already and I want some spare capacity so that I can potentially add more sensors per device.

I am very pleased with the performance improvements.

Cheers,

Ed.

Created on Mar 11, 2019 5:09:25 PM



Votes:

0

Glad it's working for you :) We're currently implementing further improvements to push PRTG even further :) Stay tuned.


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 11, 2019 8:48:34 PM by  Stephan Linke [Paessler Support]



Votes:

0

I've problems with high memory consumption when making a lot of API calls, too. In my case this wasn't fixed with the latest PRTG version(19.1.49.1966)

Created on Apr 23, 2019 2:21:55 PM



Votes:

0

Define "a lot", please :) How many in general, how many per second (rough estimates)?


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Apr 24, 2019 6:09:49 AM by  Stephan Linke [Paessler Support]



Votes:

0

I'm using a Powershell-Script. Loop thru 3400 sensors and updating the comment field.

Created on Apr 24, 2019 10:55:29 AM



Votes:

0

And what exactly does your script look like? Did you consider using PRTGapi, as per my signature?


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Apr 24, 2019 11:08:50 AM by  Stephan Linke [Paessler Support]



Votes:

0

With regard to API calls and RAM consumption, I find that all of my RAM ( currently 48GB ) will be consumed by a long running script that is used to add sensors ( typically adding three SNMP sensors to up to 200 devices ). I take the following measures:

  • sleep timer value that is used to make the script sleep for a certain number of seconds after every sensor clone API call
  • code that monitors the RAM on the core server that is use after every device has been processed. If free RAM drops below a "low water mark", I suspend the script for a set time ( ten minutes ). I continue to check until free RAM has returned to a "high water mark" before resuming the script. My values are 3GB and 6GB of free RAM.
  • code that copes with a scheduled PRTG core server restart by pausing ( typically for 30 minutes )

Running the API slows down the web interface and I have written these functions so that I can run the scripts out of hours without having to babysit them and pause manually when RAM gets too low.

When not running API calls, RAM usage is around 20 to 24GB. I have asked for an increase to 64GB on the server but I expect the API will continue to use all the RAM I can get.

Created on Jun 6, 2019 5:49:36 PM



Votes:

0

Free RAM Graph

I hope the above link shows a graph of my free RAM running down precipitously as an API script runs and then recovering as I make the script pause until RAM recovers. Might be too wide for the space available.

Created on Jun 6, 2019 6:03:23 PM



Votes:

0

96GBRAM

So I was given 96GB of RAM and set a batch of scripts to run serially over several hours. An API call to add a sensor is being executed approximately every 20 seconds ( it seems to slow down over time ). So RAM consumption quickly went to about 60GB and stayed there for a while, slowly stepping up over several hours. At around 5:45 there was a steeper increase in RAM consumption and as I type it is at 90% with 9.6GB remaining.

So it does seem that while the pattern changed a little, the trend is for inexorable consumption of RAM if there is a steady stream of API calls that create new objects.

Created on Jun 6, 2019 9:57:49 PM



Votes:

0

@GwigstaNummerEin Thanks for sharing your findings with us. We will take this into consideration when implementing our v2 API (no ETA yet). Certainly valuable, thanks again! :)

Created on Jun 7, 2019 7:44:32 AM by  Stephan Linke [Paessler Support]

Last change on Jun 7, 2019 7:47:26 AM by  Stephan Linke [Paessler Support]



Votes:

0

Hi Stephan:

I just added these functions to monitor RAM consumption this week but it is working very well. I am going to move my scheduled reboot to 5:00AM so that I have a long window from 6:00PM to 5:00AM to run my API scripts.

Adding one more graph to show CPU usage in relation to API calls. Basically, it does cause a significant increase in CPU usage and a consequent degradation of user interface responsiveness. I am going to work to get a better set of blades so I can move to a higher core count and see if that impacts user experience when API calls are being made.

For now, I am just going to run API scripts out of regular business hours.

Graphs show what happened when running API scripts from mid afternoon to late evening on two consecutive days. RAM was boosted from 48GB to 96GB around 2:00PM on 2nd day.

CPU

RAM

Created on Jun 7, 2019 6:38:14 PM



Votes:

0

Glad to hear that you found a somewhat viable workaround. We hope to improve performance further with a new webserver and API in the (hopefully not so distant) future :)

Created on Jun 11, 2019 6:12:40 AM by  Stephan Linke [Paessler Support]



Votes:

0

@GwigstaNummerEin Hello, I would like it if you shared the code with me. We have a similar setup, but with Cradlepoint routers in busses. With also a similar webbased management application.

Created on Oct 10, 2019 7:16:46 AM




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.