-
Notifications
You must be signed in to change notification settings - Fork 32
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
more modular consumables description #63
Conversation
Hi, |
Only if maximum value is available, otherwise current value is used, with a unit. Keeping the same behaviour with the new specification would produce the following results:
As an alternative, this computation could be made server-side by transmitting raw values, ie:
|
My thought about
|
I'm not sure to follow you here, as this double condition doesn't match current agent behaviour. If a value is available for max OID (.1.3.6.1.2.1.43.11.1.1.8.1), the agent currently assumes the current consumable level is a fraction ($current * 100 / $max), and ignores the unit OID (.1.3.6.1.2.1.43.11.1.1.7.1) value, which doesn't include '%' anyway AFAIK. Consider two different consumables, with the following SNMP values: consumableA:
consumableB:
With the current agent behaviour, the consumable A should be reported either by forging a value for unit, to make interpretation easier:
Let's call this scenario A. Or not reporting unit at all, and let the information consumer deduce it's a computed fraction:
Let's call this scenario B. However, if we change the agent behaviour to report raw values directly, it seems safer to not report the unit at all, ie:
Let's call this scenario C. In all case, consumable B would be reported as:
|
I agree with you. Maybe a more appropriate comment would be:
|
bbc1891
to
84a3e10
Compare
See agent PR #660 for original discussion