Really slow log2ndo

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[ Resending as this message bounced after 5 days :(  ]

On 18/09/08 11:26 PM, Mikael Fridh wrote:
> On Thu, Sep 18, 2008 at 12:20 PM, Andreas Ericsson <ae at op5.se> wrote:
>> Benjamin Krein wrote:
>>> On Sep 18, 2008, at 4:04 AM, Andreas Ericsson wrote:
>>>> Mikael Fridh wrote
>>>>> LOG ROTATION: DAILY
>>>> Implementation detail junk.
>
> The log entries where just an excerpt and I wasn't putting any weight
> on importance of their actual contents, but raw log messages _can_ be
> interesting for some humans... I'm not saying it's always useful, but
> it's there if you want it. As a user you're free to just devnull it I
> guess.
>
>>>>> I would use MyISAM MERGE tables or PARTITIONS for this if you want to
>>>>> keep an "online" archive of the logs.
>>>>> With the MERGE trick you can compress old tables and rejoin them in
>>>>> the merge periodically if you'd like.
>>>>>
>>>> Or one can just print the logfiles from disk. They're already
>>>> partitioned
>>>> into rotated logfiles so it's not that much of a chore.
>
> But they're not centralized which is one of the points of ndo.
> And selecting a time range in SQL is pretty darn easy and fast if the
> time columns are indexed.
> But if you don't like the log in the database, BLACKHOLE it or something ... ;)
>
>>>>> The event history of objects (services and hosts) is already in
>>>>> nagios_statehistory, so what else is there in the log that you could
>>>>> gain so much from parsing out into separate tables/fields?
>>>>>
>>>> Notifications. Program start and stop. Downtime start and stop.
>
> Also available in standard ndo structure afaik:
>
> notifications Table
> "This table is used to store a historical record of host and service
> notifications that have been sent out."
>
> processevents Table
> "This table is used to store a historical record of Nagios process
> events (program starts, restarts, shutdowns, etc.)."
>
> downtimehistory Table
> "This table is used to store a historical record of scheduled host and
> service downtime."
>
> statehistory Table
> "This table is used to store a historical record of host and service
> state changes."

Any reason why not using a single table with all the common log entry
stuff? Would likely be only auto-increment + date stamp, of better yet
(with some nagios modification) a TAI timestamp as the resolution would
be high enough to use it as a primary key, and possibly (if we want to
allow aggregating multiple Nagios monitoring servers together) a
monitoring host id as well.

Then each notification type would reference to this table, so that that
you could use them standalone (possibly joined to the single one if you
have a monitoring host id), but also join them all with the single table
to get a full log representation.

I forgot how this is named, but IMHO that would be the best
representation for a nagios log.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI2gPT6dZ+Kt5BchYRApLfAJ9HCYI5w4sTdKbahZJ66yMWfnfYLgCgvT/3
y5o7AXZQGEG/+khvTLba3zw=
=Ppxq
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/