Pgpool-II suporta dois destinos para registrar as mensagens Pgpool-II . Os destinos de log suportados são stderr e syslog . Você também pode definir este parâmetro para uma lista de destinos de log desejados separados por vírgulas se desejar as mensagens de log nos vários destinos.

       #por exemplo para fazer logon tanto no syslog quanto no stderr
       log_destination = 'syslog, stderr'
      

O padrão é registrar apenas no stderr .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Este parâmetro ativa o coletor de log, que é um processo em segundo plano que captura mensagens de log enviadas para stderr e as redireciona para arquivos de log.

Este parâmetro só pode ser definido no início do Pgpool-II.

logging_collector não está disponível antes de Pgpool-II V4.2 .

Quando logging_collector está ativado, este parâmetro determina o diretório no qual os arquivos de log serão criados.

O padrão é / tmp / pgpool_logs .

Este parâmetro só pode ser definido no início do Pgpool-II.

Quando logging_collector está ativado, este parâmetro define os nomes dos arquivos de log criados. O valor é tratado como um strftime padrão, de modo escapes de% pode ser usado para especificar os nomes dos arquivos variáveis no tempo. Os escapes de% suportados são semelhantes aos listados na Open Group strftime especificação.

Se você especificar um nome de arquivo sem escapes, deve planejar usar um utilitário de rotação de log para evitar o preenchimento de todo o disco.

O padrão é pgpool-% Y-% m-% d_% H% M% S.log .

Este parâmetro só pode ser definido no início do Pgpool-II.

Este parâmetro define as permissões para arquivos de log quando logging_collector está ativado. Espera-se que o valor do parâmetro seja um modo numérico especificado no formato aceito pelas chamadas de sistema chmod e umask .

Este parâmetro só pode ser definido no início do Pgpool-II.

Quando o logging_collector está habilitado, este parâmetro determina a quantidade máxima de tempo para usar um arquivo de log individual, após o qual um novo arquivo de log será criado. Se este valor for especificado sem unidades, ele será considerado em minutos. O padrão é 24 horas.

Defina como zero para desativar a criação baseada em tempo de novos arquivos de log.

Este parâmetro só pode ser definido no início do Pgpool-II.

Quando logging_collector está habilitado, este parâmetro determina o tamanho máximo de um arquivo de log individual. Depois que muitos kilobytes forem emitidos em um arquivo de log, um novo arquivo de log será criado.

Defina como zero para desativar a criação baseada em tamanho de novos arquivos de log.

Este parâmetro só pode ser definido no início do Pgpool-II.

Quando o logging_collector está habilitado, este parâmetro fará com que o Pgpool-II trunque (sobrescreva), ao invés de anexar a qualquer arquivo de log existente com o mesmo nome. No entanto, o truncamento ocorrerá apenas quando um novo arquivo estiver sendo aberto devido à rotação baseada no tempo, não durante a inicialização ou rotação baseada no tamanho. Quando desativado, os arquivos pré-existentes serão anexados em todos os casos. Por exemplo, usar esta configuração em combinação com um log_filename como pgpool-% H.log resultaria na geração de arquivos de log 24 horas por dia e, em seguida, sobrescrevendo-os ciclicamente.

Este parâmetro só pode ser definido no início do Pgpool-II.

Veja também a documentação do daemon syslog do seu sistema. Quando o registro no syslog está habilitado, este parâmetro determina o "recurso" do syslog a ser usado. Você pode escolher entre LOCAL0 , LOCAL1 , LOCAL2 , LOCAL3 , LOCAL4 , LOCAL5 , LOCAL6 , LOCAL7 ; o padrão é LOCAL0 . Veja também a documentação do daemon syslog do seu sistema .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Quando o registro no syslog está habilitado, este parâmetro determina o nome do programa usado para identificar as mensagens Pgpool-II nos logs do syslog . O padrão é pgpool .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Controla quais níveis mínimos de mensagem são enviados ao cliente. Os valores válidos são DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , LOG , NOTICE , WARNING e ERROR . Cada nível inclui todos os níveis que o seguem. O padrão é AVISO .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II . Você também pode usar o comando PGPOOL SET para alterar o valor deste parâmetro para uma sessão atual.

O padrão é AVISO. Controla quais níveis mínimos de mensagem são emitidos para registrar. Os valores válidos são DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL e PANIC . Cada nível inclui todos os níveis que o seguem. O padrão é AVISO .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II . Você também pode usar o comando PGPOOL SET para alterar o valor deste parâmetro para uma sessão atual.

Ativado, imprime todas as instruções SQL no log.

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II . Você também pode usar o comando PGPOOL SET para alterar o valor deste parâmetro para uma sessão atual.

Semelhante a log_statement , exceto que imprime os logs para cada nó do banco de dados separadamente. Pode ser útil verificar se a replicação ou o balanceamento de carga está funcionando.

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II . Você também pode usar o comando PGPOOL SET para alterar o valor deste parâmetro para uma sessão atual.

Ativado, imprime mensagens do cliente no log.

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II . Você também pode usar o comando PGPOOL SET para alterar o valor deste parâmetro para uma sessão atual.

Configurando para on, imprime o nome do host em vez do endereço IP no resultado do comando ps e os logs de conexão (quando log_connections está ativado ).

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Ativado, imprime todas as conexões do cliente de para o log.

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Ativado, imprime todas as terminações de conexão do cliente no log.

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Controla a quantidade de detalhes emitidos para cada mensagem registrada. Os valores válidos são TERSE , DEFAULT e VERBOSE , cada um adicionando mais campos às mensagens exibidas. TERSE exclui o registro de informações de erro DETAIL , HINT e CONTEXT .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II . Você também pode usar o comando PGPOOL SET para alterar o valor deste parâmetro para uma sessão atual.

Esta é uma printfstring no estilo que é produzida no início de cada linha de registro. % caracteres começam "sequências de escape" que são substituídas pelas informações descritas abaixo. Todos os escapes não reconhecidos são ignorados. Outros caracteres são copiados diretamente para a linha de registro. O padrão é '% t: pid% p:', que imprime carimbo de data / hora e id do processo, que mantém a compatibilidade com versões anteriores do Pgpool-II V3.4 .

Este parâmetro pode ser alterado recarregando as configurações do Pgpool-II .

Trabalhando Com Logs No PostgreSQL

Aqui você vai configurar onde o arquivo de log vai ser gerado, o nome do arquivo, permissões no arquivo, tamanho do arquivo, etc. Preocupações com o local, nome e espaço em disco entram aqui.

log_destination: Aqui você pode escolher entre stderr, csvlog, syslog e se estiver utilizando o Windows, eventlog. O uso do syslog ou do eventlog faz com que os logs sejam direcionados para o destino padrão dos logs no seu sistema operacional. Se você é um administrador de redes e está preocupado na gestão de dezenas de servidores, é possível que esteja mais confortável como isso. Por outro lado, DBAs em geral preferem o stderr ou csvlog. O padrão é utilizar o stderr, que produz um log mais fácil para a leitura humana, mas se você pretende importar os logs para uma ferramenta externa de analise, o csvlog pode ser uma boa opção também. logging_collector: Ligue e seja feliz. Deixe desligado e não me culpe se não souber te dizer o que houve de errado. log_directory: o diretório (dentro do diretório raiz da sua) onde os logs serão gravados. A não ser que tenha um bom motivo para isso, deixe o padrão, ‘pg_log’. log_filename: O nome do log gerado é muito importante para você. Pode acontecer de você gerar muitos logs por muito tempo e você tem que decidir se vai querer reaproveitar os logs antigos ou não. Se quiser rotacionar e manter apenas um log para cada dia da semana (manter apenas 7 dias de log) ou um para cada dia do mês (manter até 31 arquivos de log), você deve escolher um nome que seja sobrescrito periodicamente. Se você não tem alguém cuidando dos seus logs, pode ser melhor utilizar um esquema de rotação destes, não é o que eu prefiro, mas pode ser melhor do que ver seus logs lotando o espaço em disco sem que ninguém entenda o que está acontecendo. Parcimônia é uma boa pedida. Se você monitora o espaço em disco do seu servidor, não há motivos para mudar do padrão, que acredito que seja uma boa configuração. log_file_mode: Não mexa a não ser que você tenha um bom motivo para isso. log_rotation_age: O valor padrão faz com que pelo menos um novo log seja criado por dia. Gerar logs muito grandes torna muito difícil avaliar um problema. Meu conselho: deixe o valor padrão. log_rotation_size: Configura o tamanho máximo de um arquivo de log antes dele quebrar num novo arquivo. Como eu disse, logs muito grandes são difíceis de analisar. O padrão, 10MB talvez seja muito pequeno, uns 50MB ou 100MB são tranquilos para qualquer bom editor de texto abrir. log_truncate_on_rotation: Se você escolher um nome de arquivo em log_file_name de forma a ele reaproveitar os nomes anteriores, você precisa habilitar este parâmetros para ele apagar o log antigo.

client_min_messages, log_min_messages, log_min_error_statement: Estes 3 parâmetros possuem os mesmos valores que vão são DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL e PANIC. DEBUG5 é a opção que gera mais log e PANIC é a que gera menos log. DEBUG5 a DEBUG1 é utilizado em geral pelos próprios desenvolvedores do PostgreSQL. A opção PANIC por outro lado, é só vai registrar quando uma catástrofe absoluta acontecer. Um meio termo é o mais recomendado. Algo entre INFO e ERROR. O parâmetro client_min_messages se refere às mensagens enviadas para o usuário enquanto está interagindo com o banco de dados. Então a sua aplicação recebe mensagens que ela pode tratar. Um bom exemplo disso é quando você utiliza o psql. O log_min_messages é o que parâmetro que mede o que vai ser gravado de fato no nosso log. Por fim log_min_error_statement configura especificamente quando um comando SQL com erro vai ser gravado no log.  Vamos discutir um pouco mais sobre estes parâmetros mais tarde, eles são realmente importantes para nós. log_min_duration_statement: Faz com que qualquer comando SQL que leve mais do que o valor em  milissegundos configurado aqui entre no log. Muito útil para pegar comandos que estão levando muito tempo. É comum esperar que a maioria das consultas levem apenas alguns milissegundos ou no máximo alguns segundos. Capturar todas as consultas que demorem por exemplo mais de um minuto, pode ajudar a pegar gargalos importantes de performance. Se você configurar este parâmetro com 0 (zero) você vai logar todos os comandos SQL enviados para o postgres, que pode gerar uma quantidade muito grande de log. Em todo caso, experimente para ver o que acontece. Muitas pessoas se surpreendem com o que encontram…

application_name: Não faz muito sentido ajustar este parâmetro aqui, mas é muito importante que sua aplicação saiba ajustar este parâmetro quando se conecta no postgres. Ajuda muito saber qual aplicação está conectada. Pode-se também alterar este valor para passar mais detalhes conforme a operação que vai executar ex: “Contabilidade | Cadastro de cliente” debug_print_parse, debug_print_rewritten, debug_print_plan e debug_pretty_print: Nunca vi um bom motivo para mexer nisso em condições normais de temperatura e pressão. log_checkpoints: Ativa o log dos checkpoints. Você pode não entender bem o que isso quer dizer, mas é uma informação que em geral não é gravada com muita frequência e pode ser bem útil para avaliação de performance. Deixe isso ligado. log_connections e log_disconnections: Faz com que cada conexão e desconexão de um usuário seja logada. Se você tem muitas conexões entrando e saindo com frequência, isso pode ser irritante, pois serão milhares de mensagens de log. Use com parcimônia. log_duration: tem um efeito parecido com o log_min_duration_statement configurado com 0 (zero). A diferença é que aqui ele não mostra a consulta executada, apenas a duração. Em geral prefiro utilizar o log_min_duration_statement, mas você pode usar ele para ter a estatística da duração das consultas que levaram menos tempo que o estipulado em log_min_duration_statement log_error_verbosity: em geral não há um bom motivo para mexer nisso nas condições normais de temperatura e pressão. log_hostname: Se você confia nas suas configurações de DNS na rede, pode habilitar este parâmetro para mostrar o nome das máquinas que se conectam no banco ao invés do seus IPs. Caso contrário, isso pode acrescentar um custo de performance considerável. log_line_prefix: Este parâmetro é muito importante e diz quais informações adicionais vem junto com os comandos SQL que aparecerem logados. Algumas ferramentas de análise de log (vamos discutir isso mais para frente) se beneficiam de determinadas configurações. Algumas coisas dependem do seu ambiente. Informação demais pode não ajudar. Por exemplo: se você utiliza um único banco de dados no seu ambiente, ou todos usuários utilizam um único usuário do banco, logar esta informação pode não ser tão útil. Mas não seja mesquinho também… Um exemplo de configuração pode ser algo como ‘%t [%p]: [%l] db=%d,user=%u ‘, ou seja, (%t) data e hora do evento, (%p) número do processo no SO, (%l) número da sequência de execução, (%d) nome da base, (%u) nome do usuário. log_lock_waits: Loga eventos de espera com locks. Você deve deixar isso ligado. log_statement: Loga tipos diferentes de SQL executados com sucesso, como DDL, MOD (DDL + DML), ALL (tudo) ou none (nada). Deixar em DDL costuma ser bastante razoável. log_temp_files: Útil para ajustar o tamanho do parâmetro work_mem e caçar comandos SQL mal comportados. Usar com parcimônia log_timezone: Em geral não costuma ser necessário mexer aqui.

Servidor de produção PostgreSQL dedicado

# - Where to Log -
log_destination                 = 'stderr'
logging_collector               = on
log_directory                   = 'pg_log'
log_filename                    = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_truncate_on_rotation        = on
log_rotation_age                = 1d
log_rotation_size               = 64MB

# - When to Log -
client_min_messages             = log
log_min_messages                = notice
log_min_error_statement         = warning
log_min_duration_statement      = 120000

# - What to Log -
log_checkpoints                 = on
#log_connections                = off
#log_disconnections             = off
log_duration                    = off
log_error_verbosity             = default
log_hostname                    = on
log_line_prefix                 = '%t [%p]: [%l] user=%u,db=%d,app=%a,host=%h'
log_lock_waits                  = on
log_statement                   = 'ddl'
log_temp_files                  = 0
log_hostname                    = off

Aqui temos um log que será gerado em $PGDATA/pg_log e rotacionado todos os dias, ou quando o log atingir 64MB, ou quando o servidor for reiniciado. Optamos por um logar todos os comandos SQL que demorarem mais de 2 minutos para executarem, DDLs, uso do TEMP, locks, checkpoints. Logar todos os comandos pode ser inviável em termos de volume de logs gerados. Se você utiliza muitas tabelas temporárias, usar o log_statemente em ‘ddl’ pode ser um exagero também. Da mesma forma, logar conexões e desconexões pode gerar um excesso de logs.

Servidor de produção embarcado

# - Where to Log -
log_destination                 = 'stderr'
logging_collector               = on
log_directory                   = 'pg_log'
log_filename                    = 'postgresql-%d.log'
log_truncate_on_rotation        = on
log_rotation_age                = 1d
log_rotation_size               = 0

# - When to Log -
client_min_messages             = warning
log_min_messages                = warning
log_min_error_statement         = warning
log_min_duration_statement      = 120000

# - What to Log -
log_checkpoints                 = on
#log_connections                = off
#log_disconnections             = off
log_duration                    = off
log_error_verbosity             = default
log_hostname                    = on
log_line_prefix                 = '%t [%p]: [%l] user=%u,db=%d,app=%a,host=%h'
log_lock_waits                  = on
log_statement                   = 'none'
log_temp_files                  = 16MB
log_hostname                    = off

Aqui queremos um log mais enxuto, pois raramente alguém irá olhar para eles. Também vamos manter um log por dia do mês e depois reescrever eles. Também  diminuímos o número de mensagens e deixamos só as mais importantes.

Servidor de testes / homologação / desenvolvimento

# - Where to Log -
log_destination                 = 'stderr'
logging_collector               = on
log_directory                   = 'pg_log'
log_filename                    = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_truncate_on_rotation        = on
log_rotation_age                = 1d
log_rotation_size               = 256MB

# - When to Log -
client_min_messages             = log
log_min_messages                = info
log_min_error_statement         = warning
log_min_duration_statement      = 0

# - What to Log -
log_checkpoints                 = on
log_connections                 = on
log_disconnections              = on
log_duration                    = off
log_error_verbosity             = verbose
log_hostname                    = on
log_line_prefix                 = '%t [%p]: [%l] user=%u,db=%d,app=%a,host=%h'
log_lock_waits                  = on
log_statement                   = 'ddl'
log_temp_files                  = 0
log_hostname                    = on

Aqui deixamos o log mais verboso para pegar possíveis erros. Em geral o volume de logs nunca é tão grande como na produção, pois a base não é utilizada com a mesma intensidade.

Ferramentas para análise de logs

Analisar logs pode ser uma tarefa árdua. Um bom editor de texto é uma ferramenta importantíssima. Uma das coisas que você deverá fazer com frequência é seguir uma sessão do inicio ao fim. Para isso o grep será seu grande amigo. Você pode fazer algo simples como:

cat postgresql-2015-01-20_000000.log | grep 'user=user_teste' > teste.sql

Também pode filtrar por aplicação ou mesmo por PID, para pegar uma sessão específica. Isso ajuda muito a avaliar o comportamento da aplicação e ver o que realmente está acontecendo no banco de dados. Uma coisa que descobrimos como DBA é que o desenvolvedor muitas vezes não sabe o que a sua própria aplicação faz no banco de dados. Você descobre problemas crônicos apenas com este tipo de análise.

Mas haverá momentos em que você deverá descobrir onde está um gargalo de performance e existe um caso bem chato de pegar: quando um comando é repetido milhares de vezes apenas mudando os parâmetros. Por exemplo: a aplicação resolve atualizar em 10% o preço de todos os produtos e resolve fazer um UPDATE em cada produto um por vez ao invés de fazer um único UPDATE para todos os produtos. Nesta situação, outros métodos de análise falham em achar gargalos deste tipo, pois se baseiam em olhar comandos SQL lentos. Acontece que um UPDATE simples em si é bem rápido. Mas o conjunto de milhares de UPDATEs é bem lento. Uma ferramenta de analise de logs vai te ajudar nesta tarefa com muita eficiência.

pgBadger

O pgBadger é a ferramenta mais utilizada e mais eficiente que eu conheço para analisar logs do PostgreSQL. Fácil de instalar e muito rápida, ela analisa vários logs de uma vez, um intervalo de tempo específico, tem várias opções bacanas, mas se você não utilizar nenhuma delas, provavelmente já terá um resultado excepcional. Apenas tome cuidado com o parâmetro log_line_prefix, que pode ter que ser ajustado.  Segue aqui um exemplo de geração de relatório analítico do pgBadger:

~/pgbadger-6.2$ ./pgbadger --prefix '%t [%p]: [%l] user=%u,db=%d,app=%a,remote=%r ' postgresql-2015-01-20_000000.log
[========================>] Parsed 67110115 bytes of 67110115 (100.00%), queries: 87556, events: 1015
LOG: Ok, generating html report...
~/pgbadger-6.2$ ls -lh out.html
-rw-r--r-- 1 telles telles 2,0M Jan 20 17:23 out.html

O arquivo out.html pode ser aberto em qualquer navegador e possui dezenas de informações úteis. Veja aqui um exemplo de relatório gerado por ele.

Outras ferramentas

Conclusão

Uma parte considerável do trabalho do DBA é gasta analisando logs. É a melhor forma de se avaliar o que aconteceu no passado. Um log bem configurado possibilita um trabalho bem feito. E a chance do seu problema ser resolvido aumenta em probabilidade, velocidade e qualidade. Outra coisa importante é manter o log limpo. É comum ver aplicações que geram lixo no log ou cometem “erros inocentes” que não geram nenhum problema na prática, mas entopem o log de lixo. O log é uma fonte imprescindível de informações no PostgreSQL. Ele possui capacidades bem avançadas para trabalhar com seus logs, mas você precisa pelo menos configura-los corretamente.

FONTES:

- https://www.savepoint.blog.br/2015/01/20/trabalhando-com-logs-no-postgresql/

- https://www.pgpool.net/docs/42/en/html/runtime-config-logging.html

• Elasticsearch: Uma plataforma de analise de dados com inúmeras opções avançadas.