[rrd-users] trigger an alert?
Sven Ulland
sveniu at opera.com
Wed May 9 19:05:21 CEST 2007
John Conner wrote:
> Thanks for information, guys!
>
> > Yes, you have to wait for one seasonal period before the HWPREDICT
> > value is visible, and two periods before the deviation bars are there.
>
> emmm, my current seasonal period is configured as 288,
> (RRA:HWPREDICT:1440: 0.1:0.0035:288 )
> that means I will wait 2 days to get the upper|lower line, right?
>
> I must have missed some important concepts here, could you point me
> where can I find more explanation about "two periods before the
> deviation bars are there"?
Well, it sort of follows a logic: In the first period, you only
have the input values from the data source. If you were to compute
predicted values, they would be the same as the input values. The
deviations would be zero. Thus they are not even graphed.
On the second period, you can predict the values by looking at the
previous period. This means that you can draw the HWPREDICT value
here. The deviations could probably also be drawn, but they are
not, for some reason.
Sven
> This is a major hurdle when trying to tune the values, since it takes
> days and even ways to try out new values every time. That is why you
> probably want to make some scripts that can quickly regenerate graphs.
> There's something called hw-reapply that can do this for you, but I
> haven't tried it, and I don't know if it shows immediate results:
> http://rrfw.sourceforge.net/rrdman/
>
> What I do is to log all 'rrdtool update' commands to a file, so I
> can easily run this file to repopulate the RRD files. Then I can tune
> the HW values when creating the RRD, run the backlog, and see graphs
> immediately.
>
> Also, I'd rather use a 1 day (or 7 days) season. A five day season
> could have problems with deviations in week-ends. Depends on your
> traffic patterns, of course.
>
>
> Sure, mine is just a quick test, and when you say "season", you actually
> mean "array length", right? ;)
>
> Thanks again!
>
> Joh
>
>
> Sven
>
>
> > On 5/4/07, *John Conner* < bs7799 at gmail.com
> <mailto:bs7799 at gmail.com> <mailto:bs7799 at gmail.com
> <mailto:bs7799 at gmail.com>>>
> > wrote:
> >
> > Hey Sven , thank you very much for you detailed information,
> I spent
> > a few hours going thought some documents about aberrant
> yesterday
> > and feel better now.
> >
> > My current rrdtool is at version 1.0.49, which even does not
> support
> > "updatev" argument, so I am not sure what the different between
> > "update" and "updatev" will be, will install rrdtool-1.2.19
> today
> > and do some test.
> >
> > Thanks again!
> >
> > Joh
> >
> >
> >
> > On 5/3/07, *Sven Ulland* < sveniu at opera.com
> <mailto:sveniu at opera.com>
> > <mailto:sveniu at opera.com <mailto:sveniu at opera.com>>> wrote:
> >
> >
> > Next, to actually have it report aberrant behaviour in
> real-time,
> > as opposed to post-mortem, you'll need a wrapper script
> to run
> > 'rrdtool updatev' and parse the output. There are
> probably fancy
> > bindings in perl for this, or some other graceful way of
> doing it.
> > My way is a quick python script that parses the output
> looking for
> > 'FAILURES', and then determining if the corresponding
> value is
> > greater than 0.0.
> >
> > Well, that's pretty much it. Good luck!
> >
> > Sven
> >
> >
> > > > I use the aberrant behaviour detection in rrdtool
> and I find
> > > > it quite handy. To detect problems, i use the
> 'rrdtool
> > updatev'
> > > > command, which will output FAILURE=1.0 (different
> syntax), if
> > > > it detects failures. FAILURE=0.0 if not. In other
> words,
> > I parse
> > > > the output of the command, and trigger alerts
> based on
> > it. You
> > > > should probably implement a wrapper around the
> > parsing/alarming,
> > > > so that you won't get flooded with mails/SMS
> messages
> > every five
> > > > minutes while a deviation is happening.
> > > >
> > > > Sven
> >
> >
> >
>
>
More information about the rrd-users
mailing list