Re: RRD data collection irregularity

Hi John,

sorry for the late answer. I just looked into mib2-graph.properties and found that you probably can make your config more "stable", being independent from the step size. Also it might be more accurate, as the time step is not always exactly how it's defined, there probably is some jitter included as you can check from the timestamps in the rrd files (due to response time problems etc.).

Here are two samples from mib2-graph.properties:

CDEF:outSum=bytesOut,{diffTime},* \
CDEF:inSum=bytesIn,{diffTime},* \

So instead of using a fixed time interval of 300 seconds you probably should use the {diffTime}, this will prevent from jitter problems and will be "stable" if someone changes the polling interval.

-Michael




Von: JohnD Blackburn <[email protected]>
Gesendet: Freitag, 21. September 2018 03:13
An: General OpenNMS Discussion <[email protected]>
Betreff: Re: [opennms-discuss] RRD data collection irregularity

I'm still using the Counter32 type, but I've added the following CDEF entries to the snmp-graph properties file

CDEF:ctot=0.5,tot,300,*,+,FLOOR \
CDEF:cexst=0.5,exst,300,*,+,FLOOR \
CDEF:ccrt=0.5,crt,300,*,+,FLOOR \
CDEF:cnwi=0.5,nwi,300,*,+,FLOOR \
CDEF:cluf=0.5,luf,300,*,+,FLOOR \
CDEF:cnis=0.5,nis,300,*,+,FLOOR \

I'm adding .5 so I can round the result.  This is now displaying the way I'm expecting it.

[cid:[email protected]]








From: JohnD Blackburn [mailto:[email protected]]
Sent: Thursday, 20 September 2018 4:37 PM
To: General OpenNMS Discussion <[email protected]>
Subject: Re: [opennms-discuss] RRD data collection irregularity

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

This is what I get back walking the OID .1.3.6.1.4.1.2021.16.2.1.5 directly:

UCD-SNMP-MIB::logMatchGlobalCounter.1 = Counter32: 3365
UCD-SNMP-MIB::logMatchGlobalCounter.2 = Counter32: 3232
UCD-SNMP-MIB::logMatchGlobalCounter.3 = Counter32: 132
UCD-SNMP-MIB::logMatchGlobalCounter.4 = Counter32: 459
UCD-SNMP-MIB::logMatchGlobalCounter.5 = Counter32: 1323
UCD-SNMP-MIB::logMatchGlobalCounter.6 = Counter32: 1445


Using gauge32 doesn't work as the value returned is increasing, and when I graph it, I just see an increasing line, rather than a line that reflects the change.

I'll try changing my graph to multiply by the time interval (300) to see if that fixes the scale of the graph.  Good to know that the stored value is divided by the time interval.  That is probably what is throwing out the values.

Regards,
John









From: Seibold, Michael [mailto:[email protected]]
Sent: Thursday, 20 September 2018 4:21 PM
To: General OpenNMS Discussion <[email protected]<mailto:[email protected]>>
Subject: Re: [opennms-discuss] RRD data collection irregularity

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi John,


  1.  if you use Counter32 the measured values get divided by the time interval (in seconds) between the measurement points, so you should use Gauge or Gauge32 instead of Counter32 if you want to see those values directly, otherwise there will be rfTotalCalls/Second etc. in the rrd files.
  2.  I'm not sure about the output from collectd you provided - are you shure you are getting integer values back or might there are string values? You can check this using snmpwalk for the OID . 1.3.6.1.4.1.2021.16.2.1.5 directly.

For the ifmib output is like this:
IF-MIB::ifInUcastPkts.527696832 = Counter32: 270331006

-Michael

_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss