[snmp] add scale factor in snmp metrics

[pducolin]

What does this PR do?

Add scale_factor option to metric, to enable abstraction over snmp metrics representing same concepts, in different scales.

Motivation

This change is motivated by our will to provide memory usage metrics. Across all devices that exposes these metrics, they appear as:

• memory usage, in percent
• memory free/used/available, in bytes or kilobytes depending on the supported MIB

Such metrics have names that are strictly related to the MIB they are defined on. For example, Cisco supports ciscoMemoryPoolUsed, Aruba sysExtMemoryUsed

We want to be able to abstract across all these different names, and send generic metrics such as metric.usage, metric.used, metric.free, metric.available.

As metadata.csv supports one unit per metric, we need to implement an abstraction mechanism before submission, thus we are adding a scale factor.

In the example of memory.used, we will specify its unit as byte in metadata.csv, and for MIB exposing this metric in KB, we will add a factor of 1000

Additional Notes

scale_factor supports only numbers: this doesn't cover all possible scenarios in SNMP, as some SNMP metrics' units are defined in OIDs. We considered supporting scale factor defined in other OIDs too complex for now.

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

• add scale_factor to the symbol definition of scalar metric
• verify metric is multiplied by the scale factor
• add scale_factor to the symbol definition of a column metric
• verify metric is multiplied by the scale factor

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• At least one team/.. label has been applied, indicating the team(s) that should QA this change.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the config template has been updated.

[cswatt]

no docs review required

[AlexandreYang]

Thanks for the changes.

[AlexandreYang]

👍

[gmarabout]

Nice 👍🏻

[gmarabout]

Great work!