Medindo o throughput da rede usando iperf3
Olá, sou um incompetente.
Introdução
Uma vez, tentei receber dados de métricas com Elasticsearch e visualizá-los com kibana, mas não era tão ecológico para usar em casa. Na verdade, embora seja um sistema distribuído, os recursos que ele consumia eram tão intensos que nem minha mente nem meu pequeno servidor doméstico conseguiram suportar, então estou procurando outros métodos.
Ativar o OOM Killer é realmente muito triste para o computador.
Já tenho outras alternativas prontas, mas se tudo o que preciso é enviar métricas, então vou considerar os dados que devem ser enviados em primeiro lugar.
Primeiro, vamos começar com as camadas de baixo nível antes da camada de aplicação.
Instalando iperf3
Desta vez, trabalharei usando meu ThinkPad X1C@Artix Linux como remetente e meu servidor doméstico@Devuan como receptor.
ThinkPad X1C@Artix Linux
$ sudo pacman -S iperf3
Servidor Doméstico@Devuan
$ sudo apt install iperf3
$ sudo ufw allow 5201/tcp
$ sudo ufw reload
O pacote apt de iperf3 iniciará uma TUI perguntando se você deseja iniciá-lo como um daemon, mas desta vez selecionarei n.
Com isso, a preparação está completa.
Medição
O servidor escutará.
Servidor Doméstico@Devuan
$ iperf -s
Envio do lado do cliente. É um ambiente Wi-Fi com algumas paredes no meio, então por favor, seja indulgente... Por outro lado, pode-se dizer que a obtenção de dados de baixa qualidade está a meu favor?
ThinkPad X1C@Artix Linux
$ iperf3 -c DevuanSrvIP
Connecting to host DevuanSrvIP, port 5201
[ 5] local 192.168.10.118 port 41000 connected to DevuanSrvIP port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 10.8 MBytes 90.1 Mbits/sec 0 406 KBytes
[ 5] 1.00-2.00 sec 9.00 MBytes 75.5 Mbits/sec 0 484 KBytes
[ 5] 2.00-3.00 sec 9.38 MBytes 78.6 Mbits/sec 1 485 KBytes
[ 5] 3.00-4.00 sec 7.25 MBytes 60.8 Mbits/sec 0 167 KBytes
[ 5] 4.00-5.00 sec 8.25 MBytes 69.2 Mbits/sec 0 494 KBytes
[ 5] 5.00-6.00 sec 8.62 MBytes 72.3 Mbits/sec 0 496 KBytes
[ 5] 6.00-7.00 sec 9.38 MBytes 78.6 Mbits/sec 1 499 KBytes
[ 5] 7.00-8.00 sec 9.50 MBytes 79.7 Mbits/sec 0 501 KBytes
[ 5] 8.00-9.00 sec 7.62 MBytes 64.0 Mbits/sec 1 505 KBytes
[ 5] 9.00-10.00 sec 7.62 MBytes 63.9 Mbits/sec 0 508 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 87.4 MBytes 73.3 Mbits/sec 3 sender
[ 5] 0.00-10.02 sec 85.3 MBytes 71.5 Mbits/sec receiver
iperf Done.
Apenas com isso, é possível avaliar a qualidade da rede a partir de Retr como retransmissões sob controle de janela na comunicação TCP e Cwnd como o tamanho da janela, e também é possível avaliar a qualidade a partir das variações.
Se for para fazer de forma simples, extraindo apenas o sender:
$ iperf3 -c DevuanSrvIP | grep "sender"
[ 5] 0.00-10.00 sec 83.8 MBytes 70.2 Mbits/sec 1 sender
A partir daqui, parece que não seria impossível passar para awk via pipe e enviar as informações necessárias como dados de métricas.
Conclusão
Outra coisa que me interessa são os dados de métricas de I/O de disco, que parecem interessantes, mas medir o throughput intenso do disco regularmente seria apenas um incômodo, então sinto que seria melhor coletar informações razoáveis de forma pequena, tanto quanto possível. Não é algo que eu normalmente me preocupe, mas seria interessante ver os momentos em que ocorrem esperas de I/O incomuns.
Eu me pergunto até onde os dados de métricas de aplicação devem ser coletados? Sinto que o escopo a ser observado é bastante amplo.
Cada software tem sua própria filosofia de design, então, a partir daí, é preciso desvendar até onde se pode gerar saída. No que diz respeito à coleta de informações externas, parece que a ideia é introduzir módulos e fazer com que eles gerem dados? Mas parece que seria mais flexível focar principalmente nos dados que podem ser coletados apenas pelo lado do SO.
Ou melhor, se as chamadas de sistema estão enviando instruções para a CPU, parece que seria possível rastreá-las de alguma forma, mas essa é outra história...
A propósito, o Elasticsearch, que já instalei por vários motivos no passado, é bastante exigente, a menos que você possa dizer 'pode usar quantos recursos quiser!'. Então, se eu tiver um ambiente assim novamente, pretendo usá-lo.
No entanto, softwares OSS que incorporam elementos de DBs em memória como este são excelentes demais, então, se for usá-los, é preciso julgar cuidadosamente se o nível de uso corresponde ao propósito e ao custo, caso contrário, posso acabar sendo apenas um homem que observa a RAM ser consumida intensamente, então terei cuidado.
Até a próxima. Agradeço a sua atenção.