New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


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

Votes:

1

Your Vote:

Up

Down

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 [Paessler Support]

Last change on May 6, 2019 12:10:04 PM by  Maike Behnsen [Paessler Support]



23 Replies

Accepted Answer

Votes:

2

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 19 or later

Introduction to the PRTG API Interface

Users can customize and extend the functionality of PRTG Network Monitor using the following options:

  • HTTP API: Access monitoring data and manipulate monitoring objects using 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 small probes to get monitoring data from any platform

An Important Note About Technical Support Regarding API Features

Working with the PRTG API can quickly become a technical challenge and it is no everyday task. In most cases the knowledge of an experienced software developer or web developer is required to work with the API. All API features described on this page as well as their usage are not covered by Paessler's usual next-business-day support. So please understand that it may take a few days to receive an answer to inquiries about API features from Paessler Support. In general we cannot provide support for web design issues involving your own CSS and HTML nor for implementing or adjusting mini probes.


HTTP API

This section will give you a brief overview over the functionalities of the API interface. For detailed instructions see the API documentation (section Detailed HTTP API Documentation below).

The PRTG HTTP API offers the following functionality:

  • Authentication, error handling and optional encryption
  • Functions for getting live object and status data as well as 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

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

Note: Only the documentation that comes with your PRTG installation fits exactly the PRTG version you are running.


Custom Sensors

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

More details about custom sensors:

Note: With PRTG custom sensors, you can use placeholders.


Custom Notifications

Custom notifications allow you to run any script or program as a notification. Connected with a trigger connected with a sensor's settings, you can initiate a desired action—even far beyond a notification itself. This is a powerful tool to react to specific situations in your network.

Among the possibilities are the following scenarios:

Note: With PRTG notifications, you can use placeholders.


Mini Probe API

The PRTG Mini Probe interface allows you to create small probes on any device and on any operating system. They help gathering monitoring data from platforms where it is not possible or not suitable to use the PRTG common local and remote probes. Basically, this takes the Custom Sensors concept to a higher level: You have a very broad range of possibilities and can implement amazing functions.

See the following article for a collection of Mini Probe implementations:


Want to Share Your Script/Program?

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

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

Last change on Apr 4, 2019 12:14:31 PM by  Florian Weik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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 by  Stephan (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

is it possible to get these documantation?

Created on Feb 6, 2014 12:51:32 PM by  Stephan (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  onefstprld (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  tpsrichardson (0)



Votes:

0

Your Vote:

Up

Down

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 by  GwigstaNummerEin (110) 1 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  GwigstaNummerEin (110) 1 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  TorstenSeither (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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

Created on Apr 24, 2019 10:55:29 AM by  TorstenSeither (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  GwigstaNummerEin (110) 1 1



Votes:

0

Your Vote:

Up

Down

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 by  GwigstaNummerEin (110) 1 1



Votes:

0

Your Vote:

Up

Down

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 by  GwigstaNummerEin (110) 1 1



Votes:

0

Your Vote:

Up

Down

@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

Your Vote:

Up

Down

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 by  GwigstaNummerEin (110) 1 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

@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 by  ernst (10) 2



Please log in or register to enter your reply.


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.