[GTER] gerenciamento de rede

Antonio Carlos Pina antoniocarlospina at gmail.com
Tue May 29 10:20:54 -03 2007


Temos algo assim já implantado e em fase final de ajustes, também em um
datacenter, com 2000 máquinas hospedadas e 180 switches, 40 roteadores, etc.

A idéia é a mesma. Ter coletores independentes que se registram em uma
tabela, que é consultada pela central de monitoramento e que abre os dados
em um frontend. Quando precisamos de um tipo de coleta nova, desenvolvemos o
coletor e ele se registra na tabela (o registro é necessário para que a
central possa receber o "vivo" do coletor e saber que ele está no ar).

O frontend possui várias tabs para destacar os alarmes críticos para nós
(negação de serviços, falta de banda nos uplinks dos switches,etc) dos
alarmes de tendência (espaço em disco acabando, CPU muito alta, etc) e o
acompanhamento de links ponto a ponto. Existe uma tab de "interações" com
cronologia, quando o cliente vem ao Datacenter e efetua uma manutenção, por
exemplo, os alarmes são desativados até o fim da manutenção.

Nosso coletores são escritos também para anotar e atualizar nossos sistemas
internos, se uma máquina é trocada de lugar, por exemplo, ou se a
configuração de um switch é alterado. Essa base é atualizada para que o
sistema aprovisionador possa criar os dados corretamente quando acionado.

Ou seja, você está em um caminho que posso dizer que efetivamente funciona.
Dá trabalho, mas é compensador. E muito extensível.

Grato.




Em 29/05/07, Émerson Brum <emerson_brum at sicredi.com.br> escreveu:
>
>
> Ola lista,
>
> Sempre acompanhei a lista, mas nunca postei. Sei que o assunto de
> monitoramento ja' foi discutido no inicio do mes de maio. Assim, gostaria
> de
> traze-lo de volta para discutirmos.
>
> A empresa onde trabalho esta em busca de uma ferramenta de monitoramento,
> nao que as atuais ferramentas nao ajudem, mas nao satisfazem completamente
> as necessidades desta empresa sem dizer na mao-de-obra do profissional que
> precisa trabalhar com diversas telas ao mesmo tempo ao inves de somente
> uma.
>
> A meta da empresa e' unificar todas ferramentas de monitoramento em uma
> unica ferramenta de monitoramento e/ou desenvolver a partir do zero.
>
> Atualmente estamos trabalhando com ferramentas proprias e outras com
> codigo
> aberto: what'sup, nagios, cacti e zenoss. As tres ultimas citadas, por
> serem
> opensource, nao tive dificuldades em fazer alteracoes e correcoes. Por
> esta
> empresa ja foram feitos testes com os seguintes softwares: Zabix, Ntop,
> weathermap, pandora.
>
> Assim surgiu a ideia de desenvolver uma ferramenta de monitoramento com os
> mesmos principios dos softwares citados anteriormente. Porem com o
> proposito
> de unificar funcoes e caracteristicas.
>
> Trabalho no DataCenter de uma grande empresa, onde existem 500 servidores.
> Esta empresa possui 1.000 filiais espalhadas pelo Brasil. O principal foco
> e' monitorar nao somente o DataCenter, mas tambem estas filiais.
>
> Precisamos criar um agente unico que possa rodar em maquinas windows,
> linux
> e ate mesmo nos switches e routers desta empresa. Este agente –baseado em
> um
> outro softwares chamado collectd- fara' coleta das informacoes mais
> triviais
> de hw e sw. Caso este agente nao consiga fazer estas coletas o protocolo
> SNMP entrara em acao. Cada filial guardara em uma base rrdtool os dados
> coletados, em forma de grafico. Esta base sera transmitida ao DataCenter,
> toda a noite.
>
> Outra dificuldade que iremos enfrentar e' a dependencia e interdependencia
> de ativos, isto e', baseado neste desenho de uma estrutura hierarquica
> ficticia:
>
>
>
> Router
>
>   |
>
> Switch
>
>   |
>
> BD---------------Srv.App
>
>   |
>
> Srv.Web
>
>
>
>
>
> Neste exemplo todos estes ativos seriam monitorados, porem esta ferramenta
> de monitoramento ira alarmar por (sms, email, aviso sonoro) todos aqueles
> ativos que estiverem abaixo do switch, caso ele caisse INDEPENDETE DO SEU
> ESTADO (up ou down).
>
> O motivo pelo qual estou encaminhando este email e' para saber se alguem
> tem
> alguma experiencia com esta area de desenvolvimento ou ja passou por algum
> projeto similar a este e pudesse contribuir com dicas, sugestoes, criticas
> a
> este longo trabalho.
>
>
>
> abracos
>
>
>
>
>
> Att.
>
> Émerson P. Brum
>
>
>
>
>
>
>
> As informacoes contidas neste e-mail e nos arquivos anexados podem ser
> informacoes confidenciais ou privilegiadas. Caso voce nao seja o
> destinatario correto, apague o conteudo desta mensagem e notifique o
> remetente imediatamente.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list