-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
SNMP table not a table #1371
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request
Proposal:
There are 2 changes I think would make the SNMP table output more intuitive.
Current behavior:
Currently the plugin provides output such as:
This is not a table. A table is a key with multiple fields/values.
Desired behavior:
For example, this is how the
cpu
plugin outputs its data:Note how it has a key of
cpu
, with multiple fields. Not a separate line & key for each field.Thus our earlier table might instead look something like:
Now another deviation is the units. In other plugins, such as the disk plugin, the unit is not a tag, it's in the field name. For example:
This has several very significant benefits over putting the unit in a tag. First, it lets you use different units for different fields. Second, it lets you put multiple fields on a single line. Third, when graphing, the unit shows up in the graph legend (as a tag, there's no way to get it at all when graphing).
Granted, there's nothing stopping people from putting the unit in the field name now, but providing a
unit
option, which is added a tag is highly confusing. I think it would be much better if it were removed as an explicit option, and instead we provide the option to add arbitrary tags, so if people really want to add it as a tag, they can.Use case:
The main thing these changes bring is consistency & expected behavior.
I expect SNMP tables to actually generate a table. This is how it works in every other tool I've worked with which handles SNMP tables. I've never had one generate a separate table for every metric, with only a single field.
It also makes the behavior consistent with other plugins. It's rather odd that this one plugin behaves different from all the other built-in plugins (at least the ones I've used).
The text was updated successfully, but these errors were encountered: