[mrtg] Discontinuity at midnight

[Mathew Marulla]

The OIDs for those two graphs are:

New Connections: sysStatClientTotConns.0&sysStatServerTotConns.0:public@<<IP Address Here>>:::::2

Established Connections: sysStatClientCurConns.0&sysStatServerCurConns.0:public@<<IP Address Here>>:::::2

Other ones I am graphing are:

Client Traffic:  sysStatClientBytesOut.0&sysStatClientBytesIn.0:public@<<IP Address Here>>:::::2
Server Traffic:  sysStatServerBytesIn.0&sysStatServerBytesOut.0:public@<<IP Address Here>>:::::2
HTTP Requests:  sysStatHttpRequests.0&sysStatHttpRequests.0:public@<<IP Address Here>>:::::2
RAM in Use:  ( sysStatMemoryUsed.0&sysStatMemoryUsed.0:public@<<IP Address Here>>:::::2 / sysStatMemoryTotal.0&sysStatMemoryTotal.0:public@<<IP Address Here>>:::::2 ) * 100

I solved the discontinuity at midnight issue.  SNMP and MRTG are correct - the drop in traffic right at midnight is real.  There is nothing in the F5 that is responsible for this.  There are policies on the servers that cause certain traffic to be reset at midnight.

- Matt


On Dec 19, 2012, at 6:50 PM, Steve Shipway <s.shipway at auckland.ac.nz> wrote:

> What are the two OIDs you are graphing?  I assume one of them is the global total connections... a suitable-sanitised snippet of your cfg file would be helpful here.
>  
> I’m particularly interested in this as Im in the process of fully monitoring our F5 – I have created a plugin for Nagios and MRTG to pull out not only this data, but also other performance and health data on a global, cluster or per-VIP basis, and am keen to avoid any potential problems (if you want a copy of the beta plugin, it is available on www.nagiosexchange.org)
>  
> A collection of the raw data might help (to see if there really IS a sudden dropoff in connection rate at midnight); also your own knowledge of how the F5 is being used and by what might let you find out about changes in usage patterns at midnight, or any scheduled tasks or resets you have in client machines at that time.  I can’t help you with that of course.
>  
> We run several F5s in multiple clusters and have not observed this sort behaviour either singly or as a cluster, except when a cluster fails over to the other F5 member.  For this reason, I suspect the data are valid, and caused by some other even on your network or application servers.
>  
> Steve 
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20121220/71bd89e6/attachment.htm