On Thu, Jan 3, 2013 at 11:44 AM, Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de> wrote:
Hello Jean,

Sorry for the delay, got lot of ill children and woman in house ;)


Nice to see your activity in this area - is this related to the Holt-Winters
mechanism available in rrd ? If I remember correct, those uses a periodic variation
with an additional linear part.
yes and no. It's the same thing, trending, but not the same algorithm. HW is a nightmare to manage, really. I test it some months ago (the trending is in a small place in my head since one year I think), and I got lot of problems to get "nearly" the first results (in fact the trending was not so close, and the prediction was just outside the graphs.... and yes, I tried lot of HW parameters ;) ).

The real problem with HW is about "errors". If you got a "not too variable" curve, like a disk space or something like this on the time dimension, that will works. But such things as network consumptions are just not like theses flat lines. Compute what will be the value for 9h10 from 9h05 won't help a lot, or with a LOT of time to set good HW parameters for EACH metric (and not each metric type, so for N services, N configurations....). That's why my algorithm is just doing a simple smooth in the time dimension, but not the core computation that is across weeks "point in time".

Another question: Is the usage of carbon-cache (from graphite) as perfdata storage
for the forecasting thinkable ?
Don't know. The key is that the trending data are looping over the same week again and again. You will be able to draw each week trending curve as service perfdata (the check_treding.py pushed monday is about this), but I think carbon is about long time agregation, not "one week" thing. But if it can, why not trying to change from mongodb and give a try to it. The trending module got a "backend" parameter, so I4m not against more than one backend for this module, especially if the other is as easy to setup in high availability mode as mongodb ;)

At the moment we use our modules at https://bitbucket.org/hlauer/shinken2rrd to put our
perfdata from shinken into carbon-cache (besides other sources using the same minimalistic
udp protocol).

If there is interrest in adding the two broker modules (as asked some time ago) I will
happily change the name of the modules.
I saw François answer you, I'll first read it before :)

Thanks and greetings,

P.S: This time only one typo attached ;-)
Thanks ;)