check_postgres_sequencep - Online nel cloud

PROGRAMMA:

NOME

check_postgres - uno script di monitoraggio Postgres per Nagios, MRTG, Cacti e altri

Questo documento descrive check_postgres versione 2.22.0

SINOSSI

## Crea tutti i collegamenti simbolici
check_postgres --link simbolici

## Controlla la connessione al database Postgres 'pluto':
check_postgres --action=connessione --db=pluto

## Stesse cose, ma usando il collegamento simbolico
check_postgres_connection --db=pluto

## Avvisa se > 100 blocchi, critico se > 200 o > 20 esclusivi
check_postgres_locks --warning=100 --critical="total=200:exclusive=20"

## Mostra il numero corrente di connessioni inattive sulla porta 6543:
check_postgres_txn_idle --port=6543 --output=semplice

## Ci sono molte altre azioni e opzioni, continua a leggere.

Le ultime notizie e la documentazione sono sempre disponibili su:
http://bucardo.org/check_postgres/

DESCRIZIONE

check_postgres è uno script Perl che esegue molti test diversi contro uno o più
Database Postgres. Utilizza il programma psql per raccogliere le informazioni e genera il file
risultati in uno dei tre formati: Nagios, MRTG o semplice.

Uscita Modalità
L'output può essere modificato utilizzando l'opzione "--output". L'output predefinito è nagios,
anche se questo può essere modificato nella parte superiore dello script, se lo desideri. L'opzione attuale
le scelte sono nagios, sige semplice. Per evitare di dover inserire l'argomento di output ciascuno
time, il tipo di output viene impostato automaticamente se non viene fornito alcun argomento --output e se
la directory corrente ha una delle opzioni di output nel suo nome. Ad esempio, creando un
directory denominata mrtg e popolandola con collegamenti simbolici tramite il --link simbolici argomento sarebbe
assicurati che qualsiasi azione eseguita da quella directory sarà sempre predefinita su un output di "mrtg"
Come scorciatoia per --output=simple, puoi inserire --simple, che sovrascrive anche il
trucco di denominazione delle directory.

Nagios produzione

Il formato di output predefinito è per Nagios, che è una singola riga di informazioni, insieme a
quattro codici di uscita specifici:

0 (va bene)
1 (ATTENZIONE)
2 (CRITICO)
3 (SCONOSCIUTO)

La riga di output è una delle parole sopra, due punti e quindi una breve descrizione di cosa
era misurato. Ulteriori informazioni statistiche, nonché il tempo totale del comando
preso, può anche essere restituito: vedere la documentazione sugli argomenti --showperf,
--perflimite --orario dello spettacolo.

MRTG produzione

L'uscita MRTG è di quattro righe, con la prima riga che fornisce sempre un solo numero di
importanza. Quando possibile, questo numero rappresenta un valore effettivo come un numero di
byte, ma può anche essere un 1 o uno 0 per le azioni che restituiscono solo "vero" o "falso", come
come check_postgres_version. La seconda riga è una statistica aggiuntiva e viene utilizzata solo per
alcune azioni. La terza riga indica un "tempo di attività" e non viene utilizzata. La quarta riga è a
descrizione e di solito indica il nome del database la statistica dalla prima riga
è stato estratto, ma potrebbe essere diverso a seconda dell'azione.

Alcune azioni accettano un optional --mrtg argomento per controllare ulteriormente l'output.

Consultare la documentazione su ciascuna azione per i dettagli sull'output esatto di MRTG per ciascuna di esse.

Un'espansione produzione

L'output semplice è semplicemente una versione troncata di quella MRTG e restituisce semplicemente il
primo numero e nient'altro. Questo è molto utile quando vuoi solo controllare lo stato
di qualcosa, indipendentemente da qualsiasi soglia. È possibile trasformare l'output numerico di
aggiungendo KB, MB, GB, TB o EB all'argomento di output, ad esempio:

--output=semplice,MB

cactus produzione

L'output Cacti è costituito da uno o più elementi sulla stessa riga, con un nome semplice, a
due punti e poi un numero. Al momento, l'unica azione con output esplicito di cactus è
'dbstats' e in questo caso non è necessario utilizzare l'opzione --output, poiché Cacti è l'unico
output per questa azione. Per molte altre azioni, l'uso di --simple è sufficiente per creare Cacti
felice.

DATABASE COLLEGAMENTO VERSIONI

Tutte le azioni accettano un insieme comune di opzioni del database.

-H NOME or --host=NOME
Connettiti all'host indicato da NAME. Può essere un elenco di nomi separati da virgole.
Sono consentiti più argomenti dell'host. Se non viene fornito alcun host, il valore predefinito è "PGHOST"
variabile di ambiente o nessun host (che indica l'utilizzo di un socket Unix locale).
Puoi anche usare "--dbhost".

-p PORT or --port=PORTA
Si connette utilizzando il numero PORT specificato. Può essere un elenco di porte separato da virgole
sono consentiti numeri e più argomenti di porta. Se non viene fornito alcun numero di porta, il valore predefinito
alla variabile d'ambiente "PGPORT". Se non è impostato, il valore predefinito è 5432. Potresti
usa anche "--dbport"

-Db NOME or --dbname=NOME
Specifica a quale database connettersi. Può essere un elenco di nomi separati da virgole e
sono consentiti più argomenti dbname. Se non viene fornita alcuna opzione dbname, il valore predefinito è
la variabile di ambiente "PGDATABASE". Se non è impostato, il valore predefinito è "postgres"
se psql è la versione 8 o successiva e 'template1' in caso contrario.

-u USERNAME or --dbuser=NOMEUTENTE
Il nome dell'utente del database a cui connettersi. Può essere un elenco separato da virgole di
sono consentiti nomi utente e più argomenti dbuser. Se questo non è fornito, è
il valore predefinito è la variabile di ambiente "PGUSER", altrimenti il ​​valore predefinito è "postgres".

--dbpass=PASSWORD
Fornisce la password con cui connettersi al database. L'uso di questa opzione è altamente
scoraggiato. Invece, si dovrebbe usare un file .pgpass o pg_service.conf.

--dbservice=NOME
Il nome di un servizio all'interno del file pg_service.conf. Prima della versione 9.0 di
Postgres, questo è un file globale, solitamente trovato in /etc/pg_service.conf. Se sei
usando la versione 9.0 o successiva di Postgres, puoi usare il file ".pg_service.conf" in
la directory home dell'utente che esegue lo script, ad esempio nagios.

Questo file contiene un semplice elenco di opzioni di connessione. Puoi anche passare in più
informazioni quando si utilizza questa opzione come --dbservice="maindatabase sslmode=require"

La documentazione per questo file può essere trovata all'indirizzo
http://www.postgresql.org/docs/current/static/libpq-pgservice.html

Le opzioni di connessione al database possono essere raggruppate: --host=a,b --host=c --porta=1234
--porta=3344 si collegherebbe a a-1234, b-1234 e c-3344. Nota che una volta impostato, un'opzione
continua fino a quando non viene cambiato di nuovo.

Consigli d'uso:

--host=a,b --port=5433 --db=c
Si connette due volte alla porta 5433, utilizzando il database c, agli host a e b: a-5433-c b-5433-c

--host=a,b --port=5433 --db=c,d
Collega quattro volte: a-5433-c a-5433-d b-5433-c b-5433-d

--host=a,b --host=pippo --port=1234 --port=5433 --db=e,f
Collega sei volte: 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
Si collega tre volte: a-5432-alice-baz b-5433-alice-baz x-5433-bob-baz

--dbservice="pippo" --port=5433
Si connette utilizzando il servizio denominato 'foo' nel file pg_service.conf, ma sovrascrive la porta

ALTRO VERSIONI

Altre opzioni includono:

--action=NOME
Indica quale azione stiamo eseguendo. Richiesto a meno che non si utilizzi un file con collegamento simbolico, in cui
caso il nome del file viene utilizzato per capire l'azione.

--avviso=VAL or -w VAL
Imposta la soglia alla quale viene generato un avviso di avviso. Le opzioni valide per questo
L'opzione dipende dall'azione utilizzata.

--critico=VAL or -c VAL
Imposta la soglia alla quale viene generato un avviso critico. Le opzioni valide per questo
L'opzione dipende dall'azione utilizzata.

-t VAL or --timeout=VAL
Imposta il timeout in secondi dopo il quale lo script interromperà qualsiasi cosa stia facendo e
restituire uno stato SCONOSCIUTO. Il timeout è per cluster Postgres, non per l'intero
sceneggiatura. Il valore predefinito è 10; le unità sono sempre in secondi.

--assumere-modalità standby
Se specificato, prima verrà eseguito il controllo se il server in modalità standby verrà eseguito (--datadir
è richiesto), in tal caso, tutti i controlli che richiedono query SQL verranno ignorati e "Server
in modalità standby" con lo stato OK verrà invece restituito.

Esempio:

postgres@db$./check_postgres --action=version --warning=8.1 --datadir /var/lib/postgresql/8.3/main/ --assume-standby-mode
POSTGRES_VERSION OK: Server in modalità standby | tempo=0.00

--assumere-prod
Se specificato, controlla se il server è in modalità produzione (è richiesto --datadir).
L'opzione è rilevante solo per ("symlink: check_postgres_checkpoint").

Esempio:

postgres@db$./check_postgres --action=checkpoint --datadir /var/lib/postgresql/8.3/main/ --assume-prod
POSTGRES_CHECKPOINT OK: l'ultimo checkpoint è stato 72 secondi fa | età=72;;300 modalità=MASTER

-h or --Aiuto
Visualizza una schermata di aiuto con un riepilogo di tutte le azioni e opzioni.

--uomo
Visualizza l'intero manuale.

-V or --versione
Mostra la versione corrente.

-v or --verboso
Imposta il livello di verbosità. Può chiamare più di una volta per aumentare il livello. Impostandolo su
tre o più (in altre parole, l'emissione di "-v -v -v") attiva le informazioni di debug
per questo programma che viene inviato a stderr.

--showperf=VAL
Determina se emettiamo dati sulle prestazioni aggiuntivi nel formato Nagios standard (alla fine
di stringa, dopo un simbolo di pipe, utilizzando nome=valore). VAL dovrebbe essere 0 o 1. Il valore predefinito
è 1. Ha effetto solo se si utilizza la modalità di output Nagios.

--perflimit=i
Imposta un limite al numero di elementi di interesse segnalati quando si utilizza il
spettacolo opzione. Questo ha effetto solo per le azioni che restituiscono un numero elevato di
oggetti, come Dimensioni della tavola. Il valore predefinito è 0 o nessun limite. Fai attenzione quando lo usi
con la --includere or --escludere opzioni, poiché tali restrizioni sono state applicate dopo , il
la query è stata eseguita e quindi il tuo limite potrebbe non includere gli elementi desiderati. prende solo
effetto se si utilizza la modalità di uscita Nagios.

--showtime=VAL
Determina se il tempo impiegato per eseguire ogni query è mostrato nell'output. VAL dovrebbe essere 0
oppure 1. Il valore predefinito è 1. Nessun effetto a meno che spettacolo è acceso. Ha effetto solo se si utilizza
Modalità di uscita Nagios.

--test
Abilita la modalità di prova. Vedere la sezione "MODALITÀ DI PROVA" di seguito.

--PGBINDIR=PERCORSO
Indica allo script dove trovare i binari psql. Utile se ne hai più di uno
versione degli eseguibili PostgreSQL sul tuo sistema, o se non ci sono nel tuo
il percorso. Nota che questa opzione è tutta maiuscola. Per impostazione predefinita, questa opzione è non
permesso. Per abilitarlo, devi cambiare $NO_PSQL_OPTION nella parte superiore dello script
a 0. Evita di usare questa opzione se puoi, e usa invece la variabile d'ambiente
C o variabile $PGBINDIR codificata, anche nella parte superiore dello script, da impostare
il percorso del PostgreSQL da utilizzare.

--PSQL=PERCORSO
(deprecato, questo opzione può be rimosso in a futuro pubblicazione!) Dice allo script dove
per trovare il programma psql. Utile se hai più di una versione di psql
eseguibile sul tuo sistema o se non è presente alcun programma psql nel tuo percorso. Nota che questo
l'opzione è tutta maiuscola. Per impostazione predefinita, questa opzione è non permesso. Per abilitarlo, tu
deve cambiare $NO_PSQL_OPTION vicino alla parte superiore dello script in 0. Evita di usarlo
opzione se puoi, e invece codifica la tua posizione psql nella variabile $ PSQL,
anche vicino alla parte superiore dello script.

--link simbolici
Crea collegamenti simbolici al programma principale per ogni azione.

--uscita=VAL
Determina il formato dell'output, da utilizzare in vari programmi. L'impostazione predefinita è
'nagio'. Le opzioni disponibili sono "nagios", "mrtg", "semplice" e "cacti".

--mrtg=VAL
Utilizzato solo per MRTG o uscita semplice, per alcune azioni specifiche.

--debugoutput=VAL
Restituisce la stringa esatta restituita da psql, da utilizzare nel debug. Il valore è uno o
più lettere, che determinano se l'output viene visualizzato o meno, dove 'a' = all, 'c'
= critico, 'w' = avviso, 'o' = ok e 'u' = sconosciuto. Le lettere possono essere combinate.

--get_metodo=VAL
Consente di specificare il metodo utilizzato per recuperare le informazioni per "new_version_cp",
"new_version_pg", "new_version_bc", "new_version_box" e "new_version_tnm".
Si tentano, nell'ordine, i seguenti programmi per prelevare le informazioni dal web: GET,
wget, fetch, curl, lynx, links. Per forzare l'uso di uno solo (e quindi rimuovere il
sovraccarico di provare tutti gli altri fino a quando uno di questi funziona), inserisci uno dei nomi come
l'argomento per get_method. Ad esempio, una casella BSD potrebbe inserire la seguente riga in
il loro file ".check_postgresrc":

get_method=preleva

--lingua=VAL
Imposta la lingua da utilizzare per tutti i messaggi di output. Normalmente, questo viene rilevato da
esaminando le variabili d'ambiente LC_ALL, LC_MESSAGES e LANG, ma impostando questo
l'opzione sovrascriverà qualsiasi rilevamento di questo tipo.

AZIONI

Lo script esegue una o più azioni. Questo può essere fatto con il flag --action o con
utilizzando un collegamento simbolico al file principale che contiene il nome dell'azione al suo interno. Per
esempio, per eseguire l'azione "timesync", puoi emettere:

check_postgres --action=timesync

oppure usa un programma chiamato:

check_postgres_timesync

Tutti i link simbolici sono creati per te nella directory corrente se usi l'opzione --symlinks

perl check_postgres --link simbolici

Se il nome del file esiste già, non verrà sovrascritto. Se il file esiste ed è a
symlink, puoi forzarne la sovrascrittura usando "--action=build_symlinks_force"

La maggior parte delle azioni prende a --avvertimento e --critico opzione, indicando a che punto si cambia
da OK a AVVISO, e fino a che punto andiamo a CRITICO. Si noti che poiché le critiche sono
sempre controllato per primo, impostare l'avviso uguale al critico è un modo efficace per
disattivare gli avvisi e dare sempre un critico.

Le azioni attualmente supportate sono:

archivio_pronto
("symlink: check_postgres_archive_ready") Controlla quanti file WAL con estensione .pronto
esistere nel pg_xlog/stato_archivio directory, che si trova fuori dal tuo directory_dati.
Questa azione deve essere eseguita come superutente, per poter accedere ai contenuti del
pg_xlog/stato_archivio directory. La versione minima per utilizzare questa azione è Postgres 8.1.
I --avvertimento ed --critico le opzioni sono semplicemente il numero di .pronto file in
pg_xlog/stato_archivio directory. Solitamente questi valori dovrebbero essere bassi, accendendo il
meccanismo di archiviazione, di solito vogliamo che archivi i file WAL il più velocemente possibile.

Se il comando di archiviazione fallisce, il numero di WAL nel tuo pg_xlog directory crescerà fino a
esaurire tutto lo spazio su disco e forzare l'arresto immediato di PostgreSQL.

Esempio 1: verificare che il numero di file WAL pronti sia 10 o meno sull'host "pluto"

check_postgres_archive_ready --host=pluto --critical=10

Per l'output MRTG, riporta il numero di file WAL pronti sulla riga 1.

autovac_freeze
("symlink: check_postgres_autovac_freeze") Controlla quanto è vicino ogni database al
Postgres autovacuum_freeze_max_age collocamento. Questa azione funzionerà solo per i database
versione 8.2 o successiva. Il --avvertimento ed --critico le opzioni dovrebbero essere espresse come
percentuali. L'"età" delle transazioni in ciascun database viene confrontata con la
impostazione autovacuum_freeze_max_age (200 milioni per impostazione predefinita) per generare un arrotondamento
percentuale. I valori predefiniti sono 90% per l'avvertimento e 95% per il critico. Banche dati
può essere filtrato mediante l'uso del --includere ed --escludere opzioni. Vedi il "FILTRO DI BASE"
.

Esempio 1: fornire un avviso quando i database sulla porta 5432 sono superiori al 97%

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

Per la produzione MRTG, nella prima riga è riportata la percentuale complessiva più elevata e
l'età più alta è riportata sulla seconda riga. Tutti i database che hanno la percentuale da
la prima riga è riportata sulla quarta riga, separate da un simbolo di pipe.

backend
("symlink: check_postgres_backends") Controlla il numero corrente di connessioni per uno o
più database, e facoltativamente lo confronta con il massimo consentito, che è determinato da
la variabile di configurazione Postgres max_connections. --avvertimento ed --critico Opzioni
può assumere una delle tre forme. In primo luogo, si può dare un numero semplice, che rappresenta la
numero di connessioni a cui verrà dato l'avviso. Questa scelta non utilizza il
max_connections collocamento. In secondo luogo, può essere indicata la percentuale di connessioni disponibili.
Terzo, si può dare un numero negativo che rappresenta il numero di connessioni rimaste
fino a quando max_connections è raggiunto. I valori predefiniti per --avvertimento ed --critico sono
'90%' e '95%'. Puoi anche filtrare i database utilizzando il --includere ed --escludere
opzioni. Vedere la sezione "FILTRAGGIO DI BASE" per maggiori dettagli.

Per visualizzare solo i processi non inattivi, puoi utilizzare il pulsante --noidle discussione. Si noti che l'utente si
si stanno connettendo in quanto deve essere un superutente affinché funzioni correttamente.

Esempio 1: fornire un avviso quando il numero di connessioni su host quirm raggiunge 120 e a
critico se raggiunge 150.

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

Esempio 2: fornire un valore critico quando raggiungiamo il 75% della nostra impostazione max_connections sugli host
lancre o lancre2.

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

Esempio 3: inviare un avviso quando sono rimasti solo 10 slot di connessione in più sull'host
plasmide, e un critico quando ne rimangono solo 5.

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

Esempio 4: controlla tutti i database tranne quelli con "test" nel nome, ma consenti quelli che
sono denominati "pg_greatest". Connetti come porta 5432 sui primi due host e come porta 5433 su
il terzo. Vogliamo lanciare sempre un critico quando raggiungiamo 30 o più connessioni.

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

Per l'uscita MRTG, il numero di connessioni è riportato sulla prima riga e sulla quarta
line fornisce il nome del database, più le connessioni_massime correnti. Se più di
è stato interrogato un database, viene emesso quello con il maggior numero di connessioni.

gonfiare
("symlink: check_postgres_bloat") Controlla la quantità di bloat nelle tabelle e negli indici. (Gonfiare
è generalmente la quantità di spazio morto inutilizzato occupato in una tabella o in un indice. Questo spazio è
solitamente recuperato mediante l'uso del comando VACUUM.) Questa azione richiede che stats
la raccolta sia abilitata sui database di destinazione e richiede l'esecuzione di ANALISI
frequentemente. Il --includere ed --escludere le opzioni possono essere utilizzate per filtrare le tabelle da
guarda a. Vedere la sezione "FILTRAGGIO DI BASE" per maggiori dettagli.

I --avvertimento ed --critico le opzioni possono essere specificate come dimensioni, percentuali o entrambi. Valido
le unità di dimensione sono byte, kilobyte, megabyte, gigabyte, terabyte, exabyte, petabyte e
zettabyte. Puoi abbreviare tutti quelli con la prima lettera. Gli articoli senza unità sono
si presume che siano "byte". I valori predefiniti sono "1 GB" e "5 GB". Il valore rappresenta il
numero di "byte sprecati", ovvero la differenza tra quanto effettivamente utilizzato dalla tabella e
indice e cosa calcoliamo che dovrebbe essere.

Nota che questa azione ha due valori codificati per evitare falsi allarmi su piccoli
relazioni. Le tabelle devono avere almeno 10 pagine e indici almeno 15, prima di poter essere
considerato da questo test. Se vuoi davvero regolare questi valori, puoi cercare il
variabili $MINPAGINE ed $MINIPAGINE nella parte superiore della subroutine "check_bloat". Queste
i valori vengono ignorati se entrambi --escludere or --includere viene utilizzato.

Vengono mostrate solo le prime 10 relazioni più gonfie. È possibile modificare questo numero utilizzando il
--perflimit opzione per impostare il proprio limite.

Lo schema denominato 'information_schema' è escluso da questo test, in quanto le uniche tabelle che esso
contiene sono piccoli e non cambiano.

Si prega di notare che i valori calcolati da questa azione non sono precisi e dovrebbero essere usati come
solo una linea guida. È stato fatto un grande sforzo per stimare la dimensione corretta di un tavolo, ma in
alla fine è solo una stima. La dimensione dell'indice corretta è ancora più un'ipotesi di quella
dimensione corretta del tavolo, ma entrambi dovrebbero dare un'idea approssimativa di quanto siano gonfie le cose.

Esempio 1: Avvisa se una tabella sulla porta 5432 è gonfia di oltre 100 MB e critica se supera i 200
MB

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

Esempio 2: fornire un valore critico se la tabella "ordini" sull'host "sami" ha più di 10 mega di ingombro

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

Esempio 3: fornire un valore critico se la tabella "q4" sul database "vendite" è gonfiata di oltre il 50%

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

Esempio 4: dare un valore critico a qualsiasi tabella è gonfiata di oltre il 20% ed ha oltre 150 MB di rigonfiamento:

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

Esempio 5: dare un valore critico a qualsiasi tabella è gonfiata di oltre il 40% or ha oltre 500 MB di rigonfiamento:

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

Per l'output MRTG, la prima riga fornisce il maggior numero di byte sprecati per le tabelle,
e la seconda riga fornisce il maggior numero di byte sprecati per gli indici. Il quarto
line fornisce il nome del database, il nome della tabella e le informazioni sul nome dell'indice. Se lo desidera
emette invece il rapporto di bloat (quante volte maggiore è la relazione rispetto a come
grande dovrebbe essere), basta passare "--mrtg=ratio".

posto di controllo
("symlink: check_postgres_checkpoint") Determina quanto tempo è trascorso dall'ultimo checkpoint
stato eseguito. Questo deve essere eseguito sullo stesso server del database che viene controllato (es
-h flag non funzionerà). Questo controllo è pensato per essere eseguito su un server "warm standby" che è
elabora attivamente i file WAL spediti e ha lo scopo di verificare che il tuo warm standby sia
veramente "caldo". La directory dei dati deve essere impostata, o dalla variabile d'ambiente
"PGDATA", o passando l'argomento "--datadir". Restituisce il numero di secondi trascorsi dal
è stato eseguito l'ultimo checkpoint, come determinato dall'analisi della chiamata a "pg_controldata". Per colpa di
questo, l'eseguibile pg_controldata deve essere disponibile nel percorso corrente. In alternativa,
è possibile specificare "PGBINDIR" come directory in cui risiede. È anche possibile utilizzare
le opzioni speciali --assumere-prod or --assumere-modalità standby, se la modalità trovata non è la
uno previsto, viene emesso un CRITICAL.

È necessario impostare almeno un avviso o un argomento critico.

Questa azione richiede il modulo Date::Parse.

Per MRTG o output semplice, restituisce il numero di secondi.

id_cluster
("symlink: check_postgres_cluster-id") Verifica che l'identificatore di sistema del database fornito
di pg_controldata è lo stesso dell'ultima volta che hai controllato. Questo deve essere eseguito sullo stesso server
come il database che viene controllato (es. il flag -h non funzionerà). o il
--avvertimento oppure --critico l'opzione dovrebbe essere data, ma non entrambe. Il valore di ognuno è
l'identificatore del cluster, un valore intero. Puoi eseguire con lo speciale "--critical=0"
opzione per scoprire un identificatore di cluster esistente.

Esempio 1: Trova l'identificatore iniziale

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

Esempio 2: assicurarsi che il cluster sia lo stesso e avvisare in caso contrario, utilizzando il risultato dall'alto.

check_postgres_cluster_id --critical=5633695740047915135

Per l'output MRTG, restituisce 1 o 0 che indica il successo o il fallimento dell'identificatore a
incontro. Un identificatore deve essere fornito come argomento "--mrtg". La quarta riga sempre
fornisce l'identificatore corrente.

impegno
("symlink: check_postgres_commitratio") Controlla il rapporto di commit di tutti i database e
si lamenta quando sono troppo bassi. Non è necessario eseguire questo comando più di una volta per
cluster di banche dati. I database possono essere filtrati con il --includere ed --escludere opzioni. Vedere
la sezione "FILTRAGGIO DI BASE" per maggiori dettagli. Possono anche essere filtrati dal proprietario di
il database con il --includeutente ed --excludeutente opzioni. Vedi il "NOME UTENTE
FILTRO" per maggiori dettagli.

Le opzioni di avviso e critiche devono essere specificate come percentuali. Non ci sono
valori predefiniti per questa azione: è necessario specificare l'avviso e il critico. Il valore di avvertimento
non può essere maggiore del valore critico. L'output restituisce tutti i database ordinati per
commitratio, il più piccolo per primo.

Esempio: Avvisa se un database su host flagg è inferiore al 90% in commitratio e critico
se inferiore all'80%.

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

Per l'output MRTG, restituisce la percentuale del database con il commitratio più piccolo su
la prima riga e il nome del database sulla quarta riga.

veloce
("symlink: check_postgres_connection") Si connette semplicemente, emette un 'SELECT versione()', e
fogliame. non ci vuole --avvertimento or --critico opzioni.

Per l'uscita MRTG, emette semplicemente un 1 (buona connessione) o uno 0 (cattiva connessione) sul primo
linea.

query_personalizzata
("symlink: check_postgres_custom_query") Esegue una query personalizzata di tua scelta e analizza
i risultati. La query stessa viene passata tramite l'argomento "query" e dovrebbe essere
mantenuto il più semplice possibile. Se possibile, avvolgilo in una vista o in una funzione da conservare
cose più facili da gestire. La query dovrebbe restituire una o due colonne. È necessario che
una delle colonne si chiami "risultato" ed è l'elemento che verrà confrontato con il tuo
Avvertimento e valori critici. La seconda colonna è per i dati sulle prestazioni e qualsiasi nome
può essere utilizzato: questo sarà il 'valore' all'interno della sezione dei dati sulle prestazioni.

È necessario specificare almeno un avviso o un argomento critico. A cosa sono impostati dipende
sul tipo di query che stai eseguendo. Ci sono quattro tipi di custom_query che possono essere
run, specificato dall'argomento "valtype". Se non viene specificato nessuno, questa azione è predefinita su
'numero intero'. I quattro tipi sono:

numero intero: Esegue un semplice confronto di interi. La prima colonna dovrebbe essere un numero intero semplice,
e i valori di avviso e critici dovrebbero essere gli stessi.

stringa: L'avviso e il critico sono stringhe e vengono attivati ​​solo se il valore in
la prima colonna corrisponde esattamente. Questo fa distinzione tra maiuscole e minuscole.

tempo: L'avviso e il critico sono tempi e possono avere unità di secondi, minuti,
ore, o giorni. Ciascuno può essere scritto al singolare o abbreviato solo alla prima lettera. Se
non vengono fornite unità, si assumono i secondi. La prima colonna dovrebbe essere un numero intero
che rappresenta il numero di secondi da controllare.

Taglia: L'avviso e il critico sono dimensioni e possono avere unità di byte, kilobyte,
megabyte, gigabyte, terabyte o exabyte. Ciascuno può essere abbreviato alla prima lettera.
Se non vengono fornite unità, vengono assunti i byte. La prima colonna dovrebbe essere un numero intero
che rappresenta il numero di byte da controllare.

Normalmente, viene attivato un avviso se i valori restituiti sono maggiore di o uguale a
valore critico o di avvertimento. Tuttavia, un'opzione di --inversione attiverà l'avviso se il
il valore restituito è inferiore di o uguale al valore critico o di avviso.

Esempio 1: Avvisa se una relazione su 100 pagine è denominata "rad", inserisci il numero di pagine
all'interno della sezione dei dati sulle prestazioni.

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

Esempio 2: fornire un valore critico se la funzione "foobar" restituisce un numero superiore a 5 MB:

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

Esempio 2: Avvisa se la funzione "snazzo" restituisce meno di 42:

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

Se ti viene in mente un'utile query_personalizzata, considera di inviare una patch a questo programma a
trasformarlo in un'azione standard che altre persone possono usare.

Questa azione non supporta ancora MRTG o l'output semplice.

dimensione_database
("symlink: check_postgres_database_size") Controlla la dimensione di tutti i database e si lamenta
quando sono troppo grandi. Non è necessario eseguire questo comando più di una volta per database
grappolo. I database possono essere filtrati con il --includere ed --escludere opzioni. Vedi il
Sezione "FILTRAGGIO DI BASE" per maggiori dettagli. Possono anche essere filtrati dal proprietario del
database con il --includeutente ed --excludeutente opzioni. Vedi il "FILTRO NOME UTENTE"
.

Le opzioni di avviso e critiche possono essere specificate come byte, kilobyte, megabyte,
gigabyte, terabyte o exabyte. Ciascuno può anche essere abbreviato alla prima lettera.
Se non viene fornita alcuna unità, si presume che le unità siano byte. Non ci sono impostazioni predefinite per questo
azione: l'avviso e la criticità devono essere specificati. Il valore di avviso non può essere maggiore
rispetto al valore critico. L'output restituisce prima tutti i database ordinati per dimensione più grande,
mostrando sia i byte non elaborati che una versione "carina" della dimensione.

Esempio 1: Avvisa se un database sull'host flagg ha una dimensione superiore a 1 TB e critico se supera
1.1 TB.

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

Esempio 2: fornire un valore critico se il modello di database1 sulla porta 5432 è superiore a 10 MB.

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

Esempio 3: fornire un avviso se qualsiasi database sull'host 'tardis' di proprietà dell'utente 'tom' è terminato
5 GB

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

Per l'output MRTG, restituisce la dimensione in byte del database più grande sulla prima riga e
il nome del database sulla quarta riga.

dbstats
("symlink: check_postgres_dbstats") Riporta le informazioni dalla vista pg_stat_database,
e lo emette in modo compatibile con i cactus. Nessun altro output è supportato, poiché l'output è
informativo e non si presta agli avvisi, come quelli usati con Nagios. Se nessuna opzione
vengono forniti, vengono restituiti tutti i database, uno per riga. Puoi includere un database specifico
usando l'opzione "--include", oppure puoi usare l'opzione "--dbname".

Vengono restituiti undici elementi su ciascuna riga, nel formato nome:valore, separati da un singolo
spazio. Gli articoli sono:

backend
Il numero di backend attualmente in esecuzione per questo database.

impegna
Il numero totale di commit per questo database da quando è stato creato o reimpostato.

rollback
Il numero totale di rollback per questo database da quando è stato creato o reimpostato.

read
Il numero totale di blocchi del disco letti.

hit Il numero totale di hit del buffer.

ret Il numero totale di righe restituite.

andare a prendere
Il numero totale di righe recuperate.

ins Il numero totale di righe inserite.

upd Il numero totale di righe aggiornate.

del Il numero totale di righe eliminate.

nomedb
Il nome del database.

Nota che gli elementi ret, fetch, ins, upd e del saranno sempre 0 se Postgres è la versione 8.2
o inferiore, poiché quelle statistiche non erano disponibili in quelle versioni.

Se viene fornito l'argomento dbname, vengono restituiti sette elementi aggiuntivi:

idxscan
Numero totale di scansioni dell'indice utente.

idxturead
Numero totale di voci dell'indice utente restituito.

idxtupfetch
Numero totale di righe recuperate da semplici scansioni dell'indice utente.

idxblksread
Numero totale di blocchi del disco letti per tutti gli indici utente.

idxblkshit
Numero totale di accessi al buffer per tutti gli indici utente.

seqscan
Numero totale di scansioni sequenziali su tutte le tabelle utente.

seqturead
Numero totale di tuple restituite da tutte le tabelle utente.

Esempio 1: prendi le statistiche per un database chiamato "prodotti" sull'host "salice":

check_postgres_dbstats --dbhost willow --dbname prodotti

L'output restituito sarà così (tutto su una riga, non avvolto):

backend:82 commit:58374408 rollback:1651 read:268435543 hit:2920381758 idxscan:310931294 idxtupread:2777040927
idxtupfetch:1840241349 idxblksread:62860110 idxblkshit:1107812216 seqscan:5085305 seqtupread:5370500520
ret:0 fetch:0 ins:0 upd:0 del:0 dbname:salice

trigger_disabili
("symlink: check_postgres_disabled_triggers") Controlla il numero di trigger disabilitati
all'interno della banca dati. Il --avvertimento ed --critico le opzioni sono il numero di tali trigger
trovato, ed entrambi per impostazione predefinita su "1", poiché nell'uso normale avere trigger disabilitati è pericoloso
evento. Se il database da controllare è 8.3 o superiore, il controllo è per il numero di
trigger che si trovano in uno stato "disabilitato" (anziché essere "sempre" o "replica"). Il
l'output mostrerà il nome della tabella e il nome del trigger per ogni disabilitato
grilletto.

Esempio 1: assicurati che non ci siano trigger disabilitati

check_postgres_disabled_triggers

Per l'output MRTG, restituisce il numero di trigger disabilitati sulla prima riga.

spazio sul disco
("symlink: check_postgres_disk_space") Verifica lo spazio su disco fisico disponibile utilizzato da
Postgres. Questa azione richiede che tu abbia l'eseguibile "/bin/df"disponibile a segnalare
sulle dimensioni del disco e deve anche essere eseguito come superutente, in modo che possa esaminare il
directory_dati ambientazione all'interno di Postgres. Il --avvertimento ed --critico le opzioni sono date
in entrambi i formati o percentuali o entrambi. Se si utilizzano le dimensioni, i tipi di unità standard sono
consentito: byte, kilobyte, gigabyte, megabyte, gigabyte, terabyte o exabyte. Ogni
può essere abbreviato solo alla prima lettera; nessuna unità indica 'byte'. Il
i valori predefiniti sono '90%' e '95%'.

Questo comando controlla le seguenti cose per determinare tutti i diversi dischi fisici
utilizzato da Postgres.

directory_dati - Il disco su cui si trova la directory principale dei dati.

ceppo elenco - Il disco su cui si trovano i file di registro.

WAL filetto elenco - Il disco su cui si trovano i log write-ahead (es. pg_xlog con collegamento simbolico)

tablespace - Ogni tablespace che si trova su un disco separato.

L'output mostra la dimensione totale utilizzata e disponibile su ciascun disco, nonché il
percentuale, ordinata dalla percentuale più alta alla più bassa utilizzata. Ogni elemento sopra è mappato su un file
sistema: questi possono essere inclusi o esclusi. Vedere la sezione "FILTRO DI BASE" per ulteriori informazioni
dettagli.

Esempio 1: assicurarsi che nessun file system superi il 90% per il database sulla porta 5432.

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

Esempio 2: verificare che tutti i file system che iniziano con /dev/sda siano inferiori a 10 GB e
11 GB (avviso e critico)

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

Esempio 4: assicurarsi che nessun file system sia superiore al 50% ed ha più di 15 GB

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

Esempio 5: emettere un avviso se un file system è pieno per oltre il 70% or ha più di 1T

check_postgres_disk_space --warning='1T o 75'

Per l'output MRTG, restituisce la dimensione in byte del file system sulla prima riga e il
nome del file system sulla quarta riga.

fsm_pages
("symlink: check_postgres_fsm_pages") Controlla quanto è vicino un cluster a Postgres
max_fsm_pages collocamento. Questa azione funzionerà solo per i database di 8.2 o versioni successive e
richiede il modulo contributi pg_freespacemap essere installato. Il --avvertimento ed --critico
le opzioni devono essere espresse in percentuale. Il numero di pagine utilizzate nella mappa dello spazio libero
è determinato guardando nella vista pg_freespacemap_relations ed eseguendo una formula
basato sulla formula utilizzata per l'output degli slot delle pagine della mappa dello spazio libero nel vuoto verbose
comando. I valori predefiniti sono 85% per l'avvertimento e 95% per il critico.

Esempio 1: invia un avviso quando il nostro cluster ha utilizzato il 76% dello spazio libero delle pagine,
con pg_freespacemap installato nel database robert

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

Mentre devi passare il nome del database in cui è installato pg_freespacemap, tu
è necessario eseguire questo controllo solo una volta per cluster. Inoltre, il controllo di queste informazioni richiede
ottenere blocchi speciali sulla mappa dello spazio libero, quindi si consiglia di non eseguirlo
controllare a brevi intervalli.

Per l'output MRTG, restituisce la percentuale di mappa dello spazio libero sulla prima riga e il numero
di pagine attualmente utilizzate sulla seconda riga.

fsm_relazioni
("symlink: check_postgres_fsm_relations") Controlla quanto è vicino un cluster a Postgres
max_fsm_relazioni collocamento. Questa azione funzionerà solo per i database di 8.2 o superiore e
richiede il modulo contributi pg_freespacemap essere installato. Il --avvertimento ed --critico
le opzioni devono essere espresse in percentuale. Il numero di relazioni utilizzate nella libera
space-map è determinato guardando nella vista pg_freespacemap_relations. Il predefinito
i valori sono 85% per l'avvertimento e 95% per il critico.

Esempio 1: Avvisa quando il nostro cluster ha esaurito l'80% delle relazioni di spazio libero,
con pg_freespacemap installato nel database dylan

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

Mentre devi passare il nome del database in cui è installato pg_freespacemap, tu
è necessario eseguire questo controllo solo una volta per cluster. Inoltre, il controllo di queste informazioni richiede
ottenere blocchi speciali sulla mappa dello spazio libero, quindi si consiglia di non eseguirlo
controllare a brevi intervalli.

Per l'output MRTG, restituisce la percentuale di mappa dello spazio libero sulla prima riga, il numero di
relazioni attualmente utilizzate sulla seconda riga.

percentuale di successi
("symlink: check_postgres_hitratio") Controlla il rapporto di successo di tutti i database e si lamenta
quando sono troppo bassi. Non è necessario eseguire questo comando più di una volta per database
grappolo. I database possono essere filtrati con il --includere ed --escludere opzioni. Vedi il
Sezione "FILTRAGGIO DI BASE" per maggiori dettagli. Possono anche essere filtrati dal proprietario del
database con il --includeutente ed --excludeutente opzioni. Vedi il "FILTRO NOME UTENTE"
.

Le opzioni di avviso e critiche devono essere specificate come percentuali. Non ci sono
valori predefiniti per questa azione: è necessario specificare l'avviso e il critico. Il valore di avvertimento
non può essere maggiore del valore critico. L'output restituisce tutti i database ordinati per
hitratio, il più piccolo per primo.

Esempio: Avvisa se un database su host flagg è inferiore al 90% in hitratio e critico se
meno dell'80%.

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

Per l'output MRTG, restituisce la percentuale del database con l'hitratio più piccolo sul
prima riga e il nome del database sulla quarta riga.

ritardo_standby_caldo
("symlink: check_hot_standby_delay") Controlla il ritardo di replica dello streaming calcolando il
delta tra la posizione xlog corrente di un server master e la posizione di riproduzione di a
schiavo ad esso collegato. Il server slave deve essere in modalità hot_standby (es. sola lettura),
quindi la versione minima per utilizzare questa azione è Postgres 9.0. Il --avvertimento ed
--critico le opzioni sono il delta tra le posizioni di xlog. Poiché questi valori sono byte
gli offset nel WAL dovrebbero corrispondere al volume di transazioni previsto della tua applicazione
per prevenire falsi positivi o negativi.

Le prime opzioni "--dbname", "--host" e "--port", ecc. sono considerate master; il
il secondo appartiene allo schiavo.

I valori dei byte dovrebbero essere basati sul volume delle transazioni necessarie per avere lo streaming
la replica si disconnette dal master a causa di un ritardo eccessivo, determinato dal Postgres
variabile di configurazione wal_keep_segments. Per le unità di tempo, le unità valide sono "secondi",
"minuti", "ore" o "giorni". Ciascuno può essere scritto al singolare o abbreviato solo con il
prima lettera. Quando si specificano entrambi, nella forma 'bytes ed tempo', entrambe le condizioni devono essere
vero per il raggiungimento della soglia.

È necessario fornire informazioni su come raggiungere i database fornendo una virgola separata
list ai parametri --dbhost e --dbport, ad esempio "--dbport=5432,5543". Se non dato,
l'azione fallisce.

Esempio 1: Avvisa che un database con una replica locale sulla porta 5433 è in ritardo su qualsiasi riproduzione xlog
affatto

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

Esempio 2: fornire un valore critico se l'ultima transazione che replica1 riceve è superiore a 10
minuti fa

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

Esempio 3: consentire a replica1 di essere 1 segmento WAL dietro, se il master sta momentaneamente vedendo
più attività di quella che può gestire la connessione di replica in streaming, o 10 minuti indietro,
se il master vede pochissima attività e non elabora alcuna transazione, ma no
entrambi, il che indicherebbe un problema duraturo con la connessione di replica.

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

dimensione_indice
Dimensioni della tavola
dimensione_relazione
(link simbolici: "check_postgres_index_size", "check_postgres_table_size", e
"check_postgres_relation_size") Le azioni Dimensioni della tavola ed dimensione_indice sono semplicemente
variazioni del dimensione_relazione azione, che verifica una relazione anch'essa cresciuta
grande. Le relazioni (in altre parole, tabelle e indici) possono essere filtrate con il --includere
ed --escludere opzioni. Vedere la sezione "FILTRAGGIO DI BASE" per maggiori dettagli. Le relazioni possono
essere filtrati anche dall'utente che li possiede, utilizzando il --includeutente ed --excludeutente
opzioni. Vedere la sezione "FILTRO NOME UTENTE" per maggiori dettagli.

I valori per --avvertimento ed --critico le opzioni sono le dimensioni dei file e possono avere unità di
byte, kilobyte, megabyte, gigabyte, terabyte o exabyte. Ciascuno può essere abbreviato
alla prima lettera. Se non vengono fornite unità, vengono assunti i byte. Non ci sono valori predefiniti
valori: devono essere fornite sia l'avvertenza che l'opzione critica. Il testo di ritorno mostra il
dimensione della relazione più grande trovata.

Se l' --showperf l'opzione è abilitata, contro tutti i saranno fornite le relazioni con le loro dimensioni.
Per evitare ciò, si consiglia di impostare il --perflimit opzione, che causerà
la query per eseguire un "ORDER BY size DESC LIMIT (perflimit)".

Esempio 1: fornire un valore critico se una tabella è più grande di 600 MB su host burrick.

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

Esempio 2: Avvisa se i prodotti della tabella hanno una dimensione superiore a 4 GB e assegna un valore critico a 4.5 GB.

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

Esempio 3: Avvisa se un indice non di proprietà di Postgres supera i 500 MB.

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

Per l'output MRTG, restituisce la dimensione in byte della relazione più grande e il nome del
database e relazione come quarta riga.

ultima_analisi
ultimo_vuoto
last_autoanalyze
last_autovacuum
(link simbolici: "check_postgres_last_analyze", "check_postgres_last_vacuum",
"check_postgres_last_autoanalyze" e "check_postgres_last_autovacuum") Controlla per quanto tempo
lo è stato dall'ultima volta che il vuoto (o analisi) è stato eseguito su ciascuna tabella in uno o più database.
L'uso di queste azioni richiede che il database di destinazione sia la versione 8.3 o successiva, o che
la versione è 8.2 e la variabile di configurazione stats_row_level è stato abilitato. Tabelle
può essere filtrato con il --includere ed --escludere opzioni. Vedi il "FILTRO DI BASE"
sezione per maggiori dettagli. Le tabelle possono anche essere filtrate dal loro proprietario utilizzando il
--includeutente ed --excludeutente opzioni. Per ulteriori informazioni, vedere la sezione "FILTRO DEL NOME UTENTE"
dettagli.

Le unità per --avvertimento ed --critico sono specificati come tempi. Le unità valide sono secondi,
minuti, ore e giorni; tutto può essere abbreviato alla prima lettera. Se nessuna unità è
dato, si presumono 'secondi'. I valori predefiniti sono "1 giorno" e "2 giorni". notare che
che ci sono casi in cui questo campo non viene compilato automaticamente. Se certo
le tabelle ti stanno dando problemi, assicurati che abbiano righe morte da aspirare, o semplicemente
escluderli dalla prova.

Lo schema denominato 'information_schema' è escluso da questo test, in quanto le uniche tabelle che esso
contiene sono piccoli e non cambiano.

Nota che le versioni non "auto" controlleranno anche le versioni automatiche. In altro
parole, usando last_vacuum riporterà sull'ultimo vuoto, se era un vuoto normale,
o uno eseguito dal demone autovacuum.

Esempio 1: Avvisa se un tavolo non è stato aspirato in 3 giorni e assegna un critico a a
settimana, per l'assenzio ospite

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

Esempio 2: come sopra, ma salta le tabelle appartenenti agli utenti 'eve' o 'malory'

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

Per l'uscita MRTG, restituisce (sulla prima riga) il MINIMO tempo in secondi da a
il tavolo è stato aspirato o analizzato per l'ultima volta. La quarta riga restituisce il nome del database e
nome della tabella.

ascoltatore
("symlink: check_postgres_listener") Conferma che qualcuno sta ascoltando uno o più
stringhe specifiche (usando il sistema LISTEN/NOTIFY), osservando la tabella pg_listener.
Ne basta uno solo tra avvertimento o critico. Il formato è una semplice stringa che rappresenta il
LISTEN target o un carattere tilde seguito da una stringa per il controllo di un'espressione regolare.
Nota che questo controllo non funzionerà sulle versioni di Postgres 9.0 o successive.

Esempio 1: dare un avviso se nessuno sta ascoltando la stringa bucardo_mcp_ping sulle porte
5555 e 5556

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

Esempio 2: fornire un critico se non ci sono richieste LISTEN attive corrispondenti a 'grimm' on
banca dati oskar

check_postgres_listener --db oskar --critical=~grimm

Per l'output MRTG, restituisce un 1 o uno 0 sul primo, indicando l'esito positivo o negativo. Il nome
dell'avviso deve essere fornito tramite il --mrtg opzione.

serrature
("symlink: check_postgres_locks") Controlla il numero totale di blocchi su uno o più
banche dati. Non è necessario eseguirlo più di una volta per cluster di database. I database possono
essere filtrato con il --includere ed --escludere opzioni. Vedere la sezione "FILTRAGGIO DI BASE"
per ulteriori dettagli.

I --avvertimento ed --critico le opzioni possono essere specificate come semplici numeri, che rappresentano
il numero totale di serrature, oppure possono essere suddivise per tipologia di serratura. Nomi di blocco validi
sono "totale", "in attesa" o il nome di un tipo di blocco utilizzato da Postgres. Questi nomi sono
insensibile alle maiuscole e non è necessaria la parte "lucchetto" all'estremità, quindi esclusivo corrisponderà
'Blocco Esclusivo'. Il formato è nome=numero, con elementi diversi separati da due punti o
punto e virgola (o qualsiasi altro simbolo).

Esempio 1: Avvisa se il numero di blocchi è 100 o più e critico se 200 o più, attivo
padrone di casa

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

Esempio 2: Sull'artemus ospite, avvisa se esistono 200 o più serrature e dai un critico se
esistono più di 250 lock totali, o se esistono più di 20 lock esclusivi, o se più di 5 connessioni
stanno aspettando una serratura.

check_postgres_locks --host=artemus --warning=200 --critical="totale=250:attesa=5:esclusivo=20"

Per l'output MRTG, restituisce il numero di blocchi sulla prima riga e il nome del
banca dati sulla quarta riga.

file di log
("symlink: check_postgres_logfile") Assicura che il file di registro sia nella posizione prevista
ed è in corso l'accesso a. Questa azione emette un comando che genera un errore su ciascuno
database che sta controllando e garantisce che il messaggio venga visualizzato nei registri. Scansiona il
varie impostazioni log_* all'interno di Postgres per capire dove dovrebbero essere i log. Se tu
stanno usando syslog, esegue una scansione approssimativa (ma non infallibile) di /etc/syslog.conf.
In alternativa, puoi fornire il nome del file di log con il --file di log opzione. Questo è
particolarmente utile se i log hanno uno schema di rotazione personalizzato guidato da un programma esterno.
I --file di log l'opzione supporta i seguenti caratteri di escape: "%Y %m %d %H", che
rappresentano rispettivamente l'anno, il mese, la data e l'ora correnti. Un errore è sempre
segnalato come critico a meno che l'opzione di avviso non sia stata passata come valore diverso da zero.
Oltre a questo uso specifico, le opzioni "--warning" e "--critical" dovrebbero non be
Usato.

Esempio 1: sulla porta 5432, assicurarsi che il file di registro venga scritto nel file
/home/greg/pg8.2.log

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

Esempio 2: come sopra, ma solleva un avvertimento, non un critico

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

Per l'output MRTG, restituisce 1 o 0 sulla prima riga, indicando l'esito positivo o negativo. In
caso di guasto, la quarta riga fornirà maggiori dettagli sul guasto riscontrato.

nuova_versione_bc
("symlink: check_postgres_new_version_bc") Controlla se una versione più recente del Bucardo
programma è disponibile. La versione corrente si ottiene eseguendo "bucardo_ctl --version".
Se è disponibile un aggiornamento importante, viene restituito un avviso. Se un aggiornamento di revisione è
disponibile, viene restituito un critico. (Bucardo è da padrone a schiavo e da padrone a padrone
sistema di replica per Postgres: vedi http://bucardo.org per maggiori informazioni). Guarda anche
le informazioni sull'opzione "--get_method".

nuova_versione_box
("symlink: check_postgres_new_version_box") Controlla se una versione più recente di boxinfo
programma è disponibile. La versione corrente si ottiene eseguendo "boxinfo.pl --version".
Se è disponibile un aggiornamento importante, viene restituito un avviso. Se un aggiornamento di revisione è
disponibile, viene restituito un critico. (boxinfo è un programma per catturare importanti
informazioni da un server e inserirle in un formato HTML: vedi
http://bucardo.org/wiki/boxinfo per maggiori informazioni). Vedi anche le informazioni sul
opzione "--get_method".

nuova_versione_cp
("symlink: check_postgres_new_version_cp") Controlla se una versione più recente di questo programma
(check_postgres) è disponibile, prendendo la versione da un piccolo file di testo sul main
pagina della home page del progetto. Restituisce un avviso se la versione restituita non lo fa
corrisponde a quello che stai correndo. L'intervallo consigliato per il controllo è una volta al giorno. Vedi anche il
informazioni sull'opzione "--get_method".

nuova_versione_pg
("symlink: check_postgres_new_version_pg") Controlla se esiste una revisione più recente di Postgres
per ogni database connesso. Nota che questo controlla solo la revisione, ad esempio andando da
da 8.3.6 a 8.3.7. Le revisioni sono sempre compatibili con i binari al 100% e non comportano dump e
ripristinare per aggiornare. Vengono apportate revisioni per risolvere i bug, quindi aggiornare il prima possibile
è sempre consigliato. Restituisce un avviso se non si dispone dell'ultima revisione. è
consiglia di eseguire questo controllo almeno una volta al giorno. Vedi anche le informazioni sul
opzione "--get_method".

nuova_versione_tnm
("symlink: check_postgres_new_version_tnm") Controlla se una versione più recente di tail_n_mail
programma è disponibile. La versione corrente si ottiene eseguendo "tail_n_mail --version".
Se è disponibile un aggiornamento importante, viene restituito un avviso. Se un aggiornamento di revisione è
disponibile, viene restituito un critico. (tail_n_mail è uno strumento di monitoraggio dei log che può inviare
posta quando eventi interessanti vengono visualizzati nei registri di Postgres. Vedere:
http://bucardo.org/wiki/Tail_n_mail per maggiori informazioni). Vedi anche le informazioni su
l'opzione "--get_method".

pgb_pool_cl_attivo
pgb_pool_cl_in attesa
pgb_pool_sv_attivo
pgb_pool_sv_idle
pgb_pool_sv_used
pgb_pool_sv_tested
pgb_pool_sv_login
pgb_pool_maxwait
(link simbolici: "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" e "check_postgres_pgb_pool_maxwait")

Esamina le statistiche del pool di pgbouncer. Ogni pool ha una serie di connessioni "client",
riferendosi a connessioni da client esterni, e connessioni "server", riferendosi a
connessioni a PostgreSQL stesso. Le relative azioni check_postgres sono precedute da "cl_"
e "sv_", rispettivamente. Le connessioni client attive sono quelle connessioni attualmente collegate
con una connessione server attiva. Le connessioni client possono anche essere "in attesa", nel senso che
non è stata ancora assegnata una connessione al server. Le connessioni al server sono "attive" (collegate
a un client), "inattivo" (in attesa di una connessione client con cui collegarsi), "usato" (solo
scollegato da un client e non ancora restituito al pool inattivo), "testato" (attualmente in corso
testato) e "login" (in fase di accesso). Il valore maxwait mostra quanto tempo in
secondi la connessione client in attesa più vecchia è stata in attesa.

pgbouncer_backend
("symlink: check_postgres_pgbouncer_backends") Controlla il numero corrente di connessioni
per uno o più database tramite pgbouncer, e opzionalmente lo confronta con il massimo
consentito, che è determinato dalla variabile di configurazione pgbouncer max_client_conn.
--avvertimento ed --critico le opzioni possono assumere una delle tre forme. Innanzitutto, un semplice numero può
essere dato, che rappresenta il numero di connessioni a cui verrà dato l'avviso.
Questa scelta non utilizza il max_connections collocamento. In secondo luogo, la percentuale di disponibilità
si possono dare collegamenti. Terzo, si può dare un numero negativo che rappresenti il
numero di connessioni rimaste fino a max_connections è raggiunto. I valori predefiniti per
--avvertimento ed --critico sono '90%' e '95%'. Puoi anche filtrare i database usando
, il --includere ed --escludere opzioni. Vedere la sezione "FILTRAGGIO DI BASE" per maggiori dettagli.

Per visualizzare solo i processi non inattivi, puoi utilizzare il pulsante --noidle discussione. Si noti che l'utente si
si stanno connettendo in quanto deve essere un superutente affinché funzioni correttamente.

Esempio 1: fornire un avviso quando il numero di connessioni su host quirm raggiunge 120 e a
critico se raggiunge 150.

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

Esempio 2: fornire un valore critico quando raggiungiamo il 75% della nostra impostazione max_connections sugli host
lancre o lancre2.

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

Esempio 3: inviare un avviso quando sono rimasti solo 10 slot di connessione in più sull'host
plasmide, e un critico quando ne rimangono solo 5.

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

Per l'uscita MRTG, il numero di connessioni è riportato sulla prima riga e sulla quarta
line fornisce il nome del database, più l'attuale max_client_conn. Se più di uno
database è stato interrogato, viene emesso quello con il maggior numero di connessioni.

pgbouncer_checksum
("symlink: check_postgres_pgbouncer_checksum") Verifica che tutte le impostazioni di pgBouncer siano
come l'ultima volta che hai controllato. Questo viene fatto generando un checksum di un elenco ordinato
di impostare i nomi e i loro valori. Nota che non dovresti specificare il nome del database, è
verrà automaticamente impostato su pgbouncer. o il --avvertimento oppure --critico opzione
dovrebbe essere dato, ma non entrambi. Il valore di ognuno è il checksum, un 32 caratteri
valore esadecimale. Puoi correre con la speciale opzione "--critical=0" per scoprire un
checksum esistente.

Questa azione richiede il modulo Digest::MD5.

Esempio 1: Trova il checksum iniziale per la configurazione di pgbouncer sulla porta 6432 usando il pulsante
utente predefinito (di solito postgres)

check_postgres_pgbouncer_checksum --port=6432 --critical=0

Esempio 2: assicurarsi che non siano cambiate impostazioni e avvisare in caso affermativo, utilizzando il checksum from
sopra.

check_postgres_pgbouncer_checksum --port=6432 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Per l'output MRTG, restituisce 1 o 0 che indica l'esito positivo o negativo della corrispondenza del checksum.
È necessario fornire un checksum come argomento "--mrtg". La quarta riga dà sempre il
checksum attuale.

pgagent_jobs
("symlink: check_postgres_pgagent_jobs") Verifica che tutti i lavori pgAgent che hanno
eseguiti nell'intervallo di tempo precedente sono riusciti. Questo viene fatto controllando per
tutti i passaggi che hanno un risultato diverso da zero.

È possibile specificare come tempi "--warning" o "--critical", o entrambi, e i lavori saranno
controllato per errori entro i periodi di tempo specificati prima dell'ora corrente. Valido
le unità sono secondi, minuti, ore e giorni; tutto può essere abbreviato alla prima lettera.
Se non vengono fornite unità, si assumono i "secondi".

Esempio 1: fornire un valore critico quando i lavori eseguiti nell'ultimo giorno hanno avuto esito negativo.

check_postgres_pgagent_jobs --critical=1d

Esempio 2: fornire un avviso quando i lavori eseguiti nell'ultima settimana hanno avuto esito negativo.

check_postgres_pgagent_jobs --warning=7d

Esempio 3: fornire un valore critico per i lavori che non sono riusciti nelle ultime 2 ore e un avviso per
lavori che non sono riusciti nelle ultime 4 ore:

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

preparato_txns
("symlink: check_postgres_prepared_txns") Controlla l'età di qualsiasi preparato esistente
transazioni. Nota che la maggior parte delle persone NON utilizzerà transazioni preparate, poiché fanno parte
di commit in due parti e complicato da mantenere. Inoltre non devono essere confusi con
DICHIARAZIONI preparate, che è ciò a cui la maggior parte delle persone pensa quando sentono prepararsi. Il
il valore predefinito per un avviso è 1 secondo, per rilevare qualsiasi utilizzo di transazioni preparate, che
è probabilmente un errore sulla maggior parte dei sistemi. Avvertimento e critico sono il numero di secondi a
la transazione preparata è stata aperta prima che venga dato un avviso.

Esempio 1: fornire un avviso al rilevamento di eventuali transazioni preparate:

check_postgres_prepared_txns -w 0

Esempio 2: fornire un valore critico se una transazione preparata è stata aperta per più di 10
secondi, ma consenti fino a 360 secondi per il database 'shrike':

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

Per l'output MRTG, restituisce il numero di secondi in cui la transazione più vecchia è stata aperta come
prima riga e da quale database proviene come riga finale.

query_runtime
("symlink: check_postgres_query_runtime") Controlla quanto tempo impiega una query specifica per l'esecuzione,
eseguendo un "EXPLAIN ANALYZE" su di esso. Il --avvertimento ed --critico le opzioni sono le
tempo massimo che dovrebbe impiegare la query. Le unità valide sono secondi, minuti e ore;
qualsiasi può essere abbreviato alla prima lettera. Se non vengono fornite unità, si assumono i "secondi".
Devono essere forniti sia l'avvertimento che l'opzione critica. Il nome della vista o della funzione
per essere eseguito deve essere passato al --nomequery opzione. Deve consistere in una sola parola
(o schema.word), con parentesi opzionali alla fine.

Esempio 1: fornire un valore critico se la funzione denominata "speedtest" non viene eseguita in 10 secondi oppure
Di meno.

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

Per l'output MRTG, riporta il tempo in secondi per il completamento della query nella prima riga.
La quarta riga elenca il database.

query_time
("symlink: check_postgres_query_time") Controlla la lunghezza delle query in esecuzione su una o più
banche dati. Non è necessario eseguirlo più di una volta sullo stesso cluster di database. Nota
che questo esclude già le query che sono "inattive nella transazione". I database possono essere
filtrato utilizzando il --includere ed --escludere opzioni. Vedere la sezione "FILTRAGGIO DI BASE"
per ulteriori dettagli. Puoi anche filtrare in base all'utente che esegue la query con il --includeutente
ed --excludeutente opzioni. Vedere la sezione "FILTRO NOME UTENTE" per maggiori dettagli.

I valori per --avvertimento ed --critico le opzioni sono quantità di tempo e il valore predefinito è "2"
minuti' e '5 minuti' rispettivamente. Le unità valide sono "secondi", "minuti", "ore" o
'giorni'. Ciascuno può essere scritto al singolare o abbreviato solo alla prima lettera. Se non ci sono unità
sono dati, si assume che l'unità sia secondi.

Questa azione richiede Postgres 8.1 o superiore.

Esempio 1: fornire un avviso se una query è stata eseguita per più di 3 minuti e a
critico se superiore a 5 minuti.

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

Esempio 2: utilizzando i valori predefiniti (2 e 5 minuti), controllare tutti i database tranne quelli
iniziando con "modello".

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

Esempio 3: Avvisa se l'utente "don" ha una query in esecuzione per oltre 20 secondi

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

Per l'output MRTG, restituisce la lunghezza in secondi della query più lunga sul primo
linea. La quarta riga fornisce il nome del database.

replica_row
("symlink: check_postgres_replicate_row") Verifica che la replica master-slave funzioni
a uno o più schiavi.

Le prime opzioni "--dbname", "--host" e "--port", ecc. sono considerate master;
gli usi successivi sono gli schiavi. I valori o il --avvertimento ed --critico le opzioni sono
unità di tempo e almeno uno deve essere fornito (nessun valore predefinito). Le unità valide sono "secondi",
"minuti", "ore" o "giorni". Ciascuno può essere scritto al singolare o abbreviato solo con il
prima lettera. Se non vengono fornite unità, si presume che le unità siano i secondi.

Questo controllo aggiorna una singola riga sul master e quindi misura quanto tempo ci vuole per essere
applicato agli schiavi. Per fare ciò, devi scegliere una tabella che viene replicata, quindi
trova una riga che può essere modificata e non verrà modificata da nessun altro processo. UN
colonna specifica di questa riga verrà modificata da un valore all'altro. Tutto questo è nutrito
all'opzione "repinfo" e dovrebbe contenere le seguenti opzioni, separate da virgole:
nome tabella, chiave primaria, ID chiave, colonna, primo valore, secondo valore.

Esempio 1: Slony sta replicando una tabella denominata "ordini" dall'host "alpha" all'host "beta",
nel database 'vendite'. La chiave primaria della tabella si chiama id e andremo a
prova la riga con un id di 3 (che è storico e non è mai cambiato). C'è una colonna
denominato 'venditore' che passeremo da un valore di 'slon' a 'nols' per verificare
la replica. Vogliamo lanciare un avvertimento se la replica non avviene entro 10
secondi.

check_postgres_replicate_row --host=alpha --dbname=vendite --host=beta
--dbname=vendite --warning=10 --repinfo=ordini,id,3,rappresentante vendita,slon,nols

Esempio 2: Bucardo sta replicando una tabella denominata "ricevuta" dall'host "verde" agli host
'rosso', 'blu' e 'giallo'. Il database per entrambe le parti è "pubblico". I database degli schiavi
sono in esecuzione sulla porta 5455. La chiave primaria è denominata 'receipt_id', la riga che vogliamo usare
ha un valore di 9 e la colonna che vogliamo cambiare per il test si chiama 'zona'. Bene
alterna tra 'nord' e 'sud' per il valore di questa colonna e lancia un se critico
la modifica non avviene su tutti e tre gli slave entro 5 secondi.

check_postgres_replicate_row --host=verde --port=5455 --host=rosso,blu,giallo
--critical=5 --repinfo=receipt,receipt_id,9,zona,nord,sud

Per l'output MRTG, restituisce sulla prima riga il tempo in secondi impiegato dalla replica
finire. Il tempo massimo è fissato a 4 minuti e 30 secondi: se non è stata eseguita alcuna replica
posto in così tanto tempo, viene generato un errore.

stesso_schema
("symlink: check_postgres_same_schema") Verifica che due o più database siano identici
per quanto riguarda il loro schema (ma non i dati all'interno). Questo è particolarmente utile per la realizzazione
assicurati che i tuoi schiavi non siano stati modificati o corrotti in alcun modo quando usi master to slave
replica. A differenza della maggior parte delle altre azioni, questa non ha criteri di avviso o critici: il
i database sono sincronizzati o non lo sono. Se sono diversi, un elenco dettagliato dei
differenze sono presentate.

Potresti voler escludere o filtrare alcune differenze. Il modo per farlo è aggiungere
stringhe all'opzione "--filter". Per escludere un tipo di oggetto, usa "noname", dove 'name'
è il tipo di oggetto, ad esempio "noschema". Per escludere oggetti di un certo tipo da a
espressione regolare contro il loro nome, usa "noname=regex". Vedere gli esempi di seguito per a
miglior comprensione.

I tipi di oggetti che possono essere filtrati includono:

Utente
schema
tavolo
vista
Index
sequenza
costrizione
innescare
function

L'opzione di filtro "noposition" impedisce la verifica della posizione delle colonne all'interno di a
tabella.

L'opzione di filtro "nofuncbody" impedisce il confronto dei corpi di tutte le funzioni.

L'opzione di filtro "noperm" impedisce il confronto dei permessi degli oggetti.

Per fornire il secondo database, basta aggiungere le differenze al primo tramite una chiamata a
l'argomento di connessione appropriato. Ad esempio, per confrontare database su host alfa e
bravo, usa "--dbhost=alpha,bravo". Vedere anche gli esempi di seguito.

Se viene fornito un solo host, si presume che stiamo facendo un rapporto "basato sul tempo". Il
la prima volta che viene eseguito un'istantanea di tutti gli elementi nel database viene salvata in un locale
file. Quando lo esegui di nuovo, quell'istantanea viene letta e diventa "database n. 2" ed è
rispetto al database attuale.

Per sostituire il vecchio file memorizzato con la nuova versione, utilizzare l'argomento --replace.

Per abilitare le istantanee in vari punti nel tempo, puoi usare l'argomento "--suffisso" per rendere
i nomi di file univoci per ogni esecuzione. Vedere gli esempi di seguito.

Esempio 1: verificare che due database sugli host star e line siano gli stessi:

check_postgres_same_schema --dbhost=stella,riga

Esempio 2: come prima, ma escludi eventuali trigger con "slony" nel nome

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

Esempio 3: come prima, ma escludi anche tutti gli indici

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

Esempio 4: verifica le differenze per il database "battlestar" su porte diverse

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

Esempio 5: creare un file snapshot giornaliero e settimanale

check_postgres_same_schema --dbname=cylon --suffix=quotidiano
check_postgres_same_schema --dbname=cylon --suffix=settimanale

Esempio 6: eseguire un confronto cronologico, quindi sostituire il file

check_postgres_same_schema --dbname=cylon --suffix=quotidiano --replace

sequenza
("symlink: check_postgres_sequence") Controlla quanto spazio è lasciato su tutte le sequenze nel
Banca dati. Questo è misurato come la percentuale dei possibili valori totali che sono stati utilizzati
per ogni sequenza. Il --avvertimento ed --critico le opzioni dovrebbero essere espresse come
percentuali. I valori predefiniti sono 85% per l'avvertimento e 95% per il critico. Potresti
usa --include e --exclude per controllare quali sequenze devono essere controllate. Nota che questo
l'assegno tiene conto di insolito valore minimo ed incremento by valori, ma non importa se il
la sequenza è impostata su ciclo o meno.

L'output per Nagios fornisce il nome della sequenza, la percentuale utilizzata e il numero
di 'chiamate' rimaste, indicando quante altre volte nextval può essere chiamato su quella sequenza
prima di raggiungere il valore massimo.

L'output per MRTG restituisce la percentuale più alta tra tutte le sequenze sulla prima riga,
e il nome di ogni sequenza con quella percentuale sulla quarta riga, separato da un "|"
(pipe) se ci sono più sequenze in quella percentuale.

Esempio 1: fornire un avviso se una sequenza si avvicina al 95% di riempimento.

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

Esempio 2: verificare che la sequenza denominata "orders_id_seq" non sia piena per più della metà.

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

impostazioni_checksum
("symlink: check_postgres_settings_checksum") Controlla che tutte le impostazioni di Postgres siano
come l'ultima volta che hai controllato. Questo viene fatto generando un checksum di un elenco ordinato
di impostare i nomi e i loro valori. Nota che utenti diversi nello stesso database potrebbero avere
checksum diversi, a causa dell'utilizzo di ALTER USER e del fatto che i superutenti vedono di più
impostazioni rispetto agli utenti normali. o il --avvertimento oppure --critico l'opzione dovrebbe essere
dato, ma non entrambi. Il valore di ognuno è il checksum, un esadecimale di 32 caratteri
valore. Puoi correre con l'opzione speciale "--critical=0" per scoprire un esistente
somma di controllo.

Questa azione richiede il modulo Digest::MD5.

Esempio 1: trovare il checksum iniziale per il database sulla porta 5555 utilizzando l'utente predefinito
(di solito postgres)

check_postgres_settings_checksum --port=5555 --critical=0

Esempio 2: assicurarsi che non siano cambiate impostazioni e avvisare in caso affermativo, utilizzando il checksum from
sopra.

check_postgres_settings_checksum --port=5555 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Per l'output MRTG, restituisce 1 o 0 che indica l'esito positivo o negativo della corrispondenza del checksum.
È necessario fornire un checksum come argomento "--mrtg". La quarta riga dà sempre il
checksum attuale.

slony_status
("symlink: check_postgres_slony_status") controlla lo stato di un cluster Slony tramite
guardando i risultati della vista sl_status di Slony. Questo viene restituito come numero di
secondi di "ritardo". Il --avvertimento ed --critico le opzioni devono essere espresse in tempi.
I valori predefiniti sono 60 secondo per l'avvertimento e 300 secondo per il critico.

L'argomento facoltativo --schema indicato lo schema in cui è installato Slony. se è
non è dato, lo schema verrà determinato automaticamente ogni volta che viene eseguito questo controllo.

Esempio 1: avvisa se uno Slony è in ritardo di più di 20 secondi

check_postgres_slony_status --avviso 20

Esempio 2: Dare un critico se Slony, installato sotto lo schema "_slony", è superiore a 10
minuti in ritardo

check_postgres_slony_status --schema=_slony --critical=600

sincronizzazione temporale
("symlink: check_postgres_timesync") Confronta l'ora del sistema locale con l'ora riportata
da uno o più database. Il --avvertimento ed --critico le opzioni rappresentano il numero di
secondi tra i due sistemi prima che venga dato un avviso. Se nessuno dei due è specificato, il
vengono utilizzati i valori predefiniti, che sono '2' e '5'. Il valore di avviso non può essere maggiore di
il valore critico. A causa della natura non esatta di questo test, i valori di "0" o "1" non lo sono
raccomandato.

La stringa restituita mostra la differenza di tempo e il tempo scritto su ciascun lato
fuori.

Esempio 1: verifica che i database sugli host ankh, morpork e klatch non siano più di 3
secondi di differenza rispetto all'ora locale:

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

Per l'uscita MRTG, restituisce sulla prima riga il numero di secondi di differenza tra il
ora locale e l'ora del database. La quarta riga restituisce il nome del database.

txn_idle
("symlink: check_postgres_txn_idle") Controlla il numero e la durata di "idle in
transazione" query su uno o più database. Non è necessario eseguirlo più di una volta
sullo stesso cluster di database. I database possono essere filtrati utilizzando il --includere ed
--escludere opzioni. Vedere la sezione "FILTRO DI BASE" di seguito per maggiori dettagli.

I --avvertimento ed --critico le opzioni sono fornite come unità di tempo, interi con segno o
numeri interi per unità di tempo e devono essere forniti entrambi (non ci sono valori predefiniti). Unità valide
sono "secondi", "minuti", "ore" o "giorni". Ciascuno può essere scritto al singolare o abbreviato
solo alla prima lettera. Se non vengono fornite unità e i numeri sono senza segno, le unità
si presume siano secondi.

Questa azione richiede Postgres 8.3 o superiore.

Esempio 1: fornire un avviso se una connessione è rimasta inattiva nella transazione per più di 15
secondi:

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

Esempio 2: avvisa se ci sono 50 o più transazioni

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

Esempio 3: fornire un valore critico se 5 o più connessioni sono rimaste inattive nella transazione per più
di 10 secondi:

check_postgres_txn_idle --port=5432 --critical='5 per 10 secondi'

Per l'output MRTG, restituisce il tempo in secondi in cui è stata la transazione inattiva più lunga
in esecuzione. La quarta riga restituisce il nome del database e altre informazioni sul
transazione più lunga.

txn_time
("symlink: check_postgres_txn_time") Controlla la lunghezza delle transazioni aperte su una o più
banche dati. Non è necessario eseguire questo comando più di una volta per cluster di database.
I database possono essere filtrati utilizzando il --includere ed --escludere opzioni. Vedi il "BASIC
FILTERING" per maggiori dettagli. Il proprietario della transazione può anche essere filtrato, per
uso del --includeutente ed --excludeutente opzioni. Vedere la sezione "FILTRO NOME UTENTE"
per ulteriori dettagli.

I valori o il --avvertimento ed --critico le opzioni sono unità di tempo e devono essere fornite
(nessuna impostazione predefinita). Le unità valide sono "secondi", "minuti", "ore" o "giorni". Ciascuno può essere
scritto singolare o abbreviato solo alla prima lettera. Se non vengono fornite unità, il
si presume che le unità siano i secondi.

Questa azione richiede Postgres 8.3 o superiore.

Esempio 1: fornire un valore critico se una transazione è stata aperta per più di 10 minuti:

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

Esempio 1: Avvisa se l'utente "magazzino" ha una transazione aperta in 30 secondi

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

Per l'output MRTG, restituisce il tempo massimo in secondi in cui una transazione è stata aperta sul
prima linea. La quarta riga fornisce il nome del database.

txn_wraparound
("symlink: check_postgres_txn_wraparound") Controlla quanto vicino alla transazione wraparound uno
o più database stanno ottenendo. Il --avvertimento ed --critico le opzioni indicano il numero
di transazioni effettuate e deve essere un numero intero positivo. Se nessuna delle due opzioni è data, il
vengono utilizzati i valori predefiniti di 1.3 e 1.4 miliardi. Non è più necessario eseguire questo comando
di una volta per cluster di database. Per una discussione più dettagliata di cosa questo numero
rappresenta e cosa fare al riguardo, visita la pagina
<http://www.postgresql.org/docs/current/static/routine-vacuuming.html#VUOTO-PER-AVVOLGIMENTO>

I valori di avviso e critici possono avere trattini bassi nel numero per la leggibilità, come Perl
fa.

Esempio 1: controllare i valori predefiniti per il database localhost

check_postgres_txn_wraparound --host=localhost

Esempio 2: controllare la porta 6000 e fornire un valore critico quando vengono raggiunti 1.7 miliardi di transazioni:

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

Per l'output MRTG, restituisce il numero più alto di transazioni per tutti i database sulla riga uno,
mentre la riga 4 indica di quale database si tratta.

versione
("symlink: check_postgres_version") Verifica che la versione richiesta di Postgres sia
in esecuzione. Il --avvertimento ed --critico opzioni (è richiesta solo una) devono essere del formato
XY or XYZ where X è il numero di versione principale, Y è il numero di versione minore, e Z is
la revisione.

Esempio 1: fornire un avviso se il database sulla porta 5678 non è la versione 8.4.10:

check_postgres_version --port=5678 -w=8.4.10

Esempio 2: fornire un avviso se qualsiasi database su host valley,grain o sunshine non è 8.3:

check_postgres_version -H valle,grano,sole --critical=8.3

Per l'output MRTG, riporta un 1 o uno 0 che indica l'esito positivo o negativo sulla prima riga. Il
la quarta riga indica la versione corrente. La versione deve essere fornita tramite il "--mrtg"
opzione.

file_wal
("symlink: check_postgres_wal_files") Controlla quanti file WAL esistono nel pg_xlog
directory, che si trova fuori dal tuo directory_dati, a volte come collegamento simbolico a un altro
disco fisico per motivi di prestazioni. Questa azione deve essere eseguita come superutente per
accedere ai contenuti del pg_xlog directory. La versione minima per utilizzare questa azione è
Postgres 8.1. Il --avvertimento ed --critico le opzioni sono semplicemente il numero di file nel
pg_xlog directory. Il numero su cui impostarlo varierà, ma una linea guida generale è quella di mettere
un numero leggermente superiore a quello che normalmente c'è, per individuare i problemi in anticipo.

Normalmente, i file WAL vengono chiusi e quindi riutilizzati, ma una transazione aperta di lunga durata o a
difettoso archivio_comando script, potrebbe causare la creazione di troppi file da parte di Postgres. In definitiva,
questo farà esaurire lo spazio sul disco su cui si trovano, a quel punto Postgres lo farà
spegnimento.

Esempio 1: verificare che il numero di file WAL sia 20 o meno sull'host "pluto"

check_postgres_wal_files --host=pluto --critical=20

Per l'output MRTG, riporta il numero di file WAL sulla riga 1.

ricostruire_link simbolici
ricostruire_symlinks_force
Questa azione non richiede altri argomenti e non si connette a nessun database, ma semplicemente
crea collegamenti simbolici nella directory corrente per ogni azione, nella forma
check_postgres_. Se il file esiste già, non verrà sovrascritto. Se
l'azione è build_symlinks_force, quindi i collegamenti simbolici verranno sovrascritti. L'opzione
--symlinks è un modo più breve per dire --action=rebuild_symlinks

BASIC FILTRO

Le opzioni --includere ed --escludere possono essere combinati per limitare le cose da controllare,
a seconda dell'azione. Il nome del database può essere filtrato quando si utilizza quanto segue
azioni: backend, database_size, lock, query_time, txn_idle e txn_time. Il nome di
una relazione può essere filtrata quando si utilizzano le seguenti azioni: bloat, index_size,
table_size, relationship_size, last_vacuum, last_autovacuum, last_analyze e
last_autoanalyze. Il nome di un'impostazione può essere filtrato quando si utilizza settings_checksum
azione. Il nome di un file system può essere filtrato quando si utilizza l'azione disk_space.

Se viene fornita solo un'opzione di inclusione, verranno controllate SOLO le voci che corrispondono.
Tuttavia, se vengono forniti sia l'esclusione che l'inclusione, viene eseguita prima l'esclusione e l'inclusione
dopo, per ripristinare cose che potrebbero essere state escluse. Entrambi --includere ed --escludere può
essere dato più volte e/o come elenchi separati da virgole. Una tilde principale corrisponderà a
seguente parola come espressione regolare.

Per abbinare uno schema, termina il termine di ricerca con un singolo punto. È possibile utilizzare le tilde principali
anche per gli schemi

Fai attenzione quando usi il filtro: una regola di inclusione sui backend, ad esempio, potrebbe
segnala nessun problema non solo perché il database corrispondente non aveva backend, ma perché tu
ha sbagliato a scrivere il nome del database!

Consigli d'uso:

Controlla solo gli elementi denominati pg_class:

--include=classe_pg

Controlla solo gli elementi che contengono le lettere 'pg_':

--include=~pg_

Controlla solo gli elementi che iniziano con 'pg_':

--include=~^pg_

Escludi l'elemento denominato "test":

--exclude=prova

Escludi tutti gli elementi che contengono le lettere "test:

--exclude=~prova

Escludi tutti gli elementi nello schema 'pg_catalog':

--exclude='pg_catalog.'

Escludi tutti gli elementi contenenti le lettere "asso", ma consenti l'elemento "confronto":

--exclude=~asso --include=faceoff

Escludi tutti gli elementi che iniziano con le lettere 'pg_', che contengono le lettere 'slon', o
che sono denominati 'sql_settings' o 'green'. Controlla in particolare gli articoli con le lettere
'prod' nei loro nomi e controlla sempre l'elemento denominato 'pg_relname':

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

UTENTE NOME FILTRO

Le opzioni --includeutente ed --excludeutente può essere utilizzato su alcune azioni solo per esaminare
oggetti di database di proprietà di (o non di proprietà di) uno o più utenti. Un --includeutente opzione
vince sempre e --excludeutente opzione. Puoi assegnare ciascuna opzione più di una volta per
più utenti, oppure puoi fornire un elenco separato da virgole. Le azioni che attualmente utilizzano
queste opzioni sono:

dimensione_database
ultima_analisi
last_autoanalyze
ultimo_vuoto
last_autovacuum
query_time
dimensione_relazione
txn_time

Consigli d'uso:

Controlla solo gli elementi di proprietà dell'utente denominato greg:

--includeutente=greg

Controlla solo gli oggetti di proprietà di Watson o Crick:

--includeuser=watson, crick

Controlla solo gli articoli di proprietà di crick, franklin, watson o wilkins:

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

Controllare tutti gli elementi ad eccezione di quelli appartenenti all'utente scott:

--excludeuser=scott

TEST MODE

Per aiutare nella configurazione, questo programma può essere eseguito in una "modalità di test" specificando il
--test opzione. Questo eseguirà alcuni test di base per assicurarsi che i database possano essere
contattato e che siano soddisfatti determinati prerequisiti per azione, ad esempio se l'utente è
un superutente, se la versione di Postgres è abbastanza nuova e se stats_row_level è abilitato.

Usa check_postgres_sequencep online utilizzando i servizi onworks.net