If I recall correctly, DBD::SQLite includes a version of SQLite with the
package, so it is that much easier to install (or should be at least). I use
SQLite2 for many things, and it is very fast and works great. Don't know much
about version 3 actually, as I never needed anything more from it.
________________________________________
From: Jonathan S. Polacheck [EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 8:26 AM
To: Donovan Allen; Jeff Lowrey; poe@perl.org; [EMAIL PROTECTED]
Subject: RE: Wheel::Filetail and File::Readbackwards
Thanks to everyone for the feedback.
I did some test scripts and was quickly convinced that File:Readbackwards
was not an effective strategy. Too bad, as the idea that I could use one
"system of record" (the syslog file) was appealing. SQLite looks good to
me. I see that SQLite3 is available from the SQLite website, but SQLite2
is as high up as PPM or CPAN goes. I would not think this was an issue for
as "light" an implementation is I need. Any comments?
Jon
Donovan Allen
<[EMAIL PROTECTED]
o.org> To
Jeff Lowrey <[EMAIL PROTECTED]>,
10/02/2007 07:12 "poe@perl.org" <poe@perl.org>,
PM "Jonathan S. Polacheck"
<[EMAIL PROTECTED]>
cc
Subject
RE: Wheel::Filetail and
File::Readbackwards
On that note, it would be trivial to take an md5 or sha hash of the message
(minus timestamp, but include sending host I would imagine) and use it as
the key in the perl hash, and as stated previously, store the last
timestamp as the value.
However, I am a proponent of the database (SQLite would be a great
candidate) as it would keep memory low, is very fast, easy to move between
machines, and would provide persistence. It is so easy, there isn't a very
good reason not to use SQLite for this, but plenty of reasons to do so.
As for POE, it is great for big applications, but IMHO, a little heavy for
scripts such as this. You can get a lot of mileage from forks (as in
forms.pm) and a shared data queue, and if you need it, one of the event
libraries (eventlib etc). Fork a grep handler with a shared queue. Keep
the tail in the main process.
The nice things about the forks.pm module is that it can easily be turned
into threads for a win32 machine with very very small code change (or even
check OS and require the right one).
I like POE, but it really is a big and complex machine (by necessity
mostly) and in this case, might be akin to hunting gophers with a tank.
________________________________________
From: Jeff Lowrey [EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 4:47 PM
To: poe@perl.org; Jonathan S. Polacheck
Subject: Re: Wheel::Filetail and File::Readbackwards
At 05:26 PM 10/2/2007, John R. wrote:
>Jonathan S. Polacheck wrote:
> > Hello POE group,
> >
> > I have a script that uses File::Tail to monitor the syslog file on a
> > Ciscoworks server. When syslog entries pass one of the grep tests, the
> > script reads the syslog file backwards to make sure the same event has
not
> > been seen for at lease 30 min.
>
>[snip]
>
>I can't help with your questions, but how about keeping track of what
>events have been sent and then searching that? Maybe a light weight
>database can be used for tracking/expiring.
>
>John
I agree with John, but I'm going to be a little more forward in my
opinions.
It's an entire waste of effort to go back through the file.
It should be very straight forward to create a very simple hash that
is keyed of some piece of data that identifies an "event" uniquely
enough for the requirements.
Then the value of the hash would be the time that you last saw that
particular event.
When an event passes a grep test, look up the last time from the
hash. Send an email if you don't get a value, or the value is older
than 30 minutes. Then update the value to the current event time.
You could probably even use POE's HEAP for this, if you really
wanted. At a minimum, you could use it to store the hash.
There's no reason to use a database, unless you need to persist your
hash across script invocations.
-jeff lowrey
