cedrus team mailing list archive

[Rodrigo Hjort <rodrigo.hjort@xxxxxxxxx>]

Fala Leo, tudo tranquilo?


2009/12/18 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.
>
>
Não resta dúvida de que tais abordagens sejam de certo modo intrusivas,
porém
vejo nelas a vantagem de se ter uma solução altamente flexível (ex: podem-se
configurar indicadores customizados a serem monitorados) e portável (ex: o
agente
ZABBIX roda em tudo quanto é plataforma, inclusive Window$).



> 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.
>
>
Aí é que está, tais informações do SO e a maneira com que elas são extraídas
tornam-se dependentes da plataforma (i.e. syscalls e recursos distintos).

Comecei a dar uma olhada no pgsnmp, porém ele funciona da mesma forma,
é preciso rodar um serviço em background que se comunica com o PG através
da "lipq" via TCP ou Unix socket e que executa instruções SQL com base
na MIB requerida via SNMP (i.e. RDBMS-MIB). O problema dela é que não
podemos simplesmente criar um novo indicador (i.e. modificar a MIB) e mesmo
que isso fosse possível seria preciso recompilar o binário, que não está
portável
para ambientes além do Linux... Além disso, mesmo que o servidor já possua
outros agentes, tais como o do ZABBIX, teríamos que rodar o agente do
pgsnmpd..


Os detalhes desta arquitetura podemos discutir num próximo e-mail. Só
> tentei descrever o mínimo possível para contextualizar este e-mail.
>
>
OK, essa é a ideia inicial: provocar os integrantes dessa lista a
participarem com opiniões. :)



> > 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
>
>
OK, pensando em termos práticos, o CEDRUS seria uma ferramenta a ser
utilizada
pelo DBA pensando em ajudá-lo a resolver (ou até mesmo prever) problemas
específicos
de SGBD. Ao pessoal responsável pela monitoração dos servidores (e serviços)
restariam
templates com configurações padrões (ou customizadas), as quais
contemplariam
mecanismos de acionamento do DBA no caso de algum disparador ocorrer.

Em outras palavras, ao CEDRUS restaria a tarefa de análise detalhada do
SGBD,
enquanto que outras ferramentas (e.g. ZABBIX) ficariam com o trabalho
operacional de
monitoração do ambiente.



> > 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
>


Bom final de semana a todos!

Abraço,

-- 
Rodrigo Hjort
SERPRO/CETEC/Curitiba
www.serpro.gov.br