Does someone know of an Intermapper probe to test if a SQL database is alive and kick'n?

Plan B: Does someone know the basic steps with are necessary to program such a probe?

• database
• postgresql
• monitoring
• probe

According to Wikipedia InterMapper supports SNMP. pgsnmpd is a SNMP agent for PostgreSQL readily available. You can connect both right out of the box(es).

Otherwise: InterMapper said to be written in Java. It also stores its own data in PostgreSQL. This CALLS for either a generic JDBC-probe or at least one for PostgreSQL right from the start. So the best solution is to call them and persuade them to provide such a probe by default - if they don't do that already somewhere.

Regarding Plan B: The support page has a document describing the process for creating custom probes. A quick glance over it leaves three options:

• define your own probe type - by hacking some XML
• use "command line probes" which basically calls an external program. On Linux/Unix writing a script using psql to connect to the DB and issue some silly command seems not to complicated too.
• They have Nagios support for commandline probes and there are plenty Nagios-PostgreSQL plugins available.

And of course you can use the contributed probes page to get enough examples - the MS-SQL probe in the "Application Monitoring Probes" section might be a good start.

I can't help you with Intermapper today, but the programming depends in part on what "alive and kick'n" means to you.

A fairly bulletproof way to program it would be to have a cron job write a row into a table in one transaction, and read it back in another transaction. You might not need anything more than a timestamp. This should be run from a client computer, not on the server itself.

A failed write should raise an error, but I imagine there could be some esoteric failure scenarios where that might not happen. Reading back the same row, though, should be solid evidence of life.

A program like that tells you that the dbms is running and processing, and that one specific database is online. You might or might not need more than that. Some people might need to know how long it took to process those SQL statements, with an unreasonably long time meaning your attention is needed before users start to call.

Changes to database permissions might raise a false warning. For example, if a bonehead upgrade revokes your permissions to write to the heartbeat table, then a program that writes to that table should fail with a permissions error.

If your requirements are less stringent, you could just check for a running server daemon.

All those things could be done with a cron job, with email or SMS sent on failure.