Checks how long it has been since vacuum (or analyze) was last run on each
table in one or more databases. Use of these actions requires that the target
database is version 8.3 or greater, or that the version is 8.2 and the
configuration variable stats_rows_level is enabled. Tables can be filtered with the
–include and –exclude options. See the BASIC FILTERING section
for more details.
Tables can also be filtered by their owner by use of the
–includeuser and –excludeuser options.
See the USER NAME FILTERING section for more details.
The units for –warning and –critical are specified as times.
Valid units are seconds, minutes, hours, and days; all can be abbreviated
to the first letter. If no units are given, ‘seconds’ are assumed. The
default values are ‘1 day’ and ‘2 days’. Please note that there are cases
in which this field does not get automatically populated. If certain tables
are giving you problems, make sure that they have dead rows to vacuum,
or just exclude them from the test.
The schema named ‘information_schema’ is excluded from this test, as the only tables
it contains are small and do not change.
Example 1: Warn if any table has not been vacuumed in 3 days, and give a
critical at a week, for host wormwood
- check_postgres_last_vacuum --host=wormwood --warning='3d' --critical='7d'
Example 2: Same as above, but skip tables belonging to the users ‘eve’ or ‘mallory’
- check_postgres_last_vacuum --host=wormwood --warning='3d' --critical='7d' --excludeusers=eve,mallory
For MRTG output, returns (on the first line) the LEAST amount of time in seconds since a table was
last vacuumed or analyzed. The fourth line returns the name of the database and name of the table.
symlink: check_postgres_listener) Confirm that someone is listening for one or more specific strings. Only one of warning or critical is needed. The format
is a simple string representing the LISTEN target, or a tilde character followed by a string for a regular expression
Example 1: Give a warning if nobody is listening for the string bucardo_mcp_ping on ports 5555 and 5556
- check_postgres_listener --port=5555,5556 --warning=bucardo_mcp_ping
Example 2: Give a critical if there are no active LISTEN requests matching ‘grimm’ on database oskar
- check_postgres_listener --db oskar --critical=~grimm
For MRTG output, returns a 1 or a 0 on the first, indicating success or failure. The name of the notice must
be provided via the <–mrtg> option.
symlink: check_postgres_locks) Check the total number of locks on one or more databases. There is no
need to run this more than once per database cluster. Databases can be filtered
with the –include and –exclude options. See the BASIC FILTERING section
for more details.
The –warning and –critical options can be specified as simple numbers,
which represent the total number of locks, or they can be broken down by type of lock.
Valid lock names are
'waiting', or the name of a lock type used by Postgres.
These names are case-insensitive and do not need the "lock" part on the end,
so exclusive will match ‘ExclusiveLock’. The format is name=number, with different
items separated by semicolons.
Example 1: Warn if the number of locks is 100 or more, and critical if 200 or more, on host garrett
- check_postgres_locks --host=garrett --warning=100 --critical=200
Example 2: On the host artemus, warn if 200 or more locks exist, and give a critical if over 250 total locks exist, or if over 20 exclusive locks exist, or if over 5 connections are waiting for a lock.
- check_postgres_locks --host=artemus --warning=200 --critical="total=250;waiting=5;exclusive=20"
For MRTG output, returns the number of locks on the first line, and the name of the database on the fourth line.
symlink: check_postgres_logfile) Ensures that the logfile is in the expected location and is being logged to.
This action issues a command that throws an error on each database it is
checking, and ensures that the message shows up in the logs. It scans the
various log_* settings inside of Postgres to figure out where the logs should be.
If you are using syslog, it does a rough (but not foolproof) scan of
/etc/syslog.conf. Alternatively, you can provide the name of the logfile
with the –logfile option. This is especially useful if the logs have a
custom rotation scheme driven be an external program. The –logfile option
supports the following escape characters:
%Y %m %d %H, which represent
the current year, month, date, and hour respectively. An error is always
reported as critical unless the warning option has been passed in as a non-zero
value. Other than that specific usage, the
options should not be used.
Example 1: On port 5432, ensure the logfile is being written to the file /home/greg/pg8.2.log
- check_postgres_logfile --port=5432 --logfile=/home/greg/pg8.2.log
Example 2: Same as above, but raise a warning, not a critical
- check_postgres_logfile --port=5432 --logfile=/home/greg/pg8.2.log -w 1
For MRTG output, returns a 1 or 0 on the first line, indicating success or failure. In case of a
failure, the fourth line will provide more detail on the failure encountered.
symlink: check_postgres_query_runtime) Checks how long a specific query takes to run, by executing a "EXPLAIN ANALYZE"
against it. The –warning and –critical options are the maximum amount of
time the query should take. Valid units are seconds, minutes, and hours; any can be
abbreviated to the first letter. If no units are given, ‘seconds’ are assumed.
Both the warning and the critical option must be given. The name of the view or
function to be run must be passed in to the –queryname option. It must consist
of a single word (or schema.word), with optional parens at the end.
Example 1: Give a critical if the function named "speedtest" fails to run in 10 seconds or less.
- check_postgres_query_runtime --queryname='speedtest()' --critical=10 --warning=10
For MRTG output, reports the time in seconds for the query to complete on the first line. The fourth
line lists the database.