New-PrtgSnmpTrafficSensor

[FaustoNascimento]

@sandersjds, @brianaddicks can I ask where you got the string interfacenumber__check from?

I'm looking to create a function for the SNMP Disk Free sensor and struggling with finding out what the API expects.

Thx,
Fausto

[sandersjds]

We found it by watching the request/response headers (using something like the Chrome DevTools' Network tab) while creating the sensors. The request you're looking for will be "addsensor5.htm".

These are probably the fields you're looking for, although I'm not sure what data/format the disk__check one is expecting. My next step would be to guess-and-check on the values to see how it works.

• disk_:1
• disk__check:7|/vmfs/volumes/software|Network Disk|
• sensortype:snmpdiskfree

[FaustoNascimento]

Actually found an "easier" way. The IIS log from PRTG, which is held on %programdata%\Paessler\PRTG Network Monitor\Logs (Web Server) has a full detail of all incoming and outgoing requests and parameters passed.

Also for info purposes:

• disk_ has to always be 1
• disk__check comprises of 3 parameters:
  • the index of the disk as it appears in SNMP, for Windows devices the OID to query is ".1.3.6.1.2.1.25.2.3.1.1"
  • the "name" of the volume to query as per what SNMP reports. On Windows devices, this string is retrieved using OID ".1.3.6.1.2.1.25.2.3.1.3"
  • the type of disk to query. Windows devices uses OID ".1.3.6.1.2.1.25.2.3.1.2" for this, though the string that PRTG expects somewhat differs from the convention. I know the strings Fixed Disk and Network Disk, that's it.

Fausto

[sandersjds]

Ha, I'm not sure I agree that monitoring the logs is "easier," but I'm glad you were able to find the values.

[FaustoNascimento]

sandersjds: on another note, I have started creating my own PRTG module which is also on Github. It's still very new so many functions missing, but what I tried to do was remove such a massive dependency on multiple HTTP handling functions and replace them all with one.

As a rule of thumb, I also don't like having internal only functions, so I tried to get rid of that too.

Feel free to have a browse and if you feel like it we can combine our projects!

[FaustoNascimento]

I've gone down a slightly different route when creating sensors.

Instead of attempting to build the '__check' string myself which involved decoding what each of the values meant, whether they were important or not, and then leaving the user with the trouble of using SNMP to query the device to find out which objects were available (which, if the device was on another network with firewalls in between and only the probe could reach out made things incredibly difficult)...

I now don't create the __check string at all. Instead, I use PRTG itself to query which available values there are for whatever sensor the user is trying to create (which removes dependency on user having to find these values out themselves and any firewall restrictions, since it's all done via PRTG) and pass that to the new sensor function.

The returned values already include the fully built __check string, so I don't need to worry about that. More importantly, if Paessler decide to change the format of that string, I do not need to make any changes on my module.

If you're interested in contributing or having a look, here's the link:

https://github.com/FaustoNascimento/PRTGFn