check_postgres_locksp - Online na nuvem

PROGRAMA:

NOME

check_postgres - um script de monitoramento Postgres para Nagios, MRTG, Cacti e outros

Este documento descreve o check_postgres versão 2.22.0

SINOPSE

## Crie todos os links simbólicos
check_postgres --links simbólicos

## Verifique a conexão com o banco de dados Postgres 'pluto':
check_postgres --action = connection --db = pluto

## Mesmas coisas, mas usando o link simbólico
check_postgres_connection --db = pluto

## Avisar se> 100 bloqueios, crítico se> 200 ou> 20 exclusivos
check_postgres_locks --warning = 100 --critical = "total = 200: exclusivo = 20"

## Mostra o número atual de conexões inativas na porta 6543:
check_postgres_txn_idle --port = 6543 --output = simples

## Existem muitas outras ações e opções, continue lendo.

As últimas notícias e documentação podem sempre ser encontradas em:
http://bucardo.org/check_postgres/

DESCRIÇÃO

check_postgres é um script Perl que executa muitos testes diferentes em um ou mais
Bancos de dados Postgres. Ele usa o programa psql para coletar as informações e gera a
resulta em um dos três formatos: Nagios, MRTG ou simples.

saída Modos
A saída pode ser alterada usando a opção "--output". A saída padrão é nagios,
embora isso possa ser alterado no início do script, se desejar. A opção atual
escolhas são nagios, mrtg e simples. Para evitar ter que inserir o argumento de saída, cada
tempo, o tipo de saída é automaticamente definido se nenhum argumento --output for fornecido, e se o
o diretório atual possui uma das opções de saída em seu nome. Por exemplo, a criação de um
diretório chamado mrtg e preenchendo-o com links simbólicos por meio do --links simbólicos argumento seria
certifique-se de que qualquer ação executada a partir desse diretório sempre terá como padrão uma saída de "mrtg"
Como um atalho para --output = simple, você pode inserir --simple, que também substitui o
truque de nomenclatura de diretório.

Nagios saída

O formato de saída padrão é para Nagios, que é uma única linha de informação, junto com
quatro códigos de saída específicos:

0 (ok)
1 (AVISO)
2 (CRÍTICO)
3 (DESCONHECIDO)

A linha de saída é uma das palavras acima, dois pontos e uma breve descrição do que
foi medido. Informações estatísticas adicionais, bem como o tempo total do comando
tomada, também pode ser gerada: consulte a documentação sobre os argumentos --mostrar,
--perflilimit e --altura de começar.

MRTG saída

A saída do MRTG é de quatro linhas, com a primeira linha sempre dando um único número de
importância. Quando possível, este número representa um valor real, como um número de
bytes, mas também pode ser 1 ou 0 para ações que retornam apenas "verdadeiro" ou "falso", como
como check_postgres_version. A segunda linha é uma estatística adicional e só é usada para
algumas ações. A terceira linha indica um "tempo de atividade" e não é usada. A quarta linha é um
descrição e geralmente indica o nome do banco de dados a estatística da primeira linha
foi retirado, mas pode ser diferente dependendo da ação.

Algumas ações aceitam um opcional --mrtg argumento para controlar ainda mais a saída.

Consulte a documentação sobre cada ação para obter detalhes sobre a saída MRTG exata para cada uma.

simples saída

A saída simples é simplesmente uma versão truncada do MRTG e simplesmente retorna o
primeiro número e nada mais. Isso é muito útil quando você deseja apenas verificar o estado
de algo, independentemente de qualquer limite. Você pode transformar a saída numérica por
anexando KB, MB, GB, TB ou EB ao argumento de saída, por exemplo:

--output = simples, MB

Cactos saída

A saída do Cacti consiste em um ou mais itens na mesma linha, com um nome simples, um
dois pontos e um número. No momento, a única ação com saída explícita do Cacti é
'dbstats', e usando a opção --output não é necessário neste caso, já que Cacti é o único
saída para esta ação. Para muitas outras ações, usar --simple é o suficiente para fazer Cacti
feliz.

DATABASE CONEXÃO OPÇÕES

Todas as ações aceitam um conjunto comum de opções de banco de dados.

-H NOME or --host = NOME
Conecte-se ao host indicado por NAME. Pode ser uma lista de nomes separados por vírgulas.
Vários argumentos de host são permitidos. Se nenhum host for fornecido, o padrão é "PGHOST"
variável de ambiente ou nenhum host (o que indica o uso de um soquete Unix local).
Você também pode usar "--dbhost".

-p PORT or --port = PORT
Conecta usando o número da PORTA especificado. Pode ser uma lista de portas separada por vírgulas
números e vários argumentos de porta são permitidos. Se nenhum número de porta for fornecido, o padrão
à variável de ambiente "PGPORT". Se não estiver definido, o padrão é 5432. Você pode
também use "--dbport"

-db NOME or --dbname = NAME
Especifica a qual banco de dados se conectar. Pode ser uma lista de nomes separados por vírgulas e
vários argumentos dbname são permitidos. Se nenhuma opção dbname for fornecida, o padrão é
a variável de ambiente "PGDATABASE". Se não for definido, o padrão é 'postgres'
se o psql for a versão 8 ou superior, e 'template1' caso contrário.

-u NOME DE USUÁRIO or --dbuser = NOME DE USUÁRIO
O nome do usuário do banco de dados com o qual se conectar. Pode ser uma lista separada por vírgulas de
nomes de usuário e vários argumentos dbuser são permitidos. Se não for fornecido,
o padrão é a variável de ambiente "PGUSER", caso contrário, o padrão é 'postgres'.

--dbpass = SENHA
Fornece a senha para conexão com o banco de dados. O uso desta opção é altamente
desanimado. Em vez disso, deve-se usar um arquivo .pgpass ou pg_service.conf.

--dbservice = NOME
O nome de um serviço dentro do arquivo pg_service.conf. Antes da versão 9.0 de
Postgres, este é um arquivo global, geralmente encontrado em /etc/pg_service.conf. Se você é
usando a versão 9.0 ou superior do Postgres, você pode usar o arquivo ".pg_service.conf" em
o diretório inicial do usuário que está executando o script, por exemplo, nagios.

Este arquivo contém uma lista simples de opções de conexão. Você também pode passar
informações ao usar esta opção, como --dbservice = "maindatabase sslmode = require"

A documentação para este arquivo pode ser encontrada em
http://www.postgresql.org/docs/current/static/libpq-pgservice.html

As opções de conexão do banco de dados podem ser agrupadas: --host = a, b --host = c --port = 1234
--port = 3344 se conectaria a a-1234, b-1234 e c-3344. Observe que, uma vez definida, uma opção
continua até que seja alterado novamente.

Exemplos:

--host = a, b --port = 5433 --db = c
Conecta-se duas vezes à porta 5433, usando o banco de dados c, aos hosts a e b: a-5433-c b-5433-c

--host = a, b --port = 5433 --db = c, d
Conecta-se quatro vezes: a-5433-c a-5433-d b-5433-c b-5433-d

--host = a, b --host = foo --port = 1234 --port = 5433 --db = e, f
Conecta-se seis vezes: 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
Conecta-se três vezes: a-5432-alice-baz b-5433-alice-baz x-5433-bob-baz

--dbservice = "foo" --port = 5433
Conecta-se usando o serviço nomeado 'foo' no arquivo pg_service.conf, mas substitui a porta

OUTROS OPÇÕES

Outras opções incluem:

--action = NAME
Declara qual ação estamos executando. Obrigatório, a menos que use um arquivo com link simbólico, no qual
caso o nome do arquivo seja usado para descobrir a ação.

- advertência = VAL or -w VAL
Define o limite no qual um alerta de aviso é disparado. As opções válidas para este
opção depende da ação usada.

--critical = VAL or -c VAL
Define o limite no qual um alerta crítico é disparado. As opções válidas para este
opção depende da ação usada.

-t VAL or --timeout = VAL
Define o tempo limite em segundos após o qual o script abortará tudo o que estiver fazendo e
retornar um status DESCONHECIDO. O tempo limite é por cluster Postgres, não para todo o
roteiro. O valor padrão é 10; as unidades estão sempre em segundos.

--assume-modo de espera
Se especificado, primeiro a verificação se o servidor em modo de espera será realizada (--datadir
é obrigatório), em caso afirmativo, todas as verificações que exigem consultas SQL serão ignoradas e "Servidor
no modo de espera "com o status OK será retornado.

Exemplo:

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

--assume-prod
Se especificado, verifique se o servidor em modo de produção é executado (--datadir é necessário).
A opção só é relevante para ("link simbólico: check_postgres_checkpoint").

Exemplo:

postgres@db$./check_postgres --action = checkpoint --datadir /var/lib/postgresql/8.3/main/ --assume-prod
POSTGRES_CHECKPOINT OK: O último ponto de verificação foi há 72 segundos | idade = 72 ;; modo 300 = MASTER

-h or --Socorro
Exibe uma tela de ajuda com um resumo de todas as ações e opções.

--cara
Exibe todo o manual.

-V or --versão
Mostra a versão atual.

-v or --verbose
Defina o nível de verbosidade. Pode chamar mais de uma vez para aumentar o nível. Configurando para
três ou mais (em outras palavras, emitir "-v -v -v") ativa as informações de depuração
para este programa que é enviado para stderr.

--showperf = VAL
Determina se geramos dados de desempenho adicionais no formato padrão do Nagios (no final
de string, após um símbolo de barra vertical, usando nome = valor). VAL deve ser 0 ou 1. O padrão
é 1. Só tem efeito se estiver usando o modo de saída do Nagios.

--perflimit = i
Define um limite de quantos itens de interesse são relatados ao usar o
showperf opção. Isso só tem efeito para ações que retornam um grande número de
itens, como tamanho_tabela. O padrão é 0 ou sem limite. Tenha cuidado ao usar este
com o --incluir or --excluir opções, uma vez que essas restrições são feitas depois de da
a consulta foi executada e, portanto, seu limite pode não incluir os itens que você deseja. Só leva
efeito se estiver usando o modo de saída Nagios.

--showtime = VAL
Determina se o tempo gasto para executar cada consulta é mostrado na saída. VAL deve ser 0
ou 1. O padrão é 1. Nenhum efeito, a menos que showperf está ligado. Só tem efeito se usar
Modo de saída do Nagios.

--teste
Ativa o modo de teste. Consulte a seção "MODO DE TESTE" abaixo.

--PGBINDIR = PATH
Diz ao script onde encontrar os binários do psql. Útil se você tiver mais de um
versão dos executáveis ​​PostgreSQL em seu sistema, ou se não houver em seu
caminho. Observe que esta opção está em letras maiúsculas. Por padrão, esta opção é não
permitidas. Para habilitá-lo, você deve alterar o $ NO_PSQL_OPTION próximo ao topo do script
para 0. Evite usar esta opção se puder e, em vez disso, use a variável de ambiente
c ou a variável $ PGBINDIR codificada, também perto do topo do script, para definir
o caminho para o PostgreSQL a ser usado.

--PSQL = PATH
(descontinuada, esse opção pode be afastado in a futuro liberar!) Diz ao script onde
para localizar o programa psql. Útil se você tiver mais de uma versão do psql
executável em seu sistema ou se não houver um programa psql em seu caminho. Observe que este
opção está em maiúsculas. Por padrão, esta opção é não permitidas. Para habilitá-lo, você
deve alterar $ NO_PSQL_OPTION próximo ao topo do script para 0. Evite usar isto
opção se você puder e, em vez disso, codifique sua localização psql na variável $ PSQL,
também próximo ao início do script.

--links simbólicos
Cria links simbólicos para o programa principal de cada ação.

--output = VAL
Determina o formato da saída, para uso em vários programas. O padrão é
'nagios'. As opções disponíveis são 'nagios', 'mrtg', 'simples' e 'cactos'.

--mrtg = VAL
Usado apenas para MRTG ou saída simples, para algumas ações específicas.

--debugoutput = VAL
Gera a string exata retornada pelo psql, para uso na depuração. O valor é um ou
mais letras, que determinam se a saída é exibida ou não, onde 'a' = todos, 'c'
= crítico, 'w' = aviso, 'o' = ok e 'u' = desconhecido. As letras podem ser combinadas.

--get_method = VAL
Permite a especificação do método usado para buscar informações para o "new_version_cp",
verificações "new_version_pg", "new_version_bc", "new_version_box" e "new_version_tnm".
Os seguintes programas são tentados, a fim de obter as informações da web: GET,
wget, fetch, curl, lynx, links. Para forçar o uso de apenas um (e, assim, remover o
sobrecarga de tentar todos os outros até um desses trabalhos), digite um dos nomes como
o argumento para get_method. Por exemplo, uma caixa BSD pode inserir a seguinte linha em
seu arquivo ".check_postgresrc":

get_method = fetch

--language = VAL
Defina o idioma a ser usado para todas as mensagens de saída. Normalmente, isso é detectado por
examinando as variáveis ​​de ambiente LC_ALL, LC_MESSAGES e LANG, mas definindo isso
opção irá substituir qualquer detecção.

AÇÕES

O script executa uma ou mais ações. Isso pode ser feito com o sinalizador --action ou por
usando um link simbólico para o arquivo principal que contém o nome da ação dentro dele. Para
exemplo, para executar a ação "timesync", você pode emitir:

check_postgres --action = timesync

ou use um programa chamado:

check_postgres_timesync

Todos os links simbólicos são criados para você no diretório atual se usar a opção --symlinks

perl check_postgres --symlinks

Se o nome do arquivo já existir, ele não será sobrescrito. Se o arquivo existe e é um
link simbólico, você pode forçá-lo a sobrescrever usando "--action = build_symlinks_force"

A maioria das ações leva um --aviso e de um --crítico opção, indicando em que ponto nós mudamos
de OK para WARNING, e em que ponto vamos para CRITICAL. Observe que, porque os críticos são
sempre verificado primeiro, definir o aviso igual ao crítico é uma forma eficaz de
desligue os avisos e sempre dê uma crítica.

As ações atualmente suportadas são:

arquivo_pronto
("link simbólico: check_postgres_archive_ready") Verifica quantos arquivos WAL com extensão .pronto
existe no pg_xlog / archive_status diretório, que é encontrado fora de seu diretório_dados.
Esta ação deve ser executada como um superusuário, a fim de acessar o conteúdo do
pg_xlog / archive_status diretório. A versão mínima para usar esta ação é Postgres 8.1.
A --aviso e --crítico as opções são simplesmente o número de .pronto arquivos no
pg_xlog / archive_status diretório. Normalmente, esses valores devem ser baixos, ligando o
mecanismo de arquivo, geralmente queremos arquivar arquivos WAL o mais rápido possível.

Se o comando de arquivo falhar, número de WAL em seu pg_xlog diretório vai crescer até
esgotando todo o espaço em disco e forçando o PostgreSQL a parar imediatamente.

Exemplo 1: verifique se o número de arquivos WAL prontos é 10 ou menos no host "pluto"

check_postgres_archive_ready --host = pluto --critical = 10

Para saída MRTG, relata o número de arquivos WAL prontos na linha 1.

autovac_freeze
("link simbólico: check_postgres_autovac_freeze") Verifica quão próximo cada banco de dados está do
postgres autovacuum_freeze_max_age configuração. Esta ação só funcionará para bancos de dados
versão 8.2 ou superior. o --aviso e --crítico opções devem ser expressas como
percentagens. A 'idade' das transações em cada banco de dados é comparada ao
configuração autovacuum_freeze_max_age (200 milhões por padrão) para gerar um
percentagem. Os valores padrão são 90% para o aviso e 95% para o crítico. Bancos de dados
pode ser filtrado pelo uso do --incluir e --excluir opções. Veja a seção "FILTRAGEM BÁSICA"
seção para mais detalhes.

Exemplo 1: Dê um aviso quando qualquer banco de dados na porta 5432 estiver acima de 97%

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

Para a saída MRTG, a maior porcentagem geral é relatada na primeira linha, e o
a maior idade é relatada na segunda linha. Todos os bancos de dados que têm a porcentagem de
a primeira linha é relatada na quarta linha, separada por um símbolo de barra vertical.

backends
("link simbólico: check_postgres_backends") Verifica o número atual de conexões para um ou
mais bancos de dados e, opcionalmente, compara-o ao máximo permitido, que é determinado por
a variável de configuração Postgres max_connections. O --aviso e --crítico opções
pode assumir uma das três formas. Primeiro, um número simples pode ser dado, o que representa o
número de conexões em que o alerta será dado. Esta escolha não usa o
max_connections configuração. Em segundo lugar, a porcentagem de conexões disponíveis pode ser fornecida.
Terceiro, um número negativo pode ser dado, o que representa o número de conexões restantes
até max_connections é atingido. Os valores padrão para --aviso e --crítico e guarante que os mesmos estão
'90% 'e '95%'. Você também pode filtrar os bancos de dados usando o --incluir e --excluir
opções. Consulte a seção "FILTRAGEM BÁSICA" para obter mais detalhes.

Para visualizar apenas processos não ociosos, você pode usar o --noidle argumento. Observe que o usuário que você
estão se conectando, pois deve ser um superusuário para que isso funcione corretamente.

Exemplo 1: Dê um aviso quando o número de conexões no host quirm atingir 120, e um
crítico se chegar a 150.

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

Exemplo 2: Dê um crítico quando atingirmos 75% de nossa configuração max_connections nos hosts
lancre ou lancre2.

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

Exemplo 3: Dê um aviso quando houver apenas mais 10 slots de conexão restantes no host
plasmídeo, e um crítico quando temos apenas 5 restantes.

check_postgres_backends --warning = -10 --critical = -5 --host = plasmídeo

Exemplo 4: verifique todos os bancos de dados, exceto aqueles com "teste" em seus nomes, mas permita aqueles que
são chamados de "pg_greatest". Conecte-se como porta 5432 nos primeiros dois hosts e como porta 5433 em
o terceiro. Queremos sempre lançar um crítico quando chegarmos a 30 ou mais conexões.

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

Para saída MRTG, o número de conexões é relatado na primeira linha e na quarta
line fornece o nome do banco de dados, mais o maximum_connections atual. Se mais que
um banco de dados foi consultado, aquele com o maior número de conexões é gerado.

inchar
("link simbólico: check_postgres_bloat") Verifica a quantidade de inchaço nas tabelas e índices. (Inchar
é geralmente a quantidade de espaço morto não utilizado ocupado em uma tabela ou índice. Este espaço é
geralmente recuperado pelo uso do comando VACUUM.) Esta ação requer estatísticas
coleção seja habilitada nos bancos de dados de destino e requer que ANALYZE seja executado
freqüentemente. o --incluir e --excluir opções podem ser usadas para filtrar quais tabelas
Olhe para. Consulte a seção "FILTRAGEM BÁSICA" para obter mais detalhes.

A --aviso e --crítico as opções podem ser especificadas como tamanhos, porcentagens ou ambos. Válido
unidades de tamanho são bytes, kilobytes, megabytes, gigabytes, terabytes, exabytes, petabytes e
zetabytes. Você pode abreviar todos aqueles com a primeira letra. Itens sem unidades são
assumido como 'bytes'. Os valores padrão são '1 GB' e '5 GB'. O valor representa o
número de "bytes perdidos", ou a diferença entre o que é realmente usado pela mesa e
índice, e o que calculamos que deveria ser.

Observe que esta ação tem dois valores embutidos em código para evitar alarmes falsos em menores
relações. As tabelas devem ter pelo menos 10 páginas, e índices pelo menos 15, antes que possam ser
considerado por este teste. Se você realmente deseja ajustar esses valores, pode procurar o
variáveis $ MINPAGES e $ MINIPAGES na parte superior da sub-rotina "check_bloat". Esses
os valores são ignorados se qualquer um --excluir or --incluir é usado.

Apenas as dez relações mais inchadas são mostradas. Você pode alterar este número usando o
--perflilimit opção de definir seu próprio limite.

O esquema denominado 'information_schema' é excluído deste teste, pois as únicas tabelas dele
contém são pequenos e não mudam.

Observe que os valores calculados por esta ação não são precisos e devem ser usados ​​como
apenas uma diretriz. Grande esforço foi feito para estimar o tamanho correto de uma mesa, mas em
no final, é apenas uma estimativa. O tamanho correto do índice é ainda mais suspeito do que o
tamanho correto da mesa, mas ambos devem dar uma ideia aproximada de como as coisas estão inchadas.

Exemplo 1: avisa se alguma tabela na porta 5432 está inchada com mais de 100 MB e crítica se mais de 200
MB

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

Exemplo 2: dê uma crítica se a tabela 'pedidos' no host 'sami' tiver mais de 10 megas de inchaço

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

Exemplo 3: Dê uma crítica se a tabela 'q4' no banco de dados 'vendas' estiver mais de 50% inchada

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

Exemplo 4: Dê uma crítica a qualquer mesa que esteja mais de 20% inchada e tem mais de 150 MB de inchaço:

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

Exemplo 5: Dê uma crítica a qualquer mesa que esteja mais de 40% inchada or tem mais de 500 MB de inchaço:

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

Para a saída MRTG, a primeira linha fornece o maior número de bytes perdidos para as tabelas,
e a segunda linha fornece o maior número de bytes perdidos para os índices. O quarto
linha fornece o nome do banco de dados, o nome da tabela e as informações do nome do índice. Se você quiser
em vez disso, produza a taxa de inchaço (quantas vezes maior a relação é comparada a como
deve ser grande), apenas passe "--mrtg = proporção".

ponto de verificação
("link simbólico: check_postgres_checkpoint") Determina quanto tempo desde o último ponto de verificação
foi executado. Deve ser executado no mesmo servidor que o banco de dados que está sendo verificado (por exemplo, o
-h sinalizador não funcionará). Esta verificação deve ser executada em um servidor de "espera passiva" que é
processando ativamente os arquivos WAL enviados e tem como objetivo verificar se o seu warm standby está
verdadeiramente 'quente'. O diretório de dados deve ser definido, seja pela variável de ambiente
"PGDATA" ou passando o argumento "--datadir". Ele retorna o número de segundos desde o
o último ponto de verificação foi executado, conforme determinado pela análise da chamada para "pg_controldata". Por causa de
para isso, o executável pg_controldata deve estar disponível no caminho atual. Alternativamente,
você pode especificar "PGBINDIR" como o diretório em que ele reside. Também é possível usar
as opções especiais --assume-prod or --assume-modo de espera, se o modo encontrado não for o
um esperado, um CRITICAL é emitido.

Deve ser definido pelo menos um aviso ou argumento crítico.

Esta ação requer o módulo Date :: Parse.

Para MRTG ou saída simples, retorna o número de segundos.

cluster_id
("link simbólico: check_postgres_cluster-id") Verifica se o identificador do sistema de banco de dados fornecido
por pg_controldata é o mesmo da última vez que você verificou. Deve ser executado no mesmo servidor
como o banco de dados que está sendo verificado (por exemplo, o sinalizador -h não funcionará). Tanto o
--aviso ou de --crítico opção deve ser fornecida, mas não ambas. O valor de cada um é
o identificador do cluster, um valor inteiro. Você pode executar com o especial "--critical = 0"
opção para descobrir um identificador de cluster existente.

Exemplo 1: Encontre o identificador inicial

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

Exemplo 2: Certifique-se de que o cluster é o mesmo e avise se não, usando o resultado acima.

check_postgres_cluster_id --critical = 5633695740047915135

Para saída MRTG, retorna 1 ou 0 indicando sucesso ou falha do identificador para
partida. Um identificador deve ser fornecido como o argumento "--mrtg". A quarta linha sempre
fornece o identificador atual.

compromisso
("link simbólico: check_postgres_commitratio") Verifica a taxa de confirmação de todos os bancos de dados e
reclama quando eles estão muito baixos. Não há necessidade de executar este comando mais de uma vez por
cluster de banco de dados. Os bancos de dados podem ser filtrados com o --incluir e --excluir opções. Ver
a seção "FILTRAGEM BÁSICA" para mais detalhes. Eles também podem ser filtrados pelo proprietário do
o banco de dados com o --includeuser e --excludeuser opções. Veja o "NOME DE USUÁRIO
Seção FILTRAGEM "para mais detalhes.

O aviso e as opções críticas devem ser especificadas como porcentagens. Não há
padrões para esta ação: o aviso e crítico devem ser especificados. O valor de aviso
não pode ser maior que o valor crítico. A saída retorna todos os bancos de dados classificados por
commitratio, o menor primeiro.

Exemplo: avisa se algum banco de dados no host flagg está com menos de 90% na confirmação e é crítico
se menos de 80%.

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

Para saída MRTG, retorna a porcentagem do banco de dados com o menor commitratio em
a primeira linha e o nome do banco de dados na quarta linha.

da conexão
("link simbólico: check_postgres_connection") Simplesmente conecta, emite um 'SELECT versão()'e
sai. Não leva --aviso or --crítico opções.

Para saída MRTG, simplesmente produz 1 (boa conexão) ou 0 (má conexão) no primeiro
linha.

consulta_custom
("link simbólico: check_postgres_custom_query") Executa uma consulta personalizada de sua escolha e analisa
os resultados. A própria consulta é passada por meio do argumento "consulta" e deve ser
mantido o mais simples possível. Se possível, envolva-o em uma visão ou função para manter
coisas mais fáceis de gerenciar. A consulta deve retornar uma ou duas colunas. É necessário que
uma das colunas será chamada de "resultado" e é o item que será verificado em relação ao seu
aviso e valores críticos. A segunda coluna é para os dados de desempenho e qualquer nome
pode ser usado: este será o 'valor' dentro da seção de dados de desempenho.

Deve ser especificado pelo menos um aviso ou argumento crítico. O que eles estão configurados depende
no tipo de consulta que você está executando. Existem quatro tipos de custom_queries que podem ser
run, especificado pelo argumento "valtype". Se nenhum for especificado, esta ação é padronizada para
'inteiro'. Os quatro tipos são:

número inteiro: Faz uma comparação simples de números inteiros. A primeira coluna deve ser um número inteiro simples,
e o aviso e os valores críticos devem ser os mesmos.

corda: O aviso e crítico são cadeias de caracteres e são acionados apenas se o valor no
primeira coluna corresponde exatamente. Isso diferencia maiúsculas de minúsculas.

tempo: O aviso e o crítico são tempos e podem ter unidades de segundos, minutos,
horas ou dias. Cada um pode ser escrito no singular ou abreviado apenas na primeira letra. Se
nenhuma unidade é fornecida, os segundos são assumidos. A primeira coluna deve ser um inteiro
representando o número de segundos para verificar.

tamanho: O aviso e o crítico são tamanhos e podem ter unidades de bytes, kilobytes,
megabytes, gigabytes, terabytes ou exabytes. Cada um pode ser abreviado com a primeira letra.
Se nenhuma unidade for fornecida, os bytes serão assumidos. A primeira coluna deve ser um inteiro
representando o número de bytes a serem verificados.

Normalmente, um alerta é acionado se os valores retornados forem maior do que ou igual ao
valor crítico ou de advertência. No entanto, uma opção de --marcha ré irá disparar o alerta se o
o valor retornado é diminuir do que ou igual ao valor crítico ou de aviso.

Exemplo 1: avisa se alguma relação acima de 100 páginas é chamada de "rad", coloque o número de páginas
dentro da seção de dados de desempenho.

check_postgres_custom_query --valtype = string -w "rad" --query =
"SELECT relname AS result, relpages AS pages FROM pg_class ONDE relpages> 100"

Exemplo 2: dê um crítico se a função "foobar" retornar um número maior que 5 MB:

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

Exemplo 2: avisar se a função "snazzo" retorna menos que 42:

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

Se você vier com um custom_query útil, considere enviar um patch para este programa para
torná-lo uma ação padrão que outras pessoas possam usar.

Esta ação não suporta MRTG ou saída simples ainda.

tamanho_de_dados
("link simbólico: check_postgres_database_size") Verifica o tamanho de todos os bancos de dados e reclama
quando eles são muito grandes. Não há necessidade de executar este comando mais de uma vez por banco de dados
cacho. Os bancos de dados podem ser filtrados com o --incluir e --excluir opções. Veja o
Seção "FILTRAGEM BÁSICA" para mais detalhes. Eles também podem ser filtrados pelo proprietário do
banco de dados com o --includeuser e --excludeuser opções. Veja a seção "FILTRAGEM DE NOME DE USUÁRIO"
seção para mais detalhes.

As opções de aviso e críticas podem ser especificadas como bytes, kilobytes, megabytes,
gigabytes, terabytes ou exabytes. Cada um pode ser abreviado com a primeira letra também.
Se nenhuma unidade for fornecida, as unidades serão consideradas bytes. Não há padrões para este
ação: o aviso e crítico devem ser especificados. O valor do aviso não pode ser maior
do que o valor crítico. A saída retorna todos os bancos de dados classificados por tamanho maior primeiro,
mostrando bytes brutos e uma versão "bonita" do tamanho.

Exemplo 1: avisa se algum banco de dados no host flagg tem mais de 1 TB de tamanho e é crítico se acabou
1.1 TB.

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

Exemplo 2: Dê um crítico se o banco de dados template1 na porta 5432 for maior que 10 MB.

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

Exemplo 3: Dê um aviso se qualquer banco de dados no host 'tardis' pertencente ao usuário 'tom' estiver encerrado
5 GB

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

Para saída MRTG, retorna o tamanho em bytes do maior banco de dados na primeira linha, e
o nome do banco de dados na quarta linha.

dbstats
("link simbólico: check_postgres_dbstats") Informa informações da visão pg_stat_database,
e os produz de uma maneira amigável ao Cacti. Nenhuma outra saída é suportada, pois a saída é
informativo e não se presta a alertas, como o usado com o Nagios. Se não houver opções
são fornecidos, todos os bancos de dados são retornados, um por linha. Você pode incluir um banco de dados específico
usando a opção "--include", ou você pode usar a opção "--dbname".

Onze itens são retornados em cada linha, no formato nome: valor, separados por um único
espaço. Os itens são:

backends
O número de back-ends em execução para este banco de dados.

compromete-se
O número total de confirmações para este banco de dados desde sua criação ou reconfiguração.

reversões
O número total de reversões para este banco de dados desde sua criação ou reconfiguração.

ler
O número total de blocos de disco lidos.

hit O número total de ocorrências do buffer.

ret O número total de linhas retornadas.

buscar
O número total de linhas buscadas.

ins O número total de linhas inseridas.

upd O número total de linhas atualizadas.

del O número total de linhas excluídas.

nome do banco de dados
O nome do banco de dados.

Observe que os itens ret, fetch, ins, upd e del serão sempre 0 se o Postgres for a versão 8.2
ou inferior, pois essas estatísticas não estavam disponíveis nessas versões.

Se o argumento dbname for fornecido, sete itens adicionais serão retornados:

idxscan
Número total de varreduras de índice do usuário.

idxtupleado
Número total de entradas de índice do usuário retornadas.

idxtupfetch
Número total de linhas buscadas por varreduras simples de índice do usuário.

idxblksler
Número total de blocos de disco lidos para todos os índices do usuário.

idxblkmerda
Número total de ocorrências de buffer para todos os índices do usuário.

seqscan
Número total de varreduras sequenciais em todas as tabelas do usuário.

sequência
Número total de tuplas retornadas de todas as tabelas do usuário.

Exemplo 1: pegue as estatísticas de um banco de dados denominado "produtos" no host "salgueiro":

check_postgres_dbstats --dbhost willow --dbname produtos

A saída retornada será assim (tudo em uma linha, não agrupado):

backends: 82 confirmações: 58374408 reversões: 1651 leitura: 268435543 hit: 2920381758 idxscan: 310931294 idxtupread: 2777040927
idxtupfetch: 1840241349 idxblksread: 62860110 idxblkshit: 1107812216 seqscan: 5085305 seqtupread: 5370500520
ret: 0 fetch: 0 ins: 0 upd: 0 del: 0 dbname: willow

Disabled_triggers
("link simbólico: check_postgres_disabled_triggers") Verifica o número de gatilhos desativados
dentro do banco de dados. o --aviso e --crítico as opções são o número de tais gatilhos
encontrado, e ambos padrão em "1", já que em uso normal ter gatilhos desabilitados é um perigoso
evento. Se o banco de dados que está sendo verificado for 8.3 ou superior, a verificação é para o número de
gatilhos que estão em um status 'desativado' (em oposição a estar 'sempre' ou 'réplica'). o
a saída mostrará o nome da tabela e o nome do gatilho para cada desativado
desencadear.

Exemplo 1: certifique-se de que não há gatilhos desativados

check_postgres_disabled_triggers

Para saída MRTG, retorna o número de gatilhos desativados na primeira linha.

espaço em disco
("link simbólico: check_postgres_disk_space") Verifica o espaço em disco físico disponível usado por
Postgres. Esta ação requer que você tenha o executável "/ bin / df"disponível para relatar
em tamanhos de disco, e também precisa ser executado como um superusuário, para que possa examinar o
diretório_dados configuração dentro do Postgres. o --aviso e --crítico opções são dadas
em tamanhos ou porcentagens ou em ambos. Se usar tamanhos, os tipos de unidade padrão são
permitido: bytes, kilobytes, gigabytes, megabytes, gigabytes, terabytes ou exabytes. Cada
pode ser abreviado apenas na primeira letra; nenhuma unidade indica 'bytes'. o
os valores padrão são '90% 'e '95%'.

Este comando verifica o seguinte para determinar todos os diferentes discos físicos
sendo usado pelo Postgres.

diretório_dados - O disco onde está o diretório de dados principal.

log anuário - O disco em que os arquivos de log estão.

WAL lima anuário - O disco em que os logs de gravação antecipada estão (por exemplo, pg_xlog com link simbólico)

espaços de mesa - Cada espaço de tabela que está em um disco separado.

A saída mostra o tamanho total usado e disponível em cada disco, bem como o
porcentagem, ordenada da maior para a menor porcentagem usada. Cada item acima mapeia para um arquivo
sistema: estes podem ser incluídos ou excluídos. Veja a seção "FILTRAGEM BÁSICA" para mais
Detalhes.

Exemplo 1: Certifique-se de que nenhum sistema de arquivos seja superior a 90% para o banco de dados na porta 5432.

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

Exemplo 2: Verifique se todos os sistemas de arquivos começando com / dev / sda são menores que 10 GB e
11 GB (aviso e crítico)

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

Exemplo 4: Certifique-se de que nenhum sistema de arquivos seja superior a 50% e tem mais de 15 GB

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

Exemplo 5: Emita um aviso se algum sistema de arquivos estiver mais de 70% cheio or tem mais de 1T

check_postgres_disk_space --warning = '1T ou 75'

Para saída MRTG, retorna o tamanho em bytes do sistema de arquivos na primeira linha, e o
nome do sistema de arquivos na quarta linha.

fsm_pages
("link simbólico: check_postgres_fsm_pages") Verifica quão próximo um cluster está do Postgres
max_fsm_pages configuração. Esta ação só funcionará para bancos de dados de 8.2 ou superior, e
requer o módulo contrib pg_freespacemap ser instalado. o --aviso e --crítico
as opções devem ser expressas em percentagens. O número de páginas usadas no mapa de espaço livre
é determinado olhando na visualização pg_freespacemap_relations e executando uma fórmula
com base na fórmula usada para a saída de slots de página de mapa de espaço livre na verbosidade do vácuo
comando. Os valores padrão são 85% para o aviso e 95% para o crítico.

Exemplo 1: dar um aviso quando nosso cluster tiver usado até 76% dos slots de página de espaço livre,
com pg_freespacemap instalado no banco de dados robert

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

Embora você precise passar o nome do banco de dados onde o pg_freespacemap está instalado, você
só precisa executar essa verificação uma vez por cluster. Além disso, verificar essas informações exige
obter bloqueios especiais no mapa do espaço livre, por isso é recomendável que você não execute este
verifique com intervalos curtos.

Para saída MRTG, retorna a porcentagem do mapa do espaço livre na primeira linha, e o número
de páginas atualmente usadas na segunda linha.

relações_fsm
("link simbólico: check_postgres_fsm_relations") Verifica quão próximo um cluster está do Postgres
max_fsm_relations configuração. Esta ação só funcionará para bancos de dados de 8.2 ou superior, e
requer o módulo contrib pg_freespacemap ser instalado. o --aviso e --crítico
as opções devem ser expressas em percentagens. O número de relações usadas na livre
o mapa do espaço é determinado olhando na visão pg_freespacemap_relations. O padrão
valores são 85% para o aviso e 95% para o crítico.

Exemplo 1: avise quando nosso cluster tiver usado 80% das relações de espaço livre,
com pg_freespacemap instalado no banco de dados dylan

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

Embora você precise passar o nome do banco de dados onde o pg_freespacemap está instalado, você
só precisa executar essa verificação uma vez por cluster. Além disso, verificar essas informações exige
obter bloqueios especiais no mapa do espaço livre, por isso é recomendável que você não execute este
verifique com intervalos curtos.

Para saída MRTG, retorna a porcentagem do mapa do espaço livre na primeira linha, o número de
relações atualmente usadas na segunda linha.

taxa de acerto
("link simbólico: check_postgres_hitratio") Verifica a taxa de acerto de todos os bancos de dados e reclama
quando eles estão muito baixos. Não há necessidade de executar este comando mais de uma vez por banco de dados
cacho. Os bancos de dados podem ser filtrados com o --incluir e --excluir opções. Veja o
Seção "FILTRAGEM BÁSICA" para mais detalhes. Eles também podem ser filtrados pelo proprietário do
banco de dados com o --includeuser e --excludeuser opções. Veja a seção "FILTRAGEM DE NOME DE USUÁRIO"
seção para mais detalhes.

O aviso e as opções críticas devem ser especificadas como porcentagens. Não há
padrões para esta ação: o aviso e crítico devem ser especificados. O valor de aviso
não pode ser maior que o valor crítico. A saída retorna todos os bancos de dados classificados por
hitratio, o menor primeiro.

Exemplo: avisa se qualquer banco de dados no host flagg é inferior a 90% em hitratio, e crítico se
menos de 80%.

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

Para saída MRTG, retorna a porcentagem do banco de dados com o menor hitratio no
primeira linha e o nome do banco de dados na quarta linha.

hot_standby_delay
("link simbólico: check_hot_standby_delay") Verifica o atraso de replicação de streaming calculando o
delta entre a posição xlog atual de um servidor mestre e a localização de reprodução de um
escravo conectado a ele. O servidor escravo deve estar em modo hot_standby (por exemplo, somente leitura),
portanto, a versão mínima para usar esta ação é Postgres 9.0. o --aviso e
--crítico as opções são o delta entre os locais do xlog. Uma vez que esses valores são bytes
compensações no WAL devem corresponder ao volume de transação esperado de seu aplicativo
para evitar falsos positivos ou negativos.

As primeiras opções "--dbname", "--host" e "--port", etc. são consideradas mestras; a
o segundo pertence ao escravo.

Os valores de byte devem ser baseados no volume de transações necessárias para ter o streaming
replicação desconectar do mestre por causa de muito lag, determinado pelo Postgres
variável de configuração wal_keep_segments. Para unidades de tempo, as unidades válidas são 'segundos',
'minutos', 'horas' ou 'dias'. Cada um pode ser escrito no singular ou abreviado apenas para o
primeira carta. Ao especificar ambos, no formulário 'bytes e tempo', ambas as condições devem ser
verdadeiro para que o limite seja atingido.

Você deve fornecer informações sobre como acessar os bancos de dados, fornecendo uma vírgula separada
lista os parâmetros --dbhost e --dbport, como "--dbport = 5432,5543". Se não for dado,
a ação falha.

Exemplo 1: Avisar que um banco de dados com uma réplica local na porta 5433 está atrasado em qualquer xlog replay
absolutamente

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

Exemplo 2: Dê um crítico se a última transação que a réplica 1 recebe for maior que 10
minutos atrás

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

Exemplo 3: Permita que a réplica 1 esteja 1 segmento WAL atrás, se o mestre estiver vendo momentaneamente
mais atividade do que a conexão de replicação de streaming pode suportar, ou 10 minutos atrás,
se o mestre está vendo muito pouca atividade e não processando nenhuma transação, mas não
ambos, o que indicaria um problema duradouro com a conexão de replicação.

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

tamanho_índice
tamanho_tabela
tamanho_relação
(links simbólicos: "check_postgres_index_size", "check_postgres_table_size", e
"check_postgres_relation_size") As ações tamanho_tabela e tamanho_índice são simplesmente
variações do tamanho_relação ação, que verifica se há uma relação que também cresceu
grande. Relações (em outras palavras, tabelas e índices) podem ser filtradas com o --incluir
e --excluir opções. Consulte a seção "FILTRAGEM BÁSICA" para obter mais detalhes. Relações podem
também podem ser filtrados pelo usuário que os possui, usando o --includeuser e --excludeuser
opções. Consulte a seção "FILTRAGEM DE NOME DE USUÁRIO" para obter mais detalhes.

Os valores para o --aviso e --crítico as opções são tamanhos de arquivo e podem ter unidades de
bytes, kilobytes, megabytes, gigabytes, terabytes ou exabytes. Cada um pode ser abreviado
à primeira letra. Se nenhuma unidade for fornecida, os bytes serão assumidos. Não há padrão
valores: o aviso e a opção crítica devem ser fornecidos. O texto de retorno mostra o
tamanho da maior relação encontrada.

Se o --mostrar opção está habilitada, todos os das relações com seus tamanhos serão dados.
Para evitar isso, é recomendável que você defina o --perflilimit opção, o que causará
a consulta para fazer um "ORDER BY size DESC LIMIT (perflimit)".

Exemplo 1: Dê um crítico se alguma tabela for maior que 600 MB no burrick do host.

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

Exemplo 2: avisa se o produto de mesa tem mais de 4 GB de tamanho e fornece um crítico de 4.5 GB.

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

Exemplo 3: avisa se algum índice não pertencente ao postgres ultrapassar 500 MB.

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

Para saída MRTG, retorna o tamanho em bytes da maior relação e o nome do
banco de dados e relação como a quarta linha.

última_analisar
último_vácuo
last_autoanalyze
last_autovacuum
(links simbólicos: "check_postgres_last_analyze", "check_postgres_last_vacuum",
"check_postgres_last_autoanalyze" e "check_postgres_last_autovacuum") Verifica quanto tempo
tem sido desde a última execução do vácuo (ou análise) em cada tabela em um ou mais bancos de dados.
O uso dessas ações requer que o banco de dados de destino seja a versão 8.3 ou superior, ou que
a versão é 8.2 e a variável de configuração stats_row_level foi habilitado. Mesas
pode ser filtrado com o --incluir e --excluir opções. Veja a seção "FILTRAGEM BÁSICA"
seção para mais detalhes. As tabelas também podem ser filtradas por seus proprietários usando o
--includeuser e --excludeuser opções. Veja a seção "FILTRAGEM DE NOME DE USUÁRIO" para mais
Detalhes.

As unidades para --aviso e --crítico são especificados como horas. As unidades válidas são segundos,
minutos, horas e dias; todos podem ser abreviados com a primeira letra. Se nenhuma unidade for
dado, 'segundos' são assumidos. Os valores padrão são '1 dia' e '2 dias'. Observe
que há casos em que este campo não é preenchido automaticamente. Se certo
as tabelas estão causando problemas, certifique-se de que elas tenham linhas mortas para limpar ou apenas
excluí-los do teste.

O esquema denominado 'information_schema' é excluído deste teste, pois as únicas tabelas dele
contém são pequenos e não mudam.

Observe que as versões não 'automáticas' também verificarão as versões automáticas. Em outro
palavras, usando last_vacuum irá relatar no último vácuo, se foi um vácuo normal,
ou um executado pelo daemon autovacuum.

Exemplo 1: Avise se alguma mesa não tiver sido aspirada em 3 dias e dê uma crítica em um
semana, para hospedeiro absinto

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

Exemplo 2: o mesmo que acima, mas pule as tabelas pertencentes aos usuários 'véspera' ou 'mallory'

check_postgres_last_vacuum --host = wormwood --warning = '3d' --critical = '7d' --excludeusers = véspera, mallory

Para saída MRTG, retorna (na primeira linha) a quantidade MENOS de tempo em segundos desde um
a mesa foi aspirada ou analisada pela última vez. A quarta linha retorna o nome do banco de dados e
nome da mesa.

ouvinte
("link simbólico: check_postgres_listener") Confirme se alguém está ouvindo um ou mais
strings específicas (usando o sistema LISTEN / NOTIFY), observando a tabela pg_listener.
Apenas um aviso ou crítico é necessário. O formato é uma string simples que representa o
Destino LISTEN, ou um caractere til seguido por uma string para uma verificação de expressão regular.
Observe que esta verificação não funcionará nas versões do Postgres 9.0 ou superior.

Exemplo 1: Dê um aviso se ninguém estiver ouvindo a string bucardo_mcp_ping nas portas
5555 e 5556

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

Exemplo 2: Dê uma crítica se não houver solicitações LISTEN ativas correspondendo a 'grimm' em
banco de dados oskar

check_postgres_listener --db oskar --critical = ~ grimm

Para saída MRTG, retorna 1 ou 0 no primeiro, indicando sucesso ou falha. O nome
do aviso deve ser fornecido por meio do --mrtg opção.

fechaduras
("link simbólico: check_postgres_locks") Verifique o número total de bloqueios em um ou mais
bancos de dados. Não há necessidade de executar isso mais de uma vez por cluster de banco de dados. Bancos de dados podem
ser filtrado com o --incluir e --excluir opções. Consulte a seção "FILTRAGEM BÁSICA"
para mais detalhes.

A --aviso e --crítico opções podem ser especificadas como números simples, que representam
o número total de bloqueios, ou eles podem ser divididos por tipo de bloqueio. Nomes de bloqueio válidos
são 'total', 'em espera' ou o nome de um tipo de bloqueio usado pelo Postgres. Esses nomes são
não faz distinção entre maiúsculas e minúsculas e não precisa da parte "trava" no final, então exclusivo vai combinar
'ExclusiveLock'. O formato é nome = número, com diferentes itens separados por dois pontos ou
ponto e vírgula (ou qualquer outro símbolo).

Exemplo 1: avisa se o número de bloqueios é 100 ou mais e crítico se 200 ou mais, em
anfitrião garrett

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

Exemplo 2: no host artemus, avisa se existem 200 ou mais bloqueios e fornece um crítico se
mais de 250 bloqueios no total existem, ou se existem mais de 20 bloqueios exclusivos, ou se mais de 5 conexões
estão esperando por um bloqueio.

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

Para saída MRTG, retorna o número de bloqueios na primeira linha e o nome do
banco de dados na quarta linha.

arquivo de log
("link simbólico: check_postgres_logfile") Garante que o arquivo de log está no local esperado
e está sendo conectado. Esta ação emite um comando que lança um erro em cada
banco de dados que está verificando e garante que a mensagem apareça nos logs. Faz a varredura do
várias configurações log_ * dentro do Postgres para descobrir onde os logs devem estar. Se você
estão usando syslog, ele faz uma varredura aproximada (mas não infalível) de /etc/syslog.conf.
Alternativamente, você pode fornecer o nome do arquivo de log com o --arquivo de log opção. Isto é
especialmente útil se os registros tiverem um esquema de rotação personalizado conduzido por um programa externo.
A --arquivo de log opção suporta os seguintes caracteres de escape: "% Y% m% d% H", que
representam o ano, mês, data e hora atuais, respectivamente. Um erro é sempre
relatado como crítico, a menos que a opção de aviso tenha sido passada como um valor diferente de zero.
Além desse uso específico, as opções "--warning" e "--critical" devem não be
usava.

Exemplo 1: na porta 5432, certifique-se de que o arquivo de log está sendo gravado no arquivo
/home/greg/pg8.2.log

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

Exemplo 2: igual ao anterior, mas emite um aviso, não um crítico

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

Para saída MRTG, retorna 1 ou 0 na primeira linha, indicando sucesso ou falha. No
Em caso de falha, a quarta linha fornecerá mais detalhes sobre a falha encontrada.

nova_versão_bc
("link simbólico: check_postgres_new_version_bc") Verifica se há uma versão mais recente do Bucardo
programa está disponível. A versão atual é obtida executando "bucardo_ctl --version".
Se uma atualização importante estiver disponível, um aviso será retornado. Se uma atualização de revisão for
disponível, um crítico é retornado. (Bucardo é mestre para escravo, e mestre para mestre
sistema de replicação para Postgres: ver http://bucardo.org Para maiores informações). Veja também
as informações sobre a opção "--get_method".

nova_versão_box
("link simbólico: check_postgres_new_version_box") Verifica se uma versão mais recente do boxinfo
programa está disponível. A versão atual é obtida executando "boxinfo.pl --version".
Se uma atualização importante estiver disponível, um aviso será retornado. Se uma atualização de revisão for
disponível, um crítico é retornado. (boxinfo é um programa para pegar informações importantes
informações de um servidor e colocá-las em formato HTML: consulte
http://bucardo.org/wiki/boxinfo Para maiores informações). Veja também as informações sobre o
opção "--get_method".

nova_versão_cp
("link simbólico: check_postgres_new_version_cp") Verifica se uma versão mais recente deste programa
(check_postgres) está disponível, obtendo a versão de um pequeno arquivo de texto no principal
página da página inicial do projeto. Retorna um aviso se a versão retornada não
coincidir com o que você está executando. O intervalo recomendado para verificação é uma vez por dia. Veja também o
informações sobre a opção "--get_method".

nova_versão_pg
("link simbólico: check_postgres_new_version_pg") Verifica se existe uma revisão mais recente do Postgres
para cada banco de dados conectado. Observe que isso só verifica a revisão, por exemplo, indo de
8.3.6 a 8.3.7. As revisões são sempre 100% compatíveis com o binário e não envolvem despejo e
restaurar para atualizar. As revisões são feitas para corrigir bugs, portanto, atualize o mais rápido possível
é sempre recomendado. Retorna um aviso se você não tiver a revisão mais recente. Isto é
recomendado que esta verificação seja executada pelo menos uma vez por dia. Veja também as informações sobre o
opção "--get_method".

nova_versão_tnm
("link simbólico: check_postgres_new_version_tnm") Verifica se uma versão mais recente do tail_n_mail
programa está disponível. A versão atual é obtida executando "tail_n_mail --version".
Se uma atualização importante estiver disponível, um aviso será retornado. Se uma atualização de revisão for
disponível, um crítico é retornado. (tail_n_mail é uma ferramenta de monitoramento de log que pode enviar
e-mail quando eventos interessantes aparecem em seus logs do Postgres. Ver:
http://bucardo.org/wiki/Tail_n_mail Para maiores informações). Veja também as informações sobre
a opção "--get_method".

pgb_pool_cl_active
pgb_pool_cl_waiting
pgb_pool_sv_active
pgb_pool_sv_idle
pgb_pool_sv_usado
pgb_pool_sv_tested
pgb_pool_sv_login
pgb_pool_maxwait
(links 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" e "check_postgres_pgb_pool_maxwait")

Examina as estatísticas do pool do pgbouncer. Cada pool tem um conjunto de conexões de "cliente",
referindo-se a conexões de clientes externos e conexões de "servidor", referindo-se a
conexões com o próprio PostgreSQL. As ações check_postgres relacionadas são prefixadas por "cl_"
e "sv_", respectivamente. Conexões de cliente ativas são aquelas conexões atualmente vinculadas
com uma conexão de servidor ativa. As conexões do cliente também podem estar "esperando", o que significa que
ainda não foi alocada uma conexão de servidor. As conexões do servidor estão "ativas" (vinculadas
para um cliente), "inativo" (aguardando uma conexão do cliente para se conectar), "usado" (apenas
desvinculado de um cliente e ainda não retornou ao pool ocioso), "testado" (atualmente sendo
testado) e "login" (no processo de login). O valor maxwait mostra quanto tempo em
segundos, a conexão do cliente em espera mais antiga está aguardando.

pgbouncer_backends
("link simbólico: check_postgres_pgbouncer_backends") Verifica o número atual de conexões
para um ou mais bancos de dados por meio do pgbouncer e, opcionalmente, o compara ao máximo
permitido, que é determinado pela variável de configuração pgbouncer max_client_conn. O
--aviso e --crítico as opções podem assumir uma de três formas. Primeiro, um número simples pode
ser fornecido, que representa o número de conexões nas quais o alerta será dado.
Esta escolha não usa o max_connections configuração. Em segundo lugar, a porcentagem de disponibilidade
conexões podem ser fornecidas. Terceiro, um número negativo pode ser dado, o que representa o
número de conexões restantes até max_connections é atingido. Os valores padrão para
--aviso e --crítico são '90% 'e '95%'. Você também pode filtrar os bancos de dados usando
da --incluir e --excluir opções. Consulte a seção "FILTRAGEM BÁSICA" para obter mais detalhes.

Para visualizar apenas processos não ociosos, você pode usar o --noidle argumento. Observe que o usuário que você
estão se conectando, pois deve ser um superusuário para que isso funcione corretamente.

Exemplo 1: Dê um aviso quando o número de conexões no host quirm atingir 120, e um
crítico se chegar a 150.

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

Exemplo 2: Dê um crítico quando atingirmos 75% de nossa configuração max_connections nos hosts
lancre ou lancre2.

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

Exemplo 3: Dê um aviso quando houver apenas mais 10 slots de conexão restantes no host
plasmídeo, e um crítico quando temos apenas 5 restantes.

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

Para saída MRTG, o número de conexões é relatado na primeira linha e na quarta
linha fornece o nome do banco de dados, mais o max_client_conn atual. Se mais de um
banco de dados foi consultado, aquele com o maior número de conexões é gerado.

pgbouncer_checksum
("link simbólico: check_postgres_pgbouncer_checksum") Verifica se todas as configurações do pgBouncer estão
o mesmo da última vez que você verificou. Isso é feito gerando uma soma de verificação de uma lista classificada
de definir nomes e seus valores. Observe que você não deve especificar o nome do banco de dados,
será automaticamente padronizado como pgbouncer. Tanto o --aviso ou de --crítico opção
deve ser dado, mas não ambos. O valor de cada um é a soma de verificação, um código de 32 caracteres
valor hexadecimal. Você pode executar com a opção especial "--critical = 0" para descobrir um
checksum existente.

Esta ação requer o módulo Digest :: MD5.

Exemplo 1: Encontre a soma de verificação inicial para a configuração do pgbouncer na porta 6432 usando o
usuário padrão (geralmente postgres)

check_postgres_pgbouncer_checksum --port = 6432 --critical = 0

Exemplo 2: certifique-se de que nenhuma configuração tenha sido alterada e avise se sim, usando a soma de verificação de
acima.

check_postgres_pgbouncer_checksum --port=6432 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Para saída MRTG, retorna 1 ou 0 indicando sucesso ou falha da soma de verificação para corresponder.
Uma soma de verificação deve ser fornecida como o argumento "--mrtg". A quarta linha sempre dá o
soma de verificação atual.

pgagent_jobs
("link simbólico: check_postgres_pgagent_jobs") Verifica se todos os trabalhos do pgAgent que possuem
executados no intervalo de tempo anterior foram bem-sucedidos. Isso é feito verificando
quaisquer etapas que tenham um resultado diferente de zero.

Tanto "--warning" ou "--critical", ou ambos, podem ser especificados como horários, e as tarefas serão
verificado quanto a falhas dentro dos períodos de tempo especificados antes da hora atual. Válido
as unidades são segundos, minutos, horas e dias; todos podem ser abreviados com a primeira letra.
Se nenhuma unidade for fornecida, 'segundos' serão assumidos.

Exemplo 1: Dê um crítico quando qualquer tarefa executada no último dia falhou.

check_postgres_pgagent_jobs --critical = 1d

Exemplo 2: Dê um aviso quando qualquer tarefa executada na última semana falhar.

check_postgres_pgagent_jobs --warning = 7d

Exemplo 3: Dê uma crítica para as tarefas que falharam nas últimas 2 horas e um aviso para
trabalhos que falharam nas últimas 4 horas:

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

ready_txns
("link simbólico: check_postgres_prepared_txns") Verifique a idade de qualquer existente
transações. Observe que a maioria das pessoas NÃO usará transações preparadas, pois elas fazem parte
de confirmação de duas partes e complicado de manter. Eles também não devem ser confundidos com
DECLARAÇÕES preparadas, que é o que a maioria das pessoas pensa quando ouvem preparar. o
o valor padrão para um aviso é 1 segundo, para detectar qualquer uso de transações preparadas, que
provavelmente é um erro na maioria dos sistemas. Aviso e crítico são o número de segundos que um
transação preparada foi aberta antes que um alerta seja dado.

Exemplo 1: Dê um aviso sobre a detecção de quaisquer transações preparadas:

check_postgres_prepared_txns -w 0

Exemplo 2: Dê uma crítica se qualquer transação preparada estiver aberta por mais de 10
segundos, mas permita até 360 segundos para o banco de dados 'picar':

check_postgres_prepared_txns --critical = 10 --exclude = picanço
check_postgres_prepared_txns --critical = 360 --include = picanço

Para saída MRTG, retorna o número de segundos que a transação mais antiga esteve aberta como o
primeira linha e de qual banco de dados é a linha final.

query_runtime
("link simbólico: check_postgres_query_runtime") Verifica quanto tempo uma consulta específica leva para ser executada,
executando um "EXPLAIN ANALYZE" contra ele. o --aviso e --crítico as opções são o
quantidade máxima de tempo que a consulta deve levar. As unidades válidas são segundos, minutos e horas;
qualquer um pode ser abreviado com a primeira letra. Se nenhuma unidade for fornecida, 'segundos' serão assumidos.
Tanto o aviso quanto a opção crítica devem ser fornecidos. O nome da visão ou função
para ser executado deve ser passado para o --queryname opção. Deve consistir em uma única palavra
(ou schema.word), com parênteses opcionais no final.

Exemplo 1: Dê um crítico se a função chamada "speedtest" não funcionar em 10 segundos ou
Menos.

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

Para saída MRTG, relata o tempo em segundos para a consulta ser concluída na primeira linha.
A quarta linha lista o banco de dados.

horário_da_consulta
("link simbólico: check_postgres_query_time") Verifica a duração das consultas em execução em um ou mais
bancos de dados. Não há necessidade de executar isso mais de uma vez no mesmo cluster de banco de dados. Observação
que isso já exclui consultas que estão "ociosas na transação". Bancos de dados podem ser
filtrado usando o --incluir e --excluir opções. Consulte a seção "FILTRAGEM BÁSICA"
para mais detalhes. Você também pode filtrar o usuário que está executando a consulta com o --includeuser
e --excludeuser opções. Consulte a seção "FILTRAGEM DE NOME DE USUÁRIO" para obter mais detalhes.

Os valores para o --aviso e --crítico as opções são períodos de tempo e o padrão é '2
minutos 'e' 5 minutos ', respectivamente. As unidades válidas são 'segundos', 'minutos', 'horas' ou
'dias'. Cada um pode ser escrito no singular ou abreviado apenas na primeira letra. Se não houver unidades
são fornecidos, a unidade é considerada em segundos.

Esta ação requer Postgres 8.1 ou superior.

Exemplo 1: dê um aviso se alguma consulta estiver em execução por mais de 3 minutos e um
crítico se mais de 5 minutos.

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

Exemplo 2: usando valores padrão (2 e 5 minutos), verifique todos os bancos de dados, exceto aqueles
começando com 'template'.

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

Exemplo 3: avisar se o usuário 'don' tem uma consulta em execução por mais de 20 segundos

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

Para saída MRTG, retorna a duração em segundos da consulta mais longa em execução no primeiro
linha. A quarta linha fornece o nome do banco de dados.

linha_replicar
("link simbólico: check_postgres_replicate_row") Verifica se a replicação mestre-escravo está funcionando
para um ou mais escravos.

As primeiras opções "--dbname", "--host" e "--port", etc. são consideradas mestras;
os usos subsequentes são os escravos. Os valores ou o --aviso e --crítico opções são
unidades de tempo, e pelo menos uma deve ser fornecida (sem padrões). As unidades válidas são 'segundos',
'minutos', 'horas' ou 'dias'. Cada um pode ser escrito no singular ou abreviado apenas para o
primeira carta. Se nenhuma unidade for fornecida, as unidades serão consideradas segundos.

Esta verificação atualiza uma única linha no mestre e, em seguida, mede quanto tempo leva para ser
aplicado aos escravos. Para fazer isso, você precisa escolher uma tabela que está sendo replicada e, em seguida,
encontre uma linha que possa ser alterada e não seja alterada por nenhum outro processo. UMA
coluna específica desta linha será alterada de um valor para outro. Tudo isso é alimentado
à opção "repinfo", e deve conter as seguintes opções, separadas por vírgulas:
nome da tabela, chave primária, id da chave, coluna, primeiro valor, segundo valor.

Exemplo 1: Slony está replicando uma tabela chamada 'pedidos' do host 'alfa' para o host 'beta',
no banco de dados 'vendas'. A chave primária da tabela é chamada id, e vamos
teste a linha com um id de 3 (que é histórico e nunca mudou). Há uma coluna
chamado 'salesrep' que vamos alternar de um valor de 'slon' para 'nols' para verificar
a replicação. Queremos lançar um aviso se a replicação não acontecer dentro de 10
segundos.

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

Exemplo 2: Bucardo está replicando uma tabela chamada 'recibo' do host 'verde' para os hosts
'vermelho', 'azul' e 'amarelo'. O banco de dados de ambos os lados é 'público'. Os bancos de dados escravos
estão em execução na porta 5455. A chave primária é chamada 'recibo_id', a linha que queremos usar
tem o valor 9 e a coluna que queremos alterar para o teste é chamada de 'zona'. Bem
alterne entre 'norte' e 'sul' para o valor desta coluna, e lance um crítico se
a mudança não ocorre em todos os três escravos em 5 segundos.

check_postgres_replicate_row --host = green --port = 5455 --host = vermelho, azul, amarelo
--critical = 5 --repinfo = recibo, recibo_id, 9, zona, norte, sul

Para saída MRTG, retorna na primeira linha o tempo em segundos que a replicação leva para
Finalizar. O tempo máximo é definido para 4 minutos e 30 segundos: se nenhuma replicação tiver ocorrido
lugar há tanto tempo, um erro é lançado.

mesmo_squema
("link simbólico: check_postgres_same_schema") Verifica se dois ou mais bancos de dados são idênticos
tanto quanto seu esquema (mas não os dados dentro). Isso é particularmente útil para fazer
certifique-se de que seus escravos não foram modificados ou corrompidos de qualquer forma ao usar o mestre para o escravo
replicação. Ao contrário da maioria das outras ações, isso não tem nenhum aviso ou critério crítico - o
os bancos de dados estão sincronizados ou não. Se eles forem diferentes, uma lista detalhada dos
diferenças são apresentadas.

Você pode excluir ou filtrar certas diferenças. A maneira de fazer isso é adicionar
strings para a opção "--filter". Para excluir um tipo de objeto, use "noname", onde 'nome'
é o tipo de objeto, por exemplo, "noschema". Para excluir objetos de um certo tipo por um
expressão regular em relação ao seu nome, use "noname = regex". Veja os exemplos abaixo para um
melhor entendimento.

Os tipos de objetos que podem ser filtrados incluem:

usuário
esquema
mesa
view
índice
seqüência
restrição
desencadear
função

A opção de filtro "não posição" impede a verificação da posição das colunas dentro de um
tabela.

A opção de filtro "nofuncbody" impede a comparação dos corpos de todas as funções.

A opção de filtro "noperm" impede a comparação de permissões de objeto.

Para fornecer o segundo banco de dados, basta anexar as diferenças ao primeiro chamando para
o argumento de conexão apropriado. Por exemplo, para comparar bancos de dados em hosts alfa e
bravo, use "--dbhost = alpha, bravo". Veja também os exemplos abaixo.

Se apenas um único host for fornecido, presume-se que estamos fazendo um relatório "baseado no tempo". o
primeira vez que isso é executado, um instantâneo de todos os itens no banco de dados é salvo em um local
Arquivo. Quando você o executa novamente, esse instantâneo é lido e se torna "banco de dados # 2" e é
em comparação com o banco de dados atual.

Para substituir o arquivo armazenado antigo pela nova versão, use o argumento --replace.

Para habilitar instantâneos em vários pontos no tempo, você pode usar o argumento "--suffix" para fazer
os nomes de arquivo exclusivos para cada execução. Veja os exemplos abaixo.

Exemplo 1: verifique se dois bancos de dados em hosts estrela e linha são os mesmos:

check_postgres_same_schema --dbhost = estrela, linha

Exemplo 2: o mesmo que antes, mas exclua quaisquer gatilhos com "slony" no nome

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

Exemplo 3: o mesmo que antes, mas também exclui todos os índices

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

Exemplo 4: verificar diferenças para o banco de dados "battlestar" em portas diferentes

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

Exemplo 5: Criar um arquivo de instantâneo diário e semanal

check_postgres_same_schema --dbname = cylon --suffix = daily
check_postgres_same_schema --dbname = cylon --suffix = semanal

Exemplo 6: execute uma comparação histórica e, em seguida, substitua o arquivo

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

seqüência
("link simbólico: check_postgres_sequence") Verifica quanto espaço resta em todas as sequências no
base de dados. Isso é medido como a porcentagem do total de valores possíveis que foram usados
para cada sequência. o --aviso e --crítico opções devem ser expressas como
percentagens. Os valores padrão são 85% para o aviso e 95% para o crítico. Você pode
use --include e --exclude para controlar quais sequências devem ser verificadas. Observe que este
cheque conta para incomum minvalor e incremento by valores, mas não se importa se o
a sequência está definida para ciclo ou não.

A saída do Nagios fornece o nome da sequência, a porcentagem usada e o número
de 'chamadas' restantes, indicando quantas vezes mais nextval pode ser chamado nessa sequência
antes de atingir o valor máximo.

A saída para MRTG retorna a maior porcentagem em todas as sequências na primeira linha,
e o nome de cada sequência com essa porcentagem na quarta linha, separados por um "|"
(tubo) se houver mais de uma sequência nessa porcentagem.

Exemplo 1: Dê um aviso se alguma sequência estiver se aproximando de 95% da capacidade.

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

Exemplo 2: Verifique se a sequência chamada "orders_id_seq" não está mais da metade cheia.

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

soma de verificação_configurações
("link simbólico: check_postgres_settings_checksum") Verifica se todas as configurações do Postgres estão
o mesmo da última vez que você verificou. Isso é feito gerando uma soma de verificação de uma lista classificada
de definir nomes e seus valores. Observe que diferentes usuários no mesmo banco de dados podem ter
diferentes somas de verificação, devido ao uso de ALTER USER e ao fato de os superusuários verem mais
configurações do que os usuários comuns. Tanto o --aviso ou de --crítico opção deve ser
dado, mas não ambos. O valor de cada um é a soma de verificação, um hexadecimal de 32 caracteres
valor. Você pode executar com a opção especial "--critical = 0" para descobrir um existente
soma de verificação.

Esta ação requer o módulo Digest :: MD5.

Exemplo 1: Encontre a soma de verificação inicial para o banco de dados na porta 5555 usando o usuário padrão
(geralmente postgres)

check_postgres_settings_checksum --port = 5555 --critical = 0

Exemplo 2: certifique-se de que nenhuma configuração tenha sido alterada e avise se sim, usando a soma de verificação de
acima.

check_postgres_settings_checksum --port=5555 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Para saída MRTG, retorna 1 ou 0 indicando sucesso ou falha da soma de verificação para corresponder.
Uma soma de verificação deve ser fornecida como o argumento "--mrtg". A quarta linha sempre dá o
soma de verificação atual.

slony_status
("link simbólico: check_postgres_slony_status") Verifica o status de um cluster Slony por
olhando os resultados da visualização sl_status do Slony. Isso é retornado como o número de
segundos de "tempo de latência". o --aviso e --crítico as opções devem ser expressas em tempos.
Os valores padrão são 60 segundo para o aviso e 300 segundo para o crítico.

O argumento opcional --esquema indicou o esquema no qual o Slony está instalado. Se isso
não for fornecido, o esquema será determinado automaticamente sempre que essa verificação for executada.

Exemplo 1: dê um aviso se algum Slony estiver atrasado em mais de 20 segundos

check_postgres_slony_status --aviso 20

Exemplo 2: dê um crítico se o Slony, instalado sob o esquema "_slony", tiver mais de 10
minutos atrasados

check_postgres_slony_status --schema = _slony --critical = 600

sincronização de tempo
("link simbólico: check_postgres_timesync") Compara a hora do sistema local com a hora relatada
por um ou mais bancos de dados. o --aviso e --crítico opções representam o número de
segundos entre os dois sistemas antes que um alerta seja dado. Se nenhum for especificado, o
os valores padrão são usados, que são '2' e '5'. O valor do aviso não pode ser maior que
o valor crítico. Devido à natureza não exata deste teste, os valores de '0' ou '1' não são
recomendado.

A string retornada mostra a diferença de tempo, bem como a hora de cada lado escrito
para fora.

Exemplo 1: verifique se os bancos de dados nos hosts ankh, morpork e klatch não são mais do que 3
segundos fora da hora local:

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

Para saída MRTG, retorna na primeira linha o número de segundos de diferença entre o
hora local e a hora do banco de dados. A quarta linha retorna o nome do banco de dados.

txn_idle
("link simbólico: check_postgres_txn_idle") Verifica o número e a duração de "inativo em
transações "em um ou mais bancos de dados. Não há necessidade de executar mais de uma vez
no mesmo cluster de banco de dados. Os bancos de dados podem ser filtrados usando o --incluir e
--excluir opções. Consulte a seção "FILTRAGEM BÁSICA" abaixo para obter mais detalhes.

A --aviso e --crítico as opções são fornecidas como unidades de tempo, inteiros com sinal ou
inteiros para unidades de tempo e ambos devem ser fornecidos (não há padrões). Unidades válidas
são 'segundos', 'minutos', 'horas' ou 'dias'. Cada um pode ser escrito no singular ou abreviado
para apenas a primeira letra. Se nenhuma unidade for fornecida e os números não forem assinados, as unidades
são considerados segundos.

Esta ação requer Postgres 8.3 ou superior.

Exemplo 1: Dê um aviso se alguma conexão tiver ficado inativa na transação por mais de 15
segundos:

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

Exemplo 2: dê um aviso se houver 50 ou mais transações

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

Exemplo 3: Dê um crítico se 5 ou mais conexões estiveram ociosas na transação por mais
de 10 segundos:

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

Para saída MRTG, retorna o tempo em segundos que a transação inativa mais longa foi
correndo. A quarta linha retorna o nome do banco de dados e outras informações sobre o
transação mais longa.

txn_time
("link simbólico: check_postgres_txn_time") Verifica a duração das transações abertas em um ou mais
bancos de dados. Não há necessidade de executar este comando mais de uma vez por cluster de banco de dados.
Os bancos de dados podem ser filtrados pelo uso do --incluir e --excluir opções. Veja o "BÁSICO
FILTRAGEM "para obter mais detalhes. O proprietário da transação também pode ser filtrado por
a utilização do --includeuser e --excludeuser opções. Consulte a seção "FILTRAGEM DE NOME DE USUÁRIO"
para mais detalhes.

Os valores ou o --aviso e --crítico as opções são unidades de tempo e devem ser fornecidas
(nenhum padrão). As unidades válidas são 'segundos', 'minutos', 'horas' ou 'dias'. Cada um pode ser
escrito no singular ou abreviado apenas para a primeira letra. Se nenhuma unidade for fornecida, o
as unidades são consideradas segundos.

Esta ação requer Postgres 8.3 ou superior.

Exemplo 1: Dê uma crítica se alguma transação estiver aberta por mais de 10 minutos:

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

Exemplo 1: Avisar se o usuário 'warehouse' tem uma transação aberta por mais de 30 segundos

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

Para saída MRTG, retorna o tempo máximo em segundos que uma transação foi aberta no
primeira linha. A quarta linha fornece o nome do banco de dados.

txn_wraparound
("link simbólico: check_postgres_txn_wraparound") Verifica o quão perto do encerramento da transação um
ou mais bancos de dados estão obtendo. o --aviso e --crítico opções indicam o número
de transações feitas e deve ser um número inteiro positivo. Se nenhuma das opções for fornecida, o
valores padrão de 1.3 e 1.4 bilhões são usados. Não há necessidade de executar este comando mais
de uma vez por cluster de banco de dados. Para uma discussão mais detalhada sobre o que é esse número
representa e o que fazer a respeito, visite a página
<http://www.postgresql.org/docs/current/static/routine-vacuuming.html# VACUUM-FOR-WRAPAROUND>

O aviso e os valores críticos podem ter sublinhados no número para legibilidade, como Perl
faz.

Exemplo 1: verifique os valores padrão para o banco de dados localhost

check_postgres_txn_wraparound --host = localhost

Exemplo 2: verifique a porta 6000 e forneça um crítico quando 1.7 bilhão de transações forem atingidas:

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

Para saída MRTG, retorna o maior número de transações para todos os bancos de dados na linha um,
enquanto a linha 4 indica qual banco de dados é.

versão
("link simbólico: check_postgres_version") Verifica se a versão necessária do Postgres é
correndo. o --aviso e --crítico opções (apenas uma é necessária) devem estar no formato
XY or XYZ onde X é o número da versão principal, Y é o número da versão secundária, e Z is
a revisão.

Exemplo 1: dê um aviso se o banco de dados na porta 5678 não for a versão 8.4.10:

check_postgres_version --port = 5678 -w = 8.4.10

Exemplo 2: dê um aviso se algum banco de dados em hosts Valley, grain ou sunshine não for 8.3:

check_postgres_version -H valley, grain, sunshine --critical = 8.3

Para saída MRTG, relata 1 ou 0 indicando sucesso ou falha na primeira linha. o
a quarta linha indica a versão atual. A versão deve ser fornecida através do "--mrtg"
opção.

arquivos_wal
("link simbólico: check_postgres_wal_files") Verifica quantos arquivos WAL existem no pg_xlog
diretório, que é encontrado fora de seu diretório_dados, às vezes como um link simbólico para outro
disco físico por motivos de desempenho. Esta ação deve ser executada como um superusuário, a fim de
acessar o conteúdo do pg_xlog diretório. A versão mínima para usar esta ação é
Postgres 8.1. o --aviso e --crítico opções são simplesmente o número de arquivos no
pg_xlog diretório. O número para definir isso irá variar, mas uma orientação geral é colocar
um número um pouco mais alto do que o normal, para detectar problemas logo no início.

Normalmente, os arquivos WAL são fechados e reutilizados, mas uma transação aberta de longa duração ou um
defeituoso comando_arquivo script, pode fazer com que o Postgres crie muitos arquivos. Em última análise,
isso fará com que o disco em que eles estão fique sem espaço, ponto no qual o Postgres irá
desligar.

Exemplo 1: verifique se o número de arquivos WAL é 20 ou menos no host "pluto"

check_postgres_wal_files --host = pluto --critical = 20

Para saída MRTG, relata o número de arquivos WAL na linha 1.

reconstruir_symlinks
reconstruir_symlinks_force
Esta ação não requer nenhum outro argumento e não se conecta a nenhum banco de dados, mas simplesmente
cria links simbólicos no diretório atual para cada ação, no formulário
check_postgres_. Se o arquivo já existir, ele não será sobrescrito. Se
a ação é rebuild_symlinks_force, então os links simbólicos serão sobrescritos. A opção
--symlinks é uma maneira mais curta de dizer --action = rebuild_symlinks

BASIC FILTRAGEM

As opções --incluir e --excluir podem ser combinados para limitar quais itens são verificados,
dependendo da ação. O nome do banco de dados pode ser filtrado ao usar o seguinte
ações: backends, database_size, locks, query_time, txn_idle e txn_time. O nome de
uma relação pode ser filtrada ao usar as seguintes ações: bloat, index_size,
tamanho_tabela, tamanho_da_relação, último_vacuo, último_autovacuo, último_analisar e
last_autoanalyze. O nome de uma configuração pode ser filtrado ao usar settings_checksum
açao. O nome de um sistema de arquivos pode ser filtrado ao usar a ação disk_space.

Se apenas uma opção de inclusão for fornecida, SOMENTE as entradas correspondentes serão verificadas.
No entanto, se houver exclusão e inclusão, a exclusão é feita primeiro e a inclusão
depois, para restabelecer coisas que podem ter sido excluídas. Ambos --incluir e --excluir pode
ser fornecido várias vezes e / ou como listas separadas por vírgulas. Um til principal corresponderá ao
seguinte palavra como uma expressão regular.

Para corresponder a um esquema, termine o termo de pesquisa com um único ponto. Tis iniciais podem ser usados
para esquemas também.

Tenha cuidado ao usar a filtragem: uma regra de inclusão nos back-ends, por exemplo, pode
não relatar problemas, não só porque o banco de dados correspondente não tinha back-ends, mas porque você
digitou incorretamente o nome do banco de dados!

Exemplos:

Verifica apenas itens chamados pg_class:

--include = pg_class

Verifica apenas os itens que contêm as letras 'pg_':

--include = ~ pg_

Verifique apenas os itens que começam com 'pg_':

--include = ~ ^ pg_

Exclua o item denominado 'teste':

--exclude = teste

Exclua todos os itens que contêm o teste de letras:

--exclude = ~ teste

Exclua todos os itens no esquema 'pg_catalog':

--exclude = 'pg_catalog.'

Exclua todos os itens que contenham as letras 'ás', mas permita o item 'confronto':

--exclude = ~ ace --include = confronto

Exclua todos os itens que começam com as letras 'pg_', que contêm as letras 'slon', ou
que são denominados 'sql_settings' ou 'green'. Verifique especificamente os itens com as letras
'prod' em seus nomes, e sempre verifique o item chamado 'pg_relname':

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

USUÁRIO NOME FILTRAGEM

As opções --includeuser e --excludeuser pode ser usado em algumas ações para apenas examinar
objetos de banco de dados pertencentes (ou não pertencentes a) um ou mais usuários. Um --includeuser opção
sempre supera um --excludeuser opção. Você pode dar a cada opção mais de uma vez para
vários usuários, ou você pode fornecer uma lista separada por vírgulas. As ações que atualmente usam
essas opções são:

tamanho_de_dados
última_analisar
last_autoanalyze
último_vácuo
last_autovacuum
horário_da_consulta
tamanho_relação
txn_time

Exemplos:

Verifique apenas os itens pertencentes ao usuário chamado greg:

--includeuser = greg

Verifique apenas os itens pertencentes a Watson ou Crick:

--includeuser = watson, crick

Verifique apenas os itens pertencentes a crick, franklin, watson ou wilkins:

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

Verifique todos os itens, exceto aqueles pertencentes ao usuário scott:

--excludeuser = scott

TESTE MODA

Para ajudar na configuração, este programa pode ser executado em um "modo de teste", especificando o
--teste opção. Isso irá realizar alguns testes básicos para certificar-se de que os bancos de dados podem ser
contatado e que certos pré-requisitos por ação sejam atendidos, como se o usuário é
um superusuário, se a versão do Postgres for nova o suficiente e se stats_row_level estiver habilitado.

Use check_postgres_locksp online usando serviços onworks.net