pgfouine e log_line_prefix hacking

A ferramenta de análise de logs pgfouine é sem dúvida nenhuma uma ferramenta indispensável para qualquer DBA no quesito de análise de logs.

Confesso que fui utilizador assíduo do PQA (antecessor falecido do pgfouine) e quando conheci o pgfouine foi amor à primeira vista e acabei largando um pouco o ruby em troca de um php bem escrito .

Deixarei um pouco a paixão de lado pra falar de uma funcionalidade caracterizada como deficiente no pgfouine, IMHO.

A questão é que para funcionamento correto, o pgfouine exige um formato padrão da variável de configuração log_line_prefix (‘%t [%p]: [%l-1]), e diga-se de passagem é bem conciso, mas muitas vezes não aceitável.

Quem já precisou alterar uma variável de um servidor que não pode ser reiniciado vai entender de que estou falando; ou pior ainda, quem precisa manter um formato consistente com normas internas porque existe uma política na empresa para arquivamento de logs também vai perceber.

Então, antes que tudo se desabe e voce no 5o. andar de seu prédio saia de maneira inconsolável de sua mesa em direção a janela mais próxima, eis que surgem as expressões regulares. Sim, sim elas!
Basta entender a forma como o parser do pgfouine trabalha para alterar nada mais de que (com sorte) uma única linha do núcleo desta ferramenta.

Deixemos de enrolação e vamos realmente ao que interessa:

O programa pgfouine.php inicializa o percurso que os trechos de log deverão seguir até o parser. Esta parte do fluxo tem por objetivo fazer algumas validações e configurações iniciais (informações de banco, opções escolhidas, &ca) e por fim carregar a classe GenericLogReader que baseada nas opções do usuário invoca o acumulador (Acummulator) de logs específico. A função do acumulador é avaliar o eventType de listener e armazenar o resultado em um stream para análise futura pelo parser mais adequado. Basicamente existem duas classes (tipos) maiores de eventType: uma de erro e outra de instruções SQL. Os detalhes sobre os event listeners podem ser localizados em $PGFHOME/include/listeners. A próxima etapa (e a que mais nos interessa), é a fase de parser os logs.
O pgfouine ainda não foi internacionalizado (i18n) portanto pode ser necessário alterar as expressões regulares em $PGFHOME/include/postgresql/PostgreSQLRegexps.lib.php. Basta ver qual o formato de seu arquivo de log e literalmente substituir as strings desse arquivo pelas correspondentes nos logs. Agora os arquivos responsáveis por gerar a informação que o pgfouine “confia” para criação dos gráficos, estatísticas e demais recursos visualizados no produto final, são os arquivos StderrPostgreSQLParser.class.php e SyslogPostgreSQLParser.class.php localizados em $PGFHOME/include/postgresql/parsers e estão na última etapa do percurso da conversão log -> documento. As classes StderrPostgreSQLParser e
SyslogPostgreSQLParser fazem a análise de stderr e syslog respectivamente como é óbviamente notado. Ambas possuem em seus construtores uma propriedade inicializando um objeto do tipo RegExp que é o assunto principal desse post e deve ser alterado para “casar” com o formato de seu log_line_prefix. Em nosso caso estava bem simples e foi apenas alterar o caracter especial de início de linha para “casar” com o formato do log, mas conhecendo um pouquinho de expressões regulares voce será capaz de combinar qualquer formato da linha de seus logs com o pgfouine sem a alteração da variável de configuração log_line_prefix e sem reiniciar o servidor de banco de dados.

-Leo

patch retira autovaccum do backend

Pessoal,

Conforme prometido no último pgcon e com apoio financeiro da BEA Systems, é com orgulho que envio o patch que tem como objetivo retirar o autovaccum do backend.

A principal idéia responsável por esse avanço foi a criação de uma ferramenta chamada autoclean.

O componente autoclean atua como um processo filho de postmaster e toda vez que uma página é alterada, o autoclean detecta quais páginas estão disponíveis para armazenar e em seguida mover para áreas disponíveis em VacPageData. Para isso free_space_pages deve estar configurado corretamente.

Outra função do autoclean é detectar páginas sujas e enviá-las para uma área reservada de reciclagem (C:\Meu Computador\Desktop\Lixeira) aliviando a carga do background writer.

Existe ainda a possibilidade de uma página, já reciclada, estar “parcialmente” suja e o autoclean avaliar de acordo com heurísticas uma chamada para a rotina void AutoCleanDirtyClothes(Page *page) que irá causar uma limpeza total daquela página e coloca-la em VacPageListData.

TransactionId wraparound

Com a implementação do autoclean foi criado também um novo tipo para a variável TransactionId para suprir a necessidade de “zerar” o contador de transações, o uint128, um novo tipo com suporte para 128 bits (o segredo aqui foi a geração de um algoritmo de ponto flutuante para suporte ao tipo em servidores de 32 e 64 bits). Dessa forma XID agora foi tipado com uint128.

Outra novidade é que transações já nascem marcadas como XID=2 (Frozen), então o MVCC não precisa mais “adivinhar” qual é a transação mais recente e … Espera aí!! Mas então porque precisamos tipar XID com 128 bits uma vez que usa apenas 1 ??? Hmm, hora de volta à prancheta …

Gente, quanta besteira!!!

Só pra não esquecer que hoje é 1º. de abril.

Abraço!

-Leo