check_postgres_query_runtimep - Online en la nube

PROGRAMA:

NOMBRE

check_postgres: un script de monitoreo de Postgres para Nagios, MRTG, Cacti y otros

Este documento describe check_postgres versión 2.22.0

SINOPSIS

## Crea todos los enlaces simbólicos
check_postgres --enlaces simbólicos

## Verifica la conexión a la base de datos de Postgres 'pluto':
check_postgres --acción = conexión --db = pluto

## Lo mismo, pero usando el enlace simbólico
check_postgres_connection --db = plutón

## Advertir si> 100 bloqueos, crítico si> 200 o> 20 exclusivo
check_postgres_locks --warning = 100 --critical = "total = 200: exclusivo = 20"

## Muestra el número actual de conexiones inactivas en el puerto 6543:
check_postgres_txn_idle --port = 6543 --output = simple

## Hay muchas otras acciones y opciones, sigue leyendo.

Las últimas noticias y documentación siempre se pueden encontrar en:
http://bucardo.org/check_postgres/

DESCRIPCIÓN

check_postgres es un script de Perl que ejecuta muchas pruebas diferentes contra una o más
Bases de datos de Postgres. Utiliza el programa psql para recopilar la información y genera el
da como resultado uno de tres formatos: Nagios, MRTG o simple.

Salida Modos
La salida se puede cambiar mediante el uso de la opción "--output". La salida predeterminada es nagios,
aunque esto se puede cambiar en la parte superior del script si lo desea. La opción actual
las opciones son nagios, mrtgy simples. Para evitar tener que ingresar el argumento de salida cada
tiempo, el tipo de salida se establece automáticamente si no se proporciona ningún argumento --output, y si el
El directorio actual tiene una de las opciones de salida en su nombre. Por ejemplo, crear un
directorio llamado mrtg y poblarlo con enlaces simbólicos a través del --enlaces simbólicos el argumento sería
asegúrese de que cualquier acción que se ejecute desde ese directorio siempre tendrá una salida predeterminada de "mrtg"
Como atajo para --output = simple, puede ingresar --simple, que también anula el
truco de nomenclatura de directorios.

Nagios salida

El formato de salida predeterminado es para Nagios, que es una sola línea de información, junto con
cuatro códigos de salida específicos:

0 (bien)
1 (ADVERTENCIA)
2 (CRÍTICO)
3 (DESCONOCIDO)

La línea de salida es una de las palabras anteriores, dos puntos y luego una breve descripción de lo que
fue medido. Información estadística adicional, así como el tiempo total que el comando
tomó, también se puede generar: consulte la documentación sobre los argumentos --showperf,
--perflímitey --tiempo de la funcion.

MRTG salida

La salida MRTG es de cuatro líneas, con la primera línea siempre dando un solo número de
importancia. Cuando sea posible, este número representa un valor real, como un número de
bytes, pero también puede ser un 1 o un 0 para las acciones que solo devuelven "verdadero" o "falso", como
como check_postgres_version. La segunda línea es una estadística adicional y solo se usa para
algunas acciones. La tercera línea indica un "tiempo de actividad" y no se utiliza. La cuarta línea es una
descripción y generalmente indica el nombre de la base de datos la estadística de la primera línea
se extrajo, pero puede ser diferente según la acción.

Algunas acciones aceptan un opcional --mrtg argumento para controlar aún más la salida.

Consulte la documentación de cada acción para obtener detalles sobre la salida MRTG exacta de cada una.

Sencillo salida

La salida simple es simplemente una versión truncada del MRTG, y simplemente devuelve el
primer número y nada más. Esto es muy útil cuando solo desea verificar el estado
de algo, independientemente de cualquier umbral. Puede transformar la salida numérica por
agregando KB, MB, GB, TB o EB al argumento de salida, por ejemplo:

--output = simple, MB

Cactus salida

La salida de Cacti consta de uno o más elementos en la misma línea, con un nombre simple, un
dos puntos y luego un número. Por el momento, la única acción con salida explícita de Cacti es
'dbstats', y el uso de la opción --output no es necesario en este caso, ya que Cacti es el único
salida para esta acción. Para muchas otras acciones, usar --simple es suficiente para hacer Cacti
feliz.

BASE DE DATOS CONEXIÓN OPCIONES

Todas las acciones aceptan un conjunto común de opciones de base de datos.

-H NOMBRE or --host = NOMBRE
Conéctese al host indicado por NAME. Puede ser una lista de nombres separados por comas.
Se permiten varios argumentos de host. Si no se proporciona ningún host, el valor predeterminado es "PGHOST"
variable de entorno o ningún host (lo que indica el uso de un socket Unix local).
También puede utilizar "--dbhost".

-p PORT or --port = PUERTO
Se conecta utilizando el número de PUERTO especificado. Puede ser una lista de puertos separados por comas
Se permiten números y múltiples argumentos de puerto. Si no se proporciona un número de puerto, los valores predeterminados
a la variable de entorno "PGPORT". Si no se establece, el valor predeterminado es 5432. Puede
también usa "--dbport"

-Db NOMBRE or --dbname = NOMBRE
Especifica a qué base de datos conectarse. Puede ser una lista de nombres separados por comas y
se permiten varios argumentos de nombre de base de datos. Si no se proporciona la opción dbname, el valor predeterminado es
la variable de entorno "PGDATABASE". Si no está configurado, el valor predeterminado es 'postgres'
si psql es la versión 8 o superior, y 'template1' en caso contrario.

-u NOMBRE DE USUARIO or --dbuser = NOMBRE DE USUARIO
El nombre del usuario de la base de datos con el que conectarse. Puede ser una lista separada por comas de
Se permiten nombres de usuario y múltiples argumentos dbuser. Si esto no se proporciona,
por defecto a la variable de entorno "PGUSER", de lo contrario, por defecto a 'postgres'.

--dbpass = CONTRASEÑA
Proporciona la contraseña para conectarse a la base de datos. El uso de esta opción es altamente
desanimado. En su lugar, se debe utilizar un archivo .pgpass o pg_service.conf.

--dbservice = NOMBRE
El nombre de un servicio dentro del archivo pg_service.conf. Antes de la versión 9.0 de
Postgres, este es un archivo global, generalmente se encuentra en /etc/pg_service.conf. Si usted es
usando la versión 9.0 o superior de Postgres, puede usar el archivo ".pg_service.conf" en
el directorio de inicio del usuario que ejecuta el script, por ejemplo, nagios.

Este archivo contiene una lista simple de opciones de conexión. También puede pasar adicional
información al usar esta opción, como --dbservice = "maindatabase sslmode = require"

La documentación de este archivo se puede encontrar en
http://www.postgresql.org/docs/current/static/libpq-pgservice.html

Las opciones de conexión a la base de datos se pueden agrupar: --host = a, b --host = c --port = 1234
--port = 3344 se conectaría a a-1234, b-1234 y c-3344. Tenga en cuenta que una vez configurada, una opción
se transfiere hasta que se cambia de nuevo.

Ejemplos:

--host = a, b --port = 5433 --db = c
Se conecta dos veces al puerto 5433, utilizando la base de datos c, para los hosts ayb: a-5433-c b-5433-c

--host = a, b --port = 5433 --db = c, d
Se conecta cuatro veces: 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 conecta seis veces: 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 conecta tres veces: a-5432-alice-baz b-5433-alice-baz x-5433-bob-baz

--dbservice = "foo" --port = 5433
Se conecta usando el servicio nombrado 'foo' en el archivo pg_service.conf, pero anula el puerto

OTROS OPCIONES

Otras opciones incluyen:

--acción = NOMBRE
Indica qué acción estamos ejecutando. Obligatorio a menos que se utilice un archivo con enlace simbólico, en el que
caso de que el nombre del archivo se utilice para averiguar la acción.

--advertencia = VAL or -w VAL
Establece el umbral en el que se activa una alerta de advertencia. Las opciones válidas para esto
La opción depende de la acción utilizada.

--crítico = VAL or -c VAL
Establece el umbral en el que se activa una alerta crítica. Las opciones válidas para esto
La opción depende de la acción utilizada.

-t VAL or --timeout = VAL
Establece el tiempo de espera en segundos después del cual el script abortará lo que esté haciendo y
devuelve un estado DESCONOCIDO. El tiempo de espera es por clúster de Postgres, no para todo el
texto. El valor predeterminado es 10; las unidades están siempre en segundos.

--asume-modo de espera
Si se especifica, primero se comprobará si se realizará el servidor en modo de espera (--datadir
es obligatorio), de ser así, se ignorarán todas las comprobaciones que requieran consultas SQL y "Server
en modo de espera "con el estado OK se devolverá en su lugar.

Ejemplo:

postgres@db$./check_postgres --action = version --warning = 8.1 --datadir /var/lib/postgresql/8.3/main/ --assume-standby-mode
POSTGRES_VERSION OK: servidor en modo de espera | tiempo = 0.00

--asume-prod
Si se especifica, verifique si se ejecuta el servidor en modo de producción (se requiere --datadir).
La opción solo es relevante para ("enlace simbólico: check_postgres_checkpoint").

Ejemplo:

postgres@db$./check_postgres --action = checkpoint --datadir /var/lib/postgresql/8.3/main/ --assume-prod
POSTGRES_CHECKPOINT OK: El último punto de control fue hace 72 segundos | edad = 72 ;; modo 300 = MAESTRO

-h or --ayuda
Muestra una pantalla de ayuda con un resumen de todas las acciones y opciones.

--hombre
Muestra el manual completo.

-V or --versión
Muestra la versión actual.

-v or --verboso
Establece el nivel de verbosidad. Puede llamar más de una vez para aumentar el nivel. Poniéndolo en
tres o más (en otras palabras, emitir "-v -v -v") activa la información de depuración
para este programa que se envía a stderr.

--showperf = VAL
Determina si generamos datos de rendimiento adicionales en formato estándar de Nagios (al final
de cadena, después de un símbolo de tubería, usando nombre = valor). VAL debe ser 0 o 1. El valor predeterminado
es 1. Solo tiene efecto si se usa el modo de salida de Nagios.

--perflimit = i
Establece un límite en cuanto a cuántos elementos de interés se informan cuando se utiliza el
espectáculo opción. Esto solo tiene efecto para las acciones que devuelven una gran cantidad de
elementos, como tamaño de la mesa. El valor predeterminado es 0 o sin límite. Tenga cuidado al usar este
con el --incluir or --excluir opciones, ya que esas restricciones se hacen después de de la forma más
La consulta se ha ejecutado y, por lo tanto, es posible que su límite no incluya los elementos que desea. Solo toma
efecto si se usa el modo de salida de Nagios.

--showtime = VAL
Determina si el tiempo necesario para ejecutar cada consulta se muestra en la salida. VAL debe ser 0
o 1. El valor predeterminado es 1. Sin efecto a menos que espectáculo Está encendido. Solo tiene efecto si se usa
Modo de salida de Nagios.

--prueba
Habilita el modo de prueba. Consulte la sección "MODO DE PRUEBA" a continuación.

--PGBINDIR = RUTA
Le dice al script dónde encontrar los binarios psql. Útil si tienes más de uno
versión de los ejecutables de PostgreSQL en su sistema, o si no los hay en su
sendero. Tenga en cuenta que esta opción está en mayúsculas. Por defecto, esta opción es no
permitido. Para habilitarlo, debe cambiar $ NO_PSQL_OPTION cerca de la parte superior del script
a 0. Evite usar esta opción si puede, y en su lugar use la variable de entorno
C o variable $ PGBINDIR codificada de forma rígida, también cerca de la parte superior del script, para establecer
la ruta de acceso al PostgreSQL que se utilizará.

--PSQL = RUTA
(obsoleto, este vídeo opción pueden be remoto in a futuras ¡liberación!) Le dice al guión dónde
para encontrar el programa psql. Útil si tiene más de una versión de psql
ejecutable en su sistema, o si no hay un programa psql en su ruta. Tenga en cuenta que esto
La opción está en mayúsculas. Por defecto, esta opción es no permitido. Para habilitarlo,
debe cambiar $ NO_PSQL_OPTION cerca de la parte superior del script a 0. Evite usar este
opción si puede, y en su lugar codifique su ubicación psql en la variable $ PSQL,
también cerca de la parte superior del guión.

--enlaces simbólicos
Crea enlaces simbólicos al programa principal para cada acción.

--salida = VAL
Determina el formato de la salida para su uso en varios programas. El valor predeterminado es
'nagios'. Las opciones disponibles son 'nagios', 'mrtg', 'simple' y 'cactus'.

--mrtg = VAL
Se usa solo para el MRTG o salida simple, para algunas acciones específicas.

--debugoutput = VAL
Genera la cadena exacta devuelta por psql, para su uso en la depuración. El valor es uno o
más letras, que determinan si la salida se muestra o no, donde 'a' = todo, 'c'
= crítico, 'w' = advertencia, 'o' = ok y 'u' = desconocido. Las letras se pueden combinar.

--get_method = VAL
Permite especificar el método utilizado para obtener información para "new_version_cp",
Comprobaciones "new_version_pg", "new_version_bc", "new_version_box" y "new_version_tnm".
Se prueban los siguientes programas, con el fin de obtener la información de la web: GET,
wget, fetch, curl, lynx, enlaces. Para forzar el uso de solo uno (y así eliminar el
gastos generales de probar todos los demás hasta que uno de esos trabajos), ingrese uno de los nombres como
el argumento de get_method. Por ejemplo, un cuadro BSD puede ingresar la siguiente línea en
su archivo ".check_postgresrc":

get_method = buscar

--language = VAL
Configure el idioma que se utilizará para todos los mensajes de salida. Normalmente, esto es detectado por
examinando las variables de entorno LC_ALL, LC_MESSAGES y LANG, pero estableciendo esto
La opción anulará dicha detección.

ACCIONES

El script ejecuta una o más acciones. Esto se puede hacer con el indicador --action o con
usando un enlace simbólico al archivo principal que contiene el nombre de la acción dentro de él. Para
ejemplo, para ejecutar la acción "timesync", puede emitir:

check_postgres --action = timesync

o use un programa llamado:

comprobar_postgres_timesync

Todos los enlaces simbólicos se crean para usted en el directorio actual si usa la opción --symlinks

perl check_postgres --enlaces simbólicos

Si el nombre del archivo ya existe, no se sobrescribirá. Si el archivo existe y es un
enlace simbólico, puedes forzarlo a sobrescribir usando "--action = build_symlinks_force"

La mayoría de las acciones toman un --advertencia y --crítico opción, indicando en qué punto cambiamos
de OK a ADVERTENCIA, y en qué punto pasamos a CRÍTICO. Tenga en cuenta que debido a que los críticos son
siempre comprobado primero, establecer la advertencia igual al crítico es una forma eficaz de
apague las advertencias y siempre dé una crítica.

Las acciones admitidas actualmente son:

archivo_listo
("enlace simbólico: check_postgres_archive_ready") Comprueba cuántos archivos WAL con extensión .Listo
existir en el pg_xlog / archive_status directorio, que se encuentra fuera de su directorio de datos.
Esta acción debe ejecutarse como superusuario, para poder acceder a los contenidos del
pg_xlog / archive_status directorio. La versión mínima para usar esta acción es Postgres 8.1.
El sistema --advertencia y --crítico opciones son simplemente el número de .Listo archivos en el
pg_xlog / archive_status directorio. Por lo general, estos valores deben ser bajos, activando el
mecanismo de archivo, normalmente queremos que archive archivos WAL lo más rápido posible.

Si el comando de archivo falla, el número de WAL en su pg_xlog el directorio crecerá hasta
agota todo el espacio en disco y obliga a PostgreSQL a detenerse inmediatamente.

Ejemplo 1: Verifique que el número de archivos WAL listos sea 10 o menos en el host "pluto"

check_postgres_archive_ready --host = plutón --critical = 10

Para la salida MRTG, informa el número de archivos WAL listos en la línea 1.

autovac_freeze
("enlace simbólico: check_postgres_autovac_freeze") Comprueba qué tan cerca está cada base de datos de la
Postgres autovacuum_freeze_max_age configuración. Esta acción solo funcionará para bases de datos
versión 8.2 o superior. los --advertencia y --crítico las opciones deben expresarse como
porcentajes. La 'edad' de las transacciones en cada base de datos se compara con la
configuración de autovacuum_freeze_max_age (200 millones por defecto) para generar una
porcentaje. Los valores predeterminados son 90% por la advertencia y 95% para los críticos. Bases de datos
se puede filtrar mediante el uso de la --incluir y --excluir opciones. Ver "FILTRADO BÁSICO"
Sección para más detalles.

Ejemplo 1: dar una advertencia cuando cualquier base de datos en el puerto 5432 esté por encima del 97%

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

Para la salida de MRTG, el porcentaje general más alto se informa en la primera línea, y el
la edad más alta se indica en la segunda línea. Todas las bases de datos que tienen el porcentaje de
la primera línea se indica en la cuarta línea, separada por un símbolo de tubería.

backends
("enlace simbólico: check_postgres_backends") Comprueba el número actual de conexiones para una o
más bases de datos y, opcionalmente, lo compara con el máximo permitido, que está determinado por
la variable de configuración de Postgres Max_connections. --advertencia y --crítico opciones
puede tomar una de estas tres formas. Primero, se puede dar un número simple, que representa el
número de conexiones en las que se dará la alerta. Esta elección no utiliza el
Max_connections configuración. En segundo lugar, se puede dar el porcentaje de conexiones disponibles.
En tercer lugar, se puede dar un número negativo que representa el número de conexiones que quedan.
hasta Max_connections es alcanzado. Los valores predeterminados para --advertencia y --crítico están
'90% 'y '95%'. También puede filtrar las bases de datos mediante el uso de --incluir y --excluir
opciones. Consulte la sección "FILTRADO BÁSICO" para obtener más detalles.

Para ver solo los procesos que no están inactivos, puede utilizar el --niño argumento. Tenga en cuenta que el usuario que
se están conectando como debe ser un superusuario para que esto funcione correctamente.

Ejemplo 1: dar una advertencia cuando el número de conexiones en el host quirm llega a 120, y un
crítico si llega a 150.

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

Ejemplo 2: Dar un valor crítico cuando alcancemos el 75% de nuestra configuración de max_connections en los hosts
lancre o lancre 2.

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

Ejemplo 3: dar una advertencia cuando solo quedan 10 ranuras de conexión más en el host
plásmido, y un crítico cuando solo nos quedan 5.

check_postgres_backends --warning = -10 --critical = -5 --host = plásmido

Ejemplo 4: Verifique todas las bases de datos excepto aquellas con "prueba" en su nombre, pero permita las que
se denominan "pg_greatest". Conéctese como puerto 5432 en los dos primeros hosts y como puerto 5433 en
el tercero. Queremos lanzar siempre una crítica cuando lleguemos a 30 o más conexiones.

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

Para la salida MRTG, el número de conexiones se informa en la primera línea y la cuarta
line da el nombre de la base de datos, más las conexiones máximas actuales. Si mas de
se ha consultado una base de datos, se emite la que tiene el mayor número de conexiones.

inflar
("enlace simbólico: check_postgres_bloat") Comprueba la cantidad de hinchazón en tablas e índices. (Inflar
es generalmente la cantidad de espacio muerto no utilizado que se ocupa en una tabla o índice. Este espacio es
generalmente se recupera mediante el uso del comando VACUUM.) Esta acción requiere que las estadísticas
la recopilación esté habilitada en las bases de datos de destino y requiere que se ejecute ANALYZE
frecuentemente. los --incluir y --excluir Las opciones se pueden utilizar para filtrar qué tablas
mirar. Consulte la sección "FILTRADO BÁSICO" para obtener más detalles.

El sistema --advertencia y --crítico las opciones se pueden especificar como tamaños, porcentajes o ambos. Válido
las unidades de tamaño son bytes, kilobytes, megabytes, gigabytes, terabytes, exabytes, petabytes y
zettabytes. Puede abreviar todos aquellos con la primera letra. Los elementos sin unidades son
se supone que son 'bytes'. Los valores predeterminados son '1 GB' y '5 GB'. El valor representa el
número de "bytes desperdiciados", o la diferencia entre lo que realmente usa la tabla y
index, y lo que calculamos que debería ser.

Tenga en cuenta que esta acción tiene dos valores codificados para evitar falsas alarmas en
relaciones. Las tablas deben tener al menos 10 páginas y los índices al menos 15 antes de que puedan ser
considerado por esta prueba. Si realmente desea ajustar estos valores, puede buscar el
las variables $ MINPAGES y $ MINIPAGES en la parte superior de la subrutina "check_bloat". Estas
los valores se ignoran si --excluir or --incluir se utiliza.

Solo se muestran las 10 relaciones más hinchadas. Puede cambiar este número utilizando el
--perflímite opción para establecer su propio límite.

El esquema denominado 'esquema_información' se excluye de esta prueba, ya que las únicas tablas que
contiene son pequeños y no cambian.

Tenga en cuenta que los valores calculados por esta acción no son precisos y deben utilizarse como
sólo una guía. Se hizo un gran esfuerzo para estimar el tamaño correcto de una mesa, pero en
al final es solo una estimación. El tamaño de índice correcto es incluso más una conjetura que el
tamaño correcto de la mesa, pero ambos deberían dar una idea aproximada de cuán hinchadas están las cosas.

Ejemplo 1: advierta si alguna tabla en el puerto 5432 tiene más de 100 MB hinchada y es crítica si supera los 200
MB

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

Ejemplo 2: Dar un valor crítico si la tabla 'pedidos' en el host 'sami' tiene más de 10 megas de hinchazón

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

Ejemplo 3: proporcione un valor crítico si la tabla 'q4' en la base de datos 'ventas' está inflada en más del 50%

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

Ejemplo 4: Dale un valor crítico a cualquier tabla que esté hinchada en más del 20% y tiene más de 150 MB de hinchazón:

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

Ejemplo 5: Dale un valor crítico a cualquier tabla que esté hinchada en más del 40% or tiene más de 500 MB de hinchazón:

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

Para la salida MRTG, la primera línea da el mayor número de bytes desperdiciados para las tablas,
y la segunda línea da el mayor número de bytes desperdiciados para los índices. El cuarto
La línea proporciona el nombre de la base de datos, el nombre de la tabla y la información del nombre del índice. Si quieres
generar la proporción de hinchazón en su lugar (cuántas veces más grande es la relación en comparación con cómo
debe ser grande), simplemente pase "--mrtg = ratio".

control
("enlace simbólico: check_postgres_checkpoint") Determina cuánto tiempo ha transcurrido desde el último punto de control
se ha ejecutado. Debe ejecutarse en el mismo servidor que la base de datos que se está comprobando (p. Ej.
-h la bandera no funcionará). Esta comprobación está destinada a ejecutarse en un servidor de "espera en caliente" que esté
procesa activamente archivos WAL enviados, y está destinado a verificar que su espera en caliente es
verdaderamente 'cálido'. El directorio de datos debe estar configurado, ya sea por la variable de entorno
"PGDATA", o pasando el argumento "--datadir". Devuelve el número de segundos desde que
se ejecutó el último punto de control, según se determina analizando la llamada a "pg_controldata". Porque
esto, el ejecutable pg_controldata debe estar disponible en la ruta actual. Alternativamente,
puede especificar "PGBINDIR" como el directorio en el que vive. También es posible utilizar
las opciones especiales --asume-prod or --asume-modo de espera, si el modo encontrado no es el
uno esperado, se emite un CRÍTICO.

Se debe establecer al menos un argumento de advertencia o crítico.

Esta acción requiere el módulo Date :: Parse.

Para MRTG o salida simple, devuelve el número de segundos.

id_clúster
("symlink: check_postgres_cluster-id") Comprueba que el identificador del sistema de la base de datos proporcionado
por pg_controldata es lo mismo que la última vez que verificó. Esto debe ejecutarse en el mismo servidor.
como la base de datos que se está comprobando (por ejemplo, el indicador -h no funcionará). O el
--advertencia o el --crítico se debe dar la opción, pero no ambas. El valor de cada uno es
el identificador de clúster, un valor entero. Puede ejecutar con el especial "--critical = 0"
opción para averiguar un identificador de clúster existente.

Ejemplo 1: encontrar el identificador inicial

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

Ejemplo 2: asegúrese de que el clúster sea el mismo y advierta si no, utilizando el resultado de arriba.

check_postgres_cluster_id --critical = 5633695740047915135

Para la salida MRTG, devuelve un 1 o 0 que indica el éxito de la falla del identificador para
fósforo. Se debe proporcionar un identificador como argumento "--mrtg". La cuarta linea siempre
da el identificador actual.

compromiso
("symlink: check_postgres_commitratio") Comprueba la proporción de confirmaciones de todas las bases de datos y
se queja cuando son demasiado bajos. No es necesario ejecutar este comando más de una vez por
clúster de base de datos. Las bases de datos se pueden filtrar con el --incluir y --excluir opciones. Ver
la sección "FILTRADO BÁSICO" para más detalles. También pueden ser filtrados por el propietario de
la base de datos con el --incluir usuario y --excluir usuario opciones. Ver el "NOMBRE DE USUARIO
FILTRADO "sección para más detalles.

Las opciones de advertencia y críticas deben especificarse como porcentajes. No hay
valores predeterminados para esta acción: se deben especificar la advertencia y la crítica. El valor de advertencia
no puede ser mayor que el valor crítico. La salida devuelve todas las bases de datos ordenadas por
commitratio, el más pequeño primero.

Ejemplo: advierta si alguna base de datos en la bandera de host tiene menos del 90% en relación de compromiso y es crítica
si es menos del 80%.

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

Para la salida MRTG, devuelve el porcentaje de la base de datos con la relación de compromiso más pequeña en
la primera línea y el nombre de la base de datos en la cuarta línea.

conexión
("enlace simbólico: check_postgres_connection") Simplemente se conecta, emite un 'SELECT versión()'y
sale de. No toma --advertencia or --crítico .

Para la salida MRTG, simplemente emite un 1 (buena conexión) o un 0 (mala conexión) en la primera
la línea.

consulta_personalizada
("enlace simbólico: check_postgres_custom_query") Ejecuta una consulta personalizada de su elección y analiza
Los resultados. La consulta en sí se pasa a través del argumento "consulta" y debe ser
mantenido lo más simple posible. Si es posible, envuélvalo en una vista o una función para mantener
las cosas más fáciles de gestionar. La consulta debe devolver una o dos columnas. Se requiere que
una de las columnas se llamará "resultado" y es el elemento que se comparará con su
Advertencias y valores críticos. La segunda columna es para los datos de rendimiento y cualquier nombre
se puede usar: este será el 'valor' dentro de la sección de datos de rendimiento.

Se debe especificar al menos una advertencia o un argumento crítico. Lo que estos están configurados depende
según el tipo de consulta que está ejecutando. Hay cuatro tipos de consultas_personalizadas que se pueden
ejecutar, especificado por el argumento "valtype". Si no se especifica ninguno, esta acción tiene como valor predeterminado
'entero'. Los cuatro tipos son:

entero: Hace una simple comparación de enteros. La primera columna debe ser un número entero simple,
y los valores críticos y de advertencia deben ser los mismos.

cadena: La advertencia y el crítico son cadenas y se activan solo si el valor en el
la primera columna coincide exactamente con ella. Esto distingue entre mayúsculas y minúsculas.

time: La advertencia y la crítica son tiempos y pueden tener unidades de segundos, minutos,
horas o días. Cada uno puede escribirse en singular o abreviado a la primera letra. Si
no se dan unidades, se asumen segundos. La primera columna debe ser un número entero
que representa el número de segundos para comprobar.

tamaño: La advertencia y la crítica son tamaños y pueden tener unidades de bytes, kilobytes,
megabytes, gigabytes, terabytes o exabytes. Cada uno puede abreviarse a la primera letra.
Si no se dan unidades, se asumen bytes. La primera columna debe ser un número entero
que representa el número de bytes a comprobar.

Normalmente, se activa una alerta si los valores devueltos son mayor than o igual a la
valor crítico o de advertencia. Sin embargo, una opción de --contrarrestar activará la alerta si el
el valor devuelto es lower than o igual al valor crítico o de advertencia.

Ejemplo 1: advierta si alguna relación de más de 100 páginas se llama "rad", ingrese el número de páginas
dentro de la sección de datos de rendimiento.

check_postgres_custom_query --valtype = string -w "rad" --query =
"SELECT relname COMO resultado, relpages AS páginas DE pg_class DONDE relpages> 100"

Ejemplo 2: Dar un valor crítico si la función "foobar" devuelve un número superior a 5 MB:

check_postgres_custom_query --critical = '5MB' - valtype = size --query = "SELECT foobar () COMO resultado"

Ejemplo 2: Advertir si la función "snazzo" devuelve menos de 42:

check_postgres_custom_query --critical = 42 --query = "SELECCIONAR snazzo () COMO resultado" --reverse

Si se le ocurre una consulta personalizada útil, considere enviar un parche a este programa para
conviértalo en una acción estándar que otras personas puedan utilizar.

Esta acción aún no es compatible con MRTG o salida simple.

tamaño_base_datos
("enlace simbólico: check_postgres_database_size") Comprueba el tamaño de todas las bases de datos y se queja
cuando son demasiado grandes. No es necesario ejecutar este comando más de una vez por base de datos
grupo. Las bases de datos se pueden filtrar con el --incluir y --excluir opciones. Ver el
Sección "FILTRADO BÁSICO" para más detalles. También pueden ser filtrados por el propietario del
base de datos con el --incluir usuario y --excluir usuario opciones. Ver "FILTRADO DE NOMBRE DE USUARIO"
Sección para más detalles.

Las opciones críticas y de advertencia se pueden especificar como bytes, kilobytes, megabytes,
gigabytes, terabytes o exabytes. Cada uno puede abreviarse también a la primera letra.
Si no se proporciona ninguna unidad, se supone que las unidades son bytes. No hay valores predeterminados para esto
acción: se deben especificar la advertencia y la crítica. El valor de advertencia no puede ser mayor
que el valor crítico. La salida devuelve todas las bases de datos ordenadas por tamaño, la más grande primero,
mostrando tanto bytes sin procesar como una versión "bonita" del tamaño.

Ejemplo 1: advertir si alguna base de datos en la etiqueta de host tiene más de 1 TB de tamaño y es crítica si se supera
1.1 TB.

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

Ejemplo 2: proporcione un valor crítico si la plantilla1 de la base de datos en el puerto 5432 tiene más de 10 MB.

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

Ejemplo 3: Dar una advertencia si alguna base de datos en el host 'tardis' propiedad del usuario 'tom' ha terminado
5 GB

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

Para la salida MRTG, devuelve el tamaño en bytes de la base de datos más grande en la primera línea y
el nombre de la base de datos en la cuarta línea.

dbstats
("enlace simbólico: check_postgres_dbstats") Informa información de la vista pg_stat_database,
y lo emite de una manera amigable con los cactus. No se admite ninguna otra salida, ya que la salida es
informativo y no se presta a alertas, como las que se utilizan con Nagios. Si no hay opciones
se dan, se devuelven todas las bases de datos, una por línea. Puedes incluir una base de datos específica
mediante el uso de la opción "--include", o puede utilizar la opción "--dbname".

Se devuelven once elementos en cada línea, en el formato nombre: valor, separados por un solo
espacio. Los elementos son:

backends
El número de backends actualmente en ejecución para esta base de datos.

confirma
El número total de confirmaciones para esta base de datos desde que se creó o restableció.

retrocesos
El número total de reversiones de esta base de datos desde que se creó o restableció.

read
El número total de bloques de disco leídos.

hit El número total de hits de búfer.

ret El número total de filas devueltas.

ha podido recuperar
El número total de filas recuperadas.

ins El número total de filas insertadas.

upd El número total de filas actualizadas.

del El número total de filas eliminadas.

nombre de la base de datos
El nombre de la base de datos.

Tenga en cuenta que los elementos ret, fetch, ins, upd y del siempre serán 0 si Postgres es la versión 8.2
o inferior, ya que esas estadísticas no estaban disponibles en esas versiones.

Si se proporciona el argumento dbname, se devuelven siete elementos adicionales:

idxscan
Número total de análisis de índices de usuarios.

idxtupread
Número total de entradas de índice de usuario devueltas.

idxtupfetch
Número total de filas obtenidas mediante exploraciones de índice de usuario simples.

lectura idxblks
Número total de bloques de disco leídos para todos los índices de usuario.

idxblkshit
Número total de accesos al búfer para todos los índices de usuario.

escaneo secuencial
Número total de escaneos secuenciales en todas las tablas de usuarios.

seqtupread
Número total de tuplas devueltas de todas las tablas de usuario.

Ejemplo 1: obtenga las estadísticas de una base de datos denominada "productos" en el host "willow":

check_postgres_dbstats --dbhost willow --dbname productos

La salida devuelta será así (todo en una línea, no envuelto):

backends: 82 confirmaciones: 58374408 reversiones: 1651 lectura: 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

disparadores_inhabilitados
("enlace simbólico: check_postgres_disabled_triggers") Comprueba el número de activadores desactivados
dentro de la base de datos. los --advertencia y --crítico las opciones son el número de tales desencadenantes
encontrado, y ambos predeterminados a "1", ya que en el uso normal tener activadores deshabilitados es un peligro
evento. Si la base de datos que se está verificando es 8.3 o superior, la verificación es para el número de
disparadores que están en un estado 'desactivado' (en lugar de estar 'siempre' o 'réplica'). los
la salida mostrará el nombre de la tabla y el nombre del disparador para cada deshabilitado
desencadenar.

Ejemplo 1: asegúrese de que no haya activadores desactivados

check_postgres_disabled_triggers

Para la salida MRTG, devuelve el número de activadores desactivados en la primera línea.

Espacio del disco
("enlace simbólico: check_postgres_disk_space") Comprueba el espacio disponible en disco físico utilizado por
Postgres. Esta acción requiere que tengas el ejecutable "/ bin / df"disponible para informar
en tamaños de disco, y también debe ejecutarse como superusuario, para que pueda examinar el
directorio de datos dentro de Postgres. los --advertencia y --crítico se dan opciones
en tamaños o porcentajes o ambos. Si usa tamaños, los tipos de unidades estándar son
permitido: bytes, kilobytes, gigabytes, megabytes, gigabytes, terabytes o exabytes. Cada
puede abreviarse a la primera letra solamente; ninguna unidad indica 'bytes'. los
los valores predeterminados son '90% 'y '95%'.

Este comando verifica las siguientes cosas para determinar todos los diferentes discos físicos
siendo utilizado por Postgres.

directorio de datos - El disco en el que se encuentra el directorio de datos principal.

log directorio - El disco en el que se encuentran los archivos de registro.

WAL presentar directorio - El disco en el que se encuentran los registros de escritura anticipada (por ejemplo, pg_xlog con enlace simbólico)

espacios de mesa - Cada espacio de tabla que está en un disco separado.

La salida muestra el tamaño total utilizado y disponible en cada disco, así como el
porcentaje, ordenado de mayor a menor porcentaje utilizado. Cada elemento anterior se asigna a un archivo
sistema: estos se pueden incluir o excluir. Consulte la sección "FILTRADO BÁSICO" para obtener más información.
Detalles.

Ejemplo 1: asegúrese de que ningún sistema de archivos supere el 90% de la base de datos en el puerto 5432.

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

Ejemplo 2: compruebe que todos los sistemas de archivos que comienzan con / dev / sda tienen un tamaño inferior a 10 GB y
11 GB (advertencia y crítico)

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

Ejemplo 4: asegúrese de que ningún sistema de archivos supere el 50% y tiene más de 15 GB

check_postgres_disk_space --critical = '50% y 15 GB '

Ejemplo 5: emita una advertencia si algún sistema de archivos está lleno en más del 70% or tiene más de 1T

check_postgres_disk_space --warning = '1T o 75'

Para la salida MRTG, devuelve el tamaño en bytes del sistema de archivos en la primera línea y el
nombre del sistema de archivos en la cuarta línea.

páginas_fsm
("enlace simbólico: check_postgres_fsm_pages") Comprueba qué tan cerca está un clúster de Postgres
max_fsm_pages configuración. Esta acción solo funcionará para bases de datos de 8.2 o superior, y
requiere el módulo contrib pg_freespacemapa estar instalado. los --advertencia y --crítico
las opciones deben expresarse como porcentajes. El número de páginas utilizadas en el mapa de espacio libre
se determina mirando en la vista pg_freespacemap_relations y ejecutando una fórmula
basado en la fórmula utilizada para generar ranuras de páginas de mapa de espacio libre en el vacío detallado
mando. Los valores predeterminados son 85% por la advertencia y 95% para los críticos.

Ejemplo 1: dar una advertencia cuando nuestro clúster haya usado hasta el 76% de los espacios de páginas de espacio libre,
con pg_freespacemap instalado en la base de datos robert

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

Si bien debe pasar el nombre de la base de datos donde está instalado pg_freespacemap,
solo es necesario ejecutar esta verificación una vez por clúster. Además, verificar esta información requiere
obtener bloqueos especiales en el mapa de espacio libre, por lo que se recomienda no ejecutar este
comprobar con intervalos cortos.

Para la salida MRTG, devuelve el porcentaje de mapa de espacio libre en la primera línea y el número
de las páginas que se utilizan actualmente en la segunda línea.

fsm_relaciones
("enlace simbólico: check_postgres_fsm_relations") Comprueba qué tan cerca está un clúster de Postgres
max_fsm_relaciones configuración. Esta acción solo funcionará para bases de datos de 8.2 o superior, y
requiere el módulo contrib pg_freespacemapa estar instalado. los --advertencia y --crítico
las opciones deben expresarse como porcentajes. El número de relaciones utilizadas en el
space-map se determina mirando en la vista pg_freespacemap_relations. El valor por defecto
los valores son 85% por la advertencia y 95% para los críticos.

Ejemplo 1: dar una advertencia cuando nuestro clúster haya agotado el 80% de las relaciones de espacio libre,
con pg_freespacemap instalado en la base de datos dylan

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

Si bien debe pasar el nombre de la base de datos donde está instalado pg_freespacemap,
solo es necesario ejecutar esta verificación una vez por clúster. Además, verificar esta información requiere
obtener bloqueos especiales en el mapa de espacio libre, por lo que se recomienda no ejecutar este
comprobar con intervalos cortos.

Para la salida MRTG, devuelve el porcentaje de mapa de espacio libre en la primera línea, el número de
relaciones utilizadas actualmente en la segunda línea.

proporción de aciertos
("symlink: check_postgres_hitratio") Comprueba la tasa de aciertos de todas las bases de datos y se queja
cuando son demasiado bajos. No es necesario ejecutar este comando más de una vez por base de datos
grupo. Las bases de datos se pueden filtrar con el --incluir y --excluir opciones. Ver el
Sección "FILTRADO BÁSICO" para más detalles. También pueden ser filtrados por el propietario del
base de datos con el --incluir usuario y --excluir usuario opciones. Ver "FILTRADO DE NOMBRE DE USUARIO"
Sección para más detalles.

Las opciones de advertencia y críticas deben especificarse como porcentajes. No hay
valores predeterminados para esta acción: se deben especificar la advertencia y la crítica. El valor de advertencia
no puede ser mayor que el valor crítico. La salida devuelve todas las bases de datos ordenadas por
hitratio, el más pequeño primero.

Ejemplo: advertir si alguna base de datos en la bandera de host tiene menos del 90% en relación de aciertos, y es crítico si
menos del 80%.

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

Para la salida MRTG, devuelve el porcentaje de la base de datos con la menor proporción de visitas en el
primera línea y el nombre de la base de datos en la cuarta línea.

hot_standby_delay
("enlace simbólico: check_hot_standby_delay") Comprueba el retraso de replicación de transmisión calculando el
delta entre la posición actual de xlog de un servidor maestro y la ubicación de reproducción de un
esclavo conectado a él. El servidor esclavo debe estar en modo hot_standby (p. Ej., Solo lectura),
por lo tanto, la versión mínima para usar esta acción es Postgres 9.0. los --advertencia y
--crítico las opciones son el delta entre las ubicaciones de xlog. Dado que estos valores son bytes
compensaciones en el WAL deben coincidir con el volumen de transacciones esperado de su aplicación
para prevenir falsos positivos o negativos.

Las primeras opciones "--dbname", "--host" y "--port", etc. se consideran maestras; los
el segundo pertenece al esclavo.

Los valores de bytes deben basarse en el volumen de transacciones necesarias para tener la transmisión
la replicación se desconecta del maestro debido a demasiado retraso, determinado por Postgres
variable de configuración wal_keep_segmentos. Para las unidades de tiempo, las unidades válidas son 'segundos',
'minutos', 'horas' o 'días'. Cada uno puede escribirse en singular o abreviado solo al
primera letra. Al especificar ambos, en la forma 'bytes y time', ambas condiciones deben ser
cierto para el umbral a alcanzar.

Debe proporcionar información sobre cómo acceder a las bases de datos proporcionando una coma separada
list a los parámetros --dbhost y --dbport, como "--dbport = 5432,5543". Si no se da,
la acción falla.

Ejemplo 1: advertir que una base de datos con una réplica local en el puerto 5433 está atrasada en cualquier reproducción de xlog
en absoluto

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

Ejemplo 2: Dar un valor crítico si la última transacción que recibe réplica1 es más de 10
hace minutos

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

Ejemplo 3: Permita que la réplica1 esté 1 segmento de WAL por detrás, si el maestro está viendo momentáneamente
más actividad de la que puede manejar la conexión de replicación de transmisión, o 10 minutos de retraso,
si el maestro ve muy poca actividad y no procesa ninguna transacción, pero no
ambos, lo que indicaría un problema duradero con la conexión de replicación.

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

tamaño_índice
tamaño de la mesa
tamaño_relación
(enlaces simbólicos: "check_postgres_index_size", "check_postgres_table_size" y
"check_postgres_relation_size") Las acciones tamaño de la mesa y tamaño_índice son simplemente
variaciones de la tamaño_relación acción, que busca una relación que ha crecido demasiado
grande. Las relaciones (en otras palabras, tablas e índices) se pueden filtrar con el --incluir
y --excluir opciones. Consulte la sección "FILTRADO BÁSICO" para obtener más detalles. Las relaciones pueden
también ser filtrados por el usuario que los posee, usando el --incluir usuario y --excluir usuario
opciones. Consulte la sección "FILTRADO DE NOMBRE DE USUARIO" para obtener más detalles.

Los valores para el --advertencia y --crítico Las opciones son tamaños de archivo y pueden tener unidades de
bytes, kilobytes, megabytes, gigabytes, terabytes o exabytes. Cada uno puede abreviarse
a la primera letra. Si no se dan unidades, se asumen bytes. No hay valores predeterminados
valores: se deben dar tanto la opción de advertencia como la crítica. El texto de retorno muestra el
tamaño de la relación más grande encontrada.

Si --showperf la opción está habilitada, all de las relaciones con sus tamaños se darán.
Para evitar esto, se recomienda que configure el --perflímite opción, que causará
la consulta para hacer un "ORDEN POR tamaño DESC LIMIT (perflimit)".

Ejemplo 1: proporcione un valor crítico si alguna tabla tiene más de 600 MB en el host burrick.

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

Ejemplo 2: advertir si los productos de la tabla tienen un tamaño superior a 4 GB y dar un valor crítico a 4.5 GB.

check_postgres_table_size --host = burrick --warning = '4 GB' --critical = '4.5 GB' --include = productos

Ejemplo 3: advierta si algún índice que no sea propiedad de postgres supera los 500 MB.

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

Para la salida MRTG, devuelve el tamaño en bytes de la relación más grande y el nombre del
base de datos y relación como cuarta línea.

último_análisis
último_vacío
último_análisis automático
último_autovacío
(enlaces simbólicos: "check_postgres_last_analyze", "check_postgres_last_vacuum",
"check_postgres_last_autoanalyze" y "check_postgres_last_autovacuum") Comprueba cuánto tiempo
Ha sido desde la última vez que se ejecutó el vacío (o analizar) en cada tabla en una o más bases de datos.
El uso de estas acciones requiere que la base de datos de destino sea la versión 8.3 o superior, o que
la versión es 8.2 y la variable de configuración estadísticas_fila_nivel ha sido habilitado. Mesas
se puede filtrar con el --incluir y --excluir opciones. Ver "FILTRADO BÁSICO"
sección para más detalles. Las tablas también pueden ser filtradas por su propietario mediante el uso de la
--incluir usuario y --excluir usuario opciones. Consulte la sección "FILTRADO DEL NOMBRE DE USUARIO" para obtener más información.
Detalles.

Las unidades para --advertencia y --crítico se especifican como tiempos. Las unidades válidas son segundos,
minutos, horas y días; todo se puede abreviar a la primera letra. Si no hay unidades
dado, se asumen 'segundos'. Los valores predeterminados son '1 día' y '2 días'. tenga en cuenta
que hay casos en los que este campo no se completa automáticamente. Si es cierto
las mesas le están dando problemas, asegúrese de que tengan filas muertas para aspirar, o simplemente
excluirlos de la prueba.

El esquema denominado 'esquema_información' se excluye de esta prueba, ya que las únicas tablas que
contiene son pequeños y no cambian.

Tenga en cuenta que las versiones que no son "automáticas" también comprobarán las versiones automáticas. En otra
palabras, el uso de last_vacuum informará sobre el último vacío, si fue un vacío normal,
o uno ejecutado por el daemon de autovacuum.

Ejemplo 1: advierta si no se ha aspirado alguna mesa en 3 días y dé un valor crítico a
semana, para el ajenjo huésped

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

Ejemplo 2: Igual que el anterior, pero omitir las tablas que pertenecen a los usuarios 'eve' o 'mallory'

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

Para la salida MRTG, devuelve (en la primera línea) la MÍNIMA cantidad de tiempo en segundos desde una
La mesa fue aspirada o analizada por última vez. La cuarta línea devuelve el nombre de la base de datos y
nombre de la mesa.

oyente
("enlace simbólico: check_postgres_listener") Confirme que alguien está escuchando uno o más
cadenas específicas (usando el sistema LISTEN / NOTIFY), mirando la tabla pg_listener.
Solo se necesita uno de advertencia o crítico. El formato es una cadena simple que representa el
LISTEN target, o un carácter de tilde seguido de una cadena para una comprobación de expresión regular.
Tenga en cuenta que esta comprobación no funcionará en versiones de Postgres 9.0 o superiores.

Ejemplo 1: dar una advertencia si nadie está escuchando la cadena bucardo_mcp_ping en los puertos
5555 y 5556

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

Ejemplo 2: Dar una crítica si no hay solicitudes LISTEN activas que coincidan con 'grimm' en
base de datos oskar

check_postgres_listener --db oskar --critical = ~ grimm

Para la salida MRTG, devuelve un 1 o un 0 en el primero, lo que indica éxito o fracaso. El nombre
del aviso debe proporcionarse a través del --mrtg .

cabellos
("enlace simbólico: check_postgres_locks") Verifique el número total de bloqueos en uno o más
bases de datos. No es necesario ejecutar esto más de una vez por clúster de base de datos. Las bases de datos pueden
ser filtrado con el --incluir y --excluir opciones. Consulte la sección "FILTRADO BÁSICO"
para obtener más información.

El sistema --advertencia y --crítico Las opciones se pueden especificar como números simples, que representan
el número total de cerraduras, o se pueden desglosar por tipo de cerradura. Nombres de bloqueo válidos
son 'total', 'en espera' o el nombre de un tipo de bloqueo utilizado por Postgres. Estos nombres son
no distingue entre mayúsculas y minúsculas y no necesita la parte "candado" al final, por lo que PROGRAMA EXCLUSIVO coincidirá
'ExclusiveLock'. El formato es nombre = número, con diferentes elementos separados por dos puntos o
punto y coma (o cualquier otro símbolo).

Ejemplo 1: advertir si el número de bloqueos es 100 o más, y crítico si es 200 o más, en
anfitrión garrett

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

Ejemplo 2: En el artemus anfitrión, advierta si existen 200 o más bloqueos y dé un valor crítico si
existen más de 250 bloqueos en total, o si existen más de 20 bloqueos exclusivos, o si existen más de 5 conexiones
están esperando un candado.

check_postgres_locks --host = artemus --warning = 200 --critical = "total = 250: esperando = 5: exclusivo = 20"

Para la salida MRTG, devuelve el número de bloqueos en la primera línea y el nombre del
base de datos en la cuarta línea.

archivo de registro
("enlace simbólico: check_postgres_logfile") Asegura que el archivo de registro esté en la ubicación esperada
y se está registrando en. Esta acción emite un comando que arroja un error en cada
base de datos que está comprobando y se asegura de que el mensaje aparezca en los registros. Escanea el
Varias configuraciones log_ * dentro de Postgres para averiguar dónde deberían estar los registros. Si tu
están usando syslog, hace un escaneo aproximado (pero no infalible) de /etc/syslog.conf.
Alternativamente, puede proporcionar el nombre del archivo de registro con el --archivo de registro opción. Este es
especialmente útil si los registros tienen un esquema de rotación personalizado impulsado por un programa externo.
El sistema --archivo de registro La opción admite los siguientes caracteres de escape: "% Y% m% d% H", que
representan el año, mes, fecha y hora actuales, respectivamente. Un error es siempre
se informa como crítico a menos que la opción de advertencia se haya pasado como un valor distinto de cero.
Aparte de ese uso específico, las opciones "--warning" y "--critical" deben no be
usado.

Ejemplo 1: en el puerto 5432, asegúrese de que el archivo de registro se esté escribiendo en el archivo
/home/greg/pg8.2.log

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

Ejemplo 2: Igual que el anterior, pero generar una advertencia, no una crítica

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

Para la salida MRTG, devuelve un 1 o 0 en la primera línea, lo que indica éxito o fracaso. En
En caso de falla, la cuarta línea proporcionará más detalles sobre la falla encontrada.

nueva_version_bc
("enlace simbólico: check_postgres_new_version_bc") Comprueba si hay una versión más nueva del Bucardo
El programa está disponible. La versión actual se obtiene ejecutando "bucardo_ctl --version".
Si hay una actualización importante disponible, se devuelve una advertencia. Si una actualización de revisión es
disponible, se devuelve un crítico. (Bucardo es amo a esclavo y amo a amo
sistema de replicación para Postgres: ver http://bucardo.org para más información). Ver también
la información sobre la opción "--get_method".

nueva_version_box
("enlace simbólico: check_postgres_new_version_box") Comprueba si hay una versión más reciente de boxinfo
El programa está disponible. La versión actual se obtiene ejecutando "boxinfo.pl --version".
Si hay una actualización importante disponible, se devuelve una advertencia. Si una actualización de revisión es
disponible, se devuelve un crítico. (boxinfo es un programa para captar importantes
información de un servidor y ponerla en formato HTML: consulte
http://bucardo.org/wiki/boxinfo para más información). Consulte también la información sobre el
Opción "--get_method".

nueva_versión_cp
("enlace simbólico: check_postgres_new_version_cp") Comprueba si hay una versión más reciente de este programa
(check_postgres) está disponible, tomando la versión de un pequeño archivo de texto en la
página de la página de inicio del proyecto. Devuelve una advertencia si la versión devuelta no lo hace.
coincidir con el que está ejecutando. El intervalo recomendado para verificar es una vez al día. Ver también el
información sobre la opción "--get_method".

nueva_versión_pg
("enlace simbólico: check_postgres_new_version_pg") Comprueba si existe una revisión más reciente de Postgres
para cada base de datos conectada. Tenga en cuenta que esto solo comprueba la revisión, por ejemplo, yendo de
8.3.6 a 8.3.7. Las revisiones son siempre 100% compatibles con binarios y no implican volcado y
restaurar para actualizar. Las revisiones se realizan para corregir errores, por lo que debe actualizarse lo antes posible
siempre se recomienda. Devuelve una advertencia si no tiene la última revisión. Está
Se recomienda que esta comprobación se realice al menos una vez al día. Consulte también la información sobre el
Opción "--get_method".

nueva_versión_tnm
("enlace simbólico: check_postgres_new_version_tnm") Comprueba si hay una versión más nueva de tail_n_mail
El programa está disponible. La versión actual se obtiene ejecutando "tail_n_mail --version".
Si hay una actualización importante disponible, se devuelve una advertencia. Si una actualización de revisión es
disponible, se devuelve un crítico. (tail_n_mail es una herramienta de monitoreo de registros que puede enviar
correo electrónico cuando aparecen eventos interesantes en sus registros de Postgres. Ver:
http://bucardo.org/wiki/Tail_n_mail para más información). Consulte también la información sobre
la opción "--get_method".

pgb_pool_cl_activo
pgb_pool_cl_esperando
pgb_pool_sv_activo
pgb_pool_sv_idle
pgb_pool_sv_used
pgb_pool_sv_probado
pgb_pool_sv_login
pgb_pool_maxwait
(enlaces simbólicos: "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" y "check_postgres_pgb_pool_maxwait")

Examina las estadísticas del grupo de pgbouncer. Cada grupo tiene un conjunto de conexiones de "cliente",
refiriéndose a conexiones de clientes externos, y conexiones de "servidor", refiriéndose a
conexiones a PostgreSQL en sí. Las acciones check_postgres relacionadas tienen el prefijo "cl_"
y "sv_", respectivamente. Las conexiones de cliente activas son aquellas conexiones actualmente vinculadas
con una conexión de servidor activa. Las conexiones de cliente también pueden estar "esperando", lo que significa que
aún no se les ha asignado una conexión de servidor. Las conexiones del servidor están "activas" (vinculadas
a un cliente), "inactivo" (en espera de una conexión de cliente para enlazar con), "usado" (solo
desvinculado de un cliente y aún no devuelto al grupo inactivo), "probado" (actualmente
probado) e "iniciar sesión" (en el proceso de iniciar sesión). El valor maxwait muestra cuánto tiempo en
segundos ha estado esperando la conexión de cliente en espera más antigua.

pgbouncer_backends
("enlace simbólico: check_postgres_pgbouncer_backends") Comprueba el número actual de conexiones
para una o más bases de datos a través de pgbouncer y, opcionalmente, lo compara con el máximo
permitido, que está determinado por la variable de configuración pgbouncer max_client_conn.
--advertencia y --crítico las opciones pueden tomar una de estas tres formas. Primero, un simple número puede
ser dado, que representa el número de conexiones en las que se dará la alerta.
Esta elección no utiliza el Max_connections configuración. En segundo lugar, el porcentaje de disponibilidad
Se pueden dar conexiones. En tercer lugar, se puede dar un número negativo que representa la
número de conexiones restantes hasta Max_connections es alcanzado. Los valores predeterminados para
--advertencia y --crítico son '90% 'y '95%'. También puede filtrar las bases de datos mediante el uso de
de la forma más --incluir y --excluir opciones. Consulte la sección "FILTRADO BÁSICO" para obtener más detalles.

Para ver solo los procesos que no están inactivos, puede utilizar el --niño argumento. Tenga en cuenta que el usuario que
se están conectando como debe ser un superusuario para que esto funcione correctamente.

Ejemplo 1: dar una advertencia cuando el número de conexiones en el host quirm llega a 120, y un
crítico si llega a 150.

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

Ejemplo 2: Dar un valor crítico cuando alcancemos el 75% de nuestra configuración de max_connections en los hosts
lancre o lancre 2.

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

Ejemplo 3: dar una advertencia cuando solo quedan 10 ranuras de conexión más en el host
plásmido, y un crítico cuando solo nos quedan 5.

check_postgres_pgbouncer_backends --warning = -10 --critical = -5 --host = plásmido -p 6432 -u pgbouncer

Para la salida MRTG, el número de conexiones se informa en la primera línea y la cuarta
line da el nombre de la base de datos, más el actual max_client_conn. Si mas de uno
Se ha consultado la base de datos, se emite la que tiene el mayor número de conexiones.

pgbouncer_checksum
("enlace simbólico: check_postgres_pgbouncer_checksum") Comprueba que todas las configuraciones de pgBouncer son
lo mismo que la última vez que lo comprobó. Esto se hace generando una suma de comprobación de una lista ordenada.
de establecer nombres y sus valores. Tenga en cuenta que no debe especificar el nombre de la base de datos,
automáticamente por defecto a pgbouncer. O el --advertencia o el --crítico opción
debe darse, pero no ambos. El valor de cada uno es la suma de comprobación, un 32 caracteres
valor hexadecimal. Puede ejecutar con la opción especial "--critical = 0" para averiguar un
suma de comprobación existente.

Esta acción requiere el módulo Digest :: MD5.

Ejemplo 1: Encuentre la suma de verificación inicial para la configuración de pgbouncer en el puerto 6432 usando el
usuario predeterminado (generalmente postgres)

check_postgres_pgbouncer_checksum --port = 6432 --critical = 0

Ejemplo 2: asegúrese de que no haya cambiado ninguna configuración y advierta si es así, utilizando la suma de comprobación de
anterior.

check_postgres_pgbouncer_checksum --port=6432 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Para la salida MRTG, devuelve un 1 o 0 que indica el éxito o el fracaso de la suma de comprobación para coincidir.
Se debe proporcionar una suma de comprobación como argumento "--mrtg". La cuarta línea siempre da la
suma de comprobación actual.

pgagent_jobs
("enlace simbólico: check_postgres_pgagent_jobs") Comprueba que todos los trabajos de pgAgent que tienen
ejecutados en el intervalo de tiempo anterior han tenido éxito. Esto se hace comprobando
cualquier paso que tenga un resultado distinto de cero.

Se puede especificar "--warning" o "--critical", o ambos, como tiempos, y los trabajos se
comprobado por fallas dentro de los períodos de tiempo especificados antes de la hora actual. Válido
las unidades son segundos, minutos, horas y días; todo se puede abreviar a la primera letra.
Si no se dan unidades, se suponen "segundos".

Ejemplo 1: Dar una crítica cuando fallaron los trabajos ejecutados en el último día.

check_postgres_pgagent_jobs --critical = 1d

Ejemplo 2: Dar una advertencia cuando fallan los trabajos ejecutados en la última semana.

check_postgres_pgagent_jobs --warning = 7d

Ejemplo 3: proporcione una crítica para los trabajos que han fallado en las últimas 2 horas y una advertencia para
trabajos que han fallado en las últimas 4 horas:

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

preparados_txns
("enlace simbólico: check_postgres_prepared_txns") Verifique la antigüedad de cualquier
actas. Tenga en cuenta que la mayoría de las personas NO utilizarán transacciones preparadas, ya que son parte
de compromiso de dos partes y complicado de mantener. Tampoco deben confundirse con
DECLARACIONES preparadas, que es lo que la mayoría de la gente piensa cuando escuchan prepararse. los
El valor predeterminado para una advertencia es 1 segundo, para detectar cualquier uso de transacciones preparadas, que
probablemente sea un error en la mayoría de los sistemas. Advertencia y crítica son la cantidad de segundos que un
la transacción preparada se ha abierto antes de que se emita una alerta.

Ejemplo 1: dar una advertencia sobre la detección de transacciones preparadas:

comprobar_postgres_prepared_txns -w 0

Ejemplo 2: Dé un valor crítico si alguna transacción preparada ha estado abierta por más de 10
segundos, pero espere hasta 360 segundos para la base de datos 'shrike':

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

Para la salida MRTG, devuelve el número de segundos que la transacción más antigua ha estado abierta como
primera línea, y de qué base de datos proviene como línea final.

query_runtime
("enlace simbólico: check_postgres_query_runtime") Comprueba cuánto tiempo tarda en ejecutarse una consulta específica,
ejecutando un "EXPLAIN ANALYZE" en su contra. los --advertencia y --crítico las opciones son las
cantidad máxima de tiempo que debe tardar la consulta. Las unidades válidas son segundos, minutos y horas;
any se puede abreviar a la primera letra. Si no se dan unidades, se suponen "segundos".
Deben darse tanto la advertencia como la opción crítica. El nombre de la vista o función
para ser ejecutado debe pasarse a la --nombre de consulta opción. Debe constar de una sola palabra
(o schema.word), con parens opcionales al final.

Ejemplo 1: proporcione un valor crítico si la función denominada "speedtest" no se ejecuta en 10 segundos o
Menos.

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

Para la salida MRTG, informa el tiempo en segundos para que la consulta se complete en la primera línea.
La cuarta línea enumera la base de datos.

Tiempo de consulta
("enlace simbólico: check_postgres_query_time") Comprueba la duración de las consultas en ejecución en una o más
bases de datos. No es necesario ejecutar esto más de una vez en el mismo clúster de base de datos. Nota
que esto ya excluye las consultas que están "inactivas en la transacción". Las bases de datos pueden ser
filtrado usando el --incluir y --excluir opciones. Consulte la sección "FILTRADO BÁSICO"
para más detalles. También puede filtrar por el usuario que ejecuta la consulta con el --incluir usuario
y --excluir usuario opciones. Consulte la sección "FILTRADO DE NOMBRE DE USUARIO" para obtener más detalles.

Los valores para el --advertencia y --crítico las opciones son cantidades de tiempo y el valor predeterminado es '2
minutos 'y' 5 minutos 'respectivamente. Las unidades válidas son 'segundos', 'minutos', 'horas' o
'dias'. Cada uno puede escribirse en singular o abreviado a la primera letra. Si no hay unidades
se dan, se supone que la unidad son segundos.

Esta acción requiere Postgres 8.1 o mejor.

Ejemplo 1: dar una advertencia si alguna consulta se ha estado ejecutando durante más de 3 minutos, y un
crítico si dura más de 5 minutos.

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

Ejemplo 2: utilizando valores predeterminados (2 y 5 minutos), verifique todas las bases de datos excepto aquellas
comenzando con 'plantilla'.

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

Ejemplo 3: advertir si el usuario 'don' tiene una consulta que dura más de 20 segundos

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

Para la salida MRTG, devuelve la longitud en segundos de la consulta de ejecución más larga en la primera
línea. La cuarta línea da el nombre de la base de datos.

replicar_fila
("enlace simbólico: check_postgres_replicate_row") Comprueba que la replicación maestro-esclavo esté funcionando
a uno o más esclavos.

Las primeras opciones "--dbname", "--host" y "--port", etc. se consideran maestras;
los usos posteriores son los esclavos. Los valores o el --advertencia y --crítico las opciones son
unidades de tiempo, y se debe proporcionar al menos una (sin valores predeterminados). Las unidades válidas son 'segundos',
'minutos', 'horas' o 'días'. Cada uno puede escribirse en singular o abreviado solo al
primera letra. Si no se dan unidades, se supone que las unidades son segundos.

Esta verificación actualiza una sola fila en el maestro y luego mide cuánto tiempo lleva ser
aplicado a los esclavos. Para hacer esto, debe elegir una tabla que se está replicando, luego
busque una fila que se pueda cambiar y que no vaya a ser modificada por ningún otro proceso. A
La columna específica de esta fila se cambiará de un valor a otro. Todo esto se alimenta
a la opción "repinfo", y debe contener las siguientes opciones, separadas por comas:
nombre de tabla, clave principal, ID de clave, columna, primer valor, segundo valor.

Ejemplo 1: Slony está replicando una tabla llamada 'pedidos' del host 'alpha' al host 'beta',
en la base de datos 'ventas'. La clave principal de la tabla se llama id, y vamos a
pruebe la fila con una identificación de 3 (que es histórica y nunca cambió). Hay una columna
llamado 'representante de ventas' que vamos a cambiar de un valor de 'slon' a 'nols' para verificar
la replicación. Queremos lanzar una advertencia si la replicación no ocurre dentro de 10
segundos.

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

Ejemplo 2: Bucardo está replicando una tabla llamada 'recibo' desde el host 'verde' a los hosts
'rojo', 'azul' y 'amarillo'. La base de datos de ambas partes es "pública". Las bases de datos esclavas
se están ejecutando en el puerto 5455. La clave principal se llama 'Receta_id', la fila que queremos usar
tiene un valor de 9 y la columna que queremos cambiar para la prueba se llama 'zona'. Bien
alternar entre 'norte' y 'sur' para el valor de esta columna, y lanzar una crítica si
el cambio no se aplica a los tres esclavos en 5 segundos.

check_postgres_replicate_row --host = verde --port = 5455 --host = rojo, azul, amarillo
--crítico = 5 --repinfo = recibo, recibo_id, 9, zona, norte, sur

Para la salida MRTG, devuelve en la primera línea el tiempo en segundos que tarda la replicación
terminar. El tiempo máximo se establece en 4 minutos y 30 segundos: si no se ha realizado ninguna replicación
lugar en ese largo tiempo, se lanza un error.

mismo_esquema
("enlace simbólico: check_postgres_same_schema") Verifica que dos o más bases de datos sean idénticas
en cuanto a su esquema (pero no a los datos que contiene). Esto es particularmente útil para hacer
asegúrese de que sus esclavos no hayan sido modificados o corrompidos de ninguna manera al usar maestro a esclavo
replicación. A diferencia de la mayoría de las otras acciones, esta no tiene ningún criterio crítico o de advertencia: el
las bases de datos están sincronizadas o no. Si son diferentes, una lista detallada de los
se presentan las diferencias.

Es posible que desee excluir o filtrar ciertas diferencias. La forma de hacer esto es agregar
cadenas a la opción "--filter". Para excluir un tipo de objeto, use "noname", donde 'nombre'
es el tipo de objeto, por ejemplo, "noschema". Para excluir objetos de cierto tipo mediante un
expresión regular contra su nombre, use "noname = regex". Consulte los ejemplos a continuación para
mejor entendimiento.

Los tipos de objetos que se pueden filtrar incluyen:

usuario
Esquema
mesa
view
índice
secuencia
restricción
detonante
función

La opción de filtro "sin posición" evita la verificación de la posición de las columnas dentro de un
mesa.

La opción de filtro "nofuncbody" evita la comparación de los cuerpos de todas las funciones.

La opción de filtro "noperm" evita la comparación de permisos de objetos.

Para proporcionar la segunda base de datos, simplemente agregue las diferencias a la primera mediante una llamada a
el argumento de conexión apropiado. Por ejemplo, para comparar bases de datos en hosts alfa y
bravo, use "--dbhost = alpha, bravo". También vea los ejemplos a continuación.

Si solo se proporciona un host, se asume que estamos haciendo un informe "basado en el tiempo". los
La primera vez que se ejecuta, se guarda una instantánea de todos los elementos de la base de datos en un local.
expediente. Cuando lo ejecuta de nuevo, esa instantánea se lee y se convierte en "base de datos n. ° 2" y se
en comparación con la base de datos actual.

Para reemplazar el archivo almacenado antiguo con la nueva versión, use el argumento --replace.

Para habilitar instantáneas en varios momentos, puede usar el argumento "--suffix" para hacer
los nombres de archivo únicos para cada ejecución. Vea los ejemplos a continuación.

Ejemplo 1: Verifique que dos bases de datos en los hosts, estrella y línea, sean iguales:

check_postgres_same_schema --dbhost = estrella, línea

Ejemplo 2: Igual que antes, pero excluye los desencadenantes con "slony" en su nombre.

check_postgres_same_schema --dbhost = estrella, línea --filter = "notrigger = slony"

Ejemplo 3: Igual que antes, pero también excluye todos los índices

check_postgres_same_schema --dbhost = estrella, línea --filter = "notrigger = slony noindexes"

Ejemplo 4: comprobar las diferencias de la base de datos "battlestar" en diferentes puertos

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

Ejemplo 5: crear un archivo de instantánea diaria y semanal

check_postgres_same_schema --dbname = cylon --suffix = diario
check_postgres_same_schema --dbname = cylon --suffix = semanal

Ejemplo 6: Ejecute una comparación histórica, luego reemplace el archivo

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

secuencia
("enlace simbólico: check_postgres_sequence") Comprueba cuánto espacio queda en todas las secuencias en el
base de datos. Esto se mide como el porcentaje del total de valores posibles que se han utilizado.
para cada secuencia. los --advertencia y --crítico las opciones deben expresarse como
porcentajes. Los valores predeterminados son 85% por la advertencia y 95% para los críticos. Puedes
use --include y --exclude para controlar qué secuencias se deben verificar. Tenga en cuenta que esto
el cheque tiene en cuenta lo inusual valor mínimo y incremento by valores, pero no le importa si el
la secuencia está configurada en ciclo o no.

La salida de Nagios da el nombre de la secuencia, el porcentaje utilizado y el número
de 'llamadas' a la izquierda, lo que indica cuántas veces más se puede llamar a nextval en esa secuencia
antes de alcanzar el valor máximo.

La salida de MRTG devuelve el porcentaje más alto en todas las secuencias en la primera línea,
y el nombre de cada secuencia con ese porcentaje en la cuarta línea, separados por un "|"
(tubería) si hay más de una secuencia en ese porcentaje.

Ejemplo 1: Dar una advertencia si alguna secuencia se acerca al 95% de su capacidad.

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

Ejemplo 2: Compruebe que la secuencia denominada "orders_id_seq" no tenga más de la mitad de su capacidad.

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

configuración_suma de comprobación
("enlace simbólico: check_postgres_settings_checksum") Comprueba que todas las configuraciones de Postgres son
lo mismo que la última vez que lo comprobó. Esto se hace generando una suma de comprobación de una lista ordenada.
de establecer nombres y sus valores. Tenga en cuenta que diferentes usuarios de la misma base de datos pueden tener
diferentes sumas de comprobación, debido al uso de ALTER USER, y debido al hecho de que los superusuarios ven más
configuraciones que los usuarios normales. O el --advertencia o el --crítico la opción debería ser
dado, pero no ambos. El valor de cada uno es la suma de comprobación, un hexadecimal de 32 caracteres.
valor. Puede ejecutar con la opción especial "--critical = 0" para averiguar un
suma de comprobación.

Esta acción requiere el módulo Digest :: MD5.

Ejemplo 1: busque la suma de comprobación inicial para la base de datos en el puerto 5555 utilizando el usuario predeterminado
(generalmente postgres)

check_postgres_settings_checksum --port = 5555 --critical = 0

Ejemplo 2: asegúrese de que no haya cambiado ninguna configuración y advierta si es así, utilizando la suma de comprobación de
anterior.

check_postgres_settings_checksum --port=5555 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Para la salida MRTG, devuelve un 1 o 0 que indica el éxito o el fracaso de la suma de comprobación para coincidir.
Se debe proporcionar una suma de comprobación como argumento "--mrtg". La cuarta línea siempre da la
suma de comprobación actual.

estado_slony
("enlace simbólico: check_postgres_slony_status") Comprueba el estado de un clúster Slony mediante
mirando los resultados de la vista sl_status de Slony. Esto se devuelve como el número de
segundos de "tiempo de retraso". los --advertencia y --crítico las opciones deben expresarse como tiempos.
Los valores predeterminados son 60 segundos por la advertencia y 300 segundos para los críticos.

El argumento opcional --esquema indicó el esquema bajo el que está instalado Slony. Si se
no se proporciona, el esquema se determinará automáticamente cada vez que se ejecute esta verificación.

Ejemplo 1: dar una advertencia si algún Slony se retrasa más de 20 segundos

check_postgres_slony_status - advertencia 20

Ejemplo 2: Dar un valor crítico si Slony, instalado bajo el esquema "_slony", tiene más de 10
minutos de retraso

check_postgres_slony_status --schema = _slony --critical = 600

Timesync
("enlace simbólico: check_postgres_timesync") Compara la hora del sistema local con la hora informada
por una o más bases de datos. los --advertencia y --crítico las opciones representan el número de
segundos entre los dos sistemas antes de que se emita una alerta. Si no se especifica ninguno, el
se utilizan los valores predeterminados, que son '2' y '5'. El valor de advertencia no puede ser mayor que
el valor crítico. Debido a la naturaleza no exacta de esta prueba, los valores de '0' o '1' no son
recomendado.

La cadena devuelta muestra la diferencia de tiempo, así como el tiempo en cada lado escrito
fuera.

Ejemplo 1: Compruebe que las bases de datos de los hosts ankh, morpork y klatch no superen los 3
segundos fuera de la hora local:

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

Para la salida MRTG, devuelve en la primera línea el número de segundos de diferencia entre el
la hora local y la hora de la base de datos. La cuarta línea devuelve el nombre de la base de datos.

txn_idle
("enlace simbólico: check_postgres_txn_idle") Comprueba el número y la duración de "inactivo en
transacciones "consultas en una o más bases de datos. No es necesario ejecutar esto más de una vez
en el mismo clúster de base de datos. Las bases de datos se pueden filtrar utilizando el --incluir y
--excluir opciones. Consulte la sección "FILTRADO BÁSICO" a continuación para obtener más detalles.

El sistema --advertencia y --crítico Las opciones se dan como unidades de tiempo, enteros con signo o
enteros para unidades de tiempo, y se deben proporcionar ambos (no hay valores predeterminados). Unidades válidas
son 'segundos', 'minutos', 'horas' o 'días'. Cada uno puede escribirse en singular o abreviado
a solo la primera letra. Si no se dan unidades y los números no están firmados, las unidades
se supone que son segundos.

Esta acción requiere Postgres 8.3 o mejor.

Ejemplo 1: dar una advertencia si alguna conexión ha estado inactiva en la transacción durante más de 15
segundos:

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

Ejemplo 2: dar una advertencia si hay 50 transacciones o más

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

Ejemplo 3: Dar un valor crítico si 5 o más conexiones han estado inactivas en la transacción durante más
de 10 segundos:

check_postgres_txn_idle --port = 5432 --critical = '5 por 10 segundos'

Para la salida MRTG, devuelve el tiempo en segundos en que se ha realizado la transacción inactiva más larga.
corriendo. La cuarta línea devuelve el nombre de la base de datos y otra información sobre la
transacción más larga.

hora_txn
("enlace simbólico: check_postgres_txn_time") Comprueba la duración de las transacciones abiertas en una o más
bases de datos. No es necesario ejecutar este comando más de una vez por clúster de base de datos.
Las bases de datos se pueden filtrar mediante el uso de --incluir y --excluir opciones. Consulte el "BÁSICO
"FILTRADO" para obtener más detalles. El propietario de la transacción también se puede filtrar, por
el uso de la --incluir usuario y --excluir usuario opciones. Consulte la sección "FILTRADO DE NOMBRE DE USUARIO"
para obtener más información.

Los valores o el --advertencia y --crítico las opciones son unidades de tiempo y deben proporcionarse
(ningún valor predeterminado). Las unidades válidas son 'segundos', 'minutos', 'horas' o 'días'. Cada uno puede ser
escrito en singular o abreviado a la primera letra. Si no se dan unidades, el
se supone que las unidades son segundos.

Esta acción requiere Postgres 8.3 o mejor.

Ejemplo 1: Dar una crítica si alguna transacción ha estado abierta por más de 10 minutos:

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

Ejemplo 1: advertir si el usuario 'almacén' tiene una transacción abierta durante 30 segundos

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

Para la salida MRTG, devuelve el tiempo máximo en segundos que una transacción ha estado abierta en el
primera linea. La cuarta línea da el nombre de la base de datos.

txn_envolvente
("enlace simbólico: check_postgres_txn_wraparound") Comprueba qué tan cerca de la transacción envuelve una
o se están obteniendo más bases de datos. los --advertencia y --crítico las opciones indican el número
de transacciones realizadas y debe ser un número entero positivo. Si no se da ninguna de las opciones,
Se utilizan valores predeterminados de 1.3 y 1.4 mil millones. No es necesario ejecutar este comando más
de una vez por clúster de base de datos. Para una discusión más detallada de lo que este número
representa y qué hacer al respecto, visite la página
<http://www.postgresql.org/docs/current/static/routine-vacuuming.html# VACÍO PARA ENVOLVER>

Los valores críticos y de advertencia pueden tener guiones bajos en el número para facilitar la legibilidad, como Perl
hace.

Ejemplo 1: verifique los valores predeterminados para la base de datos localhost

check_postgres_txn_wraparound --host = localhost

Ejemplo 2: Verifique el puerto 6000 y dé un valor crítico cuando se realicen 1.7 mil millones de transacciones:

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

Para la salida MRTG, devuelve el mayor número de transacciones para todas las bases de datos en la línea uno,
mientras que la línea 4 indica qué base de datos es.

versión
("enlace simbólico: check_postgres_version") Comprueba que la versión requerida de Postgres es
corriendo. El --advertencia y --crítico Las opciones (solo se requiere una) deben tener el formato
Xy or XYZ donde X es el número de versión principal, Y es el número de versión menor, y Z is
la revisión.

Ejemplo 1: Dar una advertencia si la base de datos en el puerto 5678 no es la versión 8.4.10:

check_postgres_version --port = 5678 -w = 8.4.10

Ejemplo 2: Dar una advertencia si alguna de las bases de datos de hosts valley, grain o sunshine no es 8.3:

check_postgres_version -H valle, grano, sol --crítico = 8.3

Para la salida MRTG, informa un 1 o un 0 que indica éxito o fracaso en la primera línea. los
la cuarta línea indica la versión actual. La versión debe proporcionarse a través de "--mrtg"
.

archivos_wal
("enlace simbólico: check_postgres_wal_files") Comprueba cuántos archivos WAL existen en el pg_xlog
directorio, que se encuentra fuera de su directorio de datos, a veces como enlace simbólico a otro
disco físico por motivos de rendimiento. Esta acción debe ejecutarse como superusuario para poder
acceder a los contenidos de la pg_xlog directorio. La versión mínima para usar esta acción es
Postgres 8.1. los --advertencia y --crítico Las opciones son simplemente el número de archivos en el
pg_xlog directorio. El número para establecer esto variará, pero una pauta general es poner
un número un poco más alto de lo que normalmente está allí, para detectar problemas temprano.

Normalmente, los archivos WAL se cierran y luego se reutilizan, pero una transacción abierta de larga duración o una
defectuoso comando_archivo script, puede hacer que Postgres cree demasiados archivos. Por último,
esto hará que el disco en el que se encuentran se quede sin espacio, momento en el que Postgres
apagar.

Ejemplo 1: Verifique que el número de archivos WAL sea 20 o menos en el host "pluto"

check_postgres_wal_files --host = plutón --critical = 20

Para la salida MRTG, informa el número de archivos WAL en la línea 1.

reconstruir_enlaces simbólicos
reconstruir_enlaces_simbólicos_fuerza
Esta acción no requiere otros argumentos y no se conecta a ninguna base de datos, simplemente
crea enlaces simbólicos en el directorio actual para cada acción, en la forma
check_postgres_. Si el archivo ya existe, no se sobrescribirá. Si
la acción es rebuild_symlinks_force, entonces los enlaces simbólicos se sobrescribirán. La opción
--symlinks es una forma más corta de decir --action = rebuild_symlinks

ED. BÁSICA Filtrado

Las opciones --incluir y --excluir se puede combinar para limitar las cosas que se comprueban,
dependiendo de la acción. El nombre de la base de datos se puede filtrar cuando se utiliza lo siguiente
acciones: backends, database_size, locks, query_time, txn_idle y txn_time. El nombre de
una relación se puede filtrar cuando se utilizan las siguientes acciones: hinchar, index_size,
table_size, ratio_size, last_vacuum, last_autovacuum, last_analyze y
last_autoanalyze. El nombre de una configuración se puede filtrar cuando se usa settings_checksum
acción. El nombre de un sistema de archivos se puede filtrar cuando se usa la acción disk_space.

Si solo se proporciona una opción de inclusión, SOLO se marcarán las entradas que coincidan.
Sin embargo, si se dan tanto excluir como incluir, la exclusión se realiza primero y la inclusión
después, para restablecer las cosas que pudieron haber sido excluidas. Ambos --incluir y --excluir can
darse varias veces y / o como listas separadas por comas. Una tilde inicial coincidirá con el
la siguiente palabra como expresión regular.

Para hacer coincidir un esquema, finalice el término de búsqueda con un solo punto. Se pueden utilizar tildes iniciales
también para esquemas.

Tenga cuidado al usar el filtrado: una regla de inclusión en los backends, por ejemplo, puede
informar que no hay problemas no solo porque la base de datos coincidente no tenía backends, sino porque
escribió mal el nombre de la base de datos!

Ejemplos:

Solo comprueba los elementos denominados pg_class:

--include = pg_class

Solo verifica los elementos que contienen las letras 'pg_':

--include = ~ pg_

Compruebe solo los elementos que comienzan con 'pg_':

--incluir = ~ ^ pg_

Excluya el elemento denominado 'prueba':

--exclude = prueba

Excluya todos los elementos que contengan la prueba de letras:

--exclude = ~ prueba

Excluya todos los elementos del esquema 'pg_catalog':

--exclude = 'pg_catalog.'

Excluya todos los elementos que contengan las letras 'as', pero permita el elemento 'enfrentamiento':

--exclude = ~ ace --include = cara a cara

Excluya todos los elementos que comiencen con las letras 'pg_', que contengan las letras 'slon', o
que se denominan 'sql_settings' o 'green'. Verifique específicamente los artículos con las letras
'prod' en sus nombres, y siempre marque el elemento llamado 'pg_relname':

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

USUARIO NOMBRE Filtrado

Las opciones --incluir usuario y --excluir usuario se puede utilizar en algunas acciones para examinar únicamente
objetos de base de datos que pertenecen (o no) a uno o más usuarios. Un --incluir usuario opción
siempre triunfa sobre un --excluir usuario opción. Puede dar cada opción más de una vez por
varios usuarios, o puede dar una lista separada por comas. Las acciones que utilizan actualmente
estas opciones son:

tamaño_base_datos
último_análisis
último_análisis automático
último_vacío
último_autovacío
Tiempo de consulta
tamaño_relación
hora_txn

Ejemplos:

Verifique solo los elementos que son propiedad del usuario llamado greg:

--includeuser = greg

Verifique solo los artículos que sean propiedad de Watson o Crick:

--includeuser = watson, crick

Compruebe únicamente los artículos que sean propiedad de crick, franklin, watson o wilkins:

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

Marque todos los elementos excepto los que pertenecen al usuario scott:

--excludeuser = scott

PROBAR MODO

Para ayudar a configurar las cosas, este programa se puede ejecutar en un "modo de prueba" especificando el
--prueba opción. Esto realizará algunas pruebas básicas para asegurarse de que las bases de datos se puedan
contactado, y que se cumplen ciertos requisitos previos por acción, como si el usuario es
un superusuario, si la versión de Postgres es lo suficientemente nueva y si stats_row_level está habilitado.

Use check_postgres_query_runtimep en línea usando los servicios de onworks.net