Sou um apaixonado pelo Linux por ele possuir uma série de ferramentas capazes de analisar de forma rápida e prática o estado do seu servidor.

NMON, HTOP e IFTOP são indispensáveis para quem trabalha com administração de grandes parques de servidores Linux e que precisam saber, de vez em quando, sobre a saúde de seus filhotes. É claro que existe monitoração remota utilizando um Nagios ou icinga, mas nada substitui aquela análise a fundo, vc’s sabem disso.

Mas, e quando o seu ambiente, servidores Linux, começa a apresentar problemas de rede, do tipo, perda de pacotes e lentidão, o que fazer nessas horas ?

Simples, coletar evidências utilizando ferramentas como:

ethtool – comando/ferramenta capaz de lhe apresentar e detalhes uma série de informações pertinentes a sua interface rede.

ethtool eth2
Settings for eth2:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: Not reported
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

Não podemos nos esquecer do canivete suíço, eu estou falando do netstat. As opções de comandos netstat -ntlup, anp, nr são as mais comuns, mas vc já deu um simples netstat -s ? Vejam que este comando com a opção -s trás uma série de informações referentes ao servidor e protocolos:

netstat -s
Ip:
100759 total packets received
29 with invalid addresses
0 forwarded
0 incoming packets discarded
100730 incoming packets delivered
51506 requests sent out
Icmp:
16 ICMP messages received
4 input ICMP message failed.
ICMP input histogram:
destination unreachable: 4
echo requests: 7
echo replies: 5
29 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
echo request: 22
echo replies: 7
IcmpMsg:
InType0: 5
InType3: 4
InType8: 7
OutType0: 7
OutType8: 22
Tcp:
227 active connections openings
11 passive connection openings
0 failed connection attempts
5 connection resets received
2 connections established
89476 segments received
50980 segments send out
0 segments retransmited
0 bad segments received.
6 resets sent
Udp:
510 packets received
0 packets to unknown port received.
0 packet receive errors
527 packets sent
UdpLite:
TcpExt:
4 packets pruned from receive queue because of socket buffer overrun
69 TCP sockets finished time wait in fast timer
709 delayed acks sent
1 delayed acks further delayed because of locked socket
Quick ack mode was activated 251 times
1102 packets directly queued to recvmsg prequeue.
109095 bytes directly in process context from backlog
1314840 bytes directly received in process context from prequeue
73515 packet headers predicted
999 packets header predicted and directly queued to user
3014 acknowledgments not containing data payload received
1732 predicted acknowledgments
248 packets collapsed in receive queue due to low socket buffer
4 connections reset due to unexpected data
TCPBacklogDrop: 14
IpExt:
InBcastPkts: 10728
OutBcastPkts: 2
InOctets: 121784410
OutOctets: 4972890
InBcastOctets: 1355803
OutBcastOctets: 142

E o mesmo netstat com a opção -i, você já utilizou ? Vejam o resultado abaixo. Ele lhe mostra o resumo das interfaces de rede.

netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth2 1500 0 100717 0 0 0 51506 0 0 0 BMRU
lo 16436 0 46603 0 0 0 46603 0 0 0 LRU

Existe ainda uma pancada de comandos bem interessantes como o ss -s, que lhe ajuda a investigar os sockets utilizados pelo Linux. Também o nstat, não confundam com o netstat. Vejam como é o output do nstat:

nstat
#kernel
IpInReceives 347 0.0
IpInDelivers 347 0.0
IpOutRequests 227 0.0
TcpPassiveOpens 1 0.0
TcpInSegs 278 0.0
TcpOutSegs 226 0.0
UdpInDatagrams 1 0.0
UdpOutDatagrams 1 0.0
Ip6InReceives 375 0.0
Ip6InDelivers 375 0.0
Ip6OutRequests 375 0.0
Ip6InOctets 61272 0.0
Ip6OutOctets 61272 0.0
Udp6InDatagrams 375 0.0
Udp6OutDatagrams 375 0.0
TcpExtDelayedACKs 2 0.0
TcpExtDelayedACKLocked 1 0.0
TcpExtTCPPrequeued 2 0.0
TcpExtTCPDirectCopyFromPrequeue 1 0.0
TcpExtTCPHPHits 1 0.0
TcpExtTCPPureAcks 171 0.0
TcpExtTCPHPAcks 47 0.0
IpExtInBcastPkts 68 0.0
IpExtInOctets 27690 0.0
IpExtOutOctets 32039 0.0
IpExtInBcastOctets 8665 0.0

E por último, mas não menos importantes, estão o velho e conhecido ifconfig, sar (que precisa do sysstat instalado no seu Linux, além de algumas configurações e ajustes para que ele consiga gerar os relatórios de rede- papo para outro post) e o ip -s link, comando que trás estáticas de todas as suas interfaces, vejam um exemplo logo abaixo:

: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
9734841 46834 0 0 0 0
TX: bytes packets errors dropped carrier collsns
9734841 46834 0 0 0 0
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:db:4f:a6 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
121131669 101447 0 0 0 0
TX: bytes packets errors dropped carrier collsns
3682133 52154 0 0 0 0

Vocês devem estar se perguntando “Mas o que estes comandos poderão auxiliar ajudar a identificar um problema e que a sua responsabilidade seja do time de network ?” Em tudo, caros amigos.

Analisar a quantidade de pacotes dropados ou com erros já é um começo. Outro ponto é verificar se as interfaces de rede do seu servidor estão configuradas para fazer a auto-negociação, coisa que não deve estar. A responsabilidade por essa função pertence aos switches.

Isso sem falar de bater rotas e configurações de ips e netmasks em todas as interfaces. Um networking restart ou service network restart pode causar problemas bem chatos.

Vale lembrar que interfaces de rede precisam de um hardware funcional e vocês sabem que hardware falha e muito. Um cheiro de falha de hardware é quando temos muitos pacotes de erros ou dropados.

Certifique-se que tudo relacionado ao seu ambiente e de sua responsabilidade tenha sido verificado antes de passar a batata quente para alguém, onde os comandos apresentados acima já lhe darão o caminho das pedras, quer dizer onde está a causa raíz.

P.S.: Tem muito mais coisa para falar a respeito disso, redes e linux, mas acho melhor dividir em vários artigos para coisa não ficar massante.

Há, mais uma coisa, ping é bom, mas hping é melhor ainda.. 🙂

Compartilhar:

Este post tem 3 comentários

  1. Bacana, bem que poderia se tornar uma serie de dicas. No aguardo do próximo.

  2. Comprei um pocket de comandos linux, muito bom por sinal, eu uso mais é pra ter no bolso, uma hora vou ler ele, tem alguns desses comandos

  3. Show de bola, certamente um dia precisaremos desses comandos …
    espero a continuação desse assunto ok ? Fiquem com Deus.

Deixe uma resposta

Fechar Menu