On 10/13, Jeremy Hinton wrote:
> On Wed, 13 Oct 1999, Vikas Aggarwal wrote:
> > Do you all mean the 'events' that are currently in the data/ directory or
> > do you mean the 'noclogd' logs which only log 'state' changes? I think
> > only the state changes would be useful in a database.
>
> I disagree. If your goal is purely from a monitoring perspective maybe,
> but what about historical trending of non-event trigerring data? Most
> folks are probably interested in this as well (look at how big MRTG is),
> and why gather the same data twice? True, though, most of your queries for
> this sort of data would be purely sequential, restricted on date/time.
You're both right, IMO. We have built a SQL backended monitoring system
like you're all talking about. Everything logs to a central "state"
table that has the current values for all the objects monitored.
Another table specifies which objects should be stored for historical
analysis, and how to store them. We then use RRDtool to collect the
state information and store them in the appropriate RRDs.
This leverages the best of both worlds. The consolidation functions of
RRDtool make data management a breeze. We do also have a "log" table
for tracking state transitions and such, which allows us to
appropriately modify the thresholds.
Before you ask, please know that we would really love to polish and
package this software and release under GPL, but resources are quite
limited right now.
-j
--
"What is the sound of Perl? Is it not the sound of a | Jason Lavoie
wall that people have stopped banging their heads against?" | jason@mint.net
--Larry Wall in <1992Aug26.184221.29627@netlabs.com> |
|