[smokeping-users] (no subject)

[Olivier Nicole]

Hi,

> > 1) Having alias targets.
> >
> >    It could be usefull that the same target can be listed several
> >    times in the target menu, under different names, but with probing
> >    only once, and of course keeping only one rrd database.
> >
> >    This could allow to define a target being listed in "my direct
> >    connection to Internet", "list of ISP of my country" (under a
> >    geographical hierachy), "list of R&D networks"...
> >
> >    Each alias could present a different title and name in the menu of
> >    course.
> 
> I have been thinking about this too ... what I was wondering is,
> how this should be done exactly ... what happens if an alias points
> up the tree onto itself, how do we handle loops ? Or should there
> be a condition that an alias may not point to any of its parents ?

I would have two solutions. The alias is just a way to tell that the
data for the target are in another target, it is not a way to navigate
in the target tree.

Then, I remember from algorithm class that there is a way to traverse
a graph and detect loops. That is the elegant way.

The nasty way is to tell that an alias can only point to a real target
(one having data and no target optional argument). This can easily be
detected. 

Of course I assume that when parsing the configuration file, at one
time, you have the full target tree in memory.

> > 2) Having an alert reporting mechanism.
> >
> >    Yesterday, with a quick glange at a SmokePing graph I noticed that
> >    something went wrong because at some point the lattency had doubled
> >    for a link. It was not one of my direct link, but I informed the
> >    responsible people, there was a route that got lost somewhere and
> >    nobody had noticed it.
> >
> >    So let say when the average for 5 minutes is x% higher than the
> >    average of the past 3 hours, raise an alarm and send an alert.
> >
> >    I think the alert through syslog is enough, no need to implement a
> >    complicated mechanism, they already exists that read from syslog
> >    and ring a phone, send SMS or whatever, this would be out of the
> >    scope of SmokePing.
> >
> >    Of course the alert would be optional, and not for the aliased
> >    targets.
> >
> >    Why is this part of SmokePing? Basically because it reads the rrd
> >    database generated by SmokePing.
> 
> can you write a configuration example ? for such a feature ? Would
> this be setup globally or for each target seperate or would it be
> inheritable ?

Hummm, how about:

* general options

- - the message to log to syslog if the RTT has increased, including 
  a <##target##> tag (default RTT change for target <##target##>)
- - the message to log to syslog if the RTT is lower than average 
  (default same as increasing message)
- - the interval to run the alert detection script (default SmokePing interval)

* per target option

- - run the alert (yes or no, default no)
- - interval for abnormal RTT before an alert is sent (default SmokePing 
  interval)
- - interval to compare with (default 3 hours)
- - percentage of difference from normal RTT to trigger the alert in case
  of increase (default 50%)
- - percentage of difference from normal RTT to trigger the alert in case
  of decrease (default 30%)

With default values, it will mean that:

- - if in the last 5 minutes the average RTT is 50% higher than the
average on the last 3 hours, send an alert.

- - if in the last 5 minutes the average RTT is 30% lower than the
average on the 3 last hours, send an alert.

Why I need to detect decrease of RTT: if my main link is satellite,
RTT is about 500ms to the other end of the link, I have a terestrial
back-up link, with lower RTT but smaller bandwidth, in that case I
need to detect a decrease of RTT.

I see no need to define anymore thing globally as this kind of alert is
only relevant for links that are very close to where SmokePing is run
(RTT to reach the other side of the globe is likely to vary a lot and
there is little I can do for it. I can warn my friend if it is 2 hops
away from me, but further than that I have little to no control at
all, so the alert would just be informative, I could only use it to
tell the users, sorry, but that place is unreachable, too bad for you
guys but I cant do anything to help, so I don't really need it).

So I se no need to inhertiate anything.

If fact if I knew more about RRD, and how SmokePing RRD are
implemented, I beleive I could write most of that by myself (but it
would be dirty Perl).

That's about all for now.

Olivier
------- End of forwarded message -------

--
Unsubscribe mailto:smokeping-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:smokeping-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/smokeping-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi