-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature request] Allow indexed ID to be specified in the middle of OID for SNMP metric #324
Comments
+1 |
2 similar comments
+1 |
+1 |
I actually came across the exact same issue with Raritan PDUs… Definitely another +1 for this.
- Tim
… On 12 Feb 2018, at 12:58 pm, Dan Houtz ***@***.***> wrote:
Hi,
I'm currently trying to poll our Raritan PDUs to get per outlet metrics however I've run into an issue due to the OID layout that Raritan uses. Unlike most indexed tables I've dealt with, such as ifTable, where the indexed instance is appended to the end the of the OID, Raritan puts the index mid OID.
For example, to get the current Watts being pulled from an outlet you would use:
.1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.5
To get the current for outlet:
1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.1
In this case the specific outlet on the PDU (1-24) comes before the counter (5 for Watts, 1 for Current).
Unless I'm overlooking something this makes it impossible to define an SNMP metric with the OID and then define an Influx Measurement with a GetMode Indexed SNMP Table.
I think this could be solved by defining where the index goes in the OID when defining a new SNMP metric. Currently I believe they are just added to the end.
Link to Raritan SNMP MIB Doc: http://support.raritan.com/px2/version-3.0.0/PX2_MIB_Guide.pdf <http://support.raritan.com/px2/version-3.0.0/PX2_MIB_Guide.pdf>
Section
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#324>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFFaS2mPyLU1nGQL-T_vVXhRYFLlE030ks5tT5rQgaJpZM4SBnd2>.
|
+1 |
Hi guys, Sorry for the late answer and thanks for the explanation. As I answered on the related issue, this feature requires a huge change on the core metric/measurement behaviour, we are thinking on it, but it would take some time to do it Thanks for the patience!! |
+1 for this. I have a similar issue with Cisco WLC's. The Index is by Access Point name however to pull something like clients per Access Point the information is presented per radio and a .0 and .1 is appended to each OID. |
+1 In the case of IP SLA, there could even be multiple "dot" after the index... Here is an example: |
+1 @jasonyates Did you finalize implementing the WLC collections? If yes would you care in shearing an export of the "Measurement Groups" |
+1 |
@toni-moreno i have about the same requirements on some devices. So i have forked your collector and tried to understand your code and implement a running solution which works fine for my cases. My solution idea was: We have a oid like previous discussed from @dhoutz:
In my case i have the following oids:
So i created an measurement (indexed with direct tag): This oid gives the first indexes -> variable I created a metric with the Base OID: After debugging the collector i realized that you fetch all variables correct with the get bulk operation. So i changed the struct, so that i can store all variables in a map where the key is the first index:
To split indexes with values i had to change the SnmpWalkData method:
I had also changed many other methods, like the convertion methods.
My questions to you @toni-moreno:
|
Hi @wurmrobert , thanks a lot for your suggestion, and sorry for the delay in the answer. I think this could be a good staring point, but we need to review first... Could you send us a Pull Request with your changes , please ? Thanks a lot! |
Hey, |
Hello @wurmrobert, I would like to release a new version with this new feature. would be great if you could send us a PR with your changes. ( don't worry if there is some merge conflict) , we can rebase for you. Thank you very much. |
I need this feature as well because of some Qos tables where the Index referring the interface is not located at the end of the OID. For example:
Where "109" is the interface Index. BR, Jes |
Hi,
I'm currently trying to poll our Raritan PDUs to get per outlet metrics however I've run into an issue due to the OID layout that Raritan uses. Unlike most indexed tables I've dealt with, such as ifTable, where the indexed instance is appended to the end the of the OID, Raritan puts the index mid OID.
For example, to get the current Watts being pulled from an outlet you would use:
.1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.5
To get the current for outlet:
1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.1
In this case the specific outlet on the PDU (1-24) comes before the counter (5 for Watts, 1 for Current).
Unless I'm overlooking something this makes it impossible to define an SNMP metric with the OID and then define an Influx Measurement with a GetMode Indexed SNMP Table.
I think this could be solved by defining where the index goes in the OID when defining a new SNMP metric. Currently I believe they are just added to the end.
Link to Raritan SNMP MIB Doc: http://support.raritan.com/px2/version-3.0.0/PX2_MIB_Guide.pdf
Section
The text was updated successfully, but these errors were encountered: