Eu posso representar graficamente uma interface de dispositivo com ferramentas SNMP, plataformas como o Cacti até fazem gráficos bonitos, mas elas são baseadas em intervalos de pesquisa (normalmente, a cada 5 minutos).
Eu posso usar o CLI;
r1>show int gi0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is BCM1250 Internal MAC, address is 0011.2233.4455 (bia 0011.2233.4455)
Description: link 1
MTU 1540 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 35/255, rxload 20/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/3208/72484 (size/max/drops/flushes); Total output drops: 1373910311
Queueing strategy: Class-based queueing
Output queue: 0/1000/12 (size/max total/drops)
5 minute input rate 79658000 bits/sec, 19312 packets/sec
5 minute output rate 140174000 bits/sec, 21984 packets/sec
Eu posso ver a partir da taxa de saída de 5 minutos que estou transmitindo 140 Mbps de tráfego, mas essa é a média dos últimos cinco minutos. Então não agora, e não melhor que Cacti et all.
Eu poderia inserir o comando de interface load-interval 30 para reduzir a taxa de amostragem para 30 segundos, quando os valores de txload e rxload se tornam mais precisos.
Novamente, se eu precisar descobrir qual link está maximizado agora, acho difícil acreditar que, para todas as coisas incríveis que os roteadores e switches da Cisco podem fazer, eles não podem me informar sobre a taxa atual de tx / rx para uma interface, agora mesmo.
Eu entendo que um período de amostragem talvez seja necessário para que esse número seja atingível, o que há de errado com um segundo? Certamente a demanda de CPU não é muito, apenas contando o número de pacotes que passam a cada segundo e seu tamanho?
Alguém talvez tenha desenvolvido sua própria maneira de resolver isso? Vejo outros assombrados pelo mesmo enigma?
UPDATE : Eu deveria ter dado um contexto melhor para isso, então vou tentar fazer isso agora.
Uma necessidade típica para eu saber uma taxa de transferência de interface agora, é quando um cliente que tem uma porta de 100Mbps toca e diz "Ei, eu estou baixando X do seu servidor espelhado mas só transferindo a 20Mbps". Quero poder ver a taxa de transferência do seu switch switch agora, enquanto estão no telefone para mim, para confirmar isso (os clientes não técnicos geralmente relatam valores incorretos na minha experiência).
Assim, neste cenário, posso confirmar se a porta do cliente já está recebendo 100Mbps, para que eles recebam apenas 20Mbps porque sua porta está com capacidade, ou se estão até transferindo em algo como a velocidade que estão reivindicando (seja acima ou embaixo). Além disso, em seguida, vou querer ver a taxa de transferência do roteador que o switch está encerrado para todos os clientes, este é outro potencial gargalo. Além disso, posso verificar a porta do switch do servidor espelho enquanto a transferência está em andamento.
Não quero responder ao cliente com "OK, certifique-se de continuar a fazer o download por mais 5 minutos para que eu possa esperar por $ NMS_OF_CHOICE para pesquisar as interfaces", não é uma resposta aceitável aos olhos do cliente. Eu posso dar muitos mais cenários, mas essencialmente, reclamar os clientes é prioridade:)
Eu escrevi um script expect para pesquisar os bytes enviados / recebidos a cada segundo para mim, a partir da saída do comando "show int xxx". A diferença entre cada segundo é o tráfego através da interface.
O script básico está aqui: link
Foi o meu primeiro script de espera, então o meu tópico de estouro de pilha está aqui :) link
Vou adicionar alguns recursos, como descartes e descarte, e criar dois scripts, um para o tráfego e um para o tráfego.
Eu não sou um designer de comutadores, portanto, em termos de qual seria o custo de monitorar com essa frequência, não posso dizer.
O que posso dizer é que me deparei com a situação onde até um segundo nem sempre é suficiente porque você pode sobrecarregar os buffers em períodos menores que um segundo. Então, se você quiser saber se um link está maximizado, recomendo olhar para os pacotes descartados (Você também pode monitorar isso via SNMP). Se você está descartando pacotes (alguns aqui não há problema, mas muito não é bom), então você está exigindo mais do que a interface pode suportar. Isso também pode acontecer em seus servidores antes que eles atinjam o switch. A taxa precisa de pacotes descartados geralmente não é importante, mas se eles continuarem aumentando cada show interface , você provavelmente está em um lugar ruim.
Em termos de Cactos, isso não é um limite do switch ou do SNMP. O SNMP registra os bits enviados e recebidos como um contador crescente, portanto, se você pesquisar a cada segundo, obterá uma resolução por segundo. O modo como funciona é o registro de data e hora de cada amostra e a contagem atual. Em seguida, ele leva a diferença e expressa em unidades de "por segundo", mas na realidade é realmente uma taxa por 5 minutos convertido ou expresso como por segundo.
Se você tentar sondar o SNMP a cada segundo, é melhor assistir sua CPU.
Sua interface está transmitindo e recebendo em velocidades de show completas. Na verdade, não transmite nada a 140Mbps, é exatamente o que calcula a média do intervalo. A utilização do tráfego em tempo real seria inútil para você como um leitor humano, porque seria uma troca constante entre envio / recebimento em 100% e 0%. Se a sua preocupação é a rapidez com que você pode identificar um problema de rede, então eu sugiro o que @ Kyle-Brandt disse acima. Os pacotes descartados são o melhor indicador de um link superutilizado.
Monitor de interface em tempo real da SolarWinds , parte do Ferramenta de ferramentas do engenheiro de rede é capaz de pesquisar interfaces via SNMP tão baixo quanto a cada 5 segundos.
A pesquisa de interfaces de rede via SNMP a cada 5 segundos não é algo que os administradores devem estar fazendo frequentemente como parte de uma solução permanente de monitoramento . No entanto, para monitoramento em um ponto ad-hoc em tempo, há alguns casos em que o intervalo de polling de 60 segundos pode ser útil.
Entender os intervalos de sondagem - à medida que sobem e descem, é fundamental para poder interpretar os dados que saem das ferramentas.
Como um exemplo fictício (mas conceito visto muitas vezes) , uma interface que registra 90% de utilização em um intervalo de 5 segundos pode não levar a problemas percebidos pelo usuário final - no entanto, essa mesma interface em 50% de utilização em um intervalo de 60 segundos pode, de fato, levar ao fim problemas percebidos pelo usuário.
O erro em pensar que a maioria dos administradores faz é assumir que a utilização de 50% em um intervalo de 60 segundos é de alguma forma "menor que" uma utilização de 90% em um intervalo de 5 segundos. Não é "menos que" - não é "maior que". A resposta curta é que os números de utilização não podem ser comparados como se fossem números equivalentes porque os intervalos são diferentes.
Para mergulhar um pouco mais - e mostrar como os extremos podem afetar a matemática - seria possível que a interface operasse a 100% de utilização para um 30 segundos completos - depois, fique em silêncio por 30 segundos - e a utilização em um intervalo de 60 segundos ainda seria de 50%. Durante os 30 segundos de utilização de 100%, os aplicativos do usuário final experimentaram perda de pacotes e / ou atraso suficiente para tempo limite / pausa exibindo uma mensagem.
Compare isso com uma utilização de 90% em um intervalo de 5 segundos. Um caso em que, mesmo se a interface estivesse a 100% de utilização por 4,5 segundos, em silêncio por 0,5 segundos - resultando em 90% de utilização em um intervalo de 5 segundos - a perda e / ou atraso de pacote pode não ser suficiente para causar aplicação do usuário final para reagir ainda.
Os exemplos acima são completamente fictícios - no entanto, o conceito foi testemunhado muitas vezes. A avaliação cogente da sobre-assinatura / superutilização de uma interface depende do conhecimento das ferramentas de monitoramento, da compreensão dos intervalos de monitoramento / pesquisa e da interpretação da saída das ferramentas de monitoramento / pesquisa e do comportamento dos aplicativos em uso. .
Tags cisco