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

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.

is it possible to get these documantation?

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.

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?

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

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!

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 ).

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

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.

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

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)

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

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

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

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.

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.

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.

@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! :)

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.

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 :)

@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.