cedrus team mailing list archive

[Leonardo Cezar <lhcezar@xxxxxxxxx>]

2009/12/17 Rodrigo Hjort <rodrigo.hjort@xxxxxxxxx>:

> Por outro lado, o módulo de monitoração de serviços específico para o
> PostgreSQL ainda é muito superficial e um tanto quanto ardiloso (i.e.
> "xunxado"). Por exemplo, nas documentações é sugerido criar parâmetros no
> agente fazendo uso da ferramenta "psql", e cada dado é obtido
> individualmente, e isso sem falar no overhead de se criar e destruir
> backends a cada requisição efetuada, mesmo que local (Unix socket).

Bom, este é o principal problema que estou estudando neste momento.

Muito se descute da melhor forma para se obter os dados tanto do
servidor como do próprio postgres. No entanto o que efetivamente temos
e _não_tão_efetivamente_assim_ é o protocolo SNMP que no caso do
postgres é, como diria um velho amigo, "médio".

Particularmente não gosto das abordagens adotadas pelo collectd,
zabbix e outras ferramentas que utilizam executáveis no sistema de
arquivos para coletar informações. Isto gera alguns problemas de
compatibilidade, portabilidade, dependência de software de terceiros,
entre outros. Em relação a dependência  seria aceitável se fosse
dependencia de bibliotecas, agora fazer chamadas para shell é
complicado.

Considerando esta situação, estou realizando POCs de integração de
bibliotecas (.h , .so e dll) com algumas linguagens (java e python)
utilizando bind e SWIG ou mesmo ctypes (...) para obtermos tais
informações 1) de rd_stat.h 2) stat.h e correlacionar com estatísticas
do banco de dados para informações relativas a custos de acesso a CPU,
memórica em CACHE do kernel dentre outras informações que todo DBA
julga importante e que não são possíveis utilizando apenas estatística
do banco ou software do SO (sar, mpstat, iostat, &c.).

Este é o metodo utilizado pelo EM para coletar informações do sistema
operacional e eu considerei razoável tal implementação.

Os detalhes desta arquitetura podemos discutir num próximo e-mail. Só
tentei descrever o mínimo possível para contextualizar este e-mail.

> Sendo assim, o que vocês acham de fazer com que o CEDRUS não carregue essas
> funcionalidades já desempenhadas pelo ZABBIX ou ferramentas similares
> (Nagios, MRTG, etc)?

De volta a terra ...
Sem problemas. Eu acho que a maior preocupação é elaborar uma
arquitetura consistente de forma que possamos evoluir através de
plugins, assim como funciona o Zabbix, porém um pouco mais
especializado para banco de dados.

> Desta forma poderíamos nos concentrar em fornecer funcionalidades altamente
> específicas e voltadas ao DBA PostgreSQL, tais como a visualização de
> gráficos com dados oriundos do próprio repositório do ZABBIX ou da lista de
> consultas SQL mais onerosas para o SGBD.

+1

> Outra questão que poderia ser atacada seriam modelos (templates) para essas
> ferramentas de monitoração. Recentemente postei esse artigo sobre sugestões
> de configuração do ZABBIX para o  PostgreSQL:
> http://agajorte.blogspot.com/2009/12/postgresql-monitoring-on-zabbix.html

Vou dar uma olhada no seu artigo e depois comento. Mas a idéia de
"padrões" para ferramena de monitoração me agrada.

Abraço!

-Leo
--
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com