check_postgres_database_sizep - En ligne dans le Cloud

PROGRAMME:

Nom

check_postgres - un script de surveillance Postgres pour Nagios, MRTG, Cacti et autres

Ce document décrit check_postgres version 2.22.0

SYNOPSIS

## Créer tous les liens symboliques
check_postgres --liens symboliques

## Vérifiez la connexion à la base de données Postgres 'pluto' :
check_postgres --action=connexion --db=pluto

## Mêmes choses, mais en utilisant le lien symbolique
check_postgres_connection --db=pluton

## Avertir si > 100 verrous, critique si > 200, ou > 20 exclusif
check_postgres_locks --warning=100 --critical="total=200:exclusive=20"

## Affiche le nombre actuel de connexions inactives sur le port 6543 :
check_postgres_txn_idle --port=6543 --output=simple

## Il existe de nombreuses autres actions et options, continuez à lire.

Les dernières nouvelles et la documentation peuvent toujours être trouvées sur:
http://bucardo.org/check_postgres/

DESCRIPTION

check_postgres est un script Perl qui exécute de nombreux tests différents sur un ou plusieurs
Bases de données Postgres. Il utilise le programme psql pour collecter les informations et affiche le
résultats dans l'un des trois formats suivants : Nagios, MRTG ou simple.

Sortie Modes
La sortie peut être modifiée à l'aide de l'option "--output". La sortie par défaut est nagios,
bien que cela puisse être modifié en haut du script si vous le souhaitez. L'option actuelle
les choix sont nagios, monsieuret simple. Pour éviter d'avoir à saisir l'argument de sortie chaque
time, le type de sortie est défini automatiquement si aucun argument --output n'est donné, et si le
le répertoire courant a l'une des options de sortie dans son nom. Par exemple, créer un
répertoire nommé mrtg et en le remplissant de liens symboliques via le --liens symboliques l'argument serait
assurez-vous que toutes les actions exécutées à partir de ce répertoire seront toujours par défaut une sortie de "mrtg"
Comme raccourci pour --output=simple, vous pouvez entrer --simple, qui remplace également le
astuce de nommage de répertoire.

Nagios sortie

Le format de sortie par défaut est pour Nagios, qui est une seule ligne d'informations, avec
quatre codes de sortie spécifiques :

0 (d'accord)
1 (AVERTISSEMENT)
2 (CRITIQUE)
3 (INCONNU)

La ligne de sortie est l'un des mots ci-dessus, un deux-points, puis une brève description de ce que
a été mesuré. Informations statistiques supplémentaires, ainsi que la durée totale de la commande
pris, peut également être affiché : voir la documentation sur les arguments --showperf,
--perflimiteet --afficher l'heure.

MRTG sortie

La sortie MRTG est de quatre lignes, la première ligne donnant toujours un seul nombre de
importance. Lorsque cela est possible, ce nombre représente une valeur réelle telle qu'un nombre de
octets, mais il peut aussi s'agir d'un 1 ou d'un 0 pour les actions qui ne renvoient que « vrai » ou « faux », comme
comme check_postgres_version. La deuxième ligne est une statistique supplémentaire et n'est utilisée que pour
certaines actions. La troisième ligne indique un « uptime » et n'est pas utilisée. La quatrième ligne est un
description et indique généralement le nom de la base de données la stat de la première ligne
a été extrait, mais peut être différent selon l'action.

Certaines actions acceptent une option --mrtg argument pour contrôler davantage la sortie.

Voir la documentation sur chaque action pour plus de détails sur la sortie MRTG exacte pour chacune.

étapes sortie

La sortie simple est simplement une version tronquée de celle de MRTG et renvoie simplement le
premier numéro et rien d'autre. Ceci est très utile lorsque vous voulez juste vérifier l'état
de quelque chose, quel que soit le seuil. Vous pouvez transformer la sortie numérique en
en ajoutant Ko, Mo, Go, To ou EB à l'argument de sortie, par exemple :

--output=simple,Mo

Cacti sortie

La sortie Cacti se compose d'un ou plusieurs éléments sur la même ligne, avec un nom simple, un
deux-points, puis un nombre. Pour le moment, la seule action avec une sortie Cacti explicite est
'dbstats', et l'utilisation de l'option --output n'est pas nécessaire dans ce cas, car Cacti est le seul
sortie pour cette action. Pour de nombreuses autres actions, l'utilisation de --simple suffit à faire de Cacti
heureux.

BASE DE DONNÉES CONNEXION OPTIONS

Toutes les actions acceptent un ensemble commun d'options de base de données.

-H Nom or --host=NOM
Connectez-vous à l'hôte indiqué par NAME. Peut être une liste de noms séparés par des virgules.
Plusieurs arguments d'hôte sont autorisés. Si aucun hôte n'est donné, par défaut le "PGHOST"
variable d'environnement ou pas d'hôte du tout (ce qui indique l'utilisation d'un socket Unix local).
Vous pouvez également utiliser "--dbhost".

-p PORT or --port=PORT
Se connecte à l'aide du numéro de PORT spécifié. Peut être une liste de ports séparés par des virgules
nombres et plusieurs arguments de port sont autorisés. Si aucun numéro de port n'est indiqué, les valeurs par défaut
à la variable d'environnement "PGPORT". Si ce n'est pas défini, la valeur par défaut est 5432. Vous pouvez
utilisez également "--dbport"

-Db Nom or --dbname=NOM
Spécifie à quelle base de données se connecter. Peut être une liste de noms séparés par des virgules, et
plusieurs arguments de nom de base de données sont autorisés. Si aucune option dbname n'est fournie, la valeur par défaut est
la variable d'environnement "PGDATABASE". Si ce n'est pas défini, la valeur par défaut est « postgres »
si psql est la version 8 ou supérieure, et 'template1' sinon.

-u USERNAME or --dbuser=NOM D'UTILISATEUR
Nom de l'utilisateur de la base de données sous lequel se connecter. Peut être une liste séparée par des virgules de
les noms d'utilisateur et plusieurs arguments dbuser sont autorisés. Si cela n'est pas fourni, il
la valeur par défaut est la variable d'environnement "PGUSER", sinon la valeur par défaut est "postgres".

--dbpass=MOT DE PASSE
Fournit le mot de passe pour se connecter à la base de données. L'utilisation de cette option est fortement
découragé. Au lieu de cela, il faut utiliser un fichier .pgpass ou pg_service.conf.

--dbservice=NOM
Le nom d'un service dans le fichier pg_service.conf. Avant la version 9.0 de
Postgres, c'est un fichier global, généralement trouvé dans /etc/pg_service.conf. Si vous êtes
en utilisant la version 9.0 ou supérieure de Postgres, vous pouvez utiliser le fichier ".pg_service.conf" dans
le répertoire personnel de l'utilisateur exécutant le script, par exemple nagios.

Ce fichier contient une simple liste d'options de connexion. Vous pouvez également passer d'autres
informations lors de l'utilisation de cette option telles que --dbservice="maindatabase sslmode=require"

La documentation de ce fichier est disponible sur
http://www.postgresql.org/docs/current/static/libpq-pgservice.html

Les options de connexion à la base de données peuvent être regroupées : --hôte=a,b --hôte=c --port=1234
--port=3344 se connecterait à a-1234, b-1234 et c-3344. Notez qu'une fois définie, une option
se poursuit jusqu'à ce qu'il soit à nouveau modifié.

Exemples :

--host=a,b --port=5433 --db=c
Se connecte deux fois au port 5433, en utilisant la base de données c, aux hôtes a et b : a-5433-c b-5433-c

--host=a,b --port=5433 --db=c,d
Se connecte quatre fois : a-5433-c a-5433-d b-5433-c b-5433-d

--host=a,b --host=foo --port=1234 --port=5433 --db=e,f
Se connecte six fois : 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
Se connecte trois fois : a-5432-alice-baz b-5433-alice-baz x-5433-bob-baz

--dbservice="foo" --port=5433
Se connecte en utilisant le service nommé 'foo' dans le fichier pg_service.conf, mais remplace le port

AUTRES OPTIONS

D'autres options incluent:

--action=NOM
Indique quelle action nous menons. Obligatoire sauf si vous utilisez un fichier avec un lien symbolique, dans lequel
cas, le nom du fichier est utilisé pour déterminer l'action.

--avertissement=VAL or -w VAL
Définit le seuil auquel une alerte d'avertissement est déclenchée. Les options valides pour cela
L'option dépend de l'action utilisée.

--critique=VAL or -c VAL
Définit le seuil auquel une alerte critique est déclenchée. Les options valides pour cela
L'option dépend de l'action utilisée.

-t VAL or --timeout=VAL
Définit le délai d'attente en secondes après lequel le script abandonnera tout ce qu'il fait et
renvoie un statut INCONNU. Le délai d'attente est par cluster Postgres, pas pour l'ensemble
scénario. La valeur par défaut est 10 ; les unités sont toujours en secondes.

--assume-mode-veille
Si spécifié, d'abord la vérification si le serveur en mode veille sera effectuée (--datadir
est obligatoire), si c'est le cas, toutes les vérifications qui nécessitent des requêtes SQL seront ignorées et "Server
en mode veille" avec l'état OK sera renvoyé à la place.

Mise en situation :

postgres@db$./check_postgres --action=version --warning=8.1 --datadir /var/lib/postgresql/8.3/main/ --assume-standby-mode
POSTGRES_VERSION OK : Serveur en mode veille | temps=0.00

--assume-prod
Si spécifié, vérifiez si le serveur en mode production est exécuté (--datadir est requis).
L'option n'est pertinente que pour ("symlink: check_postgres_checkpoint").

Mise en situation :

postgres@db$./check_postgres --action=checkpoint --datadir /var/lib/postgresql/8.3/main/ --assume-prod
POSTGRES_CHECKPOINT OK : Le dernier point de contrôle était il y a 72 secondes | age=72;;300 mode=MASTER

-h or --Aidez-moi
Affiche un écran d'aide avec un résumé de toutes les actions et options.

--homme
Affiche l'intégralité du manuel.

-V or --version
Affiche la version actuelle.

-v or --verbeux
Réglez le niveau de verbosité. Peut appeler plus d'une fois pour augmenter le niveau. Le régler sur
trois ou plus (en d'autres termes, émettre "-v -v -v") active les informations de débogage
pour ce programme qui est envoyé à stderr.

--showperf=VAL
Détermine si nous sortons des données de performances supplémentaires au format Nagios standard (à la fin
de chaîne, après un symbole pipe, en utilisant name=value). VAL doit être 0 ou 1. La valeur par défaut
est 1. Ne prend effet que si vous utilisez le mode de sortie Nagios.

--perflimit=je
Définit une limite quant au nombre d'éléments d'intérêt signalés lors de l'utilisation du
spectacle option. Cela n'a d'effet que pour les actions qui renvoient un grand nombre de
articles, tels que taille_table. La valeur par défaut est 0, ou aucune limite. Soyez prudent lorsque vous utilisez ce
les --comprendre or --exclure options, car ces restrictions sont faites après le
requête a été exécutée, et donc votre limite peut ne pas inclure les éléments que vous voulez. ne prend que
effet si vous utilisez le mode de sortie Nagios.

--showtime=VAL
Détermine si le temps nécessaire à l'exécution de chaque requête est affiché dans la sortie. VAL doit être égal à 0
ou 1. La valeur par défaut est 1. Aucun effet sauf si spectacle est sur. Ne prend effet que si vous utilisez
Mode de sortie Nagios.

--test
Active le mode test. Voir la section "MODE TEST" ci-dessous.

--PGBINDIR=CHEMIN
Indique au script où trouver les binaires psql. Utile si vous en avez plusieurs
version des exécutables PostgreSQL sur votre système, ou s'il n'y en a pas dans votre
chemin. Notez que cette option est en majuscules. Par défaut, cette option est ne sauraient
permis. Pour l'activer, vous devez modifier $NO_PSQL_OPTION en haut du script
à 0. Évitez d'utiliser cette option si vous le pouvez et utilisez plutôt la variable d'environnement
c ou une variable $PGBINDIR codée en dur, également près du haut du script, pour définir
le chemin d'accès à PostgreSQL à utiliser.

--PSQL=CHEMIN
(obsolète, this option Au cours de cette réunion, Matthew a obtenu de précieux conseils et Linda lui a demandé de la tenir au courant de ses progrès. be enlevé in a avenir Libération!) Indique au script où
pour trouver le programme psql. Utile si vous avez plusieurs versions de psql
exécutable sur votre système, ou s'il n'y a pas de programme psql dans votre chemin. Notez que ce
option est en majuscules. Par défaut, cette option est ne sauraient permis. Pour l'activer, vous
doit changer le $NO_PSQL_OPTION près du haut du script à 0. Évitez d'utiliser ceci
option si vous le pouvez, et à la place coder en dur votre emplacement psql dans la variable $PSQL,
également près du haut du script.

--liens symboliques
Crée des liens symboliques vers le programme principal pour chaque action.

--sortie=VAL
Détermine le format de la sortie, à utiliser dans divers programmes. La valeur par défaut est
« nagios ». Les options disponibles sont 'nagios', 'mrtg', 'simple' et 'cacti'.

--mrtg=VAL
Utilisé uniquement pour le MRTG ou la sortie simple, pour quelques actions spécifiques.

--debugoutput=VAL
Affiche la chaîne exacte renvoyée par psql, à utiliser dans le débogage. La valeur est un ou
plus de lettres, qui déterminent si la sortie est affichée ou non, où 'a' = all, 'c'
= critique, 'w' = avertissement, 'o' = ok et 'u' = inconnu. Les lettres peuvent être combinées.

--get_method=VAL
Permet de spécifier la méthode utilisée pour récupérer les informations pour le "new_version_cp",
"new_version_pg", "new_version_bc", "new_version_box" et "new_version_tnm".
Les programmes suivants sont essayés, dans l'ordre, pour récupérer les informations sur le Web : GET,
wget, chercher, curl, lynx, liens. Pour forcer l'utilisation d'un seul (et donc supprimer le
d'essayer tous les autres jusqu'à ce que l'un de ces travaux fonctionne), entrez l'un des noms comme
l'argument de get_method. Par exemple, une boîte BSD peut entrer la ligne suivante dans
leur fichier ".check_postgresrc":

get_method=récupérer

--langue=VAL
Définissez la langue à utiliser pour tous les messages de sortie. Normalement, cela est détecté par
examiner les variables d'environnement LC_ALL, LC_MESSAGES et LANG, mais définir ceci
L'option remplacera toute détection de ce type.

ACTIONS

Le script exécute une ou plusieurs actions. Cela peut être fait avec le drapeau --action, ou par
en utilisant un lien symbolique vers le fichier principal qui contient le nom de l'action à l'intérieur. Pour
exemple, pour exécuter l'action "timesync", vous pouvez soit lancer :

check_postgres --action=timesync

ou utilisez un programme nommé :

check_postgres_timesync

Tous les liens symboliques sont créés pour vous dans le répertoire courant si vous utilisez l'option --symlinks

perl check_postgres --liens symboliques

Si le nom de fichier existe déjà, il ne sera pas écrasé. Si le fichier existe et est un
lien symbolique, vous pouvez le forcer à écraser en utilisant "--action=build_symlinks_force"

La plupart des actions prennent un --Attention et --critique option, indiquant à quel moment on change
de OK à AVERTISSEMENT, et à quel point on passe à CRITIQUE. Notez que parce que les critiques sont
toujours vérifié en premier, le réglage de l'avertissement égal à l'état critique est un moyen efficace de
désactiver les avertissements et toujours donner une critique.

Les actions actuellement prises en charge sont :

archive_prêt
("symlink: check_postgres_archive_ready") Vérifie combien de fichiers WAL avec l'extension .prêt
exister dans le pg_xlog/archive_status répertoire, qui se trouve dans votre répertoire_données.
Cette action doit être exécutée en tant que superutilisateur, afin d'accéder au contenu du
pg_xlog/archive_status annuaire. La version minimale pour utiliser cette action est Postgres 8.1.
La --Attention ainsi que --critique les options sont simplement le nombre de .prêt fichiers dans le
pg_xlog/archive_status annuaire. Généralement, ces valeurs doivent être faibles, en activant le
mécanisme d'archivage, nous souhaitons généralement qu'il archive les fichiers WAL le plus rapidement possible.

Si la commande d'archivage échoue, le nombre de WAL dans votre pg_xlog répertoire va croître jusqu'à ce que
épuiser tout l'espace disque et forcer PostgreSQL à s'arrêter immédiatement.

Exemple 1 : vérifiez que le nombre de fichiers WAL prêts est de 10 ou moins sur l'hôte "pluto"

check_postgres_archive_ready --host=pluton --critical=10

Pour la sortie MRTG, indique le nombre de fichiers WAL prêts à la ligne 1.

autovac_freeze
("lien symbolique : check_postgres_autovac_freeze") Vérifie à quel point chaque base de données est proche du
Postgres autovacuum_freeze_max_age réglage. Cette action ne fonctionnera que pour les bases de données
version 8.2 ou supérieure. Les --Attention ainsi que --critique les options doivent être exprimées sous la forme
pourcentages. L'« âge » des transactions dans chaque base de données est comparé au
paramètre autovacuum_freeze_max_age (200 millions par défaut) pour générer un arrondi
pourcentage. Les valeurs par défaut sont 90% pour l'avertissement et 95% pour les critiques. Bases de données
peut être filtré en utilisant le --comprendre ainsi que --exclure option. Voir le "FILTRE DE BASE"
section pour plus de détails.

Exemple 1 : donner un avertissement lorsque des bases de données sur le port 5432 sont supérieures à 97 %

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

Pour la sortie MRTG, le pourcentage global le plus élevé est indiqué sur la première ligne, et le
l'âge le plus élevé est indiqué sur la deuxième ligne. Toutes les bases de données qui ont le pourcentage de
la première ligne est signalée sur la quatrième ligne, séparée par un symbole de tuyau.

backends
("symlink: check_postgres_backends") Vérifie le nombre actuel de connexions pour un ou
plusieurs bases de données et le compare éventuellement au maximum autorisé, qui est déterminé par
la variable de configuration Postgres max_connectionsL’ --Attention ainsi que --critique Options
peut prendre l'une des trois formes. Tout d'abord, un nombre simple peut être donné, qui représente le
nombre de connexions auxquelles l'alerte sera donnée. Ce choix n'utilise pas le
max_connections réglage. Deuxièmement, le pourcentage de connexions disponibles peut être donné.
Troisièmement, un nombre négatif peut être donné qui représente le nombre de connexions restantes
jusqu'à max_connections est atteint. Les valeurs par défaut pour --Attention ainsi que --critique
« 90 % » et « 95 % ». Vous pouvez également filtrer les bases de données en utilisant le --comprendre ainsi que --exclure
option. Voir la section « FILTRAGE DE BASE » pour plus de détails.

Pour afficher uniquement les processus non inactifs, vous pouvez utiliser le --noïde argument. Notez que l'utilisateur que vous
se connectent en tant que superutilisateur pour que cela fonctionne correctement.

Exemple 1 : donner un avertissement lorsque le nombre de connexions sur l'hôte quirm atteint 120, et un
critique s'il atteint 150.

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

Exemple 2 : Donner un avis critique lorsque nous atteignons 75 % de notre paramètre max_connections sur les hôtes
lancre ou lancre2.

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

Exemple 3 : donner un avertissement lorsqu'il ne reste que 10 emplacements de connexion supplémentaires sur l'hôte
plasmide, et un critique quand il ne nous en reste que 5.

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

Exemple 4 : Vérifiez toutes les bases de données à l'exception de celles avec "test" dans leur nom, mais autorisez celles qui
sont nommés "pg_greatest". Connectez-vous en tant que port 5432 sur les deux premiers hôtes et en tant que port 5433 sur
le troisième. Nous voulons toujours lancer une critique lorsque nous atteignons 30 connexions ou plus.

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

Pour la sortie MRTG, le nombre de connexions est indiqué sur la première ligne et la quatrième
La ligne donne le nom de la base de données, ainsi que le maximum_connections actuel. Si plus de
une base de données a été interrogée, celle avec le plus grand nombre de connexions est sortie.

gonfler
("lien symbolique : check_postgres_bloat") Vérifie la quantité de gonflement dans les tables et les index. (Gonfler
est généralement la quantité d'espace mort inutilisé occupé dans une table ou un index. Cet espace est
généralement récupéré à l'aide de la commande VACUUM.) Cette action nécessite que les statistiques
la collecte doit être activée sur les bases de données cibles et nécessite l'exécution d'ANALYZE
souvent. Les --comprendre ainsi que --exclure les options peuvent être utilisées pour filtrer les tables à
Regarder. Voir la section « FILTRAGE DE BASE » pour plus de détails.

La --Attention ainsi que --critique les options peuvent être spécifiées en tant que tailles, pourcentages ou les deux. Valide
les unités de taille sont les octets, les kilo-octets, les mégaoctets, les gigaoctets, les téraoctets, les exaoctets, les pétaoctets et
zettaoctets. Vous pouvez abréger tous ceux avec la première lettre. Les articles sans unités sont
supposé être des « octets ». Les valeurs par défaut sont « 1 Go » et « 5 Go ». La valeur représente le
nombre d'"octets perdus", ou la différence entre ce qui est réellement utilisé par la table et
index, et ce que nous calculons qu'il devrait être.

Notez que cette action a deux valeurs codées en dur pour éviter les fausses alarmes sur les plus petits
rapports. Les tableaux doivent avoir au moins 10 pages et les index au moins 15, avant de pouvoir être
considéré par ce test. Si vous voulez vraiment ajuster ces valeurs, vous pouvez rechercher le
les variables $MINPAGES ainsi que $MINIPAGES en haut de la sous-routine "check_bloat". Ces
les valeurs sont ignorées si soit --exclure or --comprendre est utilisé.

Seules les 10 relations les plus gonflées sont affichées. Vous pouvez modifier ce numéro en utilisant le
--perflimite option pour définir votre propre limite.

Le schéma nommé 'information_schema' est exclu de ce test, car les seules tables qu'il
contient sont petits et ne changent pas.

Veuillez noter que les valeurs calculées par cette action ne sont pas précises et doivent être utilisées comme
une ligne directrice seulement. Un grand effort a été fait pour estimer la taille correcte d'une table, mais dans
au final ce n'est qu'une estimation. La taille correcte de l'index est encore plus une supposition que la
taille de table correcte, mais les deux devraient donner une idée approximative de la taille des choses.

Exemple 1 : Avertir si une table sur le port 5432 est surchargée de plus de 100 Mo et critique si elle dépasse 200 Mo
MB

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

Exemple 2 : donner une critique si la table 'orders' sur l'hôte 'sami' a plus de 10 Mo de ballonnement

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

Exemple 3 : Donnez une note critique si la table « q4 » sur la base de données « ventes » est gonflée à plus de 50 %

check_postgres_bloat --db=ventes --include=q4 --critical='50%'

Exemple 4 : Donnez une note critique à n'importe quelle table qui est gonflée à plus de 20 % ainsi que a plus de 150 Mo de ballonnement :

check_postgres_bloat --port=5432 --critical='20% et 150 M'

Exemple 5 : Donnez une note critique à n'importe quelle table qui est gonflée à plus de 40 % or a plus de 500 Mo de ballonnement :

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

Pour la sortie MRTG, la première ligne donne le plus grand nombre d'octets perdus pour les tables,
et la deuxième ligne donne le plus grand nombre d'octets perdus pour les index. Le quatrième
La ligne donne les informations sur le nom de la base de données, le nom de la table et le nom de l'index. Si tu veux
afficher le taux de ballonnement à la place (combien de fois la relation est-elle plus grande par rapport à la façon dont
grand il devrait être), il suffit de passer "--mrtg=ratio".

point de contrôle
("symlink: check_postgres_checkpoint") Détermine depuis combien de temps le dernier point de contrôle a
été exécuté. Celui-ci doit s'exécuter sur le même serveur que la base de données en cours de vérification (par exemple, le
-h flag ne fonctionnera pas). Cette vérification est censée s'exécuter sur un serveur de « veille à chaud » qui est
traitant activement les fichiers WAL expédiés, et est destiné à vérifier que votre veille chaude est
vraiment "chaud". Le répertoire de données doit être défini, soit par la variable d'environnement
"PGDATA", ou en passant l'argument "--datadir". Il renvoie le nombre de secondes écoulées depuis le
le dernier point de contrôle a été exécuté, comme déterminé en analysant l'appel à "pg_controldata". En raison de
ceci, l'exécutable pg_controldata doit être disponible dans le chemin courant. Alternativement,
vous pouvez spécifier "PGBINDIR" comme répertoire dans lequel il réside. Il est également possible d'utiliser
les options spéciales --assume-prod or --assume-mode-veille, si le mode trouvé n'est pas le
un attendu, un CRITIQUE est émis.

Au moins un argument d'avertissement ou critique doit être défini.

Cette action nécessite le module Date::Parse.

Pour MRTG ou une sortie simple, renvoie le nombre de secondes.

cluster_id
("symlink: check_postgres_cluster-id") Vérifie que l'identifiant du système de base de données fourni
par pg_controldata est le même que la dernière fois que vous avez vérifié. Cela doit fonctionner sur le même serveur
comme la base de données en cours de vérification (par exemple, l'indicateur -h ne fonctionnera pas). Soit le
--Attention au sein de l’ --critique l'option devrait être donnée, mais pas les deux. La valeur de chacun est
l'identifiant du cluster, une valeur entière. Vous pouvez exécuter avec le "--critical=0" spécial
option pour trouver un identifiant de cluster existant.

Exemple 1 : Trouver l'identifiant initial

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

Exemple 2 : Assurez-vous que le cluster est le même et avertissez si ce n'est pas le cas, en utilisant le résultat ci-dessus.

check_postgres_cluster_id --critical=5633695740047915135

Pour la sortie MRTG, renvoie un 1 ou 0 indiquant le succès de l'échec de l'identifiant à
rencontre. Un identifiant doit être fourni comme argument "--mrtg". La quatrième ligne toujours
donne l'identifiant courant.

taux d'engagement
("symlink: check_postgres_commitratio") Vérifie le taux de commit de toutes les bases de données et
se plaint quand ils sont trop bas. Il n'est pas nécessaire d'exécuter cette commande plus d'une fois par
grappe de bases de données. Les bases de données peuvent être filtrées avec le --comprendre ainsi que --exclure option. Voir
la section "FILTRER DE BASE" pour plus de détails. Ils peuvent également être filtrés par le propriétaire de
la base de données avec le --includeuser ainsi que --exclureutilisateur option. Voir le "NOM D'UTILISATEUR
FILTRAGE" pour plus de détails.

Les options d'avertissement et critique doivent être spécifiées sous forme de pourcentages. Il n'y a pas
valeurs par défaut pour cette action : l'avertissement et la critique doivent être spécifiés. La valeur d'avertissement
ne peut pas être supérieur à la valeur critique. La sortie renvoie toutes les bases de données triées par
commitratio, le plus petit en premier.

Exemple : Avertir si une base de données sur l'indicateur d'hôte est inférieure à 90 % en taux de commit et critique
si moins de 80%.

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

Pour la sortie MRTG, renvoie le pourcentage de la base de données avec le plus petit taux de commit sur
la première ligne et le nom de la base de données sur la quatrième ligne.

connexion
("symlink: check_postgres_connection") Se connecte simplement, émet un 'SELECT version()', et
feuilles. ne prend pas --Attention or --critique options.

Pour la sortie MRTG, sort simplement un 1 (bonne connexion) ou un 0 (mauvaise connexion) sur le premier
ligne.

requête_personnalisée
("lien symbolique : check_postgres_custom_query") Exécute une requête personnalisée de votre choix et analyse
les résultats. La requête elle-même est transmise via l'argument "query" et doit être
aussi simple que possible. Si possible, enveloppez-le dans une vue ou une fonction pour garder
choses plus faciles à gérer. La requête doit renvoyer une ou deux colonnes. Il faut que
l'une des colonnes soit nommée « résultat » et est l'élément qui sera vérifié par rapport à votre
valeurs d'avertissement et critiques. La deuxième colonne est pour les données de performance et n'importe quel nom
peut être utilisé : ce sera la « valeur » à l'intérieur de la section des données de performance.

Au moins un avertissement ou un argument critique doit être spécifié. Ce à quoi ils sont réglés dépend
sur le type de requête que vous exécutez. Il existe quatre types de custom_queries qui peuvent être
run, spécifié par l'argument "valtype". Si aucun n'est spécifié, cette action est par défaut
'entier'. Les quatre types sont :

entier: Effectue une simple comparaison d'entiers. La première colonne doit être un simple entier,
et les valeurs d'avertissement et critiques doivent être les mêmes.

un magnifique: L'avertissement et la critique sont des chaînes et ne sont déclenchés que si la valeur dans le
la première colonne correspond exactement. Ceci est sensible à la casse.

fiable: L'avertissement et le critique sont des temps, et peuvent avoir des unités de secondes, minutes,
heures ou jours. Chacun peut être écrit au singulier ou abrégé à la première lettre seulement. Si
aucune unité n'est donnée, les secondes sont supposées. La première colonne doit être un entier
représentant le nombre de secondes à vérifier.

taille: L'avertissement et le critique sont des tailles, et peuvent avoir des unités d'octets, kilo-octets,
mégaoctets, gigaoctets, téraoctets ou exaoctets. Chacun peut être abrégé à la première lettre.
Si aucune unité n'est donnée, les octets sont supposés. La première colonne doit être un entier
représentant le nombre d'octets à vérifier.

Normalement, une alerte est déclenchée si les valeurs renvoyées sont plus grand que ou égal à la
valeur critique ou d'avertissement. Cependant, une option de --sens inverse déclenchera l'alerte si le
la valeur renvoyée est baisser que ou égal à la valeur critique ou d'avertissement.

Exemple 1 : Avertir si une relation de plus de 100 pages s'appelle "rad", mettre le nombre de pages
dans la section des données de performance.

check_postgres_custom_query --valtype=string -w "rad" --query=
"SELECT relname AS résultat, relpages AS pages FROM pg_class WHERE relpages > 100"

Exemple 2 : Donnez une critique si la fonction « foobar » renvoie un nombre supérieur à 5 Mo :

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

Exemple 2 : Avertir si la fonction « snazzo » renvoie moins de 42 :

check_postgres_custom_query --critical=42 --query="SELECT snazzo() AS résultat" --reverse

Si vous proposez une custom_query utile, envisagez d'envoyer un correctif à ce programme pour
en faire une action standard que d'autres personnes peuvent utiliser.

Cette action ne prend pas encore en charge MRTG ou la sortie simple.

taille_base_de_données
("symlink: check_postgres_database_size") Vérifie la taille de toutes les bases de données et se plaint
quand ils sont trop gros. Il n'est pas nécessaire d'exécuter cette commande plus d'une fois par base de données
grappe. Les bases de données peuvent être filtrées avec le --comprendre ainsi que --exclure option. Voir le
section "FILTRER DE BASE" pour plus de détails. Ils peuvent également être filtrés par le propriétaire du
base de données avec le --includeuser ainsi que --exclureutilisateur option. Voir le "FILTRE DE NOM D'UTILISATEUR"
section pour plus de détails.

Les options d'avertissement et de critique peuvent être spécifiées en octets, kilo-octets, mégaoctets,
gigaoctets, téraoctets ou exaoctets. Chacun peut également être abrégé à la première lettre.
Si aucune unité n'est donnée, les unités sont supposées être des octets. Il n'y a pas de valeurs par défaut pour cela
action : l'avertissement et la critique doivent être spécifiés. La valeur d'avertissement ne peut pas être supérieure
que la valeur critique. La sortie renvoie d'abord toutes les bases de données triées par taille la plus grande,
montrant à la fois les octets bruts et une "jolie" version de la taille.

Exemple 1 : Avertir si une base de données sur l'indicateur d'hôte a une taille supérieure à 1 To, et critique si elle est supérieure
1.1 TB.

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

Exemple 2 : Donnez une valeur critique si le modèle de base de données 1 sur le port 5432 dépasse 10 Mo.

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

Exemple 3 : donner un avertissement si une base de données sur l'hôte « tardis » appartenant à l'utilisateur « tom » est terminée
5 GB

check_postgres_database_size --host=tardis --includeuser=tom --warning='5 Go' --critical='10 Go'

Pour la sortie MRTG, renvoie la taille en octets de la plus grande base de données sur la première ligne, et
le nom de la base de données sur la quatrième ligne.

statistiques de base de données
("symlink: check_postgres_dbstats") Rapporte les informations de la vue pg_stat_database,
et le produit d'une manière compatible avec les cactus. Aucune autre sortie n'est prise en charge, car la sortie est
informatif et ne se prête pas aux alertes, comme c'est le cas avec Nagios. Si aucune option
sont donnés, toutes les bases de données sont renvoyées, une par ligne. Vous pouvez inclure une base de données spécifique
en utilisant l'option "--include", ou vous pouvez utiliser l'option "--dbname".

Onze éléments sont renvoyés sur chaque ligne, au format nom:valeur, séparés par un seul
espacer. Les articles sont :

backends
Le nombre de backends en cours d'exécution pour cette base de données.

commits
Le nombre total de validations pour cette base de données depuis sa création ou sa réinitialisation.

annulations
Le nombre total de restaurations pour cette base de données depuis sa création ou sa réinitialisation.

lire
Le nombre total de blocs de disque lus.

hit Le nombre total d'accès au tampon.

ret Le nombre total de lignes renvoyées.

rapporter
Le nombre total de lignes extraites.

ins Le nombre total de lignes insérées.

upd Le nombre total de lignes mises à jour.

del Le nombre total de lignes supprimées.

dbname
Le nom de la base de données.

Notez que les éléments ret, fetch, ins, upd et del seront toujours à 0 si Postgres est la version 8.2
ou moins, car ces statistiques n'étaient pas disponibles dans ces versions.

Si l'argument dbname est fourni, sept éléments supplémentaires sont renvoyés :

idxscan
Nombre total d'analyses d'index utilisateur.

idxtupread
Nombre total d'entrées d'index utilisateur renvoyées.

idxtupfetch
Nombre total de lignes extraites par des analyses d'index utilisateur simples.

idxblksread
Nombre total de blocs de disque lus pour tous les index utilisateur.

idxblkshit
Nombre total d'accès au tampon pour tous les index utilisateur.

analyse séquentielle
Nombre total d'analyses séquentielles sur toutes les tables utilisateur.

lire séquentiellement
Nombre total de tuples renvoyés par toutes les tables utilisateur.

Exemple 1 : récupérez les statistiques d'une base de données nommée « produits » sur l'hôte « willow » :

check_postgres_dbstats --dbhost saule --dbname produits

La sortie renvoyée sera comme ceci (le tout sur une seule ligne, non enveloppé) :

backends : 82 commits : 58374408 rollbacks : 1651 lecture : 268435543 hit : 2920381758 idxscan : 310931294 idxtupread : 2777040927
idxtupfetch:1840241349 idxblksread:62860110 idxblkshit:1107812216 seqscan:5085305 seqtupread:5370500520
ret:0 récupérer:0 ins:0 upd:0 del:0 dbname:willow

disable_triggers
("lien symbolique : check_postgres_disabled_triggers") Vérifie le nombre de déclencheurs désactivés
à l'intérieur de la base de données. Les --Attention ainsi que --critique les options sont le nombre de ces déclencheurs
trouvé, et les deux par défaut à "1", comme dans l'utilisation normale avoir désactivé les déclencheurs est un dangereux
un événement. Si la base de données en cours de vérification est 8.3 ou supérieure, la vérification porte sur le nombre de
déclencheurs dont le statut est « désactivé » (par opposition à « toujours » ou « réplique »). Les
la sortie affichera le nom de la table et le nom du déclencheur pour chaque désactivé
déclencheur.

Exemple 1 : Assurez-vous qu'il n'y a pas de déclencheurs désactivés

check_postgres_disabled_triggers

Pour la sortie MRTG, renvoie le nombre de déclencheurs désactivés sur la première ligne.

espace disque
("symlink: check_postgres_disk_space") Vérifie l'espace disque physique disponible utilisé par
Postgres. Cette action nécessite que vous ayez l'exécutable "/bin/df" disponible pour signaler
sur les tailles de disque, et il doit également être exécuté en tant que superutilisateur, afin qu'il puisse examiner le
répertoire_données à l'intérieur de Postgres. Les --Attention ainsi que --critique les options sont données
en tailles ou en pourcentages ou les deux. Si vous utilisez des tailles, les types d'unités standard sont
autorisés : octets, kilooctets, gigaoctets, mégaoctets, gigaoctets, téraoctets ou exaoctets. Chaque
peut être abrégé à la première lettre seulement ; aucune unité n'indique des « octets ». Les
les valeurs par défaut sont « 90 % » et « 95 % ».

Cette commande vérifie les éléments suivants pour déterminer tous les différents disques physiques
utilisé par Postgres.

répertoire_données - Le disque sur lequel se trouve le répertoire de données principal.

enregistrer annuaire - Le disque sur lequel se trouvent les fichiers journaux.

WAL filet annuaire - Le disque sur lequel se trouvent les journaux d'écriture anticipée (par exemple, le lien symbolique pg_xlog)

espaces de table - Chaque tablespace qui se trouve sur un disque séparé.

La sortie montre la taille totale utilisée et disponible sur chaque disque, ainsi que le
pourcentage, classé du pourcentage le plus élevé au plus faible utilisé. Chaque élément ci-dessus correspond à un fichier
système : ceux-ci peuvent être inclus ou exclus. Voir la section "FILTRE DE BASE" pour plus
détails.

Exemple 1 : assurez-vous qu'aucun système de fichiers ne dépasse 90 % pour la base de données sur le port 5432.

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

Exemple 2 : vérifiez que tous les systèmes de fichiers commençant par /dev/sda sont inférieurs à 10 Go et
11 Go (avertissement et critique)

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

Exemple 4 : Assurez-vous qu'aucun système de fichiers n'est à la fois supérieur à 50 % ainsi que a plus de 15 Go

check_postgres_disk_space --critical='50% et 15 Go'

Exemple 5 : Émettre un avertissement si un système de fichiers est rempli à plus de 70 % or a plus de 1T

check_postgres_disk_space --warning='1T ou 75'

Pour la sortie MRTG, renvoie la taille en octets du système de fichiers sur la première ligne, et le
nom du système de fichiers sur la quatrième ligne.

pages_fsm
("lien symbolique : check_postgres_fsm_pages") Vérifie à quel point un cluster est proche de Postgres
max_fsm_pages réglage. Cette action ne fonctionnera que pour les bases de données de 8.2 ou supérieur, et il
nécessite le module contrib pg_freeespacemap être installé. Les --Attention ainsi que --critique
les options doivent être exprimées en pourcentages. Le nombre de pages utilisées dans le free-space-map
est déterminé en regardant dans la vue pg_freeespacemap_relations et en exécutant une formule
basé sur la formule utilisée pour la sortie des emplacements de pages de carte d'espace libre dans le vide verbeux
commander. Les valeurs par défaut sont 85% pour l'avertissement et 95% pour les critiques.

Exemple 1 : donner un avertissement lorsque notre cluster a utilisé 76 % des emplacements de pages d'espace libre,
avec pg_freeespacemap installé dans la base de données robert

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

Alors que vous devez passer le nom de la base de données où pg_freeespacemap est installé, vous
n'avez besoin d'exécuter cette vérification qu'une seule fois par cluster. De plus, la vérification de ces informations nécessite
obtenir des verrous spéciaux sur la carte de l'espace libre, il est donc recommandé de ne pas exécuter cette
vérifier avec de courts intervalles.

Pour la sortie MRTG, renvoie le pourcentage d'espace libre sur la première ligne et le nombre
de pages actuellement utilisées sur la deuxième ligne.

relations_fsm
("lien symbolique : check_postgres_fsm_relations") Vérifie à quel point un cluster est proche de Postgres
max_fsm_relations réglage. Cette action ne fonctionnera que pour les bases de données de 8.2 ou supérieur, et
il nécessite le module contrib pg_freeespacemap être installé. Les --Attention ainsi que --critique
les options doivent être exprimées en pourcentages. Le nombre de relations utilisées dans le libre-
space-map est déterminé en regardant dans la vue pg_freeespacemap_relations. Le défaut
les valeurs sont 85% pour l'avertissement et 95% pour les critiques.

Exemple 1 : donner un avertissement lorsque notre cluster a utilisé 80% des relations d'espace libre,
avec pg_freeespacemap installé dans la base de données dylan

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

Alors que vous devez passer le nom de la base de données où pg_freeespacemap est installé, vous
n'avez besoin d'exécuter cette vérification qu'une seule fois par cluster. De plus, la vérification de ces informations nécessite
obtenir des verrous spéciaux sur la carte de l'espace libre, il est donc recommandé de ne pas exécuter cette
vérifier avec de courts intervalles.

Pour la sortie MRTG, renvoie le pourcentage d'espace libre sur la première ligne, le nombre de
les relations actuellement utilisées sur la deuxième ligne.

taux de réussite
("symlink: check_postgres_hitratio") Vérifie le taux de réussite de toutes les bases de données et se plaint
quand ils sont trop bas. Il n'est pas nécessaire d'exécuter cette commande plus d'une fois par base de données
grappe. Les bases de données peuvent être filtrées avec le --comprendre ainsi que --exclure option. Voir le
section "FILTRER DE BASE" pour plus de détails. Ils peuvent également être filtrés par le propriétaire du
base de données avec le --includeuser ainsi que --exclureutilisateur option. Voir le "FILTRE DE NOM D'UTILISATEUR"
section pour plus de détails.

Les options d'avertissement et critique doivent être spécifiées sous forme de pourcentages. Il n'y a pas
valeurs par défaut pour cette action : l'avertissement et la critique doivent être spécifiés. La valeur d'avertissement
ne peut pas être supérieur à la valeur critique. La sortie renvoie toutes les bases de données triées par
hitratio, le plus petit en premier.

Exemple : Avertir si une base de données sur l'indicateur d'hôte a un taux d'accès inférieur à 90 %, et critique si
moins de 80%.

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

Pour la sortie MRTG, renvoie le pourcentage de la base de données avec le plus petit taux d'accès sur le
première ligne et le nom de la base de données sur la quatrième ligne.

hot_standby_delay
("symlink: check_hot_standby_delay") Vérifie le délai de réplication de streaming en calculant le
delta entre la position xlog actuelle d'un serveur maître et l'emplacement de relecture d'un
esclave qui y est connecté. Le serveur esclave doit être en mode hot_standby (par exemple en lecture seule),
par conséquent, la version minimale pour utiliser cette action est Postgres 9.0. Les --Attention ainsi que
--critique les options sont le delta entre les emplacements xlog. Étant donné que ces valeurs sont des octets
compensations dans le WAL, elles doivent correspondre au volume de transaction attendu de votre application
pour éviter les faux positifs ou négatifs.

Les premières options "--dbname", "--host" et "--port", etc. sont considérées comme le maître ; les
le second appartient à l'esclave.

Les valeurs d'octet doivent être basées sur le volume de transactions nécessaires pour que le streaming
la réplication se déconnecte du maître en raison d'un décalage trop important, déterminé par Postgres
variable de configuration wal_keep_segments. Pour les unités de temps, les unités valides sont les « secondes »,
« minutes », « heures » ou « jours ». Chacun peut être écrit au singulier ou abrégé en
première lettre. Lorsque vous spécifiez les deux, sous la forme 'octets ainsi que fiable', les deux conditions doivent être
vrai pour le seuil à atteindre.

Vous devez fournir des informations sur la façon d'accéder aux bases de données en fournissant une virgule séparée
list aux paramètres --dbhost et --dbport, tels que "--dbport=5432,5543". S'il n'est pas donné,
l'action échoue.

Exemple 1 : Avertir qu'une base de données avec une réplique locale sur le port 5433 est en retard sur n'importe quelle relecture xlog
du tout

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

Exemple 2 : Donnez une valeur critique si la dernière transaction que le réplica1 reçoit est supérieure à 10
il y a quelques minutes

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

Exemple 3 : Autoriser la réplique1 à avoir 1 segment WAL de retard, si le maître voit momentanément
plus d'activité que la connexion de réplication en streaming peut gérer, ou 10 minutes de retard,
si le maître voit très peu d'activité et ne traite aucune transaction, mais pas
les deux, ce qui indiquerait un problème durable avec la connexion de réplication.

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

index_taille
taille_table
relation_taille
(liens symboliques : "check_postgres_index_size", "check_postgres_table_size", et
"check_postgres_relation_size") Les actions taille_table ainsi que index_taille sont tout simplement
variations de la relation_taille action, qui vérifie une relation qui a trop grandi
gros. Les relations (c'est-à-dire les tables et les index) peuvent être filtrées avec le --comprendre
ainsi que --exclure option. Voir la section « FILTRAGE DE BASE » pour plus de détails. Les relations peuvent
également être filtrés par l'utilisateur qui les possède, en utilisant le --includeuser ainsi que --exclureutilisateur
option. Voir la section "FILTRER LE NOM D'UTILISATEUR" pour plus de détails.

Les valeurs pour le --Attention ainsi que --critique les options sont des tailles de fichier et peuvent avoir des unités de
octets, kilooctets, mégaoctets, gigaoctets, téraoctets ou exaoctets. Chacun peut être abrégé
à la première lettre. Si aucune unité n'est donnée, les octets sont supposés. Il n'y a pas de défaut
valeurs : à la fois l'avertissement et l'option critique doivent être donnés. Le texte de retour indique le
taille de la plus grande relation trouvée.

Si la --showperf l'option est activée, TOUTE des relations avec leurs tailles seront données.
Pour éviter cela, il est recommandé de régler le --perflimite option, ce qui entraînera
la requête pour faire un "ORDER BY size DESC LIMIT (perflimit)".

Exemple 1 : Donnez une valeur critique si une table est supérieure à 600 Mo sur l'hôte burrick.

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

Exemple 2 : Avertir si la taille des produits de la table dépasse 4 Go et donner une valeur critique à 4.5 Go.

check_postgres_table_size --host=burrick --warning='4 Go' --critical='4.5 Go' --include=products

Exemple 3 : Avertir si un index n'appartenant pas à postgres dépasse 500 Mo.

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

Pour la sortie MRTG, renvoie la taille en octets de la plus grande relation et le nom du
base de données et relation comme quatrième ligne.

dernière_analyse
dernier_vide
dernière_analyse automatique
dernier_autovacuum
(liens symboliques : "check_postgres_last_analyze", "check_postgres_last_vacuum",
"check_postgres_last_autoanalyze", et "check_postgres_last_autovacuum") Vérifie combien de temps
c'est depuis que le vide (ou l'analyse) a été exécuté pour la dernière fois sur chaque table dans une ou plusieurs bases de données.
L'utilisation de ces actions nécessite que la base de données cible soit la version 8.3 ou supérieure, ou que
la version est 8.2 et la variable de configuration stats_row_level a été activé. les tables
peut être filtré avec le --comprendre ainsi que --exclure option. Voir le "FILTRE DE BASE"
rubrique pour plus de détails. Les tables peuvent également être filtrées par leur propriétaire en utilisant le
--includeuser ainsi que --exclureutilisateur option. Voir la section "FILTRE DE NOM D'UTILISATEUR" pour plus d'informations
détails.

Les unités pour --Attention ainsi que --critique sont spécifiés en temps. Les unités valides sont les secondes,
minutes, heures et jours; tout peut être abrégé à la première lettre. Si aucune unité n'est
étant donné, les « secondes » sont supposées. Les valeurs par défaut sont '1 jour' et '2 jours'. Veuillez noter
qu'il existe des cas dans lesquels ce champ n'est pas automatiquement renseigné. Si certains
les tables vous posent des problèmes, assurez-vous qu'elles ont des lignes mortes à vider, ou tout simplement
les exclure du test.

Le schéma nommé 'information_schema' est exclu de ce test, car les seules tables qu'il
contient sont petits et ne changent pas.

Notez que les versions non « auto » vérifieront également les versions automatiques. En d'autre
mots, en utilisant last_vacuum rapportera sur le dernier vide, s'il s'agissait d'un vide normal,
ou un exécuté par le démon autovacuum.

Exemple 1 : Avertir si une table n'a pas été aspirée depuis 3 jours, et donner une critique à un
semaine, pour l'absinthe hôte

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

Exemple 2 : Identique à ci-dessus, mais ignore les tables appartenant aux utilisateurs 'eve' ou 'mallory'

check_postgres_last_vacuum --host=absinthe --warning='3d' --critical='7d' --excludeusers=eve,mallory

Pour la sortie MRTG, renvoie (sur la première ligne) le MOINS de temps en secondes depuis qu'un
table a été aspirée ou analysée pour la dernière fois. La quatrième ligne renvoie le nom de la base de données et
nom du tableau.

auditeur
("symlink: check_postgres_listener") Confirmez que quelqu'un écoute un ou plusieurs
des chaînes spécifiques (en utilisant le système LISTEN/NOTIFY), en consultant la table pg_listener.
Un seul avertissement ou critique est nécessaire. Le format est une simple chaîne représentant le
LISTEN cible, ou un caractère tilde suivi d'une chaîne pour une vérification d'expression régulière.
Notez que cette vérification ne fonctionnera pas sur les versions de Postgres 9.0 ou supérieures.

Exemple 1 : donner un avertissement si personne n'écoute la chaîne bucardo_mcp_ping sur les ports
5555 et 5556

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

Exemple 2 : donner une critique s'il n'y a pas de requêtes LISTEN actives correspondant à « grimm » sur
base de données oskar

check_postgres_listener --db oskar --critical=~grimm

Pour la sortie MRTG, renvoie un 1 ou un 0 sur le premier, indiquant le succès ou l'échec. Le nom
de l'avis doit être fourni via le --mrtg option.

serrures
("symlink: check_postgres_locks") Vérifiez le nombre total de verrous sur un ou plusieurs
bases de données. Il n'est pas nécessaire de l'exécuter plus d'une fois par cluster de bases de données. Les bases de données peuvent
être filtré avec le --comprendre ainsi que --exclure option. Voir la rubrique "FILTRER DE BASE"
pour plus de détails.

La --Attention ainsi que --critique les options peuvent être spécifiées sous forme de nombres simples, qui représentent
le nombre total de verrous, ou ils peuvent être ventilés par type de verrou. Noms de verrou valides
sont « total », « en attente » ou le nom d'un type de verrou utilisé par Postgres. Ces noms sont
insensible à la casse et n'ont pas besoin de la partie "lock" à la fin, donc exclusif correspondra
'ExclusiveLock'. Le format est nom=numéro, avec différents éléments séparés par des deux-points ou
points-virgules (ou tout autre symbole).

Exemple 1 : Avertir si le nombre de verrous est de 100 ou plus, et critique si 200 ou plus, sur
hôte garrett

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

Exemple 2 : sur l'artemus hôte, avertir s'il existe 200 verrous ou plus, et donner un si critique
plus de 250 verrous au total existent, ou s'il existe plus de 20 verrous exclusifs, ou si plus de 5 connexions
attendent un cadenas.

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

Pour la sortie MRTG, renvoie le nombre de verrous sur la première ligne et le nom du
base de données sur la quatrième ligne.

fichier journal
("symlink: check_postgres_logfile") Assure que le fichier journal se trouve à l'emplacement attendu
et est connecté à. Cette action émet une commande qui renvoie une erreur sur chaque
base de données qu'il vérifie et s'assure que le message apparaît dans les journaux. Il scanne le
divers paramètres log_* à l'intérieur de Postgres pour déterminer où les journaux doivent être. Si tu
utilisent syslog, il effectue une analyse approximative (mais pas infaillible) de /etc/syslog.conf.
Alternativement, vous pouvez fournir le nom du fichier journal avec le --fichier journal option. C'est
particulièrement utile si les journaux ont un schéma de rotation personnalisé piloté par un programme externe.
La --fichier journal L'option prend en charge les caractères d'échappement suivants : "%Y %m %d %H", qui
représentent respectivement l'année, le mois, la date et l'heure en cours. Une erreur est toujours
signalé comme critique à moins que l'option d'avertissement n'ait été transmise en tant que valeur différente de zéro.
En dehors de cette utilisation spécifique, les options "--warning" et "--critical" devraient ne sauraient be
utilisé.

Exemple 1 : Sur le port 5432, assurez-vous que le fichier journal est écrit dans le fichier
/home/greg/pg8.2.log

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

Exemple 2 : Identique à ci-dessus, mais déclenche un avertissement, pas une critique

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

Pour la sortie MRTG, renvoie un 1 ou un 0 sur la première ligne, indiquant le succès ou l'échec. Dans
en cas de panne, la quatrième ligne donnera plus de détails sur la panne rencontrée.

nouvelle_version_bc
("symlink: check_postgres_new_version_bc") Vérifie si une version plus récente du Bucardo
programme est disponible. La version actuelle est obtenue en exécutant "bucardo_ctl --version".
Si une mise à niveau majeure est disponible, un avertissement est renvoyé. Si une mise à niveau de révision est
disponible, une critique est renvoyée. (Bucardo est un maître à esclave, et maître à maître
système de réplication pour Postgres : voir http://bucardo.org pour plus d'informations). Voir également
les informations sur l'option "--get_method".

nouvelle_version_box
("symlink: check_postgres_new_version_box") Vérifie si une version plus récente de la boxinfo
programme est disponible. La version actuelle est obtenue en exécutant "boxinfo.pl --version".
Si une mise à niveau majeure est disponible, un avertissement est renvoyé. Si une mise à niveau de révision est
disponible, une critique est renvoyée. (boxinfo est un programme pour saisir des informations importantes
informations d'un serveur et les mettre au format HTML : voir
http://bucardo.org/wiki/boxinfo pour plus d'informations). Voir aussi les informations sur le
l'option "--get_method".

nouvelle_version_cp
("symlink: check_postgres_new_version_cp") Vérifie si une version plus récente de ce programme
(check_postgres) est disponible, en récupérant la version à partir d'un petit fichier texte sur le principal
page de la page d'accueil du projet. Renvoie un avertissement si la version renvoyée ne
correspond à celui que vous exécutez. L'intervalle recommandé pour vérifier est une fois par jour. Voir aussi le
informations sur l'option "--get_method".

nouvelle_version_pg
("symlink: check_postgres_new_version_pg") Vérifie si une nouvelle révision de Postgres existe
pour chaque base de données connectée. Notez que cela ne vérifie que la révision, par exemple en allant de
8.3.6 à 8.3.7. Les révisions sont toujours 100% binaires compatibles et n'impliquent aucun vidage et
restaurer pour mettre à niveau. Des révisions sont apportées pour corriger les bogues, donc la mise à niveau dès que possible
est toujours recommandé. Renvoie un avertissement si vous n'avez pas la dernière révision. Il est
recommandé que cette vérification soit exécutée au moins une fois par jour. Voir aussi les informations sur le
l'option "--get_method".

nouvelle_version_tnm
("symlink: check_postgres_new_version_tnm") Vérifie si une version plus récente du tail_n_mail
programme est disponible. La version actuelle est obtenue en exécutant "tail_n_mail --version".
Si une mise à niveau majeure est disponible, un avertissement est renvoyé. Si une mise à niveau de révision est
disponible, une critique est renvoyée. (tail_n_mail est un outil de surveillance des journaux qui peut envoyer
mail lorsque des événements intéressants apparaissent dans vos journaux Postgres. Voir:
http://bucardo.org/wiki/Tail_n_mail pour plus d'informations). Voir aussi les informations sur
l'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
(liens symboliques : "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" et "check_postgres_pgb_pool_maxwait")

Examine les statistiques du pool de pgbouncer. Chaque pool dispose d'un ensemble de connexions "client",
se référant aux connexions des clients externes, et les connexions "serveur", se référant à
connexions à PostgreSQL lui-même. Les actions check_postgres associées sont préfixées par "cl_"
et "sv_", respectivement. Les connexions clientes actives sont les connexions actuellement liées
avec une connexion serveur active. Les connexions clientes peuvent également être "en attente", ce qui signifie qu'elles
n'ont pas encore reçu de connexion au serveur. Les connexions au serveur sont "actives" (liées
à un client), "inactif" (en attente d'une connexion client avec laquelle se lier), "utilisé" (juste
déconnecté d'un client, et pas encore retourné au pool inactif), "testé" (en cours
testé) et "login" (en cours de connexion). La valeur maxwait indique combien de temps dans
secondes la plus ancienne connexion client en attente a attendu.

pgbouncer_backends
("symlink: check_postgres_pgbouncer_backends") Vérifie le nombre actuel de connexions
pour une ou plusieurs bases de données via pgbouncer, et le compare éventuellement au maximum
autorisé, qui est déterminé par la variable de configuration pgbouncer max_client_connL’
--Attention ainsi que --critique les options peuvent prendre l'une des trois formes suivantes. Premièrement, un simple nombre peut
être donné, qui représente le nombre de connexions auxquelles l'alerte sera donnée.
Ce choix n'utilise pas le max_connections réglage. Deuxièmement, le pourcentage de disponibilité
des connexions peuvent être données. Troisièmement, un nombre négatif peut être donné qui représente le
nombre de connexions restantes jusqu'à max_connections est atteint. Les valeurs par défaut pour
--Attention ainsi que --critique sont « 90 % » et « 95 % ». Vous pouvez également filtrer les bases de données à l'aide de
le --comprendre ainsi que --exclure option. Voir la section « FILTRAGE DE BASE » pour plus de détails.

Pour afficher uniquement les processus non inactifs, vous pouvez utiliser le --noïde argument. Notez que l'utilisateur que vous
se connectent en tant que superutilisateur pour que cela fonctionne correctement.

Exemple 1 : donner un avertissement lorsque le nombre de connexions sur l'hôte quirm atteint 120, et un
critique s'il atteint 150.

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

Exemple 2 : Donner un avis critique lorsque nous atteignons 75 % de notre paramètre max_connections sur les hôtes
lancre ou lancre2.

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

Exemple 3 : donner un avertissement lorsqu'il ne reste que 10 emplacements de connexion supplémentaires sur l'hôte
plasmide, et un critique quand il ne nous en reste que 5.

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

Pour la sortie MRTG, le nombre de connexions est indiqué sur la première ligne et la quatrième
La ligne donne le nom de la base de données, plus le max_client_conn actuel. Si plus d'un
base de données a été interrogée, celle avec le plus grand nombre de connexions est affichée.

pgbouncer_checksum
("symlink: check_postgres_pgbouncer_checksum") Vérifie que tous les paramètres de pgBouncer sont
le même que la dernière fois que vous avez vérifié. Ceci est fait en générant une somme de contrôle d'une liste triée
de définir les noms et leurs valeurs. Notez que vous ne devez pas spécifier le nom de la base de données, il
sera automatiquement par défaut pgbouncer. Soit le --Attention au sein de l’ --critique option
devrait être donné, mais pas les deux. La valeur de chacun est la somme de contrôle, un nombre de 32 caractères
valeur hexadécimale. Vous pouvez exécuter avec l'option spéciale "--critical=0" pour trouver un
somme de contrôle existante.

Cette action nécessite le module Digest::MD5.

Exemple 1 : Trouvez la somme de contrôle initiale pour la configuration de pgbouncer sur le port 6432 en utilisant le
utilisateur par défaut (généralement postgres)

check_postgres_pgbouncer_checksum --port=6432 --critical=0

Exemple 2 : assurez-vous qu'aucun paramètre n'a changé et avertissez si c'est le cas, en utilisant la somme de contrôle de
au dessus.

check_postgres_pgbouncer_checksum --port=6432 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Pour la sortie MRTG, renvoie un 1 ou 0 indiquant le succès de l'échec de la somme de contrôle pour correspondre.
Une somme de contrôle doit être fournie comme argument "--mrtg". La quatrième ligne donne toujours le
somme de contrôle actuelle.

pgagent_jobs
("symlink: check_postgres_pgagent_jobs") Vérifie que toutes les tâches pgAgent qui ont
exécutés dans l'intervalle de temps précédent ont réussi. Cela se fait en vérifiant
toutes les étapes qui ont un résultat différent de zéro.

Soit "--warning" ou "--critical", ou les deux, peuvent être spécifiés en tant qu'heures, et les travaux seront
vérifié les échecs dans les périodes de temps spécifiées avant l'heure actuelle. Valide
les unités sont les secondes, les minutes, les heures et les jours ; tout peut être abrégé à la première lettre.
Si aucune unité n'est donnée, les « secondes » sont supposées.

Exemple 1 : Donnez une valeur critique lorsque des tâches exécutées le dernier jour ont échoué.

check_postgres_pgagent_jobs --critical=1d

Exemple 2 : donner un avertissement lorsque des tâches exécutées au cours de la dernière semaine ont échoué.

check_postgres_pgagent_jobs --warning=7d

Exemple 3 : donnez une note critique pour les travaux qui ont échoué au cours des 2 dernières heures et un avertissement pour
tâches qui ont échoué au cours des 4 dernières heures :

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

prepare_txns
("symlink: check_postgres_prepared_txns") Vérifiez l'âge de tout préparé existant
transactions. Notez que la plupart des gens n'utiliseront PAS de transactions préparées, car elles font partie
de commit en deux parties et compliqué à maintenir. Il ne faut pas non plus les confondre avec
DÉCLARATIONS préparées, ce à quoi la plupart des gens pensent lorsqu'ils entendent préparer. Les
la valeur par défaut d'un avertissement est de 1 seconde, pour détecter toute utilisation de transactions préparées, qui
est probablement une erreur sur la plupart des systèmes. Avertissement et critique sont le nombre de secondes a
transaction préparée a été ouverte avant qu'une alerte ne soit donnée.

Exemple 1 : donner un avertissement lors de la détection de transactions préparées :

check_postgres_prepared_txns -w 0

Exemple 2 : Donnez une note critique si une transaction préparée est ouverte depuis plus de 10 ans
secondes, mais prévoyez jusqu'à 360 secondes pour la base de données « shrike » :

check_postgres_prepared_txns --critical=10 --exclude=grièche
check_postgres_prepared_txns --critical=360 --include=grièche

Pour la sortie MRTG, renvoie le nombre de secondes pendant lesquelles la transaction la plus ancienne a été ouverte en tant que
première ligne et de quelle base de données provient la dernière ligne.

requête_runtime
("symlink: check_postgres_query_runtime") Vérifie combien de temps une requête spécifique prend pour s'exécuter,
en exécutant un "EXPLAIN ANALYZE" contre lui. Les --Attention ainsi que --critique les options sont les
durée maximale de la requête. Les unités valides sont les secondes, les minutes et les heures ;
tout peut être abrégé à la première lettre. Si aucune unité n'est donnée, les « secondes » sont supposées.
L'avertissement et l'option critique doivent être donnés. Le nom de la vue ou de la fonction
pour être exécuté doit être transmis au --nom de requête option. Il doit consister en un seul mot
(ou schema.word), avec des parenthèses facultatives à la fin.

Exemple 1 : Donnez un point critique si la fonction nommée "speedtest" ne s'exécute pas en 10 secondes ou
Moins.

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

Pour la sortie MRTG, indique le temps en secondes pour que la requête se termine sur la première ligne.
La quatrième ligne répertorie la base de données.

heure_requête
("symlink: check_postgres_query_time") Vérifie la longueur des requêtes en cours d'exécution sur un ou plusieurs
bases de données. Il n'est pas nécessaire de l'exécuter plusieurs fois sur le même cluster de bases de données. Noter
que cela exclut déjà les requêtes qui sont "inactives en transaction". Les bases de données peuvent être
filtré en utilisant le --comprendre ainsi que --exclure option. Voir la rubrique "FILTRER DE BASE"
pour plus de détails. Vous pouvez également filtrer sur l'utilisateur exécutant la requête avec le --includeuser
ainsi que --exclureutilisateur option. Voir la section "FILTRER LE NOM D'UTILISATEUR" pour plus de détails.

Les valeurs pour le --Attention ainsi que --critique les options sont des quantités de temps, et par défaut à '2
minutes' et '5 minutes' respectivement. Les unités valides sont « secondes », « minutes », « heures » ou
'jours'. Chacun peut être écrit au singulier ou abrégé à la première lettre seulement. Si aucune unité
sont données, l'unité est supposée être la seconde.

Cette action nécessite Postgres 8.1 ou supérieur.

Exemple 1 : donner un avertissement si une requête s'exécute depuis plus de 3 minutes, et un
critique si plus de 5 minutes.

check_postgres_query_time --port=5432 --warning='3 minutes' --critical='5 minutes'

Exemple 2 : En utilisant les valeurs par défaut (2 et 5 minutes), vérifiez toutes les bases de données sauf celles
commençant par « modèle ».

check_postgres_query_time --port=5432 --exclude=~^modèle

Exemple 3 : Avertir si l'utilisateur 'don' a une requête qui s'exécute sur 20 secondes

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

Pour la sortie MRTG, renvoie la durée en secondes de la requête la plus longue du premier
ligne. La quatrième ligne donne le nom de la base de données.

replica_row
("symlink: check_postgres_replicate_row") Vérifie que la réplication maître-esclave fonctionne
à un ou plusieurs esclaves.

Les premières options "--dbname", "--host" et "--port", etc. sont considérées comme le maître ;
les utilisations ultérieures sont les esclaves. Les valeurs ou les --Attention ainsi que --critique les options sont
unités de temps, et au moins une doit être fournie (aucune valeur par défaut). Les unités valides sont les « secondes »,
« minutes », « heures » ou « jours ». Chacun peut être écrit au singulier ou abrégé en
première lettre. Si aucune unité n'est donnée, les unités sont supposées être des secondes.

Cette vérification met à jour une seule ligne sur le maître, puis mesure le temps qu'il faut pour être
appliqué aux esclaves. Pour ce faire, vous devez sélectionner une table en cours de réplication, puis
trouver une ligne qui peut être modifiée et qui ne sera modifiée par aucun autre processus. UNE
colonne spécifique de cette ligne sera modifiée d'une valeur à une autre. Tout cela se nourrit
à l'option "repinfo", et doit contenir les options suivantes, séparées par des virgules :
nom de table, clé primaire, identifiant de clé, colonne, première valeur, deuxième valeur.

Exemple 1 : Slony réplique une table nommée 'orders' de l'hôte 'alpha' vers l'hôte 'beta',
dans la base de données 'ventes'. La clé primaire de la table est nommée id, et nous allons
testez la ligne avec un identifiant de 3 (qui est historique et n'a jamais changé). il y a une colonne
nommé 'salesrep' que nous allons basculer d'une valeur de 'slon' à 'nols' pour vérifier
la réplication. Nous voulons lancer un avertissement si la réplication ne se produit pas dans les 10
secondes.

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

Exemple 2 : Bucardo réplique une table nommée « reçu » de l'hôte « vert » vers les hôtes
« rouge », « bleu » et « jaune ». La base de données des deux côtés est « publique ». Les bases de données esclaves
s'exécutent sur le port 5455. La clé primaire est nommée 'receipt_id', la ligne que nous voulons utiliser
a une valeur de 9, et la colonne que nous voulons modifier pour le test s'appelle 'zone'. Bien
basculer entre « nord » et « sud » pour la valeur de cette colonne, et lancer un si critique
le changement n'est pas sur les trois esclaves dans les 5 secondes.

check_postgres_replicate_row --host=green --port=5455 --host=rouge,bleu,jaune
--critical=5 --repinfo=receipt,receipt_id,9,zone,nord,sud

Pour la sortie MRTG, renvoie sur la première ligne le temps en secondes que prend la réplication pour
terminer. Le temps maximum est fixé à 4 minutes 30 secondes : si aucune réplication n'a pris
lieu dans ce laps de temps, une erreur est levée.

même_schéma
("symlink: check_postgres_same_schema") Vérifie que deux ou plusieurs bases de données sont identiques
en ce qui concerne leur schéma (mais pas les données qu'il contient). Ceci est particulièrement pratique pour faire
assurez-vous que vos esclaves n'ont pas été modifiés ou corrompus de quelque manière que ce soit lors de l'utilisation de maître à esclave
réplication. Contrairement à la plupart des autres actions, celle-ci n'a pas de critère d'avertissement ou critique - le
les bases de données sont synchronisées ou ne le sont pas. S'ils sont différents, une liste détaillée des
différences est présenté.

Vous pouvez vouloir exclure ou filtrer certaines différences. La façon de faire est d'ajouter
à l'option "--filter". Pour exclure un type d'objet, utilisez "noname", où 'name'
est le type d'objet, par exemple, "noschema". Pour exclure des objets d'un certain type par un
expression régulière contre leur nom, utilisez "noname=regex". Voir les exemples ci-dessous pour un
meilleur compréhension.

Les types d'objets pouvant être filtrés incluent :

utilisateur
schéma
table
vue
indice
séquence
contrainte
déclencher
fonction

L'option de filtre "noposition" empêche la vérification de la position des colonnes dans un
tableau.

L'option de filtre "nofuncbody" empêche la comparaison des corps de toutes les fonctions.

L'option de filtre "noperm" empêche la comparaison des autorisations d'objet.

Pour fournir la deuxième base de données, il suffit d'ajouter les différences à la première par un appel à
l'argument de connexion approprié. Par exemple, pour comparer des bases de données sur des hôtes alpha et
bravo, utilisez "--dbhost=alpha,bravo". Voir aussi les exemples ci-dessous.

Si un seul hôte est indiqué, il est supposé que nous faisons un rapport " basé sur le temps ". Les
la première fois que cela est exécuté, un instantané de tous les éléments de la base de données est enregistré dans un local
déposer. Lorsque vous l'exécutez à nouveau, cet instantané est lu et devient "base de données #2" et est
par rapport à la base de données actuelle.

Pour remplacer l'ancien fichier stocké par la nouvelle version, utilisez l'argument --replace.

Pour activer les instantanés à différents moments, vous pouvez utiliser l'argument "--suffix" pour faire
les noms de fichiers uniques à chaque exécution. Voir les exemples ci-dessous.

Exemple 1 : vérifiez que deux bases de données sur les hôtes star et line sont identiques :

check_postgres_same_schema --dbhost=star,ligne

Exemple 2 : Idem qu'avant, mais excluez tous les déclencheurs contenant « slony » dans leur nom

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

Exemple 3 : Identique au précédent, mais exclut également tous les index

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

Exemple 4 : Vérifier les différences pour la base de données "battlestar" sur différents ports

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

Exemple 5 : Créer un fichier instantané quotidien et hebdomadaire

check_postgres_same_schema --dbname=cylon --suffix=quotidien
check_postgres_same_schema --dbname=cylon --suffix=hebdomadaire

Exemple 6 : Exécutez une comparaison historique, puis remplacez le fichier

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

séquence
("symlink: check_postgres_sequence") Vérifie combien de place il reste sur toutes les séquences dans le
base de données. Ceci est mesuré comme le pourcentage du total des valeurs possibles qui ont été utilisées
pour chaque séquence. Les --Attention ainsi que --critique les options doivent être exprimées sous la forme
pourcentages. Les valeurs par défaut sont 85% pour l'avertissement et 95% pour les critiques. Tu peux
utilisez --include et --exclude pour contrôler les séquences à vérifier. Notez que ce
le chèque tient compte de l'inhabituel valeur minimale ainsi que incrément by valeurs, mais ne se soucie pas si le
la séquence est réglée pour cycler ou non.

La sortie pour Nagios donne le nom de la séquence, le pourcentage utilisé et le nombre
d'appels restants, indiquant combien de fois nextval peut être appelé sur cette séquence
avant d'atteindre la valeur maximale.

La sortie pour MRTG renvoie le pourcentage le plus élevé sur toutes les séquences sur la première ligne,
et le nom de chaque séquence avec ce pourcentage sur la quatrième ligne, séparés par un " | "
(tuyau) s'il y a plus d'une séquence à ce pourcentage.

Exemple 1 : donner un avertissement si des séquences sont presque pleines à 95 %.

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

Exemple 2 : vérifiez que la séquence nommée "orders_id_seq" n'est pas plus qu'à moitié pleine.

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

paramètres_checksum
("symlink: check_postgres_settings_checksum") Vérifie que tous les paramètres Postgres sont
le même que la dernière fois que vous avez vérifié. Ceci est fait en générant une somme de contrôle d'une liste triée
de définir les noms et leurs valeurs. Notez que différents utilisateurs dans la même base de données peuvent avoir
sommes de contrôle différentes, en raison de l'utilisation de ALTER USER et du fait que les super-utilisateurs voient plus
paramètres que les utilisateurs ordinaires. Soit le --Attention au sein de l’ --critique l'option devrait être
donné, mais pas les deux. La valeur de chacun est la somme de contrôle, un hexadécimal de 32 caractères
valeur. Vous pouvez exécuter avec l'option spéciale "--critical=0" pour découvrir un
somme de contrôle.

Cette action nécessite le module Digest::MD5.

Exemple 1 : recherchez la somme de contrôle initiale pour la base de données sur le port 5555 à l'aide de l'utilisateur par défaut
(généralement postgres)

check_postgres_settings_checksum --port=5555 --critical=0

Exemple 2 : assurez-vous qu'aucun paramètre n'a changé et avertissez si c'est le cas, en utilisant la somme de contrôle de
au dessus.

check_postgres_settings_checksum --port=5555 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Pour la sortie MRTG, renvoie un 1 ou 0 indiquant le succès de l'échec de la somme de contrôle pour correspondre.
Une somme de contrôle doit être fournie comme argument "--mrtg". La quatrième ligne donne toujours le
somme de contrôle actuelle.

statut_slony
("symlink: check_postgres_slony_status") Vérifie l'état d'un cluster Slony en
en regardant les résultats de la vue sl_status de Slony. Ceci est renvoyé comme le nombre de
secondes de "temps de latence". Les --Attention ainsi que --critique les options doivent être exprimées en temps.
Les valeurs par défaut sont 60 secondes pour l'avertissement et 300 secondes pour les critiques.

L'argument facultatif --schéma a indiqué le schéma sous lequel Slony est installé. Si ça
n'est pas fourni, le schéma sera déterminé automatiquement à chaque exécution de cette vérification.

Exemple 1 : donner un avertissement si un Slony est retardé de plus de 20 secondes

check_postgres_slony_status --avertissement 20

Exemple 2 : Donnez une critique si Slony, installé sous le schéma "_slony", est supérieur à 10
minutes de retard

check_postgres_slony_status --schema=_slony --critical=600

synchronisation horaire
("symlink: check_postgres_timesync") Compare l'heure du système local avec l'heure rapportée
par une ou plusieurs bases de données. Les --Attention ainsi que --critique les options représentent le nombre de
secondes entre les deux systèmes avant qu'une alerte ne soit donnée. Si ni l'un ni l'autre n'est spécifié, le
les valeurs par défaut sont utilisées, qui sont « 2 » et « 5 ». La valeur d'avertissement ne peut pas être supérieure à
la valeur critique. En raison de la nature non exacte de ce test, les valeurs « 0 » ou « 1 » ne sont pas
recommandé.

La chaîne renvoyée indique le décalage horaire ainsi que l'heure de chaque côté écrite
en dehors.

Exemple 1 : vérifiez que les bases de données sur les hôtes ankh, morpork et klatch ne dépassent pas 3
secondes hors de l'heure locale :

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

Pour la sortie MRTG, renvoie sur la première ligne le nombre de secondes de différence entre le
l'heure locale et l'heure de la base de données. La quatrième ligne renvoie le nom de la base de données.

txn_idle
("symlink: check_postgres_txn_idle") Vérifie le nombre et la durée de "idle in
transaction" sur une ou plusieurs bases de données. Il n'est pas nécessaire de l'exécuter plusieurs fois
sur le même cluster de bases de données. Les bases de données peuvent être filtrées en utilisant le --comprendre ainsi que
--exclure option. Voir la section "FILTRE DE BASE" ci-dessous pour plus de détails.

La --Attention ainsi que --critique les options sont données sous forme d'unités de temps, d'entiers signés ou
entiers pour les unités de temps, et les deux doivent être fournis (il n'y a pas de valeurs par défaut). Unités valides
sont des « secondes », des « minutes », des « heures » ou des « jours ». Chacun peut être écrit au singulier ou en abrégé
à la première lettre seulement. Si aucune unité n'est donnée et que les nombres ne sont pas signés, les unités
sont supposés être des secondes.

Cette action nécessite Postgres 8.3 ou supérieur.

Exemple 1 : donner un avertissement si une connexion est restée inactive pendant plus de 15 ans
secondes :

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

Exemple 2 : donner un avertissement s'il y a 50 transactions ou plus

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

Exemple 3 : Donnez une valeur critique si 5 connexions ou plus sont restées inactives en transaction pendant plus
plus de 10 secondes :

check_postgres_txn_idle --port=5432 --critical='5 pendant 10 secondes'

Pour la sortie MRTG, renvoie le temps en secondes pendant lequel la transaction inactive la plus longue a été
fonctionnement. La quatrième ligne renvoie le nom de la base de données et d'autres informations sur le
opération la plus longue.

txn_heure
("symlink: check_postgres_txn_time") Vérifie la durée des transactions ouvertes sur un ou plusieurs
bases de données. Il n'est pas nécessaire d'exécuter cette commande plusieurs fois par cluster de bases de données.
Les bases de données peuvent être filtrées en utilisant le --comprendre ainsi que --exclure option. Voir le "BASIQUE
FILTRAGE" pour plus de détails. Le propriétaire de la transaction peut également être filtré, par
l'utilisation de l' --includeuser ainsi que --exclureutilisateur option. Voir la section "FILTRER LE NOM D'UTILISATEUR"
pour plus de détails.

Les valeurs ou les --Attention ainsi que --critique les options sont des unités de temps et doivent être fournies
(aucun défaut). Les unités valides sont « secondes », « minutes », « heures » ou « jours ». Chacun peut être
écrit au singulier ou abrégé à la première lettre seulement. Si aucune unité n'est donnée, le
les unités sont supposées être des secondes.

Cette action nécessite Postgres 8.3 ou supérieur.

Exemple 1 : Donnez une note critique si une transaction est ouverte depuis plus de 10 minutes :

check_postgres_txn_time --port=5432 --critical='10 minutes'

Exemple 1 : Avertir si l'utilisateur « entrepôt » a une transaction ouverte plus de 30 secondes

check_postgres_txn_time --port-5432 --warning=30s --includeuser=entrepôt

Pour la sortie MRTG, renvoie la durée maximale en secondes pendant laquelle une transaction a été ouverte sur le
Première ligne. La quatrième ligne donne le nom de la base de données.

txn_wraparound
("lien symbolique : check_postgres_txn_wraparound") Vérifie à quel point le wraparound de la transaction est proche
ou plusieurs bases de données deviennent. Les --Attention ainsi que --critique les options indiquent le nombre
des transactions effectuées, et doit être un entier positif. Si l'une ou l'autre option n'est pas donnée, le
des valeurs par défaut de 1.3 et 1.4 milliard sont utilisées. Il n'est pas nécessaire d'exécuter cette commande plus
qu'une fois par cluster de bases de données. Pour une discussion plus détaillée de ce que ce nombre
représente et que faire à ce sujet, veuillez visiter la page
<http://www.postgresql.org/docs/current/static/routine-vacuuming.html#VIDE-POUR-ENVELOPPEMENT>

Les valeurs d'avertissement et critiques peuvent avoir des traits de soulignement dans le nombre pour la lisibilité, comme Perl
t.

Exemple 1 : vérifier les valeurs par défaut de la base de données localhost

check_postgres_txn_wraparound --host=localhost

Exemple 2 : vérifiez le port 6000 et donnez un avis critique lorsque 1.7 milliard de transactions sont atteintes :

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

Pour la sortie MRTG, renvoie le plus grand nombre de transactions pour toutes les bases de données sur la première ligne,
tandis que la ligne 4 indique de quelle base de données il s'agit.

version
("symlink: check_postgres_version") Vérifie que la version requise de Postgres est
fonctionnement. Les --Attention ainsi que --critique les options (une seule est requise) doivent être au format
Xy or XYZ De X est le numéro de version principal, Y est le numéro de version mineure, et Z is
la révision.

Exemple 1 : donner un avertissement si la base de données sur le port 5678 n'est pas la version 8.4.10 :

check_postgres_version --port=5678 -w=8.4.10

Exemple 2 : donner un avertissement si des bases de données sur les hôtes valley,grain ou sunshine n'est pas 8.3 :

check_postgres_version -H vallée,grain,soleil --critical=8.3

Pour la sortie MRTG, signale un 1 ou un 0 indiquant le succès ou l'échec sur la première ligne. Les
la quatrième ligne indique la version actuelle. La version doit être fournie via le "--mrtg"
option.

fichiers_wal
("symlink: check_postgres_wal_files") Vérifie combien de fichiers WAL existent dans le pg_xlog
répertoire, qui se trouve dans votre répertoire_données, parfois comme lien symbolique vers un autre
disque physique pour des raisons de performances. Cette action doit être exécutée en tant que superutilisateur, afin de
accéder au contenu du pg_xlog annuaire. La version minimale pour utiliser cette action est
Postgres 8.1. Les --Attention ainsi que --critique les options sont simplement le nombre de fichiers dans le
pg_xlog annuaire. Le nombre à définir variera, mais une directive générale est de mettre
un nombre légèrement supérieur à ce qui est normalement là, pour détecter les problèmes tôt.

Normalement, les fichiers WAL sont fermés puis réutilisés, mais une transaction ouverte de longue durée, ou un
défectueux archive_commande script, peut amener Postgres à créer trop de fichiers. Finalement,
cela entraînera un manque d'espace sur le disque sur lequel ils se trouvent, auquel cas Postgres
fermer.

Exemple 1 : Vérifiez que le nombre de fichiers WAL est de 20 ou moins sur l'hôte "pluto"

check_postgres_wal_files --host=pluto --critical=20

Pour la sortie MRTG, indique le nombre de fichiers WAL sur la ligne 1.

reconstruire_liens symboliques
reconstruire_symlinks_force
Cette action ne nécessite aucun autre argument et ne se connecte à aucune base de données, mais simplement
crée des liens symboliques dans le répertoire courant pour chaque action, sous la forme
check_postgres_. Si le fichier existe déjà, il ne sera pas écrasé. Si
l'action est reconstruct_symlinks_force, alors les liens symboliques seront écrasés. L'option
--symlinks est une façon plus courte de dire --action=rebuild_symlinks

BASIQUE Filtrage

Les options --comprendre ainsi que --exclure peuvent être combinés pour limiter les éléments à vérifier,
en fonction de l'action. Le nom de la base de données peut être filtré lors de l'utilisation des éléments suivants
actions : backends, database_size, verrous, query_time, txn_idle et txn_time. Le nom de
une relation peut être filtrée lors de l'utilisation des actions suivantes : bloat, index_size,
table_size, relation_size, last_vacuum, last_autovacuum, last_analyze et
last_autoanalyze. Le nom d'un paramètre peut être filtré lors de l'utilisation de settings_checksum
action. Le nom d'un système de fichiers peut être filtré lors de l'utilisation de l'action disk_space.

Si seule une option d'inclusion est donnée, alors SEULE les entrées qui correspondent seront vérifiées.
Cependant, si elle est à la fois exclue et incluse, l'exclusion est effectuée en premier et l'inclusion
après, pour rétablir des choses qui auraient pu être exclues. Les deux --comprendre ainsi que --exclure vous
être donné plusieurs fois et/ou sous forme de listes séparées par des virgules. Un tilde de tête correspondra au
mot suivant comme expression régulière.

Pour faire correspondre un schéma, terminez le terme de recherche par un seul point. Les tildes principaux peuvent être utilisés
aussi pour les schémas.

Soyez prudent lorsque vous utilisez le filtrage : une règle d'inclusion sur les backends, par exemple, peut
signaler aucun problème non seulement parce que la base de données correspondante n'avait pas de backends, mais parce que vous
mal orthographié le nom de la base de données !

Exemples :

Vérifie uniquement les éléments nommés pg_class :

--include=pg_classe

Vérifie uniquement les éléments contenant les lettres 'pg_' :

--include=~pg_

Vérifiez uniquement les éléments commençant par 'pg_' :

--include=~^pg_

Excluez l'élément nommé « test » :

--exclude=tester

Exclure tous les éléments contenant les lettres « test :

--exclude=~tester

Exclure tous les éléments du schéma 'pg_catalog' :

--exclude='pg_catalog.'

Excluez tous les éléments contenant les lettres « as », mais autorisez l'élément « mise en jeu » :

--exclude=~as --include=face à face

Exclure tous les éléments qui commencent par les lettres « pg_ », qui contiennent les lettres « slon », ou
qui sont nommés 'sql_settings' ou 'green'. Vérifiez spécifiquement les éléments avec les lettres
'prod' dans leurs noms, et vérifiez toujours l'élément nommé 'pg_relname' :

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

UTILISATEUR Nom Filtrage

Les options --includeuser ainsi que --exclureutilisateur peut être utilisé sur certaines actions pour examiner uniquement
objets de base de données détenus (ou non détenus par) un ou plusieurs utilisateurs. Un --includeuser option
l'emporte toujours sur un --exclureutilisateur option. Vous pouvez donner à chaque option plus d'une fois pour
plusieurs utilisateurs, ou vous pouvez donner une liste séparée par des virgules. Les actions qui utilisent actuellement
ces options sont :

taille_base_de_données
dernière_analyse
dernière_analyse automatique
dernier_vide
dernier_autovacuum
heure_requête
relation_taille
txn_heure

Exemples :

Vérifiez uniquement les éléments appartenant à l'utilisateur nommé Greg :

--includeuser=greg

Vérifiez uniquement les objets appartenant à Watson ou à Crick :

--includeuser=watson,crick

Vérifiez uniquement les articles appartenant à crick, franklin, watson ou wilkins :

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

Vérifiez tous les éléments à l'exception de ceux appartenant à l'utilisateur scott :

--excludeuser=scott

TEST MODE

Pour aider à la configuration, ce programme peut être exécuté en "mode test" en spécifiant le
--test option. Cela effectuera quelques tests de base pour s'assurer que les bases de données peuvent être
contacté, et que certaines conditions préalables par action sont remplies, par exemple si l'utilisateur est
un superutilisateur, si la version de Postgres est suffisamment récente et si stats_row_level est activé.

Utilisez check_postgres_database_sizep en ligne à l'aide des services onworks.net