-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Very interesting. Thank you for clarifying it.
My problem is, as you can see from the graphing function, I am arbitrarily taking numerous rrds and adding them together to get a cumulative graph. While some of these summation graphs are predictable, many are not; thus I can't store a cumulative rrd in all situations. My goal is to minimize this disparity that is caused by taking the MAX of a consolidated function. I am going to see if using the AVG instead of the MAX of the consolidated function will help, but if I really want to fix this, my only recourse is to not consolidate? I'd be storing a 1years worth of 1min slices for ~5000 devices. On 06/08/2015 10:01 AM, Simon Hobson wrote: > I wrote: > >> So when you draw a graph over a longer time period, depending on the >> consolidation, you may >> see your maximum value go up (with these made up figures, by 1/3) when you >> add max values >> together. > > > To add ... > > I had something similar for some of my servers - I wanted a maximum mail > queue size across > several servers. Simply adding the max queue sizes doesn't work for the > reasons I gave before, > eg if 3 servers all have a queue size of 1 but at different times, the > maximum cumulative queue > size is 1, not 3. I wrote a script* that would periodically query the stats > for each server, > get the latest figures, add them, and put them into another RRD file for the > totals. So as well > as RRD files for each server, I have one for the combined values. As long as > the script keeps > the combined file up to date enough, it can use unconsolidated values from > the individual > servers. > > This combined RRD can then be consolidated and return the correct max values. > > * Which turns out to be more complicated than you might think ! It needs to > find out the last > complete "bucket" of data for each of the source files and see if the oldest > of these is newer > than that for the combined file - and if so, then update the combined file. > You need to allow > for delayed data from one or more servers (I'm using RRD cached which can > delay updates unless > you keep flushing it which defeats the object of the cacheing). But then, you > need to allow for > one (or more) servers being offline (as far as stats collection goes), so you > need to decide > how long to wait before taking an individual value as NaN. > > _______________________________________________ rrd-users mailing list > [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users > - -- Munroe Sollog LTS - Network Analyst x85002 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVdaJSAAoJEPbbZiWCKDVCNVsH/0jHOevrrJy+hIfC3BuqNlRZ nsQrluZ5GXCvubFiYdQSDjofuWajrdZ4PE9pZK7EaaH7YCchbWmQlkfm6TIExLhj lCdwk69pe5JiI0Dn/C1I6J4KRnUrf/gX+pecewzftdpIVJTX1wyqekUTS2auRXpt Z+zkbRGA/t7OYeV2Ihlpb/M32U8UfpnqwoMyxxca1cpgZ9WKGtHc+YVIxtV827TD MHr7+HzY7qvYAStSgmIsJiQsyx3rh2H7fKGJNsw9vsBrmXJxiXhXy4FDd+Rf2n5y bsuNCScEZVCR/5NVFikbbNwe+42V5xEkFwqAUq63Rqr8qteoPa2+sQOY+EuFHJA= =eHbp -----END PGP SIGNATURE----- _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
