check_postgres_pgb_pool_sv_activep – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

check_postgres - ein Postgres-Überwachungsskript für Nagios, MRTG, Cacti und andere

Dieses Dokument beschreibt check_postgres Version 2.22.0

ZUSAMMENFASSUNG

## Alle symbolischen Links erstellen
check_postgres --symlinks

## Verbindung zur Postgres-Datenbank 'pluto' prüfen:
check_postgres --action=Verbindung --db=pluto

## Gleiche Dinge, aber mit dem Symlink
check_postgres_connection --db=pluto

## Warnen bei > 100 Sperren, kritisch bei > 200 oder > 20 exklusiv
check_postgres_locks --warning=100 --critical="total=200:exclusive=20"

## Zeigt die aktuelle Anzahl der inaktiven Verbindungen auf Port 6543 an:
check_postgres_txn_idle --port=6543 --output=simple

## Es gibt viele andere Aktionen und Optionen, bitte lesen Sie weiter.

Die neuesten Nachrichten und Dokumentationen finden Sie immer unter:
http://bucardo.org/check_postgres/

BESCHREIBUNG

check_postgres ist ein Perl-Skript, das viele verschiedene Tests gegen einen oder mehrere ausführt
Postgres-Datenbanken. Es verwendet das psql-Programm, um die Informationen zu sammeln, und gibt die
Ergebnisse in einem von drei Formaten: Nagios, MRTG oder einfach.

Ausgang Modi
Die Ausgabe kann mit der Option "--output" geändert werden. Die Standardausgabe ist nagios,
Dies kann jedoch bei Bedarf oben im Skript geändert werden. Die aktuelle Option
Entscheidungen sind nagios, mrtg und einfach. Um nicht jedes Ausgabeargument eingeben zu müssen
Zeit wird der Ausgabetyp automatisch gesetzt, wenn kein --output-Argument angegeben wird und wenn die
Das aktuelle Verzeichnis hat eine der Ausgabeoptionen im Namen. Erstellen Sie beispielsweise a
Verzeichnis mit dem Namen mrtg und füllen es mit Symlinks über das - Symlinks argument würde
Stellen Sie sicher, dass alle Aktionen, die von diesem Verzeichnis aus ausgeführt werden, standardmäßig immer die Ausgabe "mrtg" haben.
Als Abkürzung für --output=simple können Sie --simple eingeben, was ebenfalls die
Trick bei der Verzeichnisbenennung.

Nagios Möglichkeiten für das Ausgangssignal:

Das Standardausgabeformat ist für Nagios, das eine einzelne Informationszeile ist, zusammen mit
vier spezifische Exit-Codes:

0 (in Ordnung)
1 (WARNUNG)
2 (KRITISCH)
3 (UNBEKANNT)

Die Ausgabezeile ist eines der obigen Wörter, ein Doppelpunkt und dann eine kurze Beschreibung dessen, was
wurde gemessen. Zusätzliche Statistikinformationen sowie die Gesamtzeit des Befehls
nahm, kann auch ausgegeben werden: siehe Dokumentation zu den Argumenten --showperf,
--perflimit und --Show Time.

MRTG Möglichkeiten für das Ausgangssignal:

Die MRTG-Ausgabe besteht aus vier Zeilen, wobei die erste Zeile immer eine einzelne Zahl von angibt
Bedeutung. Wenn möglich, stellt diese Zahl einen tatsächlichen Wert dar, z. B. eine Zahl von
Bytes, aber es kann auch eine 1 oder eine 0 für Aktionen sein, die nur "true" oder "false" zurückgeben, wie z
als check_postgres_version. Die zweite Zeile ist eine zusätzliche Statistik und wird nur für verwendet
einige Aktionen. Die dritte Zeile zeigt eine "Uptime" an und wird nicht verwendet. Die vierte Zeile ist a
Beschreibung und gibt normalerweise den Namen der Datenbank an die Statistik aus der ersten Zeile
gezogen wurde, kann aber je nach Aktion unterschiedlich sein.

Einige Aktionen akzeptieren ein optionales --mrtg Argument, um die Ausgabe weiter zu steuern.

Einzelheiten zur genauen MRTG-Ausgabe für jede Aktion finden Sie in der Dokumentation zu jeder Aktion.

Einfacher Möglichkeiten für das Ausgangssignal:

Die einfache Ausgabe ist einfach eine abgeschnittene Version der MRTG-Ausgabe und gibt einfach die
erste Nummer und sonst nichts. Dies ist sehr nützlich, wenn Sie nur den Status überprüfen möchten
von etwas, unabhängig von jeder Schwelle. Sie können die numerische Ausgabe umwandeln um
Anhängen von KB, MB, GB, TB oder EB an das Ausgabeargument, zum Beispiel:

--output=einfach,MB

Kakteen Möglichkeiten für das Ausgangssignal:

Die Cacti-Ausgabe besteht aus einem oder mehreren Elementen in derselben Zeile mit einem einfachen Namen, a
Doppelpunkt und dann eine Zahl. Im Moment ist die einzige Aktion mit expliziter Kakteenausgabe
'dbstats' und die Verwendung der Option --output ist in diesem Fall nicht erforderlich, da Cacti der einzige ist
Ausgabe für diese Aktion. Für viele andere Aktionen reicht die Verwendung von --simple aus, um Cacti
glücklich.

DATABASE CONNECTION OPTIONAL

Alle Aktionen akzeptieren einen gemeinsamen Satz von Datenbankoptionen.

-H NAME/FUNKTION or --host=NAME
Verbinden Sie sich mit dem von NAME angegebenen Host. Kann eine durch Kommas getrennte Liste von Namen sein.
Mehrere Hostargumente sind zulässig. Wenn kein Host angegeben ist, wird standardmäßig "PGHOST" verwendet.
Umgebungsvariable oder gar kein Host (was darauf hinweist, dass ein lokaler Unix-Socket verwendet wird).
Sie können auch "--dbhost" verwenden.

-p PORT or --port=PORT
Verbindet unter Verwendung der angegebenen PORT-Nummer. Kann eine durch Kommas getrennte Liste von Ports sein
Nummern und mehrere Portargumente sind zulässig. Wenn keine Portnummer angegeben wird, Standardwerte
in die Umgebungsvariable "PGPORT". Wenn dies nicht festgelegt ist, wird standardmäßig 5432 verwendet. Sie können
auch "--dbport" verwenden

-db NAME/FUNKTION or --dbname=NAME
Gibt an, zu welcher Datenbank eine Verbindung hergestellt werden soll. Kann eine durch Kommas getrennte Liste von Namen sein, und
mehrere dbname-Argumente sind zulässig. Wenn keine dbname-Option bereitgestellt wird, wird standardmäßig verwendet
die Umgebungsvariable "PGDATABASE". Wenn dies nicht festgelegt ist, wird standardmäßig 'postgres' verwendet.
wenn psql Version 8 oder höher ist, andernfalls 'template1'.

-u USERNAME or --dbuser=BENUTZERNAME
Der Name des Datenbankbenutzers, als der eine Verbindung hergestellt werden soll. Kann eine durch Kommas getrennte Liste von sein
Benutzernamen und mehrere dbuser-Argumente sind zulässig. Wenn dies nicht vorgesehen ist, wird es
standardmäßig auf die Umgebungsvariable "PGUSER", ansonsten auf 'postgres'.

--dbpass=PASSWORT
Gibt das Kennwort für die Verbindung mit der Datenbank an. Die Nutzung dieser Option ist sehr
entmutigt. Stattdessen sollte man eine .pgpass- oder pg_service.conf-Datei verwenden.

--dbservice=NAME
Der Name eines Dienstes in der Datei pg_service.conf. Vor Version 9.0 von
Postgres, dies ist eine globale Datei, die normalerweise in /etc/pg_service.conf zu finden ist. Wenn du bist
Wenn Sie Version 9.0 oder höher von Postgres verwenden, können Sie die Datei ".pg_service.conf" in . verwenden
das Home-Verzeichnis des Benutzers, der das Skript ausführt, zB nagios.

Diese Datei enthält eine einfache Liste von Verbindungsoptionen. Sie können auch zusätzlich passieren
Informationen bei Verwendung dieser Option wie --dbservice="maindatabase sslmode=require"

Die Dokumentation zu dieser Datei finden Sie unter
http://www.postgresql.org/docs/current/static/libpq-pgservice.html

Die Datenbankverbindungsoptionen können gruppiert werden: --host=a,b --host=c --port=1234
--port=3344 würde an a-1234, b-1234 und c-3344 anschließen. Beachten Sie, dass nach der Einstellung eine Option
wird übernommen, bis es wieder geändert wird.

Beispiele:

--host=a,b --port=5433 --db=c
Verbindet sich zweimal über die Datenbank c mit Port 5433 zu den Hosts a und b: a-5433-c b-5433-c

--host=a,b --port=5433 --db=c,d
Verbindet viermal: a-5433-c a-5433-d b-5433-c b-5433-d

--host=a,b --host=foo --port=1234 --port=5433 --db=e,f
Verbindet sechsmal: a-1234-e a-1234-f b-1234-e b-1234-f foo-5433-e foo-5433-f

--host=a,b --host=x --port=5432,5433 --dbuser=alice --dbuser=bob -db=baz
Verbindet dreimal: a-5432-alice-baz b-5433-alice-baz x-5433-bob-baz

--dbservice="foo" --port=5433
Verbindet sich über den benannten Dienst 'foo' in der Datei pg_service.conf, überschreibt aber den Port

anderes OPTIONAL

Weitere Optionen sind:

--action=NAME
Gibt an, welche Aktion wir ausführen. Erforderlich, es sei denn, Sie verwenden eine Datei mit Symlink, in der
Fall wird der Name der Datei verwendet, um die Aktion herauszufinden.

--warning=WERT or -w VAL
Legt den Schwellenwert fest, bei dem eine Warnmeldung ausgelöst wird. Die gültigen Optionen dafür
Option hängt von der verwendeten Aktion ab.

--kritisch=VAL or -c VAL
Legt den Schwellenwert fest, bei dem eine kritische Warnung ausgelöst wird. Die gültigen Optionen dafür
Option hängt von der verwendeten Aktion ab.

-t VAL or --timeout=WERT
Legt die Zeitüberschreitung in Sekunden fest, nach der das Skript abbricht, was immer es tut und
einen UNBEKANNTEN Status zurückgeben. Das Timeout gilt pro Postgres-Cluster, nicht für den gesamten
Skript. Der Standardwert ist 10; die Einheiten sind immer in Sekunden.

--Standby-Modus annehmen
Falls angegeben, wird zuerst geprüft, ob sich der Server im Standby-Modus befindet (--datadir
ist erforderlich), wenn ja, werden alle Prüfungen, die SQL-Abfragen erfordern, ignoriert und "Server
im Standby-Modus" mit OK-Status wird stattdessen zurückgegeben.

Beispiel:

postgres@db$./check_postgres --action=version --warning=8.1 --datadir /var/lib/postgresql/8.3/main/ --assume-standby-mode
POSTGRES_VERSION OK: Server im Standby-Modus | Zeit=0.00

--asme-prod
Falls angegeben, prüfen Sie, ob der Server im Produktionsmodus ausgeführt wird (--datadir ist erforderlich).
Die Option ist nur relevant für ("symlink: check_postgres_checkpoint").

Beispiel:

postgres@db$./check_postgres --action=checkpoint --datadir /var/lib/postgresql/8.3/main/ --assume-prod
POSTGRES_CHECKPOINT OK: Letzter Kontrollpunkt war 72 Sekunden her | Alter=72;;300 Modus=MASTER

-h or --help
Zeigt einen Hilfebildschirm mit einer Zusammenfassung aller Aktionen und Optionen an.

--Mann
Zeigt das gesamte Handbuch an.

-V or --Version
Zeigt die aktuelle Version an.

-v or - ausführlich
Legen Sie die Ausführlichkeitsstufe fest. Kann mehr als einmal anrufen, um das Level zu erhöhen. Einstellen auf
drei oder höher (mit anderen Worten, die Ausgabe von "-v -v -v") aktiviert Debugging-Informationen
für dieses Programm, das an stderr gesendet wird.

--showperf=WERT
Bestimmt, ob wir zusätzliche Leistungsdaten im Standard-Nagios-Format ausgeben (am Ende
of string, nach einem Pipe-Symbol, mit name=value). VAL sollte 0 oder 1 sein. Die Standardeinstellung
ist 1. Wird nur wirksam, wenn der Nagios-Ausgabemodus verwendet wird.

--perflimit=i
Legt ein Limit fest, wie viele interessante Elemente zurückgemeldet werden, wenn die
schauspieler Möglichkeit. Dies wirkt sich nur auf Aktionen aus, die eine große Anzahl von zurückgeben
Gegenstände, wie z Tischgröße. Der Standardwert ist 0 oder keine Begrenzung. Seien Sie vorsichtig, wenn Sie dies verwenden
an. Nach der Installation können Sie HEIC-Dateien mit der --enthalten or --ausschließen Optionen, da diese Einschränkungen erledigt sind nachdem
Abfrage ausgeführt wurde, und daher enthält Ihr Limit möglicherweise nicht die gewünschten Elemente. Nur dauert
Effekt bei Verwendung des Nagios-Ausgabemodus.

--showtime=WERT
Bestimmt, ob die für die Ausführung jeder Abfrage benötigte Zeit in der Ausgabe angezeigt wird. VAL sollte 0 . sein
oder 1. Der Standardwert ist 1. Keine Auswirkung, es sei denn schauspieler ist an. Wirkt nur bei Verwendung
Nagios-Ausgabemodus.

--Prüfung
Aktiviert den Testmodus. Siehe den Abschnitt "TESTMODUS" unten.

--PGBINDIR=PFAD
Teilt dem Skript mit, wo die psql-Binärdateien zu finden sind. Nützlich, wenn Sie mehr als einen haben
Version der ausführbaren PostgreSQL-Dateien auf Ihrem System, oder wenn keine in Ihrem
Weg. Beachten Sie, dass diese Option nur in Großbuchstaben angegeben ist. Standardmäßig ist diese Option nicht
erlaubt. Um es zu aktivieren, müssen Sie die $NO_PSQL_OPTION oben im Skript ändern
auf 0. Vermeiden Sie die Verwendung dieser Option, wenn Sie können, und verwenden Sie stattdessen die Umgebungsvariable
C oder hartcodierte $PGBINDIR-Variable, ebenfalls oben im Skript, zum Setzen
den Pfad zum zu verwendenden PostgreSQL.

--PSQL=PFAD
(veraltet, fehlen uns die Worte. zu erhalten Mai be entfernt in a Zukunft Veröffentlichung!) Sagt dem Skript, wo
um das psql-Programm zu finden. Nützlich, wenn Sie mehr als eine Version von psql haben
auf Ihrem System ausführbar ist oder kein psql-Programm in Ihrem Pfad vorhanden ist. Beachten Sie, dass dies
Option ist in Großbuchstaben. Standardmäßig ist diese Option nicht erlaubt. Um es zu aktivieren, müssen Sie
muss die $NO_PSQL_OPTION am oberen Rand des Skripts auf 0 ändern. Vermeiden Sie dies
Option, wenn Sie können, und codieren Sie stattdessen Ihren psql-Speicherort in die $PSQL-Variable.
auch am oberen Rand des Skripts.

- Symlinks
Erstellt für jede Aktion symbolische Links zum Hauptprogramm.

--output=WERT
Bestimmt das Ausgabeformat zur Verwendung in verschiedenen Programmen. Die Standardeinstellung ist
'Nagios'. Verfügbare Optionen sind 'nagios', 'mrtg', 'simple' und 'cacti'.

--mrtg=WERT
Wird nur für die MRTG- oder einfache Ausgabe für einige spezifische Aktionen verwendet.

--debugoutput=VAL
Gibt die genaue von psql zurückgegebene Zeichenfolge zur Verwendung beim Debuggen aus. Der Wert ist eins oder
weitere Buchstaben, die bestimmen, ob die Ausgabe angezeigt wird oder nicht, wobei 'a' = alle, 'c'
= kritisch, 'w' = Warnung, 'o' = ok und 'u' = unbekannt. Buchstaben können kombiniert werden.

--get_method=VAL
Ermöglicht die Angabe der Methode zum Abrufen von Informationen für "new_version_cp",
Überprüfungen von "new_version_pg", "new_version_bc", "new_version_box" und "new_version_tnm".
Folgende Programme werden ausprobiert, um die Informationen aus dem Web zu holen: GET,
wget, holen, curl, Luchs, Links. Um die Verwendung von nur einem zu erzwingen (und damit die
Aufwand, alle anderen auszuprobieren, bis einer davon funktioniert), geben Sie einen der Namen ein als
das Argument für get_method. Zum Beispiel könnte eine BSD-Box die folgende Zeile in
ihre Datei ".check_postgresrc":

get_method=holen

--language=WERT
Legen Sie die Sprache fest, die für alle Ausgabenachrichten verwendet werden soll. Normalerweise wird dies erkannt durch
Untersuchen der Umgebungsvariablen LC_ALL, LC_MESSAGES und LANG, aber setzen dies
Option überschreibt eine solche Erkennung.

MASSNAHMEN

Das Skript führt eine oder mehrere Aktionen aus. Dies kann entweder mit dem Flag --action oder durch
Verwenden eines symbolischen Links zur Hauptdatei, der den Namen der darin enthaltenen Aktion enthält. Zum
Um beispielsweise die Aktion "timesync" auszuführen, können Sie entweder Folgendes ausführen:

check_postgres --action=timesync

oder verwenden Sie ein Programm namens:

check_postgres_timesync

Alle Symlinks werden für Sie im aktuellen Verzeichnis erstellt, wenn Sie die Option --symlinks . verwenden

perl check_postgres --symlinks

Wenn der Dateiname bereits existiert, wird er nicht überschrieben. Wenn die Datei existiert und a
symlink, Sie können das Überschreiben erzwingen, indem Sie "--action=build_symlinks_force" verwenden.

Die meisten Aktionen dauern --Warnung und einem --kritisch Option, die angibt, an welcher Stelle wir wechseln
von OK zu WARNUNG, und wann gehen wir zu KRITISCH. Beachten Sie, dass die kritischen Punkte
immer zuerst überprüft, ist es eine effektive Möglichkeit, die Warnung gleich dem kritischen Wert zu setzen
Schalten Sie Warnungen aus und geben Sie immer einen kritischen Fehler.

Die derzeit unterstützten Aktionen sind:

archiv_bereit
("symlink: check_postgres_archive_ready") Prüft, wie viele WAL-Dateien mit Erweiterung .bereit
existieren in der pg_xlog/archive_status Verzeichnis, das von Ihrem gefunden wird Datenverzeichnis.
Diese Aktion muss als Superuser ausgeführt werden, um auf die Inhalte der
pg_xlog/archive_status Verzeichnis. Die Mindestversion für diese Aktion ist Postgres 8.1.
Die --Warnung und --kritisch Optionen sind einfach die Anzahl der .bereit Dateien in der
pg_xlog/archive_status Verzeichnis. Normalerweise sollten diese Werte niedrig sein
Archiv-Mechanismus möchten wir normalerweise, dass er WAL-Dateien so schnell wie möglich archiviert.

Wenn der Archivierungsbefehl fehlschlägt, wird die Anzahl der WAL in Ihrem pg_xlog Verzeichnis wird wachsen bis
Erschöpfen des gesamten Speicherplatzes und erzwingen, dass PostgreSQL sofort beendet wird.

Beispiel 1: Überprüfen Sie, ob die Anzahl der fertigen WAL-Dateien auf dem Host "pluto" 10 oder weniger beträgt

check_postgres_archive_ready --host=pluto --kritische=10

Meldet für die MRTG-Ausgabe die Anzahl der fertigen WAL-Dateien in Zeile 1.

autovac_freeze
("symlink: check_postgres_autovac_freeze") Prüft, wie nah jede Datenbank an der
Postgres autovacuum_freeze_max_age Einstellung. Diese Aktion funktioniert nur für Datenbanken
Version 8.2 oder höher. Die --Warnung und --kritisch Optionen sollten ausgedrückt werden als
Prozentsätze. Das 'Alter' der Transaktionen in jeder Datenbank wird mit dem
autovacuum_freeze_max_age-Einstellung (200 Millionen standardmäßig), um eine gerundete zu generieren
Prozentsatz. Die Standardwerte sind 90% für die Warnung und 95% für die kritischen. Datenbanken
kann gefiltert werden mit der --enthalten und --ausschließen Optionen. Siehe "GRUNDLEGENDE FILTERUNG"
Abschnitt für weitere Details.

Beispiel 1: Geben Sie eine Warnung aus, wenn eine Datenbank auf Port 5432 über 97% liegt

check_postgres_autovac_freeze --port=5432 --warning="97%"

Für die MRTG-Ausgabe wird der höchste Gesamtprozentsatz in der ersten Zeile gemeldet, und die
Das höchste Alter wird in der zweiten Zeile angegeben. Alle Datenbanken, die den Prozentsatz von . haben
die erste Zeile wird in der vierten Zeile gemeldet, getrennt durch ein Pipe-Symbol.

Backends
("symlink: check_postgres_backends") Prüft die aktuelle Anzahl der Verbindungen auf eine oder
mehr Datenbanken und vergleicht sie optional mit dem maximal erlaubten, das bestimmt wird durch
die Postgres-Konfigurationsvariable max_connectionsdem „Vermischten Geschmack“. Seine --Warnung und --kritisch Optionen
kann eine von drei Formen annehmen. Zunächst kann eine einfache Zahl angegeben werden, die die
Anzahl der Verbindungen, bei denen die Warnung ausgegeben wird. Diese Auswahl verwendet nicht die
max_connections Einstellung. Zweitens kann der Prozentsatz der verfügbaren Verbindungen angegeben werden.
Drittens kann eine negative Zahl angegeben werden, die die Anzahl der verbleibenden Verbindungen darstellt
bis max_connections ist erreicht. Die Standardwerte für --Warnung und --kritisch sind
'90%' und '95%'. Sie können die Datenbanken auch filtern, indem Sie die --enthalten und --ausschließen
Optionen. Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG".

Um nur Prozesse anzuzeigen, die nicht im Leerlauf sind, können Sie die --Nudel Streit. Beachten Sie, dass der Benutzer, den Sie
verbinden, da Sie ein Superuser sein müssen, damit dies ordnungsgemäß funktioniert.

Beispiel 1: Geben Sie eine Warnung aus, wenn die Anzahl der Verbindungen auf Host quirm 120 erreicht, und a
kritisch, wenn sie 150 erreicht.

check_postgres_backends --host=quirm --warning=120 --kritische=150

Beispiel 2: Geben Sie einen kritischen Wert an, wenn wir 75% unserer max_connections-Einstellung auf Hosts erreichen
Lancre oder Lancre2.

check_postgres_backends --warning='75%' --kritische='75%' --host=lancre,lancre2

Beispiel 3: Geben Sie eine Warnung aus, wenn nur noch 10 Verbindungsslots auf dem Host übrig sind
Plasmid, und ein kritisches, wenn wir nur noch 5 übrig haben.

check_postgres_backends --warning=-10 --critical=-5 --host=plasmid

Beispiel 4: Überprüfen Sie alle Datenbanken außer denen mit "test" im Namen, aber lassen Sie diejenigen zu, die
heißen "pg_greatest". Verbinden Sie sich als Port 5432 auf den ersten beiden Hosts und als Port 5433 auf
der dritte. Wir wollen immer einen kritischen Punkt werfen, wenn wir 30 oder mehr Verbindungen erreichen.

check_postgres_backends --dbhost=hong,kong --dbhost=fooey --dbport=5432 --dbport=5433 --warning=30 --critical=30 --exclude="~test" --include="pg_greatest,~prod "

Für die MRTG-Ausgabe wird die Anzahl der Verbindungen in der ersten Zeile und in der vierten angezeigt
line gibt den Namen der Datenbank plus die aktuellen maximum_connections an. Wenn mehr als
eine Datenbank abgefragt wurde, wird diejenige mit den meisten Verbindungen ausgegeben.

schlankere Taille:
("symlink: check_postgres_bloat") Überprüft die Menge an Bloat in Tabellen und Indizes. (Aufblähen
ist im Allgemeinen die Menge an totem ungenutztem Speicherplatz, die in einer Tabelle oder einem Index eingenommen wird. Dieser Raum ist
normalerweise mit dem VACUUM-Befehl zurückgefordert.) Diese Aktion erfordert, dass stats
Sammlung auf den Zieldatenbanken aktiviert sein und erfordert, dass ANALYZE ausgeführt wird
häufig. Die --enthalten und --ausschließen Optionen können verwendet werden, um herauszufiltern, welche Tabellen
ansehen. Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG".

Die --Warnung und --kritisch Optionen können als Größen, Prozent oder beides angegeben werden. Gültig
Größeneinheiten sind Byte, Kilobyte, Megabyte, Gigabyte, Terabyte, Exabyte, Petabyte und
Zettabyte. Sie können alle mit dem ersten Buchstaben abkürzen. Artikel ohne Einheiten sind
als "Byte" angenommen. Die Standardwerte sind '1 GB' und '5 GB'. Der Wert repräsentiert die
Anzahl der "verschwendeten Bytes", oder der Unterschied zwischen dem, was tatsächlich von der Tabelle verwendet wird, und
Index, und was wir berechnen, dass es sein sollte.

Beachten Sie, dass diese Aktion zwei hartcodierte Werte hat, um Fehlalarme bei kleineren . zu vermeiden
Beziehungen. Tabellen müssen mindestens 10 Seiten und Indizes mindestens 15 Seiten haben, bevor sie erstellt werden können
bei diesem Test berücksichtigt. Wenn Sie diese Werte wirklich anpassen möchten, können Sie nach dem
Variablen $MINPAGES und $Miniseiten oben in der Unterroutine "check_bloat". Diese
Werte werden ignoriert, wenn entweder --ausschließen or --enthalten wird eingesetzt.

Nur die Top 10 der am meisten aufgeblähten Beziehungen werden angezeigt. Sie können diese Nummer ändern, indem Sie die
--perflimit Möglichkeit, Ihr eigenes Limit festzulegen.

Das Schema mit dem Namen 'information_schema' ist von diesem Test ausgeschlossen, da es die einzige Tabelle ist
enthält sind klein und ändern sich nicht.

Bitte beachten Sie, dass die durch diese Aktion berechneten Werte nicht präzise sind und als
nur eine Richtlinie. Es wurden große Anstrengungen unternommen, um die richtige Größe einer Tabelle zu schätzen, aber in
Am Ende ist es nur eine Schätzung. Die richtige Indexgröße ist noch eine Vermutung als die
richtige Tischgröße, aber beide sollten eine ungefähre Vorstellung davon geben, wie aufgedunsen die Dinge sind.

Beispiel 1: Warnen, wenn eine Tabelle auf Port 5432 über 100 MB aufgebläht ist, und kritisch, wenn über 200
MB

check_postgres_bloat --port=5432 --warning='100 M' --kritische='200 M'

Beispiel 2: Geben Sie einen kritischen Punkt, wenn die Tabelle 'orders' auf dem Host 'sami' mehr als 10 Megabyte aufgebläht hat

check_postgres_bloat --host=sami --include=orders --critical='10 MB'

Beispiel 3: Geben Sie einen kritischen Wert an, wenn die Tabelle 'q4' in der Datenbank 'Sales' über 50% aufgebläht ist

check_postgres_bloat --db=sales --include=q4 --kritische='50%'

Beispiel 4: Geben Sie einem kritischen Punkt an, dass jeder Tisch über 20 % aufgebläht ist und hat über 150 MB aufgebläht:

check_postgres_bloat --port=5432 --critical='20% und 150 Mio.'

Beispiel 5: Geben Sie einem kritischen Punkt an, dass jeder Tisch über 40 % aufgebläht ist or hat über 500 MB aufgebläht:

check_postgres_bloat --port=5432 --warning='500 M oder 40%'

Bei der MRTG-Ausgabe gibt die erste Zeile die höchste Anzahl an verschwendeten Bytes für die Tabellen an.
und die zweite Zeile gibt die höchste Anzahl an verschwendeten Bytes für die Indizes an. Die vierte
line gibt Informationen zum Datenbanknamen, Tabellennamen und Indexnamen an. Wenn du möchtest
Geben Sie stattdessen die Bloat Ratio aus (wie oft ist die Relation größer im Vergleich zu wie)
groß sollte es sein), übergeben Sie einfach "--mrtg=ratio".

Kontrollpunkt
("symlink: check_postgres_checkpoint") Legt fest, wie lange seit dem letzten Checkpoint
gelaufen worden. Diese muss auf demselben Server laufen wie die zu prüfende Datenbank (zB die
-h Flag funktioniert nicht). Diese Prüfung soll auf einem "Warm-Standby"-Server ausgeführt werden, der
aktiv versendete WAL-Dateien verarbeitet und soll überprüfen, ob Ihr Warm-Standby
wirklich "warm". Das Datenverzeichnis muss gesetzt werden, entweder durch die Umgebungsvariable
"PGDATA" oder Übergabe des Arguments "--datadir". Es gibt die Anzahl der Sekunden seit dem
Der letzte Prüfpunkt wurde ausgeführt, wie durch das Parsen des Aufrufs von "pg_controldata" bestimmt wurde. Durch
Dazu muss die ausführbare Datei pg_controldata im aktuellen Pfad verfügbar sein. Alternative,
Sie können "PGBINDIR" als Verzeichnis angeben, in dem es sich befindet. Es ist auch möglich,
die besonderen optionen --asme-prod or --Standby-Modus annehmen, wenn der gefundene Modus nicht der ist
erwartet, wird ein CRITICAL ausgegeben.

Mindestens eine Warnung oder ein kritisches Argument muss festgelegt werden.

Diese Aktion erfordert das Date::Parse-Modul.

Gibt für MRTG oder einfache Ausgabe die Anzahl der Sekunden zurück.

Cluster-ID
("symlink: check_postgres_cluster-id") Überprüft, ob die bereitgestellte Datenbanksystemkennung
by pg_controldata ist das gleiche wie bei der letzten Überprüfung. Dies muss auf dem gleichen Server laufen
als Datenbank, die überprüft wird (zB das Flag -h funktioniert nicht). Entweder
--Warnung oder unter der --kritisch Option sollte angegeben werden, aber nicht beides. Der Wert jedes einzelnen ist
die Cluster-ID, ein ganzzahliger Wert. Sie können mit dem speziellen "--critical=0" laufen
Option, um eine vorhandene Cluster-ID herauszufinden.

Beispiel 1: Finden Sie die Anfangskennung

check_postgres_cluster_id --kritische=0 --datadir=/var//lib/postgresql/9.0/main

Beispiel 2: Stellen Sie sicher, dass der Cluster gleich ist, und warnen Sie andernfalls, indem Sie das Ergebnis von oben verwenden.

check_postgres_cluster_id --critical=5633695740047915135

Gibt für die MRTG-Ausgabe eine 1 oder 0 zurück, die den Erfolg oder das Fehlschlagen des Bezeichners an . anzeigt
Spiel. Als Argument "--mrtg" muss ein Bezeichner angegeben werden. Die vierte Zeile immer
gibt die aktuelle Kennung an.

Verpflichtungsverhältnis
("symlink: check_postgres_commitratio") Prüft das Commit-Verhältnis aller Datenbanken und
beschwert sich, wenn sie zu niedrig sind. Sie müssen diesen Befehl nicht mehr als einmal pro ausführen
Datenbankcluster. Datenbanken können mit dem gefiltert werden --enthalten und --ausschließen Optionen. Sehen
Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG". Sie können auch nach dem Eigentümer von . gefiltert werden
die Datenbank mit dem --includeuser und --excludeuser Optionen. Siehe "BENUTZERNAME
FILTERUNG" für weitere Details.

Die Optionen Warnung und Kritisch sollten in Prozent angegeben werden. Es gibt keine
Standardwerte für diese Aktion: Warnung und kritisch müssen angegeben werden. Der Warnwert
darf nicht größer als der kritische Wert sein. Die Ausgabe liefert alle Datenbanken sortiert nach
Commitration, kleinste zuerst.

Beispiel: Warnen, wenn eine Datenbank auf Host-Flagg weniger als 90% im Commitratio aufweist und kritisch ist
wenn weniger als 80%.

check_postgres_database_commitratio --host=flagg --warning='90%' --kritische='80%'

Gibt für die MRTG-Ausgabe den Prozentsatz der Datenbank mit dem kleinsten Commitratio zurück
in der ersten Zeile und der Name der Datenbank in der vierten Zeile.

Verbindung
("symlink: check_postgres_connection") Einfach eine Verbindung herstellen, ein 'SELECT . ausgeben Ausführung()', und
Laub. Nimmt nein --Warnung or --kritisch Optionen.

Für die MRTG-Ausgabe einfach eine 1 (gute Verbindung) oder eine 0 (schlechte Verbindung) auf der ersten ausgeben
Linie.

benutzerdefinierte_Abfrage
("symlink: check_postgres_custom_query") Führt eine benutzerdefinierte Abfrage Ihrer Wahl aus und analysiert
die Ergebnisse. Die Abfrage selbst wird über das Argument "query" übergeben und sollte
so einfach wie möglich gehalten. Wenn möglich, wickeln Sie es in eine Ansicht oder Funktion ein, um es beizubehalten
Dinge einfacher zu handhaben. Die Abfrage sollte eine oder zwei Spalten zurückgeben. Es ist erforderlich, dass
Eine der Spalten trägt den Namen "Ergebnis" und ist das Element, das mit Ihrem verglichen wird
Warn- und kritische Werte. Die zweite Spalte ist für die Leistungsdaten und einen beliebigen Namen
kann verwendet werden: Dies ist der 'Wert' innerhalb des Leistungsdatenabschnitts.

Es muss mindestens eine Warnung oder ein kritisches Argument angegeben werden. Auf was diese eingestellt sind, hängt davon ab
vom Typ der Abfrage, die Sie ausführen. Es gibt vier Arten von benutzerdefinierten Abfragen, die sein können
run, angegeben durch das Argument "valtype". Wenn keine angegeben ist, ist diese Aktion standardmäßig
'ganze Zahl'. Die vier Typen sind:

ganze Zahl: Führt einen einfachen Ganzzahlvergleich durch. Die erste Spalte sollte eine einfache ganze Zahl sein,
und die Warn- und kritischen Werte sollten gleich sein.

Schnur: Warning und Critical sind Strings und werden nur ausgelöst, wenn der Wert im
erste Spalte stimmt genau damit überein. Hierbei wird die Groß-/Kleinschreibung beachtet.

Zeit: Die Warnung und die kritische sind Zeiten und können Einheiten von Sekunden, Minuten,
Stunden oder Tage. Jeder kann einzeln geschrieben oder auf den ersten Buchstaben abgekürzt werden. Wenn
Es werden keine Einheiten angegeben, Sekunden werden angenommen. Die erste Spalte sollte eine ganze Zahl sein
steht für die Anzahl der zu überprüfenden Sekunden.

Größe: Die Warnung und der kritische Wert sind Größen und können Einheiten von Bytes, Kilobytes,
Megabyte, Gigabyte, Terabyte oder Exabyte. Jeder kann auf den ersten Buchstaben abgekürzt werden.
Wenn keine Einheiten angegeben sind, werden Bytes angenommen. Die erste Spalte sollte eine ganze Zahl sein
die die Anzahl der zu überprüfenden Bytes darstellt.

Normalerweise wird eine Warnung ausgelöst, wenn die zurückgegebenen Werte mehr als oder gleich dem
kritischer oder Warnwert. Jedoch eine Option von --umkehren löst die Warnung aus, wenn die
zurückgegebener Wert ist senken als oder gleich dem kritischen oder Warnwert.

Beispiel 1: Warnen, wenn eine Beziehung über 100 Seiten "rad" heißt, geben Sie die Anzahl der Seiten an
im Abschnitt Leistungsdaten.

check_postgres_custom_query --valtype=string -w "rad" --query=
"SELECT relname AS Ergebnis, relpages AS Seiten FROM pg_class WHERE relpages > 100"

Beispiel 2: Geben Sie einen kritischen Wert ein, wenn die Funktion "foobar" eine Zahl über 5 MB zurückgibt:

check_postgres_custom_query --critical='5MB'--valtype=size --query="SELECT foobar() AS result"

Beispiel 2: Warnen, wenn die Funktion "snazzo" weniger als 42 zurückgibt:

check_postgres_custom_query --critical=42 --query="SELECT snazzo() AS result" --reverse

Wenn Sie eine nützliche custom_query haben, sollten Sie einen Patch an dieses Programm senden an
machen Sie es zu einer Standardaktion, die andere Leute verwenden können.

Diese Aktion unterstützt noch nicht MRTG oder einfache Ausgabe.

Datenbankgröße
("symlink: check_postgres_database_size") Prüft die Größe aller Datenbanken und beschwert sich
wenn sie zu groß sind. Dieser Befehl muss nicht mehr als einmal pro Datenbank ausgeführt werden
Cluster. Datenbanken können mit dem gefiltert werden --enthalten und --ausschließen Optionen. Siehe die
Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG". Sie können auch nach dem Eigentümer des gefiltert werden
Datenbank mit der --includeuser und --excludeuser Optionen. Siehe "FILTERUNG DES BENUTZERNAMENS"
Abschnitt für weitere Details.

Die Warnungs- und kritischen Optionen können als Byte, Kilobyte, Megabyte,
Gigabyte, Terabyte oder Exabyte. Jeder kann auch auf den ersten Buchstaben abgekürzt werden.
Wenn keine Einheit angegeben ist, werden die Einheiten als Bytes angenommen. Dafür gibt es keine Vorgaben
Aktion: Warnung und kritisch müssen angegeben werden. Der Warnwert kann nicht größer sein
als der kritische Wert. Die Ausgabe gibt alle Datenbanken sortiert nach der größten Größe zuerst zurück,
zeigt sowohl rohe Bytes als auch eine "hübsche" Version der Größe an.

Beispiel 1: Warnen, wenn eine Datenbank auf Host-Flagg größer als 1 TB ist, und kritisch, wenn sie größer ist
1.1 TB.

check_postgres_database_size --host=flagg --warning='1 TB' --critical='1.1 t'

Beispiel 2: Geben Sie einen kritischen Wert ein, wenn die Datenbankvorlage1 auf Port 5432 über 10 MB groß ist.

check_postgres_database_size --port=5432 --include=template1 --warning='10MB' --kritische='10MB'

Beispiel 3: Geben Sie eine Warnung aus, wenn eine Datenbank auf dem Host 'tardis', die dem Benutzer 'tom' gehört, überschritten ist
5 GB

check_postgres_database_size --host=tardis --includeuser=tom --warning='5 GB' --kritische='10 GB'

Gibt für die MRTG-Ausgabe die Größe in Bytes der größten Datenbank in der ersten Zeile zurück, und
der Name der Datenbank in der vierten Zeile.

dbstats
("symlink: check_postgres_dbstats") Meldet Informationen aus der pg_stat_database-Ansicht,
und gibt es kakteenfreundlich aus. Keine andere Ausgabe wird unterstützt, da die Ausgabe
informativ und eignet sich nicht für Warnungen, wie sie bei Nagios verwendet werden. Wenn keine Optionen
gegeben sind, werden alle Datenbanken zurückgegeben, eine pro Zeile. Sie können eine bestimmte Datenbank einschließen
mit der Option "--include" oder mit der Option "--dbname".

In jeder Zeile werden elf Elemente zurückgegeben, im Format Name:Wert, getrennt durch ein einzelnes
Platz. Die Artikel sind:

Backends
Die Anzahl der derzeit ausgeführten Back-Ends für diese Datenbank.

verpflichtet
Die Gesamtzahl der Commits für diese Datenbank seit ihrer Erstellung oder Zurücksetzung.

Rollbacks
Die Gesamtzahl der Rollbacks für diese Datenbank seit ihrer Erstellung oder Zurücksetzung.

lesen
Die Gesamtzahl der gelesenen Datenträgerblöcke.

hit Die Gesamtzahl der Puffertreffer.

ret Die Gesamtzahl der zurückgegebenen Zeilen.

holen
Die Gesamtzahl der abgerufenen Zeilen.

ins Die Gesamtzahl der eingefügten Zeilen.

upd Die Gesamtzahl der aktualisierten Zeilen.

del Die Gesamtzahl der gelöschten Zeilen.

Datenbankname
Der Name der Datenbank.

Beachten Sie, dass ret-, fetch-, ins-, upd- und del-Elemente immer 0 sind, wenn Postgres Version 8.2 ist
oder niedriger, da diese Statistiken in diesen Versionen nicht verfügbar waren.

Wenn das Argument dbname angegeben wird, werden sieben zusätzliche Elemente zurückgegeben:

idxscan
Gesamtzahl der Benutzerindex-Scans.

idxtupread
Gesamtzahl der zurückgegebenen Benutzerindexeinträge.

idxtupfetch
Gesamtzahl der Zeilen, die durch einfache Benutzerindex-Scans abgerufen wurden.

idxblksread
Gesamtzahl der gelesenen Plattenblöcke für alle Benutzerindizes.

idxblkshit
Gesamtzahl der Puffertreffer für alle Benutzerindizes.

seqscan
Gesamtanzahl sequenzieller Scans für alle Benutzertabellen.

weiterlesen
Gesamtzahl der von allen Benutzertabellen zurückgegebenen Tupel.

Beispiel 1: Besorgen Sie sich die Statistiken für eine Datenbank namens "products" auf dem Host "willow":

check_postgres_dbstats --dbhost willow --dbname Produkte

Die zurückgegebene Ausgabe sieht so aus (alles in einer Zeile, nicht umbrochen):

Backends:82 Commits:58374408 Rollbacks:1651 Read:268435543 Hit:2920381758 idxscan:310931294 idxtupread:2777040927
idxtupfetch:1840241349 idxblksread:62860110 idxblkshit:1107812216 seqscan:5085305 seqtupread:5370500520
ret:0 fetch:0 ins:0 upd:0 del:0 dbname:willow

disabled_triggers
("symlink: check_postgres_disabled_triggers") Prüft die Anzahl der deaktivierten Trigger
innerhalb der Datenbank. Die --Warnung und --kritisch Optionen sind die Anzahl solcher Trigger
gefunden, und beide sind standardmäßig auf "1" eingestellt, da es im normalen Gebrauch gefährlich ist, deaktivierte Trigger zu haben
Veranstaltung. Wenn die überprüfte Datenbank 8.3 oder höher ist, wird die Anzahl der
Trigger, die sich im Status "deaktiviert" befinden (im Gegensatz zu "Immer" oder "Replikat"). Die
Die Ausgabe zeigt den Namen der Tabelle und den Namen des Triggers für jede Deaktivierung an
auslösen.

Beispiel 1: Stellen Sie sicher, dass keine deaktivierten Trigger vorhanden sind

check_postgres_disabled_triggers

Gibt für die MRTG-Ausgabe die Anzahl der deaktivierten Trigger in der ersten Zeile zurück.

Festplattenplatz
("symlink: check_postgres_disk_space") Überprüft den verfügbaren physischen Speicherplatz, der von . verwendet wird
Postgres. Diese Aktion erfordert, dass Sie die ausführbare Datei "/bin/df"verfügbar zu melden
auf Datenträgergrößen, und es muss auch als Superuser ausgeführt werden, damit es die
Datenverzeichnis Einstellung innerhalb von Postgres. Die --Warnung und --kritisch Optionen sind gegeben
entweder in Größen oder Prozentsätzen oder beidem. Bei Verwendung von Größen sind die Standardgerätetypen
erlaubt: Byte, Kilobyte, Gigabyte, Megabyte, Gigabyte, Terabyte oder Exabyte. Jeder
darf nur auf den ersten Buchstaben abgekürzt werden; überhaupt keine Einheiten zeigen 'Bytes' an. Die
Standardwerte sind '90%' und '95%'.

Dieser Befehl überprüft die folgenden Dinge, um alle verschiedenen physischen Festplatten zu bestimmen
von Postgres verwendet wird.

Datenverzeichnis - Der Datenträger, auf dem sich das Hauptdatenverzeichnis befindet.

Log Verzeichnis - Die Festplatte, auf der sich die Protokolldateien befinden.

WAL Datei Verzeichnis - Die Platte, auf der sich die Write-Ahead-Protokolle befinden (zB pg_xlog symbolisiert)

Tablespaces - Jeder Tablespace, der sich auf einer separaten Platte befindet.

Die Ausgabe zeigt die auf jedem Datenträger verwendete und verfügbare Gesamtgröße sowie die
Prozent, sortiert nach dem höchsten zum niedrigsten verwendeten Prozentsatz. Jedes obige Element ist einer Datei zugeordnet
System: Diese können ein- oder ausgeschlossen werden. Siehe den Abschnitt "GRUNDLEGENDE FILTERUNG" für mehr
Details.

Beispiel 1: Stellen Sie sicher, dass kein Dateisystem für die Datenbank auf Port 90 über 5432% ist.

check_postgres_disk_space --port=5432 --warning='90%' --kritische='90%'

Beispiel 2: Überprüfen Sie, ob alle Dateisysteme, die mit /dev/sda beginnen, kleiner als 10 GB sind und
11 GB (Warnung und kritisch)

check_postgres_disk_space --port=5432 --warning='10 GB' --kritische='11 GB' --include="~^/dev/sda"

Beispiel 4: Stellen Sie sicher, dass kein Dateisystem mehr als 50% beträgt und hat über 15 GB

check_postgres_disk_space --kritisch='50% und 15 GB'

Beispiel 5: Eine Warnung ausgeben, wenn ein Dateisystem entweder zu über 70 % voll ist or hat mehr als 1T

check_postgres_disk_space --warning='1T oder 75'

Gibt für die MRTG-Ausgabe in der ersten Zeile die Größe des Dateisystems in Bytes zurück und die
Name des Dateisystems in der vierten Zeile.

fsm_seiten
("symlink: check_postgres_fsm_pages") Prüft, wie nah ein Cluster am Postgres liegt
max_fsm_pages Einstellung. Diese Aktion funktioniert nur für Datenbanken der Version 8.2 oder höher und es
benötigt das contrib-Modul pg_freespacemap installiert werden. Die --Warnung und --kritisch
Optionen sollten in Prozent angegeben werden. Die Anzahl der verwendeten Seiten in der Free-Space-Map
wird bestimmt, indem Sie in der Ansicht pg_freespacemap_relations nachsehen und eine Formel ausführen
basierend auf der Formel, die für die Ausgabe von Free-Space-Map-Seitenschlitzen im Vakuum ausführlich verwendet wird
Befehl. Die Standardwerte sind 85% für die Warnung und 95% für die kritischen.

Beispiel 1: Geben Sie eine Warnung aus, wenn unser Cluster 76 % der freien Seitenschlitze aufgebraucht hat.
mit pg_freespacemap in der Datenbank Robert installiert

check_postgres_fsm_pages --dbname=robert --warning="76%"

Sie müssen zwar den Namen der Datenbank übergeben, in der pg_freespacemap installiert ist, Sie
Sie müssen diese Prüfung nur einmal pro Cluster ausführen. Die Überprüfung dieser Informationen erfordert außerdem
spezielle Sperren auf der Free-Space-Map zu erhalten, daher wird empfohlen, dies nicht auszuführen
in kurzen Abständen überprüfen.

Gibt für die MRTG-Ausgabe den Prozentsatz der Free-Space-Map in der ersten Zeile und die Zahl zurück
der aktuell verwendeten Seiten in der zweiten Zeile.

fsm_relations
("symlink: check_postgres_fsm_relations") Prüft, wie nah ein Cluster am Postgres liegt
max_fsm_relations Einstellung. Diese Aktion funktioniert nur für Datenbanken ab Version 8.2 und
es erfordert das contrib-Modul pg_freespacemap installiert werden. Die --Warnung und --kritisch
Optionen sollten in Prozent angegeben werden. Die Anzahl der verwendeten Relationen im freien
space-map wird durch einen Blick in die Ansicht pg_freespacemap_relations bestimmt. Der Standard
Werte sind 85% für die Warnung und 95% für die kritischen.

Beispiel 1: Geben Sie eine Warnung aus, wenn unser Cluster 80% der freien Speicherplatzbeziehungen aufgebraucht hat,
mit pg_freespacemap installiert in Datenbank dylan

check_postgres_fsm_relations --dbname=dylan --warning="75%"

Sie müssen zwar den Namen der Datenbank übergeben, in der pg_freespacemap installiert ist, Sie
Sie müssen diese Prüfung nur einmal pro Cluster ausführen. Die Überprüfung dieser Informationen erfordert außerdem
spezielle Sperren auf der Free-Space-Map zu erhalten, daher wird empfohlen, dies nicht auszuführen
in kurzen Abständen überprüfen.

Gibt für die MRTG-Ausgabe den Prozentsatz der Free-Space-Map in der ersten Zeile zurück, die Anzahl der
Relationen, die derzeit in der zweiten Zeile verwendet werden.

Trefferquote
("symlink: check_postgres_hitratio") Prüft die Trefferquote aller Datenbanken und beschwert sich
wenn sie zu niedrig sind. Dieser Befehl muss nicht mehr als einmal pro Datenbank ausgeführt werden
Cluster. Datenbanken können mit dem gefiltert werden --enthalten und --ausschließen Optionen. Siehe die
Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG". Sie können auch nach dem Eigentümer des gefiltert werden
Datenbank mit der --includeuser und --excludeuser Optionen. Siehe "FILTERUNG DES BENUTZERNAMENS"
Abschnitt für weitere Details.

Die Optionen Warnung und Kritisch sollten in Prozent angegeben werden. Es gibt keine
Standardwerte für diese Aktion: Warnung und kritisch müssen angegeben werden. Der Warnwert
darf nicht größer als der kritische Wert sein. Die Ausgabe liefert alle Datenbanken sortiert nach
Hitrate, kleinste zuerst.

Beispiel: Warnen, wenn eine Datenbank auf Host-Flagg weniger als 90% in der Trefferquote hat, und kritisch, wenn
weniger als 80%.

check_postgres_hitratio --host=flagg --warning='90%' --kritische='80%'

Gibt für die MRTG-Ausgabe den Prozentsatz der Datenbank mit der kleinsten Trefferquote auf der
erste Zeile und der Name der Datenbank in der vierten Zeile.

hot_standby_delay
("symlink: check_hot_standby_delay") Überprüft die Streaming-Replikationsverzögerung durch Berechnung der
Delta zwischen der aktuellen xlog-Position eines Master-Servers und dem Wiedergabeort eines
Sklave daran angeschlossen. Der Slave-Server muss sich im Hot_Standby-Modus (zB nur lesen) befinden,
daher ist die Mindestversion für diese Aktion Postgres 9.0. Die --Warnung und
--kritisch Optionen sind das Delta zwischen den xlog-Speicherorten. Da diese Werte Bytes sind
Offsets in der WAL sollten sie dem erwarteten Transaktionsvolumen Ihrer Anwendung entsprechen
um falsch positive oder negative Ergebnisse zu vermeiden.

Die ersten Optionen "--dbname", "--host" und "--port" usw. werden als Master betrachtet; das
zweite gehört dem Sklaven.

Bytewerte sollten auf dem Transaktionsvolumen basieren, das für das Streaming erforderlich ist
Replikationsabbruch vom Master wegen zu großer Verzögerung, bestimmt durch die Postgres
Konfigurationsvariable wal_keep_segments. Gültige Einheiten für Zeiteinheiten sind "Sekunden",
„Minuten“, „Stunden“ oder „Tage“. Jeder kann einzeln geschrieben oder auf nur die abgekürzt werden
erster Brief. Wenn Sie beide angeben, in der Form 'Bytes und Zeit', beide Bedingungen müssen sein
true für den zu erreichenden Schwellenwert.

Sie müssen durch Komma getrennt angeben, wie Sie die Datenbanken erreichen
listen Sie die Parameter --dbhost und --dbport auf, z. B. "--dbport=5432,5543". Wenn nicht gegeben,
die Aktion schlägt fehl.

Beispiel 1: Warnung, dass eine Datenbank mit einem lokalen Replikat auf Port 5433 bei jeder xlog-Wiedergabe im Rückstand ist


check_hot_standby_delay --dbport=5432,5433 --warning='1'

Beispiel 2: Geben Sie einen kritischen Wert an, wenn die letzte Transaktion, die Replik1 empfängt, mehr als 10 . beträgt
Vor ein paar Minuten

check_hot_standby_delay --dbhost=master,replica1 --critical='10 min'

Beispiel 3: Replica1 darf 1 WAL-Segment hinterher sein, wenn der Master momentan sieht
mehr Aktivität, als die Streaming-Replikationsverbindung verarbeiten kann, oder 10 Minuten später,
wenn der Master sehr wenig Aktivität sieht und keine Transaktionen verarbeitet, aber nicht
beides, was auf ein dauerhaftes Problem mit der Replikationsverbindung hinweisen würde.

check_hot_standby_delay --dbhost=master,replica1 --warning='1048576 und 2 min' --critical='16777216 und 10 min'

Indexgröße
Tischgröße
relation_size
(symlinks: "check_postgres_index_size", "check_postgres_table_size" und
"check_postgres_relation_size") Die Aktionen Tischgröße und Indexgröße sind einfach
Variationen der relation_size Aktion, die nach einer mitgewachsenen Beziehung sucht
groß. Relationen (also Tabellen und Indizes) können mit dem --enthalten
und --ausschließen Optionen. Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG". Beziehungen können
auch von dem Benutzer gefiltert werden, der sie besitzt, indem Sie die --includeuser und --excludeuser
Optionen. Weitere Informationen finden Sie im Abschnitt "FILTERUNG DES BENUTZERNAMENS".

Die Werte für die --Warnung und --kritisch Optionen sind Dateigrößen und können Einheiten von haben
Byte, Kilobyte, Megabyte, Gigabyte, Terabyte oder Exabyte. Jeder kann abgekürzt werden
zum ersten Buchstaben. Wenn keine Einheiten angegeben sind, werden Bytes angenommen. Es gibt keine Vorgabe
Werte: Sowohl die Warnung als auch die kritische Option müssen angegeben werden. Der Rückgabetext zeigt die
Größe der größten gefundenen Relation.

Besitzt das --showperf Option ist aktiviert, alle der Beziehungen zu ihren Größen angegeben werden.
Um dies zu verhindern, wird empfohlen, die --perflimit Option, die dazu führen wird
die Abfrage, um eine "ORDER BY size DESC LIMIT (perflimit)" durchzuführen.

Beispiel 1: Geben Sie einen kritischen Wert an, wenn eine Tabelle auf Host Burrick größer als 600 MB ist.

check_postgres_table_size --critical='600 MB' --warning='600 MB' --host=burrick

Beispiel 2: Warnen Sie, wenn die Tabellenprodukte größer als 4 GB sind, und geben Sie einen kritischen Wert von 4.5 GB an.

check_postgres_table_size --host=burrick --warning='4 GB' --kritische='4.5 GB' --include=products

Beispiel 3: Warnen, wenn ein Index, der nicht im Besitz von postgres ist, 500 MB überschreitet.

check_postgres_index_size --port=5432 --excludeuser=postgres -w 500 MB -c 600 MB

Gibt für die MRTG-Ausgabe die Größe der größten Relation in Bytes und den Namen der
Datenbank und Relation als vierte Zeile.

letzte_analyse
letztes_vakuum
last_autoanalyze
last_autovacuum
(symlinks: "check_postgres_last_analyze", "check_postgres_last_vacuum",
"check_postgres_last_autoanalyze" und "check_postgres_last_autovacuum") Prüft, wie lange
es ist seit der letzten Ausführung von Vacuum (oder Analyze) für jede Tabelle in einer oder mehreren Datenbanken her.
Die Verwendung dieser Aktionen erfordert, dass die Zieldatenbank Version 8.3 oder höher ist oder dass
die Version ist 8.2 und die Konfigurationsvariable stats_row_level Wurde aktiviert. Tabellen
kann mit dem gefiltert werden --enthalten und --ausschließen Optionen. Siehe "GRUNDLEGENDE FILTERUNG"
Abschnitt für weitere Details. Tabellen können auch nach ihrem Besitzer gefiltert werden, indem Sie die
--includeuser und --excludeuser Optionen. Weitere Informationen finden Sie im Abschnitt "FILTERUNG DES BENUTZERNAMENS".
Details.

Die Einheiten für --Warnung und --kritisch werden als Zeiten angegeben. Gültige Einheiten sind Sekunden,
Minuten, Stunden und Tage; alle können auf den ersten Buchstaben abgekürzt werden. Wenn keine Einheiten vorhanden sind
gegeben, werden 'Sekunden' angenommen. Die Standardwerte sind '1 Tag' und '2 Tage'. bitte beachten Sie
dass es Fälle gibt, in denen dieses Feld nicht automatisch ausgefüllt wird. Wenn sicher
Tabellen machen Ihnen Probleme, stellen Sie sicher, dass sie tote Zeilen zum Staubsaugen haben, oder einfach
sie vom Test ausschließen.

Das Schema mit dem Namen 'information_schema' ist von diesem Test ausgeschlossen, da es die einzige Tabelle ist
enthält sind klein und ändern sich nicht.

Beachten Sie, dass die Nicht-'Auto'-Versionen auch die Auto-Versionen überprüfen. In anderen
Wörter, mit last_vacuum wird das letzte Vakuum gemeldet, ob es ein normales Vakuum war,
oder eine, die vom Autovacuum-Daemon ausgeführt wird.

Beispiel 1: Warnen, wenn ein Tisch in 3 Tagen nicht gesaugt wurde, und geben Sie einen kritischen Punkt bei a
Woche, für Wirt Wermut

check_postgres_last_vacuum --host=Wermut --warning='3d' --critical='7d'

Beispiel 2: Wie oben, aber Tabellen der Benutzer 'eve' oder 'mallory' überspringen

check_postgres_last_vacuum --host=Wermut --warning='3d' --kritische='7d' --excludeusers=eve,mallory

Gibt für die MRTG-Ausgabe (in der ersten Zeile) die KLEINSTE Zeitdauer in Sekunden seit a . zurück
Tabelle wurde zuletzt gesaugt oder analysiert. Die vierte Zeile gibt den Namen der Datenbank zurück und
Name der Tabelle.

Hörer
("symlink: check_postgres_listener") Bestätige, dass jemand auf einen oder mehrere hört
bestimmte Zeichenfolgen (unter Verwendung des LISTEN/NOTIFY-Systems), indem Sie sich die Tabelle pg_listener ansehen.
Nur eine Warnung oder kritisch ist erforderlich. Das Format ist eine einfache Zeichenfolge, die die
LISTEN-Ziel oder ein Tilde-Zeichen gefolgt von einer Zeichenfolge für eine Prüfung auf reguläre Ausdrücke.
Beachten Sie, dass diese Prüfung bei Versionen von Postgres 9.0 oder höher nicht funktioniert.

Beispiel 1: Geben Sie eine Warnung aus, wenn niemand auf Ports auf den String bucardo_mcp_ping lauscht
5555 und 5556

check_postgres_listener --port=5555,5556 --warning=bucardo_mcp_ping

Beispiel 2: Geben Sie einen kritischen Punkt, wenn keine aktiven LISTEN-Anfragen vorhanden sind, die mit 'grimm' übereinstimmen
Datenbank oskar

check_postgres_listener --db oskar --kritische=~grimm

Gibt für die MRTG-Ausgabe beim ersten eine 1 oder eine 0 zurück, was auf Erfolg oder Misserfolg hinweist. Der Name
der Mitteilung muss über die --mrtg .

Schlösser
("symlink: check_postgres_locks") Überprüfen Sie die Gesamtzahl der Sperren auf einer oder mehreren
Datenbanken. Dies muss nicht mehr als einmal pro Datenbankcluster ausgeführt werden. Datenbanken können
mit dem gefiltert werden --enthalten und --ausschließen Optionen. Siehe Abschnitt "GRUNDLEGENDE FILTERUNG"
für weitere Informationen an.

Die --Warnung und --kritisch Optionen können als einfache Zahlen angegeben werden, die
die Gesamtzahl der Schlösser, oder sie können nach Schlosstyp aufgeschlüsselt werden. Gültige Schlossnamen
sind 'total', 'waiting' oder der Name eines von Postgres verwendeten Sperrtyps. Diese Namen sind
Groß-/Kleinschreibung nicht beachten und den "Lock"-Teil am Ende nicht benötigen, also exklusiv passt auf
'Exklusive Sperre'. Das Format ist Name=Zahl, wobei verschiedene Elemente durch Doppelpunkte getrennt sind oder
Semikolon (oder ein anderes Symbol).

Beispiel 1: Warnen, wenn die Anzahl der Sperren 100 oder mehr beträgt, und kritisch, wenn 200 oder mehr, an
Gastgeber Garrett

check_postgres_locks --host=garrett --warning=100 --critical=200

Beispiel 2: Warnen Sie auf dem Host-Artemus, wenn 200 oder mehr Sperren vorhanden sind, und geben Sie ein kritisches if . ein
mehr als 250 Sperren insgesamt vorhanden sind, oder wenn mehr als 20 exklusive Sperren vorhanden sind, oder wenn mehr als 5 Verbindungen vorhanden sind
warten auf ein Schloss.

check_postgres_locks --host=artemus --warning=200 --critical="total=250:waiting=5:exclusive=20"

Gibt für die MRTG-Ausgabe die Anzahl der Sperren in der ersten Zeile und den Namen des
Datenbank in der vierten Zeile.

Logdatei
("symlink: check_postgres_logfile") Stellt sicher, dass sich die Logdatei am erwarteten Ort befindet
und wird angemeldet. Diese Aktion gibt einen Befehl aus, der bei jedem einen Fehler auslöst
Datenbank, die es überprüft, und stellt sicher, dass die Nachricht in den Protokollen angezeigt wird. Es scannt die
verschiedene log_*-Einstellungen innerhalb von Postgres, um herauszufinden, wo die Protokolle sein sollten. wenn du
Syslog verwenden, führt es einen groben (aber nicht narrensicheren) Scan durch /etc/syslog.conf.
Alternativ können Sie den Namen des Logfiles mit dem --Logdatei Möglichkeit. Das ist
besonders nützlich, wenn die Protokolle ein benutzerdefiniertes Rotationsschema haben, das von einem externen Programm gesteuert wird.
Die --Logdatei Option unterstützt die folgenden Escape-Zeichen: "%Y %m %d %H", was
stehen für das aktuelle Jahr, den Monat, das Datum und die Stunde. Ein Fehler ist immer
als kritisch gemeldet, es sei denn, die Warnungsoption wurde als Wert ungleich Null übergeben.
Abgesehen von dieser spezifischen Verwendung sollten die Optionen "--warning" und "--critical" nicht be
benutzt.

Beispiel 1: Stellen Sie auf Port 5432 sicher, dass die Protokolldatei in die Datei geschrieben wird
/home/greg/pg8.2.log

check_postgres_logfile --port=5432 --logfile=/home/greg/pg8.2.log

Beispiel 2: Wie oben, aber eine Warnung ausgeben, keine kritische

check_postgres_logfile --port=5432 --logfile=/home/greg/pg8.2.log -w 1

Gibt für die MRTG-Ausgabe eine 1 oder 0 in der ersten Zeile zurück, die Erfolg oder Misserfolg anzeigt. In
Im Falle eines Fehlers enthält die vierte Zeile weitere Details zum aufgetretenen Fehler.

neue_version_bc
("symlink: check_postgres_new_version_bc") Prüft, ob eine neuere Version des Bucardo
Programm vorhanden ist. Die aktuelle Version erhält man durch Ausführen von "bucardo_ctl --version".
Wenn ein größeres Upgrade verfügbar ist, wird eine Warnung zurückgegeben. Wenn ein Revisions-Upgrade
verfügbar, wird ein kritischer Wert zurückgegeben. (Bucardo ist ein Meister des Sklaven und Meister des Meisters
Replikationssystem für Postgres: siehe http://bucardo.org für mehr Informationen). Siehe auch
die Informationen zur Option "--get_method".

neue_version_box
("symlink: check_postgres_new_version_box") Prüft, ob eine neuere Version der Boxinfo
Programm vorhanden ist. Die aktuelle Version erhält man durch Ausführen von "boxinfo.pl --version".
Wenn ein größeres Upgrade verfügbar ist, wird eine Warnung zurückgegeben. Wenn ein Revisions-Upgrade
verfügbar, wird ein kritischer Wert zurückgegeben. (boxinfo ist ein Programm zum Erfassen wichtiger
Informationen von einem Server und bringen sie in ein HTML-Format: siehe
http://bucardo.org/wiki/boxinfo für mehr Informationen). Siehe auch die Informationen zum
"--get_method"-Option.

neue_version_cp
("symlink: check_postgres_new_version_cp") Prüft, ob eine neuere Version dieses Programms
(check_postgres) ist verfügbar, indem Sie die Version aus einer kleinen Textdatei im Hauptverzeichnis holen
Seite der Homepage des Projekts. Gibt eine Warnung zurück, wenn die zurückgegebene Version dies nicht tut
mit dem übereinstimmen, den Sie ausführen. Das empfohlene Intervall für die Überprüfung ist einmal täglich. Siehe auch die
Informationen zur Option "--get_method".

neue_version_pg
("symlink: check_postgres_new_version_pg") Prüft, ob eine neuere Revision von Postgres existiert
für jede verbundene Datenbank. Beachten Sie, dass dies nur auf Revision prüft, z. B. ausgehend von
8.3.6 bis 8.3.7. Revisionen sind immer 100% Binärkompatibel und beinhalten keinen Dump und
wiederherstellen, um zu aktualisieren. Überarbeitungen werden vorgenommen, um Fehler zu beheben, also aktualisieren Sie so schnell wie möglich
wird immer empfohlen. Gibt eine Warnung zurück, wenn Sie nicht über die neueste Version verfügen. es ist
Empfohlen wird diese Prüfung mindestens einmal täglich. Siehe auch die Informationen zum
"--get_method"-Option.

neue_version_tnm
("symlink: check_postgres_new_version_tnm") Prüft, ob eine neuere Version der tail_n_mail
Programm vorhanden ist. Die aktuelle Version erhält man durch Ausführen von "tail_n_mail --version".
Wenn ein größeres Upgrade verfügbar ist, wird eine Warnung zurückgegeben. Wenn ein Revisions-Upgrade
verfügbar, wird ein kritischer Wert zurückgegeben. (tail_n_mail ist ein Protokollüberwachungstool, das senden kann
E-Mail, wenn interessante Ereignisse in Ihren Postgres-Protokollen erscheinen. Sehen:
http://bucardo.org/wiki/Tail_n_mail für mehr Informationen). Siehe auch die Informationen zu
die Option "--get_method".

pgb_pool_cl_active
pgb_pool_cl_waiting
pgb_pool_sv_active
pgb_pool_sv_idle
pgb_pool_sv_used
pgb_pool_sv_tested
pgb_pool_sv_login
pgb_pool_maxwait
(symlinks: "check_postgres_pgb_pool_cl_active", "check_postgres_pgb_pool_cl_waiting",
"check_postgres_pgb_pool_sv_active", "check_postgres_pgb_pool_sv_idle",
"check_postgres_pgb_pool_sv_used", "check_postgres_pgb_pool_sv_tested",
"check_postgres_pgb_pool_sv_login" und "check_postgres_pgb_pool_maxwait")

Untersucht die Poolstatistiken von pgbouncer. Jeder Pool hat eine Reihe von "Client"-Verbindungen,
Verweise auf Verbindungen von externen Clients und "Server"-Verbindungen, bezogen auf
Verbindungen zu PostgreSQL selbst. Den zugehörigen check_postgres-Aktionen wird "cl_" vorangestellt.
bzw. "sv_". Aktive Clientverbindungen sind die Verbindungen, die derzeit verknüpft sind
mit aktiver Serververbindung. Clientverbindungen können auch "warten", was bedeutet, dass sie
noch keine Serververbindung zugewiesen wurde. Serververbindungen sind "aktiv" (verknüpft
an einen Client), "idle" (bereit für eine Client-Verbindung zum Verknüpfen), "used" (nur
von einem Client getrennt und noch nicht in den Leerlaufpool zurückgekehrt), "getestet" (derzeit
getestet) und "Login" (beim Login). Der maxwait-Wert zeigt an, wie lange in
Sekunden hat die älteste wartende Client-Verbindung gewartet.

pgbouncer_backends
("symlink: check_postgres_pgbouncer_backends") Prüft die aktuelle Anzahl der Verbindungen
für eine oder mehrere Datenbanken über pgbouncer und vergleicht sie optional mit dem Maximum
erlaubt, was durch die Konfigurationsvariable pgbouncer bestimmt wird max_client_conndem „Vermischten Geschmack“. Seine
--Warnung und --kritisch Optionen können eine von drei Formen annehmen. Zuerst kann eine einfache Zahl
angegeben werden, die die Anzahl der Verbindungen darstellt, bei denen die Warnung ausgegeben wird.
Diese Auswahl verwendet nicht die max_connections Einstellung. Zweitens, der Prozentsatz der verfügbaren
Verbindungen gegeben werden können. Drittens kann eine negative Zahl angegeben werden, die die
Anzahl der Verbindungen übrig bis max_connections ist erreicht. Die Standardwerte für
--Warnung und --kritisch sind '90%' und '95%'. Sie können die Datenbanken auch filtern nach
--enthalten und --ausschließen Optionen. Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG".

Um nur Prozesse anzuzeigen, die nicht im Leerlauf sind, können Sie die --Nudel Streit. Beachten Sie, dass der Benutzer, den Sie
verbinden, da Sie ein Superuser sein müssen, damit dies ordnungsgemäß funktioniert.

Beispiel 1: Geben Sie eine Warnung aus, wenn die Anzahl der Verbindungen auf Host quirm 120 erreicht, und a
kritisch, wenn sie 150 erreicht.

check_postgres_pgbouncer_backends --host=quirm --warning=120 --kritische=150 -p 6432 -u pgbouncer

Beispiel 2: Geben Sie einen kritischen Wert an, wenn wir 75% unserer max_connections-Einstellung auf Hosts erreichen
Lancre oder Lancre2.

check_postgres_pgbouncer_backends --warning='75%' --kritische='75%' --host=lancre,lancre2 -p 6432 -u pgbouncer

Beispiel 3: Geben Sie eine Warnung aus, wenn nur noch 10 Verbindungsslots auf dem Host übrig sind
Plasmid, und ein kritisches, wenn wir nur noch 5 übrig haben.

check_postgres_pgbouncer_backends --warning=-10 --critical=-5 --host=plasmid -p 6432 -u pgbouncer

Für die MRTG-Ausgabe wird die Anzahl der Verbindungen in der ersten Zeile und in der vierten angezeigt
line gibt den Namen der Datenbank plus die aktuelle max_client_conn an. Wenn mehr als einer
Datenbank abgefragt wurde, wird diejenige mit den meisten Verbindungen ausgegeben.

pgbouncer_checksum
("symlink: check_postgres_pgbouncer_checksum") Überprüft, ob alle pgBouncer-Einstellungen
das gleiche wie bei der letzten Überprüfung. Dies geschieht durch Generieren einer Prüfsumme einer sortierten Liste
der Einstellungsnamen und deren Werte. Beachten Sie, dass Sie den Datenbanknamen nicht angeben sollten, es
wird automatisch pgbouncer verwendet. Entweder --Warnung oder unter der --kritisch zu erhalten
sollte gegeben werden, aber nicht beides. Der Wert jedes einzelnen ist die Prüfsumme, ein 32-stelliges
Hexadezimalwert. Sie können mit der speziellen Option "--critical=0" ausführen, um herauszufinden,
vorhandene Prüfsumme.

Diese Aktion erfordert das Modul Digest::MD5.

Beispiel 1: Ermitteln Sie die anfängliche Prüfsumme für die pgbouncer-Konfiguration auf Port 6432 mithilfe des
Standardbenutzer (normalerweise postgres)

check_postgres_pgbouncer_checksum --port=6432 --kritisch=0

Beispiel 2: Stellen Sie sicher, dass sich keine Einstellungen geändert haben und warnen Sie in diesem Fall mit der Prüfsumme von
zu teilen.

check_postgres_pgbouncer_checksum --port=6432 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Gibt für die MRTG-Ausgabe eine 1 oder 0 zurück, die anzeigt, dass die Prüfsumme erfolgreich war oder nicht übereinstimmt.
Als Argument "--mrtg" muss eine Prüfsumme angegeben werden. Die vierte Zeile gibt immer das
aktuelle Prüfsumme.

pgagent_jobs
("symlink: check_postgres_pgagent_jobs") Überprüft, ob alle pgAgent-Jobs mit
im vorangegangenen Zeitintervall ausgeführt wurden, erfolgreich waren. Dies geschieht, indem Sie nach suchen
alle Schritte, die ein Ergebnis ungleich Null haben.

Als Zeiten können entweder "--warning" oder "--critical" oder beides angegeben werden, und die Jobs werden
auf Fehler innerhalb der angegebenen Zeiträume vor der aktuellen Uhrzeit überprüft. Gültig
Einheiten sind Sekunden, Minuten, Stunden und Tage; alle können auf den ersten Buchstaben abgekürzt werden.
Wenn keine Einheiten angegeben sind, werden 'Sekunden' angenommen.

Beispiel 1: Geben Sie einen kritischen Wert an, wenn alle am letzten Tag ausgeführten Jobs fehlgeschlagen sind.

check_postgres_pgagent_jobs --kritisch=1d

Beispiel 2: Geben Sie eine Warnung aus, wenn in der letzten Woche ausgeführte Jobs fehlgeschlagen sind.

check_postgres_pgagent_jobs --warning=7d

Beispiel 3: Geben Sie einen kritischen Wert für Jobs, die in den letzten 2 Stunden fehlgeschlagen sind, und eine Warnung für
Jobs, die in den letzten 4 Stunden fehlgeschlagen sind:

check_postgres_pgagent_jobs --critical=2h --warning=4h

vorbereitet_txns
("symlink: check_postgres_prepared_txns") Überprüfen Sie das Alter von vorhandenen vorbereiteten
Transaktionen. Beachten Sie, dass die meisten Leute KEINE vorbereiteten Transaktionen verwenden werden, da sie Teil sind
von zweiteiligem Commit und kompliziert zu pflegen. Sie sollten auch nicht verwechselt werden mit
vorbereitete STATEMENTS, an die die meisten Leute denken, wenn sie "vorbereiten" hören. Die
Der Standardwert für eine Warnung ist 1 Sekunde, um jede Verwendung vorbereiteter Transaktionen zu erkennen, die
ist wahrscheinlich ein Fehler auf den meisten Systemen. Warnung und kritisch sind die Anzahl der Sekunden a
Die vorbereitete Transaktion war geöffnet, bevor eine Warnung ausgegeben wird.

Beispiel 1: Geben Sie eine Warnung aus, wenn Sie vorbereitete Transaktionen erkennen:

check_postgres_prepared_txns -w 0

Beispiel 2: Geben Sie einen kritischen Wert an, wenn eine vorbereitete Transaktion länger als 10 . geöffnet ist
Sekunden, aber erlauben Sie bis zu 360 Sekunden für die Datenbank 'shrike':

check_postgres_prepared_txns --critical=10 --exclude=shrike
check_postgres_prepared_txns --critical=360 --include=shrike

Gibt für die MRTG-Ausgabe die Anzahl der Sekunden zurück, die die älteste Transaktion geöffnet war, als
erste Zeile und aus welcher Datenbank die letzte Zeile stammt.

query_runtime
("symlink: check_postgres_query_runtime") Prüft, wie lange die Ausführung einer bestimmten Abfrage dauert,
indem Sie ein "EXPLAIN ANALYZE" dagegen ausführen. Die --Warnung und --kritisch Optionen sind die
die maximale Zeit, die die Abfrage in Anspruch nehmen sollte. Gültige Einheiten sind Sekunden, Minuten und Stunden;
any kann auf den ersten Buchstaben abgekürzt werden. Wenn keine Einheiten angegeben sind, werden 'Sekunden' angenommen.
Sowohl die Warnung als auch die kritische Option müssen angegeben werden. Der Name der Ansicht oder Funktion
ausgeführt werden muss an die --Abfragename Möglichkeit. Es muss aus einem einzigen Wort bestehen
(oder schema.word), mit optionalen Klammern am Ende.

Beispiel 1: Geben Sie einen kritischen Wert an, wenn die Funktion namens "speedtest" in 10 Sekunden nicht ausgeführt wird oder
Weniger.

check_postgres_query_runtime --queryname='speedtest()' --critical=10 --warning=10

Gibt für die MRTG-Ausgabe in der ersten Zeile die Zeit in Sekunden an, die die Abfrage bis zum Abschluss benötigt.
Die vierte Zeile listet die Datenbank auf.

Abfragezeit
("symlink: check_postgres_query_time") Prüft die Länge der laufenden Abfragen auf eine oder mehrere
Datenbanken. Dies muss nicht mehr als einmal auf demselben Datenbankcluster ausgeführt werden. Notiz
dass dies bereits Abfragen ausschließt, die "in Transaktion im Leerlauf" sind. Datenbanken können sein
gefiltert mit dem --enthalten und --ausschließen Optionen. Siehe Abschnitt "GRUNDLEGENDE FILTERUNG"
für mehr Details. Sie können auch nach dem Benutzer filtern, der die Abfrage ausführt --includeuser
und --excludeuser Optionen. Weitere Informationen finden Sie im Abschnitt "FILTERUNG DES BENUTZERNAMENS".

Die Werte für die --Warnung und --kritisch Optionen sind Zeitangaben und standardmäßig auf '2
Minuten“ bzw. „5 Minuten“. Gültige Einheiten sind "Sekunden", "Minuten", "Stunden" oder
'Tage'. Jeder kann einzeln geschrieben oder auf den ersten Buchstaben abgekürzt werden. Wenn keine Einheiten
gegeben sind, wird als Einheit Sekunden angenommen.

Diese Aktion erfordert Postgres 8.1 oder höher.

Beispiel 1: Geben Sie eine Warnung aus, wenn eine Abfrage länger als 3 Minuten ausgeführt wird, und a
kritisch, wenn länger als 5 Minuten.

check_postgres_query_time --port=5432 --warning='3 Minuten' --kritische='5 Minuten'

Beispiel 2: Unter Verwendung von Standardwerten (2 und 5 Minuten) alle Datenbanken außer diesen überprüfen
beginnend mit 'Vorlage'.

check_postgres_query_time --port=5432 --exclude=~^Vorlage

Beispiel 3: Warnen, wenn Benutzer 'don' eine Abfrage hat, die länger als 20 Sekunden läuft

check_postgres_query_time --port=5432 --includeuser=don --warning=20s

Gibt für die MRTG-Ausgabe die Länge der am längsten laufenden Abfrage in Sekunden zurück
Leitung. Die vierte Zeile gibt den Namen der Datenbank an.

replikate_row
("symlink: check_postgres_replicate_row") Überprüft, ob die Master-Slave-Replikation funktioniert
an einen oder mehrere Sklaven.

Die ersten Optionen "--dbname", "--host" und "--port" usw. werden als Master betrachtet;
nachfolgende Verwendungen sind die Sklaven. Die Werte oder die --Warnung und --kritisch Optionen sind
Zeiteinheiten, und mindestens eine muss angegeben werden (keine Voreinstellungen). Gültige Einheiten sind 'Sekunden',
„Minuten“, „Stunden“ oder „Tage“. Jeder kann einzeln geschrieben oder auf nur die abgekürzt werden
erster Brief. Wenn keine Einheiten angegeben sind, werden die Einheiten als Sekunden angenommen.

Diese Prüfung aktualisiert eine einzelne Zeile auf dem Master und misst dann, wie lange es dauert
auf die Sklaven angewendet. Dazu müssen Sie eine Tabelle auswählen, die repliziert wird, dann
Finden Sie eine Zeile, die geändert werden kann und von keinem anderen Prozess geändert wird. EIN
Eine bestimmte Spalte dieser Zeile wird von einem Wert in einen anderen geändert. All das wird gefüttert
zur Option "repinfo" und sollte die folgenden durch Kommas getrennten Optionen enthalten:
Tabellenname, Primärschlüssel, Schlüssel-ID, Spalte, erster Wert, zweiter Wert.

Beispiel 1: Slony repliziert eine Tabelle namens 'orders' vom Host 'alpha' zum Host 'beta'.
in der Datenbank 'Vertrieb'. Der Primärschlüssel der Tabelle heißt id, und wir werden
Testen Sie die Zeile mit einer ID von 3 (die historisch ist und nie geändert wurde). Es gibt eine Spalte
namens 'salesrep', dass wir von einem Wert von 'slon' auf 'nols' umschalten werden, um dies zu überprüfen
die Nachbildung. Wir möchten eine Warnung ausgeben, wenn die Replikation nicht innerhalb von 10 . erfolgt
Sekunden.

check_postgres_replicate_row --host=alpha --dbname=sales --host=beta
--dbname=sales --warning=10 --repinfo=orders,id,3,salesrep,slon,nols

Beispiel 2: Bucardo repliziert eine Tabelle namens 'receipt' von Host 'green' auf hosts
'rot', 'blau' und 'gelb'. Die Datenbank für beide Seiten ist 'öffentlich'. Die Sklavendatenbanken
laufen auf Port 5455. Der Primärschlüssel heißt 'receipt_id', die Zeile, die wir verwenden möchten
hat den Wert 9, und die Spalte, die wir für den Test ändern möchten, heißt 'zone'. Brunnen
Wechseln Sie zwischen 'Nord' und 'Süd' für den Wert dieser Spalte und werfen Sie ein kritisches if
die Änderung erfolgt nicht auf allen drei Slaves innerhalb von 5 Sekunden.

check_postgres_replicate_row --host=green --port=5455 --host=red,blue,yellow
--critical=5 --repinfo=Receipt,Receipt_id,9,Zone,Nord,Süd

Gibt für die MRTG-Ausgabe in der ersten Zeile die Zeit in Sekunden zurück, die die Replikation benötigt
beenden. Die maximale Zeit ist auf 4 Minuten 30 Sekunden eingestellt: wenn keine Replikation durchgeführt wurde
In dieser langen Zeit wird ein Fehler geworfen.

gleiches_schema
("symlink: check_postgres_same_schema") Überprüft, ob zwei oder mehr Datenbanken identisch sind
soweit ihr Schema (aber nicht die Daten darin). Dies ist besonders praktisch für die Herstellung
Stellen Sie sicher, dass Ihre Slaves in keiner Weise modifiziert oder beschädigt wurden, wenn Sie Master-to-Slave verwenden
Reproduzieren. Im Gegensatz zu den meisten anderen Aktionen hat dies keine Warn- oder kritischen Kriterien - die
Datenbanken sind entweder synchron oder nicht. Wenn sie unterschiedlich sind, eine detaillierte Liste der
Unterschiede präsentiert.

Möglicherweise möchten Sie bestimmte Unterschiede ausschließen oder herausfiltern. Der Weg, dies zu tun, ist hinzuzufügen
Zeichenfolgen an die Option "--filter". Um einen Objekttyp auszuschließen, verwenden Sie "noname", wobei "name"
ist der Objekttyp, zum Beispiel "noschema". Ausschließen von Objekten eines bestimmten Typs durch a
regulären Ausdruck gegen ihren Namen verwenden, verwenden Sie "noname=regex". Siehe die Beispiele unten für a
besseres Verstehen.

Folgende Objekttypen können gefiltert werden:

Benutzer
Schema
Tabelle
view
Index
Reihenfolge
Einschränkung
auslösen
Funktion

Die Filteroption "noposition" verhindert die Überprüfung der Position von Spalten innerhalb von a
Tabelle.

Die Filteroption "nofuncbody" verhindert den Vergleich der Körper aller Funktionen.

Die Filteroption "noperm" verhindert den Vergleich von Objektberechtigungen.

Um die zweite Datenbank bereitzustellen, hängen Sie einfach die Differenzen an die erste durch einen Aufruf an . an
das entsprechende Verbindungsargument. Zum Beispiel, um Datenbanken auf Hosts alpha und . zu vergleichen
bravo, verwenden Sie "--dbhost=alpha,bravo". Siehe auch die Beispiele unten.

Wenn nur ein einzelner Host angegeben wird, wird davon ausgegangen, dass wir einen "zeitbasierten" Bericht erstellen. Die
Beim ersten Ausführen wird ein Snapshot aller Elemente in der Datenbank in einem lokalen gespeichert
Datei. Wenn Sie es erneut ausführen, wird dieser Snapshot eingelesen und wird zu "Datenbank #2" und ist
im Vergleich zur aktuellen Datenbank.

Um die alte gespeicherte Datei durch die neue Version zu ersetzen, verwenden Sie das Argument --replace.

Um Snapshots zu verschiedenen Zeitpunkten zu aktivieren, können Sie das Argument "--suffix" verwenden, um zu erstellen
die für jeden Lauf eindeutigen Dateinamen. Siehe die Beispiele unten.

Beispiel 1: Überprüfen Sie, ob zwei Datenbanken auf den Hosts star und line identisch sind:

check_postgres_same_schema --dbhost=star,line

Beispiel 2: Wie zuvor, aber alle Trigger mit "slony" im Namen ausschließen

check_postgres_same_schema --dbhost=star,line --filter="notrigger=slony"

Beispiel 3: Wie zuvor, aber zusätzlich alle Indizes ausschließen

check_postgres_same_schema --dbhost=star,line --filter="notrigger=slony noindexes"

Beispiel 4: Unterschiede für die Datenbank "battlestar" auf verschiedenen Ports prüfen

check_postgres_same_schema --dbname=battlestar --dbport=5432,5544

Beispiel 5: Erstellen Sie eine tägliche und wöchentliche Snapshot-Datei

check_postgres_same_schema --dbname=cylon --suffix=daily
check_postgres_same_schema --dbname=cylon --suffix=wöchentlich

Beispiel 6: Führen Sie einen historischen Vergleich durch und ersetzen Sie dann die Datei

check_postgres_same_schema --dbname=cylon --suffix=daily --replace

Reihenfolge
("symlink: check_postgres_sequence") Prüft, wie viel Platz auf allen Sequenzen im
Datenbank. Dies wird als Prozentsatz der gesamten möglichen Werte gemessen, die verwendet wurden
für jede Folge. Die --Warnung und --kritisch Optionen sollten ausgedrückt werden als
Prozentsätze. Die Standardwerte sind 85% für die Warnung und 95% für die kritischen. Du darfst
Verwenden Sie --include und --exclude, um zu steuern, welche Sequenzen überprüft werden sollen. Beachten Sie, dass dies
Scheck berücksichtigt ungewöhnliche Mindestwert und Zuwachs by Werte, aber es ist egal, ob die
Sequenz ist auf Zyklus eingestellt oder nicht.

Die Ausgabe für Nagios gibt den Namen der Sequenz, den verwendeten Prozentsatz und die Nummer an
von 'Aufrufen' übrig, die angeben, wie oft nextval in dieser Sequenz noch aufgerufen werden kann
bevor der Maximalwert erreicht wird.

Die Ausgabe für MRTG gibt den höchsten Prozentsatz über alle Sequenzen in der ersten Zeile zurück,
und der Name jeder Sequenz mit diesem Prozentsatz in der vierten Zeile, getrennt durch ein "|"
(Pipe), wenn bei diesem Prozentsatz mehr als eine Sequenz vorhanden ist.

Beispiel 1: Geben Sie eine Warnung aus, wenn eine Sequenz fast 95 % voll ist.

check_postgres_sequence --dbport=5432 --warning=95%

Beispiel 2: Prüfen Sie, ob die Sequenz namens "orders_id_seq" nicht mehr als halb voll ist.

check_postgres_sequence --dbport=5432 --kritisch=50% --include=orders_id_seq

Settings_Checksum
("symlink: check_postgres_settings_checksum") Überprüft, ob alle Postgres-Einstellungen
das gleiche wie bei der letzten Überprüfung. Dies geschieht durch Generieren einer Prüfsumme einer sortierten Liste
der Einstellungsnamen und deren Werte. Beachten Sie, dass verschiedene Benutzer in derselben Datenbank möglicherweise
unterschiedliche Prüfsummen, aufgrund der ALTER USER-Nutzung und aufgrund der Tatsache, dass Superuser mehr sehen
Einstellungen als normale Benutzer. Entweder --Warnung oder unter der --kritisch Option sollte sein
gegeben, aber nicht beides. Der Wert jedes einzelnen ist die Prüfsumme, eine 32-stellige Hexadezimalzahl
Wert. Sie können mit der speziellen Option "--critical=0" ausführen, um einen vorhandenen
Prüfsumme.

Diese Aktion erfordert das Modul Digest::MD5.

Beispiel 1: Ermitteln Sie die anfängliche Prüfsumme für die Datenbank auf Port 5555 mit dem Standardbenutzer
(normalerweise postgres)

check_postgres_settings_checksum --port=5555 --kritisch=0

Beispiel 2: Stellen Sie sicher, dass sich keine Einstellungen geändert haben und warnen Sie in diesem Fall mit der Prüfsumme von
zu teilen.

check_postgres_settings_checksum --port=5555 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Gibt für die MRTG-Ausgabe eine 1 oder 0 zurück, die anzeigt, dass die Prüfsumme erfolgreich war oder nicht übereinstimmt.
Als Argument "--mrtg" muss eine Prüfsumme angegeben werden. Die vierte Zeile gibt immer das
aktuelle Prüfsumme.

slony_status
("symlink: check_postgres_slony_status") Prüft den Status eines Slony-Clusters von
Betrachten Sie die Ergebnisse der sl_status-Ansicht von Slony. Dies wird als Anzahl von zurückgegeben
Sekunden "Verzögerungszeit". Die --Warnung und --kritisch Optionen sollten als Zeiten ausgedrückt werden.
Die Standardwerte sind 60 Sekunden für die Warnung und 300 Sekunden für die kritischen.

Das optionale Argument --Schema hat das Schema angegeben, unter dem Slony installiert ist. Wenn es
nicht angegeben ist, wird das Schema bei jeder Ausführung dieser Prüfung automatisch ermittelt.

Beispiel 1: Geben Sie eine Warnung, wenn ein Slony um mehr als 20 Sekunden verzögert ist

check_postgres_slony_status --Warnung 20

Beispiel 2: Geben Sie einen kritischen Wert an, wenn Slony, installiert unter dem Schema "_slony", über 10 . ist
Minuten verzögert

check_postgres_slony_status --schema=_slony --kritische=600

Zeitsynchronisation
("symlink: check_postgres_timesync") Vergleicht die lokale Systemzeit mit der gemeldeten Zeit
durch eine oder mehrere Datenbanken. Die --Warnung und --kritisch Optionen stehen für die Anzahl der
Sekunden zwischen den beiden Systemen, bevor eine Warnung ausgegeben wird. Wenn keines angegeben ist, wird die
Es werden Standardwerte verwendet, die '2' und '5' sind. Der Warnwert kann nicht größer sein als
der kritische Wert. Aufgrund der nicht genauen Natur dieses Tests sind Werte von '0' oder '1' nicht
empfohlen.

Der zurückgegebene String zeigt den Zeitunterschied sowie die Zeit auf jeder geschriebenen Seite an
out.

Beispiel 1: Überprüfen Sie, ob die Datenbanken auf den Hosts ankh, morpork und klatch nicht größer als 3 . sind
Sekunden von der Ortszeit entfernt:

check_postgres_timesync --host=ankh,morpork,klatch --kritische=3

Gibt für die MRTG-Ausgabe in der ersten Zeile die Anzahl der Sekundendifferenz zwischen den
Ortszeit und Datenbankzeit. Die vierte Zeile gibt den Namen der Datenbank zurück.

txn_idle
("symlink: check_postgres_txn_idle") Prüft die Anzahl und Dauer von "idle in
Transaktion"-Abfragen für eine oder mehrere Datenbanken. Sie müssen dies nicht mehr als einmal ausführen
auf demselben Datenbankcluster. Datenbanken können gefiltert werden, indem Sie die --enthalten und
--ausschließen Optionen. Weitere Informationen finden Sie im Abschnitt "GRUNDLEGENDE FILTERUNG" weiter unten.

Die --Warnung und --kritisch Optionen werden als Zeiteinheiten, ganze Zahlen mit Vorzeichen oder . angegeben
Ganzzahlen für Zeiteinheiten, und beide müssen angegeben werden (es gibt keine Standardwerte). Gültige Einheiten
sind „Sekunden“, „Minuten“, „Stunden“ oder „Tage“. Jeder kann einzeln oder abgekürzt geschrieben werden
nur auf den ersten Buchstaben. Wenn keine Einheiten angegeben sind und die Zahlen vorzeichenlos sind, werden die Einheiten
werden als Sekunden angenommen.

Diese Aktion erfordert Postgres 8.3 oder höher.

Beispiel 1: Geben Sie eine Warnung aus, wenn eine Verbindung während der Transaktion länger als 15 . im Leerlauf war
Sekunden:

check_postgres_txn_idle --port=5432 --warning='15 Sekunden'

Beispiel 2: Geben Sie eine Warnung aus, wenn es 50 oder mehr Transaktionen gibt

check_postgres_txn_idle --port=5432 --warning='+50'

Beispiel 3: Geben Sie einen kritischen Wert an, wenn 5 oder mehr Verbindungen länger in der Transaktion im Leerlauf waren
als 10 Sekunden:

check_postgres_txn_idle --port=5432 --critical='5 für 10 Sekunden'

Gibt für die MRTG-Ausgabe die Zeit in Sekunden zurück, die die längste Transaktion im Leerlauf war
Laufen. Die vierte Zeile gibt den Namen der Datenbank und weitere Informationen über die
längste Transaktion.

txn_time
("symlink: check_postgres_txn_time") Prüft die Länge offener Transaktionen auf einer oder mehreren
Datenbanken. Dieser Befehl muss nicht mehr als einmal pro Datenbankcluster ausgeführt werden.
Datenbanken können mithilfe der --enthalten und --ausschließen Optionen. Siehe "BASIC"
FILTERING" für weitere Details. Der Eigentümer der Transaktion kann auch gefiltert werden, nach
Verwendung der --includeuser und --excludeuser Optionen. Siehe Abschnitt "FILTERUNG DES BENUTZERNAMENS"
für weitere Informationen an.

Die Werte oder die --Warnung und --kritisch Optionen sind Zeiteinheiten und müssen angegeben werden
(kein Standard). Gültige Einheiten sind "Sekunden", "Minuten", "Stunden" oder "Tage". Jeder kann sein
Singular geschrieben oder auf den ersten Buchstaben abgekürzt. Wenn keine Einheiten angegeben sind,
Einheiten werden als Sekunden angenommen.

Diese Aktion erfordert Postgres 8.3 oder höher.

Beispiel 1: Geben Sie einen kritischen Wert an, wenn eine Transaktion länger als 10 Minuten geöffnet ist:

check_postgres_txn_time --port=5432 --kritische='10 Minuten'

Beispiel 1: Warnen, wenn der Benutzer 'Warehouse' eine Transaktion länger als 30 Sekunden geöffnet hat

check_postgres_txn_time --port-5432 --warning=30s --includeuser=warehouse

Gibt für die MRTG-Ausgabe die maximale Zeit in Sekunden zurück, die eine Transaktion am . geöffnet war
erste Linie. Die vierte Zeile gibt den Namen der Datenbank an.

txn_wraparound
("symlink: check_postgres_txn_wraparound") Prüft, wie nah am Transaktions-Wraparound ist
oder mehr Datenbanken bekommen. Die --Warnung und --kritisch Optionen geben die Zahl an
der durchgeführten Transaktionen und muss eine positive ganze Zahl sein. Wenn keine der Optionen angegeben ist, wird die
Standardwerte von 1.3 und 1.4 Milliarden werden verwendet. Dieser Befehl muss nicht mehr ausgeführt werden
als einmal pro Datenbankcluster. Für eine detailliertere Diskussion darüber, was diese Zahl
repräsentiert und was Sie dagegen tun können, besuchen Sie bitte die Seite
<http://www.postgresql.org/docs/current/static/routine-vacuuming.html#VAKUUM-FÜR-UMWICKELN>

Die Warning- und Critical-Werte können aus Gründen der Lesbarkeit unterstrichen in der Zahl sein, da Perl
tut.

Beispiel 1: Überprüfen Sie die Standardwerte für die localhost-Datenbank

check_postgres_txn_wraparound --host=localhost

Beispiel 2: Überprüfen Sie Port 6000 und geben Sie einen kritischen Wert, wenn 1.7 Milliarden Transaktionen getroffen werden:

check_postgres_txn_wraparound --port=6000 --critical=1_700_000_000

Gibt für die MRTG-Ausgabe die höchste Anzahl von Transaktionen für alle Datenbanken in Zeile eins zurück.
während Zeile 4 angibt, um welche Datenbank es sich handelt.

Version
("symlink: check_postgres_version") Überprüft, ob die erforderliche Version von Postgres
Laufen. Das --Warnung und --kritisch Optionen (nur eine ist erforderlich) müssen das Format . haben
XY or XYZ woher X ist die Hauptversionsnummer, Y ist die Nebenversionsnummer und Z is
Die Revision.

Beispiel 1: Geben Sie eine Warnung aus, wenn die Datenbank auf Port 5678 nicht Version 8.4.10 ist:

check_postgres_version --port=5678 -w=8.4.10

Beispiel 2: Geben Sie eine Warnung aus, wenn eine Datenbank für Hosts Valley, Grain oder Sunshine nicht 8.3 ist:

check_postgres_version -H-Tal,Korn,Sonnenschein --kritische=8.3

Meldet für MRTG-Ausgabe eine 1 oder eine 0, die Erfolg oder Misserfolg in der ersten Zeile anzeigt. Die
vierte Zeile zeigt die aktuelle Version an. Die Version muss über das "--mrtg" bereitgestellt werden
.

wal_files
("symlink: check_postgres_wal_files") Prüft, wie viele WAL-Dateien im pg_xlog
Verzeichnis, das von Ihrem gefunden wird Datenverzeichnis, manchmal als symbolischer Link zu einem anderen
physischen Datenträger aus Leistungsgründen. Diese Aktion muss als Superuser ausgeführt werden, um
Zugriff auf den Inhalt der pg_xlog Verzeichnis. Die Mindestversion für diese Aktion ist
Postgres 8.1. Die --Warnung und --kritisch Optionen sind einfach die Anzahl der Dateien im
pg_xlog Verzeichnis. Auf welche Zahl dies eingestellt werden soll, ist unterschiedlich, aber eine allgemeine Richtlinie ist die Angabe von
eine etwas höhere Zahl als normalerweise vorhanden, um Probleme frühzeitig zu erkennen.

Normalerweise werden WAL-Dateien geschlossen und dann wiederverwendet, aber eine lang laufende offene Transaktion oder ein
fehlerhaft archive_command Skript, kann dazu führen, dass Postgres zu viele Dateien erstellt. Letzten Endes,
Dies führt dazu, dass die Festplatte, auf der sie sich befinden, nicht mehr genügend Speicherplatz hat, woraufhin Postgres
Herunterfahren.

Beispiel 1: Überprüfen Sie, ob die Anzahl der WAL-Dateien auf dem Host "pluto" 20 oder weniger beträgt

check_postgres_wal_files --host=pluto --kritische=20

Meldet für die MRTG-Ausgabe die Anzahl der WAL-Dateien in Zeile 1.

rebuild_symlinks
rebuild_symlinks_force
Diese Aktion erfordert keine weiteren Argumente und stellt keine Verbindung zu Datenbanken her, sondern einfach
erstellt im aktuellen Verzeichnis für jede Aktion symbolische Links in der Form
check_postgres_. Wenn die Datei bereits existiert, wird sie nicht überschrieben. Wenn
die Aktion ist rebuild_symlinks_force, dann werden symbolische Links überschrieben. Die Option
--symlinks ist eine kürzere Form für --action=rebuild_symlinks

BASIC FILTERUNG

Die Optionen --enthalten und --ausschließen kann kombiniert werden, um einzuschränken, welche Dinge überprüft werden,
je nach Aktion. Der Name der Datenbank kann gefiltert werden, wenn Sie folgendes verwenden
Aktionen: Backends, Datenbankgröße, Sperren, query_time, txn_idle und txn_time. Der Name von
eine Relation kann mit folgenden Aktionen gefiltert werden: bloat, index_size,
table_size, relation_size, last_vacuum, last_autovacuum, last_analyze und
last_autoanalyze. Der Name einer Einstellung kann bei Verwendung der settings_checksum gefiltert werden
Handlung. Der Name eines Dateisystems kann mit der Aktion disk_space gefiltert werden.

Wenn nur eine Include-Option angegeben ist, werden NUR die übereinstimmenden Einträge geprüft.
Wenn jedoch sowohl "ausschließen" als auch "einschließen" angegeben ist, wird der Ausschluss zuerst durchgeführt, und der Einschluss
danach, um Dinge wiederherzustellen, die möglicherweise ausgeschlossen wurden. Beide --enthalten und --ausschließen können.
mehrfach und/oder als durch Kommas getrennte Listen angegeben werden. Eine führende Tilde entspricht der
folgendes Wort als regulärer Ausdruck.

Um ein Schema abzugleichen, beenden Sie den Suchbegriff mit einem einzelnen Punkt. Führende Tilden können verwendet werden
auch für Schemata.

Seien Sie beim Filtern vorsichtig: Eine Einschlussregel in den Back-Ends kann beispielsweise
keine Probleme melden, nicht nur weil die passende Datenbank keine Backends hatte, sondern weil Sie
den Namen der Datenbank falsch geschrieben!

Beispiele:

Überprüft nur Elemente mit dem Namen pg_class:

--include=pg_class

Prüft nur Elemente, die die Buchstaben 'pg_' enthalten:

--include=~pg_

Überprüfen Sie nur Elemente, die mit 'pg_' beginnen:

--include=~^pg_

Schließen Sie das Element namens 'test' aus:

--exclude=testen

Schließen Sie alle Elemente aus, die die Buchstaben 'test:

--exclude=~test

Alle Elemente im Schema 'pg_catalog' ausschließen:

--exclude='pg_catalog.'

Schließen Sie alle Elemente aus, die die Buchstaben "Ass" enthalten, aber lassen Sie das Element "Faceoff" zu:

--exclude=~ace --include=faceoff

Alle Elemente ausschließen, die mit den Buchstaben 'pg_' beginnen, die die Buchstaben 'slon' enthalten, oder
die 'sql_settings' oder 'green' heißen. Überprüfen Sie die Elemente speziell mit den Buchstaben
'prod' in ihren Namen und überprüfen Sie immer das Element namens 'pg_relname':

--exclude=~^pg_,~slon,sql_settings --exclude=green --include=~prod,pg_relname

USER NAME/FUNKTION FILTERUNG

Die Optionen --includeuser und --excludeuser kann bei einigen Aktionen verwendet werden, um nur zu untersuchen
Datenbankobjekte, die einem oder mehreren Benutzern gehören (oder nicht gehören). Ein --includeuser zu erhalten
trumpft immer auf --excludeuser Möglichkeit. Sie können jede Option mehrmals für
mehrere Benutzer, oder Sie können eine durch Kommas getrennte Liste angeben. Die Aktionen, die derzeit verwendet werden
diese Optionen sind:

Datenbankgröße
letzte_analyse
last_autoanalyze
letztes_vakuum
last_autovacuum
Abfragezeit
relation_size
txn_time

Beispiele:

Überprüfen Sie nur Elemente, die dem Benutzer namens greg gehören:

--includeuser=greg

Überprüfen Sie nur Gegenstände, die entweder Watson oder Crick gehören:

--includeuser=watson,crick

Überprüfen Sie nur Gegenstände, die im Besitz von Crick, Franklin, Watson oder Wilkins sind:

--includeuser=watson --includeuser=franklin --includeuser=crick,wilkins

Überprüfen Sie alle Elemente mit Ausnahme derjenigen, die dem Benutzer Scott gehören:

--excludeuser=scott

TESTEN MODUS

Um die Einrichtung zu erleichtern, kann dieses Programm in einem "Testmodus" ausgeführt werden, indem die
--Prüfung Möglichkeit. Dadurch werden einige grundlegende Tests durchgeführt, um sicherzustellen, dass die Datenbanken
kontaktiert werden und dass bestimmte aktionsbezogene Voraussetzungen erfüllt sind, z. B. ob der Benutzer
ein Superuser, wenn die Version von Postgres neu genug ist und wenn stats_row_level aktiviert ist.

Verwenden Sie check_postgres_pgb_pool_sv_activep online über die Dienste von onworks.net