ZenPacks, JSON API, and Integrations

Expand all | Collapse all

Access previous metric values from Data Source

  • 1.  Access previous metric values from Data Source

    Posted 11-25-2020 10:05 AM
    Edited by Peter 11-25-2020 10:07 AM
    I currently have a Data Source that uses an SSH script to grab some statistics from a networking device. These statistics are from the previous 2 minutes and show very recent changes. However, due to operation reasons, I'd like to move away from using SSH for this check.

    It turns out that this data is also available via SNMP, which is the preferred method. However, the statistics are only accessible as lifetime values, which are extremely large and anything but massive changes would be detectable. A 10% change in values on the CLI output might be a 0.0001% change in the lifetime values. Not great.

    I would like to create a custom Data Source that collects the statistics from SNMP and only consider the most recent values. However, I don't know how to access a previous value for a metric. Is this even possible in a Zenoss Data Source? In Nagios you could send previous performance data along to a check plugin, but Zenoss doesn't have that feature.

    Is this something that Zenoss can do?

    I intend to create this as a Python Data Source, and if I am able to efficiently access previous metric values, it would help me transition the check to something more reliable.

    Peter


  • 2.  RE: Access previous metric values from Data Source

    Posted 11-25-2020 07:29 PM
    Edited by Michael 11-25-2020 07:30 PM
    Peter,

    I think regular SNMP datasources will already do what you're looking for, as long as you configure the datapoint with the correct type for your data.  Since Zenoss originally stored perf data in .rrd files, we still use Tobias Oetiker's data source types:

    DST (Data Source Type) defines the type of the DS. It can be COUNTER, DERIVE, ABSOLUTE, GAUGE. A DS declared as COUNTER will save the rate of change of the value over a step period. This assumes that the value is always increasing (the difference between the current and the previous value is greater than 0). Traffic counters on a router are an ideal candidate for using COUNTER as DST. DERIVE is the same as COUNTER, but it allows negative values as well. If you want to see the rate of change in free disk space on your server, then you might want to use the DERIVE data type. ABSOLUTE also saves the rate of change, but it assumes that the previous value is set to 0. The difference between the current and the previous value is always equal to the current value. Thus it just stores the current value divided by the step interval (300 seconds in our example). GAUGE does not save the rate of change. It saves the actual value itself. There are no divisions or calculations. Memory consumption in a server is a typical example of gauge. The difference between the different types DSTs can be explained better with the following example:

    From https://oss.oetiker.ch/rrdtool/tut/rrd-beginners.en.html

    Mind you, this all depends on whether or not the the SNMP OID for the lifetime value 1) updates in a timely fashion and 2) has enough precision that the change over your cycle time is detectable.  Do two snmpgets separated by 5 minutes show a change in the value, or are the differences rounded off?

    I'll be checking the forums from time to time over the holiday weekend, so feel free to throw in any additional info.  If we know the specific OID, we may go digging through the MIB file to see if something better crops up?

    ------------------------------
    Michael J. Rogers
    Senior Instructor - Zenoss
    Austin TX
    ------------------------------