perfparse-users

[Perfparse-users] monitor perfparsed with nagios

[Tim W. <tim...@gm...>]

All,

I'm trying to see what the best way is of monitoring perfparsed,
preferably using nagios itself. I'm currently using perfparsed in
combination with the write to pipe method.

What are my options?

1.  check_procs -c1:1 -C perfparsed -u nagios
this will notify me in case the daemon died. I could attach an event
handler to restart the perfparse daemon.
The problem with this method is that there is no way of knowing the
perfparse daemon is still doing anything useful, since nagios writes
to a named pipe, and this never fails. (and even then, should it fail,
there's apparently no trace of the failure anywhere). This hasn't
happened (yet), the daemon seems to die whenever something goes wrong.

2. write a (perl) check script that checks the perfparse_service_bin
(since I'm storing in a mysql db) for new data (i.e check the
timestamp of the most recent record, cry wolf if it's older than x
minutes). Attach an event handler to check for perfparsed still
running and eventually restarting it. In my view this is the only
right way to check the sanity of perfparse.

I'd like to hear your thoughts on this, or any other ideas....

Tim.

Re: [Perfparse-users] monitor perfparsed with nagios

[Yves <yme...@pe...>]

> All,
>
> I'm trying to see what the best way is of monitoring perfparsed,
> preferably using nagios itself. I'm currently using perfparsed in
> combination with the write to pipe method.
>
> What are my options?
>
> 1.  check_procs -c1:1 -C perfparsed -u nagios
> this will notify me in case the daemon died. I could attach an event
> handler to restart the perfparse daemon.
> The problem with this method is that there is no way of knowing the
> perfparse daemon is still doing anything useful, since nagios writes
> to a named pipe, and this never fails. (and even then, should it fail,
> there's apparently no trace of the failure anywhere). This hasn't
> happened (yet), the daemon seems to die whenever something goes wrong.
>
> 2. write a (perl) check script that checks the perfparse_service_bin
> (since I'm storing in a mysql db) for new data (i.e check the
> timestamp of the most recent record, cry wolf if it's older than x
> minutes). Attach an event handler to check for perfparsed still
> running and eventually restarting it. In my view this is the only
> right way to check the sanity of perfparse.
>
> I'd like to hear your thoughts on this, or any other ideas....

What about a plugin that does both ?
Do you think that adding some "watchdog" function to perfparsed would be =
a good idea ? I
mean adding some "touch /var/lock/some.perparse.lock" feature in the main=
 loop. Your
plugin could test that file mtime :)

When perfparsed breaks, if you can find the reason, tell us, and we'll tr=
y to find a way
to make perfparsed do something else than break.


Yves
--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- Perfparse   - http://perfparse.sf.net/                           -

Re: [Perfparse-users] monitor perfparsed with nagios

[Tim W. <tim...@gm...>]

On Tue, 7 Dec 2004 14:11:17 +0100 (CET), Yves <yme...@pe...> wrote:
> 
> 
> 

> When perfparsed breaks, if you can find the reason, tell us, and we'll try to find a way
> to make perfparsed do something else than break.

well, whenever there is a problem with one of the storage modules, it
simply exits:
e.g. if the db is unavailable or (like I had this morning) the
filesystem where the db resides is full. Last week I tried to use the
file_output and mysql storage modules, but the file_output module
would not load (haven't figured out why yet, it just said
"storage_file_output module failed to initialize itself").  In all
these cases, perfparsed exited.

The question of course is, what should perfparsed do? Should it exit
or not? I don't think there's a simple answer to that, except that in
case of failure, I'd like to know about it :) One place I look at is
the error log. The things I'd like to add to the error log is some
extra info when a module is succesfully initialised, a bigger buffer
for error messages (they get truncated at 256 chars), and a clear
'perfparsed stopped' message whenever there is a fatal error.


Tim.

> 
> Yves
> --
> - Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
> - GPG key     - http://ymettier.free.fr/gpg.txt                    -
> - Maitretarot - http://www.nongnu.org/maitretarot/                 -
> - Perfparse   - http://perfparse.sf.net/                           -
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Perfparse-users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perfparse-users
>

Re: [Perfparse-users] monitor perfparsed with nagios

[Yves <yme...@pe...>]

>> When perfparsed breaks, if you can find the reason, tell us, and we'll=
 try to find a
>> way
>> to make perfparsed do something else than break.
>
> well, whenever there is a problem with one of the storage modules, it
> simply exits:
> e.g. if the db is unavailable or (like I had this morning) the
> filesystem where the db resides is full. Last week I tried to use the
> file_output and mysql storage modules, but the file_output module
> would not load (haven't figured out why yet, it just said
> "storage_file_output module failed to initialize itself").  In all
> these cases, perfparsed exited.

OK. In those cases, I consider that perfparsed should exit. I was just th=
inking about
cases where perfparsed could deal with the situation and does not. If the=
re are any :)

> The question of course is, what should perfparsed do? Should it exit
> or not? I don't think there's a simple answer to that, except that in
> case of failure, I'd like to know about it :) One place I look at is
> the error log. The things I'd like to add to the error log is some
> extra info when a module is succesfully initialised, a bigger buffer

storage_%s module successfully loaded\n", storage_name
done :)

> for error messages (they get truncated at 256 chars), and a clear

#define LOG_MESSAGE_LENGTH 1024

Is that OK for you ?

> 'perfparsed stopped' message whenever there is a fatal error.

Done (thanks to already implemented atexit function :)

This is available in few minutes in perfparse-0.104.2ym2 on
http://pagesperso.laposte.net/ymettier/perfparse-devel/

Yves

--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- Perfparse   - http://perfparse.sf.net/                           -