Posted by admin on ago 13, 2010 in
Network
 |
Quando você tem um site ou uma rede, é sempre bom ser alertado sobre possíveis problemas tão logo eles ocorram. Existem diversas ferramentas gratuitas e com código aberto que podem supervisionar sua infraestrutura e enviar alertas quando ocorrerem problemas.
Conheça abaixo 10 ferramentas gratuitas que podem ajudar você a monitorar seu servidor, cluster ou rede. |
1. Monit – Link: http://mmonit.com/monit/
O Monit não apenas monitora seu servidor como também tenta solucionar problemas executando ações pré-definidas para certas situações. Por exemplo, se seu banco de dados travar, o Monit pode reiniciar o serviço automaticamente se esta for a ação que você deseja executar (e geralmente é).
Além disso se você tiver mais de um servidor para monitorar, você pode usar o M/Monit, uma versão do Monit com recursos para monitorar múltioplos servidores.
2. Ganglia – Link: http://ganglia.info/
Quando você tem um cluster com várias máquinas, é difícil saber qual o estado do cluster como um todo. E é aí que entra o Ganglia, já que com ele você tem uma visão geral de todo o cluster.
3. Munin – Link: http://munin.projects.linpro.no/
O Munin monitora e exibe um gráfico da performance do sistema. Ele pode produzir gráficos de performance diários, semanais, mensais, anuais e relatórios com diversas informações importantes. Ele pode monitorar recursos como memória, espaço em disco, uso de CPU e aplicações para servidores como MySQL, Apache e Squid.
Um destaque do Munin é que com apenas algumas linhas de código você pode criar um plugin para o monitoramento de praticamente qualquer coisa.
4. Cacti – Link: http://www.cacti.net/
O Cacti é simular ao Munin em vários aspectos, mas o que o torna diferente é que ele permite o redimensionamento dos gráficos e a visualização de dados em um intervalo específico (de 2 em 2 horas, por exemplo).
5. Nagios – Link: http://www.nagios.org/
O Nagios pode ser um pouco complicado para instalar e usar, mas seu grande número de recursos supera muitas outras ferramentas voltadas para administradores de TI. O programa suporta o monitoramento de múltiplos hosts e pode enviar alertas via e-mail, pager (!) ou SMS.
Assim como o Monit, ele pode agir automaticamente em certas situações.
6. Zabbix – Link:
O Zabbix é uma ferramenta de monitoramento repleta de recursos. Ele suporta visualizações personalizadas, zoom e mapeamento. Além disso ele também pode enviar alertas por e-mail, SMS, mensagem instantânea e também pode emitir alertas sonoros, o que é bom para quando você não estiver perto da máquina monitorada.
7. ObserverNMS – Link: http://www.observernms.org/
O ObserverNMS é voltado para o Linux, BSD e redes Cisco. O programa suporta a descoberta automática da infraestrutura de rede, oferece gráficos detalhados e pode ser usado em conjunto com o Nagios. Ele também se integra bem ao Collectd caso você queira uma interface mais robusta.
8. Zenoss – Link: http://www.zenoss.com/
O Zenoss é uma versão com código aberto da ferramenta comercial para monitoramento de servidores chamada Zenoss Enterprise. Ele foi criado inteiramente em Python, suporta o formato de plugins do Nagios e sua interface é simples e fácil de usar.
9. Collectd – Link: http://collectd.org/
O Collectd é similar ao Munin e ao Cacti. A diferença é que o Collectd foi desenvolvido com foco na portabilidade e performance. O programa pode coletar dados a cada 10 segundos sem interferir nos processos do seu servidor. Você pode criar extensões para ele em C, Perl ou Java.
10. Argus – Link: http://argus.tcp4me.com/
O foco do Argus é o monitoramento dos serviços de rede e suporta os protocolos IPv4 e IPv6. Seu sistema de alertas é bem interessante: se ele enviar um alerta sobre um problema para você e este problema não for resolvido em um intervalo pré-definido, um outro alerta será enviado para outra pessoa.
Fonte: CPTURBO
Posted by admin on fev 16, 2009 in
Network A ferramenta traceroute é utilizada para determinar o caminho (ou rota) por onde os pacotes IP trafegam de uma origem A até um destino B na rede. No entanto, a forma como esta ferramenta é utilizada e como são determinadas as rotas na Internet pode confundir o usuário desatento.
O traceroute funciona enviando pacotes com o campo Time To Live (TTL) configurado para 1. O primeiro roteador (primeiro hop) envia então um pacote (ICMP) indicando que o pacote não pode ser roteado (devido ter expirado o TTL) para a origem. Após receber a indicação de erro, um outro pacote é enviado com o TTL configurado para 2 e o segundo roteador (segundo hop) neste momento enviará uma indicação de erro para a origem. Esse processo continua até que se alcance o destino ou um limite pré-determinado. Para mais informações sobre o funcionamento do traceroute consultar o RFC1393.
Uma das desvantagens deste mecanismo é que existem alguns roteadores (ou firewalls de camada 3) que não enviam pacotes ICMP TTL Expiried e, portanto, o traceroute ficará incompleto nestes casos. No entanto, o mecanismo do traceroute continuará funcionando ou mesmo o acesso da origem até o destino independentemente do resultado do traceroute.
Vejamos então o exemplo abaixo:
traceroute to registro.br (200.160.2.3), 30 hops max, 38 byte packets
1 10.13.0.1 (10.13.0.1) 13.016 ms 14.776 ms 20.168 ms
2 c9060002.virtua.com.br (201.6.0.2) 26.941 ms 12.479 ms 47.129 ms
3 c9060005.virtua.com.br (201.6.0.5) 15.636 ms 15.005 ms 13.898 ms
4 embratel-G6-0-gacc05.spo.embratel.net.br (200.178.78.1) 25.453 ms 12.044 ms 12.600 ms
5 ebt-C1-core03.spo.embratel.net.br (200.230.242.18) 166.976 ms 152.516 ms 59.465 ms
MPLS Label=440 CoS=0 TTL=1 S=1
6 200.244.40.185 (200.244.40.185) 25.348 ms 32.426 ms 45.846 ms
MPLS Label=26 CoS=0 TTL=1 S=1
7 ebt-G6-0-gacc02.pae.embratel.net.br (200.230.221.130) 34.828 ms 26.831 ms 40.176 ms
8 brasiltelecom-P4-1-gacc02.pae.embratel.net.br (200.248.240.26) 51.079 ms 40.072 ms 35.036 ms
9 BrT-G7-1-1-pae-core01.brasiltelecom.net.br (201.10.225.29) 173.797 ms 70.255 ms 48.286 ms
MPLS Label=836 CoS=0 TTL=1 S=1
10 BrT-G3-0-bsace-core01.brasiltelecom.net.br (201.10.192.33) 50.676 ms 61.465 ms 49.934 ms
MPLS Label=898 CoS=0 TTL=1 S=1
11 BrT-P2-11-spopa-core01.brasiltelecom.net.br (201.10.192.169) 61.742 ms 54.972 ms 72.244 ms
MPLS Label=35 CoS=0 TTL=1 S=1
12 BrT-G0-1-2-spopa302.brasiltelecom.net.br (201.10.241.150) 47.699 ms 86.113 ms 79.095 ms
13 BRT-RegistroBR.brasiltelecom.net.br (200.169.193.2) 55.980 ms 52.105 ms 71.012 ms
14 registro.br (200.160.2.3) 58.213 ms 49.184 ms 70.845 ms
Este traceroute, feito de um acesso net/virtua para um IP do registro.br, mostra por onde os pacotes devem passar para sair do meu computador até os servidores do Registro.br: net/virtua, embratel, brasiltelecom e finalmente, registro.br. Observe o caminho de ida traçado em verde e o caminho de volta (do registro.br para o meu computador) destacado em vermelho. Este caminho destacado em vermelho é a interconexão entre NET e Registro.br através do PTT-Metro.
Desta figura podemos rapidamente chegar a duas conclusões importantes:
1) O tempo total apresentado nos pacotes de A (net/virtua) até B (registro.br) é o tempo de ida (destacado em verde) adicionado ao tempo de volta (em vermelho).
2) Sabendo que o tempo total é o tempo de ida + volta, então também devemos admitir que, dada a política de roteamento adotada por cada provedor presente na rede, o pacote de resposta para cada um dos hops pode retornar por caminhos diferentes do caminho de ida e, portanto, o tempo apresentado por cada hop pode sofrer influência de outros caminhos que não aquele que podemos visualizar na saída do traceroute (caminho de ida).
Por exemplo, se observarmos atentamente as conexões da figura acima veremos que a embratel possui uma conexão com a globalcrossing (gblx) que, por sua vez, possui uma conexão com a net/virtua. Em um determinado momento os pacotes da embratel até a net/virtua podem (devido a política de roteamento adotada pela embratel) trafegar pela gblx e, portanto, o tempo da net/virtua até a embratel será a soma do tempo de ida (net/virtua até embratel) e do tempo de volta (embratel até net/virtua, passando pela gblx). A observação de um tempo de resposta elevado no hop embratel poderá portanto indicar um problema na net/virtua, embratel ou gblx.
A ferramenta traceroute pode ser facilmente utilizada nos principais sistemas operacionais disponíveis (unix/linux ou windows). No unix/linux o traceroute utiliza geralmente pacotes UDP (utilizar opção “-I” para pacotes ICMP) e no windows o tracert utiliza pacotes ICMP. Além disso, podemos utilizar front-ends disponíveis na web para obter o resultado da ferramenta traceroute – dentre outras ferramentas – para analisar problemas de rede verificando o caminho de diversos provedores e lugares do mundo para um destino específico. Para mais informações acessar o website traceroute.org mantido por Thomas Kernen
Tags:Network
