Contadores de tráfego do OpenVPN versus E/S de disco: três números diferentes
Os bytes da interface, os contadores de caracteres do processo e as gravações em disco medem trabalho diferente. Compare-os antes de dimensionar discos pelo volume do túnel.
Faça passar um ficheiro grande por um túnel e o contador da interface sobe pelo tamanho do ficheiro. Nada nesse número implica que o mesmo volume chegou a um disco. Nestas discussões comparam-se três medições diferentes, e respondem a três perguntas diferentes: quanto tráfego atravessou uma camada de rede, quantos bytes um processo leu e escreveu através de chamadas ao sistema, e quanto trabalho chegou à camada de armazenamento.
Comparar a primeira com a terceira é o erro habitual, e produz ou um problema de disco fantasma ou um plano de capacidade que ignora as gravações que realmente acontecem. As três são separáveis, e cada uma tem um uso correto.
Três números que se confundem
Os contadores de interface descrevem o tráfego tratado numa camada de rede. São o número correto para a largura de banda, para o tamanho de um túnel e para modelos de faturação que dão preço ao trânsito.
Os contadores de caracteres do processo descrevem os bytes movidos por chamadas de leitura e escrita em qualquer descritor, incluindo condutas, terminais e dispositivos de caracteres. São o número correto para perguntar quão ocupado está um processo no limite da chamada ao sistema, e não são uma fatura de armazenamento.
Os contadores de armazenamento descrevem os bytes que o núcleo tentou mover para ou de um dispositivo de blocos. São o número correto para planear a capacidade, com a ressalva de que o núcleo documenta os seus próprios limites de contabilização: as leituras em cache não se tornam leituras de armazenamento, e uma escrita mais tarde cancelada não se torna uma escrita de dispositivo concluída.
| Measurement | Question it answers |
|---|---|
| Interface bytes | How much traffic crossed this layer |
rchar and wchar | How much data the process moved through system calls |
read_bytes and write_bytes | How much work reached the storage layer |
Porque é que um descritor de ficheiro não é uma escrita em disco
Uma VPN de espaço de utilizador troca pacotes com o núcleo através de um dispositivo TUN, que é um dispositivo de caracteres e não um ficheiro normal. Ler dele entrega um pacote; escrever nele injeta um. Não há qualquer página de conteúdo de ficheiro preparada para armazenamento, nem qualquer caminho de sistema de ficheiros envolvido.
É por isso que um túnel ocupado pode mostrar contadores de caracteres enormes com quase nenhum contador de armazenamento. O processo realmente moveu esses bytes, e o núcleo realmente não precisou de um disco para o fazer.
cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0
Leia a primeira saída como acumulada desde o início do processo, não como uma taxa. A segunda dá a vista de interface do mesmo tráfego. Uma grande diferença entre as duas é esperada e não indica fuga, fila nem configuração errada.
De onde vêm realmente os bytes
A saída persistente tem o seu próprio orçamento, e é movida por operações e não pela carga útil. Um nível de registo detalhado, uma lista de clientes que muda com frequência ou um erro que se repete num ciclo apertado podem gerar gravações consideráveis enquanto o túnel transporta muito pouco.
Um ficheiro de estado é uma captura reescrita a intervalos, pelo que o seu custo depende do intervalo e de quantos registos contém. Não é uma cópia contínua do tráfego de cada cliente, e encurtar o intervalo muda o volume de escrita sem mudar o volume de tráfego.
A propriedade importa quando procura essas gravações. Se o serviço entrega mensagens a um daemon de registo, o diário ou o ficheiro é escrito por esse daemon, e os bytes aparecem na contabilidade do daemon e não nos contadores próprios do processo VPN. Olhar apenas para o processo VPN não explica nem a atividade de disco nem a sua ausência.
Outros contribuintes são fáceis de ignorar: leituras de certificados e configuração no arranque, ganchos que escrevem os seus próprios registos, extensões de contabilidade, ficheiros de falha e cargas não relacionadas no mesmo anfitrião. Nenhum deles deve ser estimado equiparando o tráfego do túnel aos bytes escritos.
Ler cada contador corretamente
Três detalhes decidem se uma comparação significa algo. A identidade do processo importa, porque um serviço reiniciado reinicia os seus contadores. O intervalo de tempo importa, porque uma cifra acumulada e um gráfico por segundo são medições diferentes. E a unidade importa, porque o tamanho atual de um ficheiro de registo também não é uma taxa.
grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage
Se suspeitar de gravações reais de carga útil, procure um componente cuja tarefa seja armazenar carga útil: uma ferramenta de captura de pacotes, um proxy que guarda corpos em cache, uma extensão que arquiva. Estes produzem tráfego de armazenamento que escala com o que lhes é pedido registar, e pertencem a uma decisão de política separada sobre retenção e acesso.
Planear a capacidade com o número correto
Dimensione o caminho dos pacotes com números de rede: débito, processamento criptográfico e movimento de memória. Dimensione o armazenamento com as escolhas de observabilidade que realmente fez: nível de registo, retenção, intervalo de estado e qualquer captura deliberadamente ativada.
Manter estes dois orçamentos separados também torna os incidentes mais fáceis de ler. Um disco cheio com tráfego de túnel modesto aponta para registos, capturas ou algo não relacionado, e o contador de interface nunca o explicará. Uma ligação saturada com um registo silencioso aponta para o outro lado.
A comparação que vale a pena é entre medições do mesmo tipo. Bytes de interface contra bytes de interface ao longo do tempo falam-lhe do caminho. Gravações de armazenamento contra capacidade de armazenamento falam-lhe da retenção. A comparação cruzada, tráfego contra disco, só parece significativa e nunca o é.