From: "Tod E. Kurt" <tod@goto.com>
Cricket is a wonderful tool. We use it to monitor network devices,
protocol-level (HTTP, IP) functionality, and internal state of our
application servers. In all we probably monitor around 300-400
different values.
The biggest functionality area I'd like to see improved upon is the
interactiveness of the Grapher. Here's some scenarios of what I'm
thinking about:
Scenario 1: interactive scaling
-----------
Occasionally, we'll have a situation where a value that normally
fluctuates around 50% of its median value will shoot up to 1000% of the
median because of a counter roll-over problem (RRD still seems to have
problems with this), or because of a true transient. The problem is
that now the graphs are 'squashed', making it hard to read the normal
variation that occurs.
It would be very useful to be able to somehow click on some 'range'
setting that would effectively set 'y-max' on a per-request basis. It's
not useful hard-code 'y-max' in the config file, because it disables the
nice autoscaling that normally happens. It might also hide some
problems that go above 'y-max'.
Scenario 2: adding 'event's interactively
-----------
Let's say we've a graph of ping times to some external service. (Maybe
it's an NTP server or a DNS server). We notice (from both Cricket and
'mon') that our connectivity to that service is degraded. At the same
time, we get a call from our network provider saying they are upgrading
a switch, and that's causing our problem.
So, to log this in Cricket, we just click on the ping-time graph at the
time the service degradation occured, type in a description (with the
ticket number from our provider), and click 'add event'. From that
point on, anyone viewing that graph will see that event in the graphs.
I'm not sure how either of these would be done, but it would be cool to
have both!
>From my limited knowledge of Cricket, both of these would currently be
hard to do, since it seems they both would need to make modifications to
the information in 'config.db'. Even if the grapher _could_ make
changes to the config.db, it shouldn't because a) it's a security risk,
grapher should be a read-only user of config.db, b) there's no easy way
to go from 'config.db' to a config tree, and c) it's just aesthetically
displeasing.
Jeff, have you considered similar things? To me, having the graphs
generated dynamically (unlike MRTG), just begs for them to be made more
interactive. :)
-=tod
-- tod@alumni.caltech.edu tod@goto.com Tod E. Kurt http://goto.com/ http://todbot.com/ GoTo.com: Search made simple------------------------------------------------------------------------ Campaign 2000 is here! http://www.onelist.com Discuss your thoughts; get informed at ONElist. See our homepage.
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 19:00:54 PST