Re: RFP: Remstats -- RRDtool-based monitor that can launch alerts
On Mon, Nov 20, 2000 at 05:33:13PM +0100, Alexander Reelsen wrote:
> On Mon, Nov 20, 2000 at 05:58:39PM +0200, Tommi Virtanen wrote:
> > Remstats is a system of programs to:
> > - gather data from servers and routers,
> > - store and maintain the data for long periods,
> > - produce graphs and web-pages tieing them together, and
> > - monitor the data for anomalous behavious and issue alerts
> >
> > (please do compare the feature list with Cricket
> > before packaging; it does sound nicer, though..)
> Cricket has been designed for collecting from Cisco routers and to work
> with SNMP mainly. However there a contribs and patches to make it work
> with non-SNMP things like server statistics as well. On the other side
> remstats has a lot of those things already builtin.
> Both lack of the problem of not being threaded, what makes them quite slow
> when monitoring large amounts of routers/servers (I used cricket for about
> 2500 network interfaces). Another speed decrease is the use of Perl, but
> that's a thing one can live with.
Cricket may have been originally designed to do only SNMP collection, but it
has grown far beyond that. Data collection can be done from:
- SNMP
- External program output
- Arbitrary file reads
- Arbitrary Perl functions
There is certainly nothing Cisco-centric about it; the device-specific data is
all in the config tree. Example configurations happen to be provided for
monitoring the environmental data provided by Cisco equipment, but there are
also example configurations for many other types of devices.
The threading problem is a big one, but as you say, this is a problem with most
software of this kind. Cricket, at least, can be configured to run multiple
process instances of its collector, each collecting a different subset of the
configuration. This way, you can thread the collection process yourself.
> The biggest advantage of remstats in fact is the alert function, which can
> be individually setup for each config entry.
Cricket also does this, with its monitoring functionality. When a data source
exceeds certain thresholds (configured on a per-target basis), an SNMP trap is
sent. It is trivial to configure any desired command to be run in response to
an SNMP trap. In particular, you can hook this into more full-featured
monitoring software like mon, without having to teach mon about how to read the
RRDs.
> Furthermore cricket has a CGI script with greater 2000 lines of code to
> display the interfaces. The graphics are generated at runtime and this
> script eats up some CPU as well (more as 20 clients and my U5 wasn't able
> to collect in a good time anymore). remstats creates the graphics at
> runtime as well, but doesn't update them if not needed.
Cricket's graphics are cached for the collection interval, so it will never
generate the same graph twice. Also, cached images are displayed by a smaller
CGI, to ease CPU usage.
1929 grapher.cgi
146 mini-graph.cgi
2075 total
You can also generate a whole tree of static pages and graphs (using a
contributed script), and let your users browse that. Then you have control
over how frequently they are updated.
> A small problem is the upstream author. He seems to be unreachable for
> time to time, but I think that's a solvable issue.
>
> I would really appreciate the packaging of remstats as well. So, one of
> the developers go for it, please!
I see no reason why remstats should not be packaged. Even if its functionality
is similar to that of cricket, it is bound to be better at some things, and
some users will prefer it.
Undoubtably, there would be still other users who would prefer some thing
similar to these programs that was not Perl.
--
Matt Zimmerman
Cricket and RRDtool maintainer
Reply to: