Here is my suggestion for a fairly simple solution. Change pfdb2.pl to open a socket connection to a monitoring program. In pfdb2.pl, where you do a read on the logging interface pipe, set a time limit on the read (either using alarm or select (IO::Select::can_read)), and every _n_ seconds (say 30 seconds), send a short "OK" message to the socket connection. Also, if you get a mysql or any other serious error, send a "NOTOK" message.

These monitoring messages don't seem sensitive to me, so you could send them unencrypted. You could even use UDP, since there's no serious consequence to losing one message.

But if you do feel the need to encrypt, I think you can just add another "-R" option to ssh and forward that port to the monitoring machine.

The monitoring software is pretty simple, you just keep a list (a hash, probably) of the last time each logging process sent us an "OK" message. You have to have a timeout on the read, obviously. If you haven't heard from a process in, say, 90 seconds, then you raise an alarm.

If you are using TCP (including if you are using SSH), you could do a fork on accept and have one process for each connection, but I don't think that's necessary. I would use the IO::Select method.

If you are using UDP, then you don't have to worry about that.

Some other things to watch out for:

Don't have pfdb2.pl die if it gets an error opening a connection to or writing to the monitoring process. Just have it try again in 30 seconds. You want your logging to continue even if the monitor is down.

You'll need to have some logic to make sure that the monitoring process knows which connections to expect. Otherwise a process that never starts up will never give an error.

I hope that's clear. If not, feel free to ask more questions.