PostgreSQL^®-Monitoring mit check_postgres

Das Standardtool zur Überwachung von PostgreSQL^®-Datenbanken ist check_postgres. Die jetzt veröffentlichte und mit Hilfe von credativ entwickelte Version 2.21.0 unterstützt nun auch PostgreSQL^® 9.3. Auf apt.postgresql.org ist die neue Version bereits als Paket für Debian und Ubuntu verfügbar.

check_postgres besteht aus fast 60 einzelnen Tests mit eigenen Namen, z.B. check_postgres_connection. Da die meisten dieser Tests nur für spezielle Setups sinnvoll sind, sollte man sich zunächst auf einige Basistests beschränken.

Wichtige Checks

• check_postgres_archive_ready: Wenn WAL-Archiving aktiviert ist: Die Zahl der noch nicht archivierten xlog-Files sollte in der Regel 0 sein.
• check_postgres_backends: Zahl der Verbindungen. Das Charmante an diesem Check ist, dass er sich über max_connections automatisch einstellt. Ggf. ist 90% aber zu nah am kritischen Wert dran, so dass man in der Praxis evtl. früher gewarnt werden möchte.
• check_postgres_connection: Einfacher Verbindungs-Test. Leider ohne Möglichkeit bei langsamem Verbindungsaufbau zu warnen. (Die Zeit wird aber als „performance data“ angezeigt.)
• check_postgres_hot_standby_delay: Wenn (Streaming-)Replikation benutzt wird: Verzögerung des Slave-Servers. Das Delay wird leider in Transaktionen gemessen, was schwierig einzustellen ist.
• check_postgres_locks: Die Zahl der normalen Locks hängt stark von der Datenbank ab, aber eine übermäßige Zahl sollte eine Warnung ergeben. Sinnvoll erscheint, den Test überall auszurollen, und bei einzelnen Datenbanken zu ändern/deaktivieren, bei denen es falsche Alarme gibt.
• check_postgres_txn_idle: Prüft auf langlaufende „idle“-Transaktionen. Lang laufende Transaktionen, die nichts tun, sind meistens ein Anwendungsfehler oder ein Bedienfehler. Wenn dies über längere Zeit vorliegt, kann Vacuum nicht richtig arbeiten, da die Transaktion die alten Tupel noch sehen kann. Eine Einstellung der Größenordnung zwischen warning=1h/critical=4h bis warning=4h critical=12h erscheint sinnvoll.
• check_postgres_wal_files: Prüft die Zahl WAL-Dateien im pg_xlog-Verzeichnis. Dieser Check prüft etwas ähnliches wie archive_ready; in Hochlast-Situationen kann es allerdings auch ohne WAL-Archiving vorkommen, dass hier viele Files in pg_xlog/ anfallen. Wenn es deutlich mehr sind als 3*checkpoint_segments sollte man die Ursache prüfen. (Der Check konfiguriert sich leider nicht automatisch über diese Einstellung.)

Nützliche Checks

Diese Checks sind nützlich, aber nicht immer anwendbar, oder benötigen spezielle Konfiguration pro Datenbank:

• check_postgres_autovac_freeze: Prüft wie nah Datenbanken an autovacuum_freeze_max_age sind. Normalerweise passiert ein „Freeze“ automatisch, sobald die Datenbank sich autovacuum_freeze_max_age nähert. Falls Transaktionen sehr lange offen sind (mehrere 100 Millionen andere Transaktionen), kann das problematisch werden. In der Praxis tritt das Problem wenn überhaupt nur bei sehr aktiven Datenbanken auf, der Check ist aber sehr leicht zu installieren und benötigt kein Tuning.
• check_postgres_bloat: Tabellen- und Index-Bloat. Vacuum ist meist das größte Thema für den PostgreSQL^®-Administrator. Dieser Check überwacht, ob Tabellen größer sind, als sie von der Zahl der Tupel her sein sollten. Die dafür angestellte Berechnung ist aber nur eine sehr grobe Schätzung, und auch die Definition, welcher Overhead (Bloat) für eine gegebene Tabelle noch OK ist, hängt stark von der Benutzung der Tabelle ab. Der Check ist außerdem nicht einfach zu konfigurieren. Auf keinen Fall sollte man sich durch Warnungen verunsichern lassen, sondern diesen Check nur als Hinweis nehmen, ggf. genauer hin zu schauen.
• check_postgres_custom_query: Kein wirklicher Check, aber eine einfache Möglichkeit, eigene SQL-Queries in Warnungen umzusetzen.
• check_postgres_database_size: Prüft auf zu große Datenbanken. Nur sinnvoll, wenn man eine obere Grenze für die DB-Größe hat. Ggf. kann man das am Anfang einstellen, um bei DB-Wachstum benachrichtigt zu werden.
• check_postgres_disabled_triggers: Ggf. sinnvoll, um Trigger zu finden, die bei Wartungsarbeiten abgeschaltet und vergessen wurden.
• check_postgres_disk_space: Alternative zum direkten Check mit anderen Nagios-Plugins.
• check_postgres_hitratio: Dieser Check könnte einen Hinweis geben, dass der DB-Server vielleicht zu wenig RAM (shared_buffers) hat. Je nach Workload kann das aber auch völlig normal sein. Schwierig ohne genauere Kenntnis der Datenbank einzustellen.
• check_postgres_last_analyze: Zeit seit dem ältesten Analyze.
• check_postgres_last_autoanalyze: Zeit seit dem ältesten Autoanalyze.
• check_postgres_last_autovacuum: Zeit seit dem ältesten Autovacuum.
• check_postgres_last_vacuum: Zeit seit dem ältesten Vacuum. Ähnlich wie der Bloat-Checks sind diese Check schwierig einzustellen, Tabellen an denen keine Änderungen passieren müssen nicht jedesmal neu von Analyze oder Vacuum besucht werden. Als Anfang könnte man die Schwellwerte sehr hoch stellen (3 Monate?). Wenn sich in der Praxis herausstellt, dass man hier überwiegend nur falsche Alarme erhält, sollte man den Check einfach weglassen.
• check_postgres_prepared_txns: Offene Prepared Transactions (nicht zu verwechseln mit Prepared Statements) sind ein großes Problem, da sie auch über Server-Neustarts liegen bleiben, und dann Vacuum verhindern und allgemein mit laufenden Transaktionen kollidieren können. Im schlimmsten Fall läuft man in eine Datenbank, die nicht „gefreezt“ werden kann (siehe autovac_freeze). Eigentlich ein wichtiger Check, aber das Feature ist per default in der Server-Config deaktiviert.
• check_postgres_query_runtime: Prüft Laufzeit einer angegebenen Query. Analog custom_query eine Möglichkeit, eigene Checks zu bauen.
• check_postgres_query_time: Prüft, ob es akutell lang laufende Queries gibt. Die Default-Einstellungen sollte man deutlich erhöhen, z.B. auf 4h/24h. (Oder man passt es nach Erfahrung im Betrieb an.)
• check_postgres_sequence: Sequenzen haben per Default ein Maximum (bei bigserial allerdings ziemlich groß). Wenn das Ende erreicht wird, kann die Datenbank keine neuen Werte mehr bekommen.
• check_postgres_txn_time: Prüft, ob es akutell lang laufende Transaktionen gibt. Analog query_time. (Vermutlich ist es nicht sinnvoll, beide Checks zu benutzen.)
• check_postgres_txn_wraparound: Prüft wie nah Datenbanken am Transaktions-ID-Wraparound sind. Analog autovac_freeze prüft dieser Check, wie nah an der maximalen Transaktionszahl die Datenbank ist, bevor „vacuum freeze“ spätestens aufgerufen werden muss (normal passiert das automatisch durch Autovacuum). Beide Checks prüfen das gleiche, autovac_freeze wird viel früher anspringen, das eigentliche Problem wird dann durch txn_wraparound geprüft.