SNMP Library Support for New-SensorParameters discovery #69
Comments
lordmilko
added
the
enhancement
|
Hi @JustinGrote, As noted on the wiki, PrtgAPI does not currently support retrieving sensor targets or dynamic sensor parameters for sensors that you require you to enter some information before PRTG will load the sensor creation page. SNMP Library sensors fall into this category, and as such can only be created by creating a set of custom parameters. I have had a thought about this previously and believe this external interface for this feature can be implemented by allowing the user to specify a list or dictionary or something to While implementing the external user interface is fairly straight forward to do, what is not clear is how to implement a system to tell you what query parameters should be specified when you fail to enter them properly. Is that even possible? What is the page that is opened to select a SNMP Library when you go to to add the sensor? How does PRTG know that page needs to be opened? What requests are made? These questions will require a bit of investigating to determine the best way to implement the feature. My current priority is getting .NET Core/.NET Standard support shipped, I will add this issue to the roadmap to hopefully tackle after .NET Core support is implemented Regards, |
|
I agree that is priority. I'll write a wrapper for now. Thanks!
…On Wed, Apr 3, 2019, 8:02 PM lordmilko ***@***.***> wrote:
Hi @JustinGrote <https://github.com/JustinGrote>,
As noted on the wiki, PrtgAPI does not currently support retrieving sensor
targets or dynamic sensor parameters for sensors that you require you to
enter some information before PRTG will load the sensor creation page. SNMP
Library sensors fall into this category, and as such can only be created by
creating a set of custom parameters
<https://github.com/lordmilko/PrtgAPI/wiki/Custom-Parameters>.
I have had a thought about this previously and believe this external
interface for this feature can be implemented by allowing the user to
specify a list or dictionary or something to GetSensorTargets /
GetDynamicSensorParameters. In the PowerShell interface this would
presumably be achieved via parameter accepting a hashtable or something.
These *query parameters* would then be passed to
BeginAddSensorQueryParameters, where they would be added as a set
CustomParameter objects
While implementing the external user interface is fairly straight forward
to implement, what is not clear is how to implement a system to *tell you
what query parameters should be specified when you fail to enter them
properly*. Is that even possible? What is the page that is opened to
select a SNMP Library when you go to to add the sensor? How does PRTG know
that page needs to be opened? What requests are made? These questions will
require a bit of investigating to determine the best way to implement the
feature.
My current priority is getting .NET Core/.NET Standard support shipped, I
will add this issue to the roadmap to hopefully tackle after .NET Core
support is implemented
Regards,
lordmilko
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOjVUky37SGGJ6DVjT27bOBowB17NVKoks5vdWs5gaJpZM4cbteZ>
.
|
|
Here's the rough proof of concept, requires my PowerHTML module (on the gallery) as well Examples on my system (some custom sensors visible)~> Get-PRTGSNMPLibraryOIDLibs
ads.Adtran.oidlib
ads.BGP.Peers.oidlib
ads.EIGRP.Peers.oidlib
ads.MIB2.basicinfo.oidlib
ads.Talari.oidlib
APC UPS.oidlib
APCSensorstationlib.oidlib
Basic Linux Library (UCD-SNMP-MIB).oidlib
cisco-interfaces.oidlib
cisco-queue.oidlib
Dell Storage Management.oidlib
Dell Systems Management Instrumentation.oidlib
HP Laserjet Status.oidlib
Linux SNMP (AX BGP DisMan EtherLike Host).oidlib
Linux SNMP (Framework Proxy Noti v2).oidlib
Linux SNMP (IP Net SNMP Noti OSPF RMON SMUX).oidlib
Linux SNMP (Source TCP UCD UDP).oidlib
Paessler Common OID Library.oidlib
SNMP Informant Std.oidlib
Tab Completion works on the second parameter here.
``` powershell
~\desktop> Get-PRTGSnmpLibraryTargets (get-device Test-SDW*) ads.Talari.oidlib
OIDName TargetValue
------- -----------
TALARI-MIBConduit 458795: NORTHCHASE_DR-CANDLER-GAJitter 1.3.6.1.4.1.34086.2.2.17.2.1.12.2|TALARI-MIB|Conduit 458795: NORTHCHASE_DR-CANDLER-GA|Jitter|ms|0|0|Jitter|2|1|0|1|The current best jitter value (in...
TALARI-MIBConduit 458795: NORTHCHASE_DR-CANDLER-GABytes Dropped 1.3.6.1.4.1.34086.2.2.17.2.1.9.2|TALARI-MIB|Conduit 458795: NORTHCHASE_DR-CANDLER-GA|Bytes Dropped|Bytes|0|1|Bytes Dropped|0|1|0|1|The count of byte...
TALARI-MIBConduit 458795: NORTHCHASE_DR-CANDLER-GABytes In 1.3.6.1.4.1.34086.2.2.17.2.1.7.2|TALARI-MIB|Conduit 458795: NORTHCHASE_DR-CANDLER-GA|Bytes In|Bytes|0|1|Bytes In|0|1|0|1|The count of bytes received...
TALARI-MIBConduit 458795: NORTHCHASE_DR-CANDLER-GASent 1.3.6.1.4.1.34086.2.2.17.2.1.5.2|TALARI-MIB|Conduit 458795: NORTHCHASE_DR-CANDLER-GA|Sent|Bytes|0|1|Sent|0|1|0|1|The count of bytes sent for this Co...
TALARI-MIBConduit 458795: NORTHCHASE_DR-CANDLER-GAState 1.3.6.1.4.1.34086.2.2.17.2.1.4.2|TALARI-MIB|Conduit 458795: NORTHCHASE_DR-CANDLER-GA|State|#|0|0|State|2|1|0|1|The current operational state of the ...
TALARI-MIBConduit 458795: NORTHCHASE_DR-CANDLER-GAID 1.3.6.1.4.1.34086.2.2.17.2.1.2.2|TALARI-MIB|Conduit 458795: NORTHCHASE_DR-CANDLER-GA|ID|#|0|0|ID|2|1|0|1|The unique Talari ID for the Conduit.|0|0|0...
TALARI-MIBConduit 7: INTERNAP-COLO-CANDLER-GAJitter 1.3.6.1.4.1.34086.2.2.17.2.1.12.1|TALARI-MIB|Conduit 7: INTERNAP-COLO-CANDLER-GA|Jitter|ms|0|0|Jitter|2|1|0|1|The current best jitter value (in mill...
TALARI-MIBConduit 7: INTERNAP-COLO-CANDLER-GABytes Dropped 1.3.6.1.4.1.34086.2.2.17.2.1.9.1|TALARI-MIB|Conduit 7: INTERNAP-COLO-CANDLER-GA|Bytes Dropped|Bytes|0|1|Bytes Dropped|0|1|0|1|The count of bytes dro...
TALARI-MIBConduit 7: INTERNAP-COLO-CANDLER-GABytes In 1.3.6.1.4.1.34086.2.2.17.2.1.7.1|TALARI-MIB|Conduit 7: INTERNAP-COLO-CANDLER-GA|Bytes In|Bytes|0|1|Bytes In|0|1|0|1|The count of bytes received for ...
TALARI-MIBConduit 7: INTERNAP-COLO-CANDLER-GASent 1.3.6.1.4.1.34086.2.2.17.2.1.5.1|TALARI-MIB|Conduit 7: INTERNAP-COLO-CANDLER-GA|Sent|Bytes|0|1|Sent|0|1|0|1|The count of bytes sent for this Conduit...
TALARI-MIBConduit 7: INTERNAP-COLO-CANDLER-GAState 1.3.6.1.4.1.34086.2.2.17.2.1.4.1|TALARI-MIB|Conduit 7: INTERNAP-COLO-CANDLER-GA|State|#|0|0|State|2|1|0|1|The current operational state of the condu...
TALARI-MIBConduit 7: INTERNAP-COLO-CANDLER-GAID 1.3.6.1.4.1.34086.2.2.17.2.1.2.1|TALARI-MIB|Conduit 7: INTERNAP-COLO-CANDLER-GA|ID|#|0|0|ID|2|1|0|1|The unique Talari ID for the Conduit.|0|0|0|0||1...
TALARI-MIBWan Link 12: CAN-CENTURYLINK1Bytes Dropped 1.3.6.1.4.1.34086.2.2.16.2.1.9.1|TALARI-MIB|Wan Link 12: CAN-CENTURYLINK1|Bytes Dropped|Bytes|0|1|Bytes Dropped|0|1|0|1|The count of bytes dropped ...
TALARI-MIBWan Link 12: CAN-CENTURYLINK1Bytes In 1.3.6.1.4.1.34086.2.2.16.2.1.7.1|TALARI-MIB|Wan Link 12: CAN-CENTURYLINK1|Bytes In|Bytes|0|1|Bytes In|0|1|0|1|The count of bytes received for this ...
TALARI-MIBWan Link 12: CAN-CENTURYLINK1Bytes Out 1.3.6.1.4.1.34086.2.2.16.2.1.5.1|TALARI-MIB|Wan Link 12: CAN-CENTURYLINK1|Bytes Out|Bytes|0|1|Bytes Out|0|1|0|1|The count of bytes sent for this WA...
TALARI-MIBWan Link 12: CAN-CENTURYLINK1State 1.3.6.1.4.1.34086.2.2.16.2.1.4.1|TALARI-MIB|Wan Link 12: CAN-CENTURYLINK1|State|#|0|0|State|2|1|0|1|The current operational state of the conduit.|0...
TALARI-MIBWan Link 12: CAN-CENTURYLINK1ID 1.3.6.1.4.1.34086.2.2.16.2.1.2.1|TALARI-MIB|Wan Link 12: CAN-CENTURYLINK1|ID|#|0|0|ID|2|1|0|1|The unique Talari ID for the WAN Link.|0|0|0|0||1.3.6...
TALARI-MIBWan Link 13: CAN-COMCAST1Bytes Dropped 1.3.6.1.4.1.34086.2.2.16.2.1.9.2|TALARI-MIB|Wan Link 13: CAN-COMCAST1|Bytes Dropped|Bytes|0|1|Bytes Dropped|0|1|0|1|The count of bytes dropped for ...
TALARI-MIBWan Link 13: CAN-COMCAST1Bytes In 1.3.6.1.4.1.34086.2.2.16.2.1.7.2|TALARI-MIB|Wan Link 13: CAN-COMCAST1|Bytes In|Bytes|0|1|Bytes In|0|1|0|1|The count of bytes received for this WAN ...
TALARI-MIBWan Link 13: CAN-COMCAST1Bytes Out 1.3.6.1.4.1.34086.2.2.16.2.1.5.2|TALARI-MIB|Wan Link 13: CAN-COMCAST1|Bytes Out|Bytes|0|1|Bytes Out|0|1|0|1|The count of bytes sent for this WAN Li...
TALARI-MIBWan Link 13: CAN-COMCAST1State 1.3.6.1.4.1.34086.2.2.16.2.1.4.2|TALARI-MIB|Wan Link 13: CAN-COMCAST1|State|#|0|0|State|2|1|0|1|The current operational state of the conduit.|0|0|0...
TALARI-MIBWan Link 13: CAN-COMCAST1ID 1.3.6.1.4.1.34086.2.2.16.2.1.2.2|TALARI-MIB|Wan Link 13: CAN-COMCAST1|ID|#|0|0|ID|2|1|0|1|The unique Talari ID for the WAN Link.|0|0|0|0||1.3.6.1.4...Bringing it all together (Autodiscover Talari MIB on systems and only onboard the WAN Links, not the Conduits)$device = (get-device -id 8322)
$targets = Get-PRTGSNMPLibraryTargets -device $device -OIDLibName 'ads.Talari.oidlib' | where oidname -match 'MIBWan'
$sensorParameters = New-SensorParameters -RawType snmplibrary -device $device
Add-PrtgSnmpLibrarySensor $targets $device $sensorParametersResult: Only WAN Link Sensors Onboarded. Could have also manipulated the sensor parameters to change priority, etc. Contributes
Quirks Learned
Is there any way to get at the httpclient that the PRTGClient uses? Maybe expose it as a public property? EDIT: Bonus Script to auto-rename the created SNMP tables to something nicer if (-not (Get-PRTGClient)) {throw "You must be connected to a PRTG Server First"}
$snmpTableNameRegex = '^Table\((.+)\): .+}$'
$sensors = Get-Sensor -Filter (New-SearchFilter type eq snmpcustomtable) | where name -match $snmpTableNameRegex
foreach ($sensorItem in $sensors) {
$newSensorName = $sensorItem.name -replace $snmpTableNameRegex,'$1'
write-host -fore green "$($sensorItem.Device): Renaming $($sensorItem.Name) to $newSensorName"
$sensorItem | Rename-Object $newSensorName
} |
|
Thanks @JustinGrote, I'm not sure what the rules are like in the current version of PRTG and/or for SNMP Library sensors, however generally speaking the I can see you're right - SNMP Library sensors do appear to utilize a parameter called PrtgAPI currently supports the The fact PrtgAPI uses a I can see that the complexity of implementing this feature is quickly blowing up; I'm glad I made the decision to put a pin in this for now! :P Regards, |
|
Yes it's not a simple fix. My main concern of getting at your HttpClient is
that it maintains the state and cookies, and you can use that instead of
constantly passing username and passhash, so I can run commands "in module
scope" of sorts without having to instantiate a new session.
In regards to tmpid you'll see I do preserve it all the way through
addsensor thorugh addsensor4, my point was just that it doesn't appear you
need it for the addsensor5 step.
The sensortypes.json offers a boatload of information about sensors so it's
a good starting point for building parameters, hence why I made the
autocomplete as a proof of concept.
100% agree core comes first, I just had a pressing need for this (need to
onboard about 500 snmp library sensors for Talari systems that all have
different interface indexes and some need to be filtered), so I just wanted
to check that I wasn't reinventing the wheel.
…On Fri, Apr 5, 2019 at 1:49 AM lordmilko ***@***.***> wrote:
Thanks @JustinGrote <https://github.com/JustinGrote>,
I'm not sure what the rules are like in the current version of PRTG and/or
for SNMP Library sensors, however generally speaking the tmpid and cookie
are definitely *not* optional. In my experience, failure to maintain the
correct state when performing sensor creation queries will result in PRTG
responding that a session is no longer valid. This is definitely true of
sensors that take a long time to query; if you don't identify your session,
how will PRTG know what progress percentage your request is up to? The only
page that is stateless is the page that actually creates the sensor,
addsensor5.htm
I can see you're right - SNMP Library sensors do appear to utilize a
parameter called name, not name_. I'll need to figure out an appropriate
way to implement this in a way that works for both dynamic sensor
parameters and raw parameters.
PrtgAPI currently supports the api/sensortypes.json endpoint through the
Get-SensorType cmdlet. Currently however it only deserializes the bare
minimum of properties. From a quick check I can see that calling this page
is the technique PRTG uses itself, so I will need to expand the properties
of the SensorTypeDescriptor type.
The fact PrtgAPI uses a HttpClient is an implementation detail. My
HttpClient doesn't really do anything that yours doesn't do. The only
part of PrtgAPI that even knows a HttpClient is the class
<https://github.com/lordmilko/PrtgAPI/blob/master/PrtgAPI/Request/PrtgWebClient.cs>
the implements the IWebClient
<https://github.com/lordmilko/PrtgAPI/blob/master/PrtgAPI/Request/IWebClient.cs>
interface. If PrtgAPI's existing extension mechanisms (supporting "raw"
values, etc) do not support a given feature, users can either invoke the
request directly via Invoke-WebRequest, etc as a one off, or modify the
PrtgAPI source code specifically for their use case.
I can see that the complexity of implementing this feature is quickly
blowing up; I'm glad I made the decision to put a pin in this for now! :P
Regards,
lordmilko
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOjVUlpPOFDe5qTWPPqunMFqWq-hnJTJks5vdw4CgaJpZM4cbteZ>
.
|
|
Hi @JustinGrote, I am currently doing some research into the implementation of this feature. Are you able to advise whether you are aware of any other sensor types that give initial prompts in the PRTG UI prior to taking you to the normal sensor creation page? So far, I am aware of the following types
Depending on the types of information you can get away with not specifying during the requests leading up to the normal sensor creation page, this will determine how simple or complicated the API for this will have to be Regards, |
|
I'm not aware of any outside of SNMP Library off the top of my head, short
of taking the time to click every sensor and find out :/
…On Sun, Apr 28, 2019 at 3:48 AM lordmilko ***@***.***> wrote:
Hi @JustinGrote <https://github.com/JustinGrote>,
I am currently doing some research into the implementation of this feature.
Are you able to advise whether you are aware of any other sensor types
that give initial prompts in the PRTG UI prior to taking you to the normal
sensor creation page?
So far, I am aware of the following types
SensorType Stage Content Mandatory
snmplibrary After addsensor2.htm Preselection Yes
oracletablespace After addsensor3.htm Partial query No
Depending on the types of information you can get away with not specifying
during the requests leading up to the normal sensor creation page, this
will determine how simple or complicated the API for this will have to be
Regards,
lordmilko
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUNKUXQCWXQESPPHWK5JRDPSV6INANCNFSM4HDO26MQ>
.
|
…roperties on NewObjectParameters (#69) -DynamicSensorParameters will automatically override the names of any properties based on properties contained in the PRTG response
…rying sensor targets and retrieving dynamic sensor parameters (#69) -Sensor query targets can now be retrieved from GetSensorTypes / Get-SensorType -Sensor query targets can be specified as SensorQueryTarget objects or as sensor query target parameter objects, representing a set of parameters required to retrieve the data required to create the specified sensor (such as IPMI authentication details, OAuth tokens, etc)
|
Hi @JustinGrote, Please be advised that PrtgAPI 0.9.7 has now been released, which includes fixes for these issues To update to the latest version, run Update-Module PrtgAPIand reopen PowerShell. Please see the release notes for a list of breaking changes that may affect you. PrtgAPI 0.9.7 introduces the concept of sensor query targets, which unlike sensor targets, merely specify the target that a query should apply to (such as the oidlib to use for an SNMP Library, the details of a database server or the authentication details to use for a niche sensor type). For more information on sensor query targets, please see the wiki. In your case, you should now be able to create a sensor for the oidlib $device = Get-Device -Id 8322
$params = $device | New-SensorParameters -RawType snmplibrary -qt "ads.Talari.oidlib"
$device | Add-Sensor $paramsAttempting to query dynamic sensor parameters or sensor targets of a sensor type that requires some type of sensor query target will now generate an
For sensor types that require multiple values be specified, you can do so using the new $params = $device | New-SensorParameters -RawType ipmisensor -qp @{
username = "admin"
password = "password"
}For sensor types that require custom parameter names be used for common parameters defined under Thanks for raising this issue! Regards, |
|
@lordmilko I apologize I got pulled off to another priority and didn't get to test this. Initially the parameter discovery works great and I get all the relevant OIDs for the SNMPLibrary $sensorparameters = new-sensorparameters -RawType snmplibrary -QueryTarget 'ads.Talari.oidlib' -device (get-device -id 8322) -verbose
$sensorparameters.targets.interfacenumber__checkHowever, in attempting to create the sensor itself, it only creates the first channel of the first sensor. What is expected is to create 4 interface sensors with individual channels each (22 channels total) as my powershell above and the GUI do. I tried creating it in this fashion: Let me know if the syntax is correct or if I need to go about it otherwise. I also would assume if I filtered the targets property and only wanted to create a couple of the OIDs, that it would work as expected if I edited that property. |
|
Hi @JustinGrote, By default only the first sensor target is selected. Therefore you need to add Regards, |
|
@lordmilko So the target parameter is useless in this scenario and should allow for a richer evaluation. I was able to get it to work by unlocking the returned object and filtering out the unwanted targets, but obviously unlocking is an "off the reservation activity" $sp = new-sensorparameters -rawtype snmplibrary -device $device -querytarget 'ads.talari.oidlib' -target '*'
$sp.unlock()
$sp.interfacenumber__check = $sp.interfacenumber__check.where{$PSItem.properties[2] -notmatch 'Centurylink'}
|
|
As per the wiki, you can either filter by # Untested but more or less correct
$params = new-sensorparameters -rawtype snmplibrary -device $device -querytarget 'ads.talari.oidlib'
$params.interfacenumber__check = $params.Targets.interfacenumber__check | where { $_.properties[2] -notmatch 'Centurylink' } |
|
In regards to your query (now deleted?) the
As a result of this, any property that does represent a sensor target will only have the first sensor target in the list. While I can think of a number of scenarios where selecting all targets by default would be useful (WMI Volumes, VMware Datastores, Exchange Databases, etc) there are other scenarios where it wouldn't be (WMI Services - you sure don't want a sensor for all 200 services on your system!) Bottom line, for now I have decided not to go the additional step of selecting all of the targets by default, and have left it up to users to specify what they want. If you really do want to select all targets, it's not that hard to add In your case however, you don't want to specify |
|
@lordmilko I deleted it as I sorted it out but I appreciate the
explanation.
…On Mon, Jul 8, 2019, 10:42 PM lordmilko ***@***.***> wrote:
In regards to your query (now deleted?) the DynamicSensorParameters type
constructs itself by
1. Instantiating its parameters using their default values, and then
2. Constructing a dictionary of values that appear to be suitable as
sensor targets
As a result of this, any property that *does* represent a sensor target
will only have the first sensor target in the list. While I can think of a
number of scenarios where selecting all targets by default would be useful
(WMI Volumes, VMware Datastores, Exchange Databases, etc) there are other
scenarios where it wouldn't be (WMI Services - you sure don't want a sensor
for all 200 services on your system!)
Bottom line, for now I have decided not to go the additional step of
selecting all of the targets by default, and have left it up to users to
specify what they want. If you really do want to select all targets, it's
not that hard to add -Target * to your call to New-SensorParamters`.
In your case however, you *don't* want to specify -Target * you should
simply filter the targets via the Targets property of the parameters
object *after* the object has been created
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69?email_source=notifications&email_token=ADUNKUTR6MEZ5Z7OQOGCXP3P6QQNHA5CNFSM4HDO26M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZPE4WI#issuecomment-509496921>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUNKUVL3OQ4I7CUMYFMMWLP6QQNHANCNFSM4HDO26MQ>
.
|
With the current PRTG version, Fiddler shows that a special syntax is required to get the dynamic parameters of SNMP Libraries.
https://myserver/controls/addsensor2.htm?id=8322&sensortype=snmplibrary_nolist&preselection_snmplibrary_nolist=ads.Talari.oidlib
(Note the preselection_snmplibrary_nolist)
Currently I don't see a way to specify the preselection parameter in the current PRTGAPI
Here's a simple proof of concept using httpClient in Powershell (couldn't get Invoke-Restmethod to work due to the additional unremovable headres it adds) for getting the raw HTML containing the table values.
Example Table Entry
Implementation Proposal
Lots of different ways this could be done, @lordmilko I invite feedback if you've done any existing work on this and have any plans, otherwise I will write a Powershell function that will parse the table with HTMLAgilityPack, and produce a SensorParameters that can be passed to add-sensor and make it available as a Gist or something. The list of OIDLIB files is in /api/sensortypes.json so I would make it query that for an autocompleter.
The text was updated successfully, but these errors were encountered: