Contadores de tráfico de OpenVPN fronte a E/S de disco: tres números distintos
Os bytes de interface, os contadores de caracteres do proceso e as escrituras en disco miden traballo distinto. Compáreos antes de dimensionar discos a partir do volume do túnel.
Faga pasar un ficheiro grande por un túnel e o contador de interface sobe polo tamaño do ficheiro. Nada nese número implica que o mesmo volume chegase a un disco. Nestas conversas compáranse tres medicións distintas, e responden a tres preguntas distintas: canto tráfico cruzou unha capa de rede, cantos bytes leu e escribiu un proceso mediante chamadas ao sistema, e canto traballo chegou á capa de almacenamento.
Comparar a primeira coa terceira é o erro habitual, e produce ou ben un problema de disco pantasma ou ben un plan de capacidade que ignora as escrituras que realmente ocorren. As tres son separables, e cada unha ten un uso correcto.
Tres números que se confunden
Os contadores de interface describen o tráfico xestionado nunha capa de rede. Son o número correcto para o ancho de banda, para o tamaño dun túnel e para os modelos de facturación que poñen prezo ao tránsito.
Os contadores de caracteres do proceso describen os bytes movidos por chamadas de lectura e escrita sobre calquera descritor, incluídas tubaxes, terminais e dispositivos de caracteres. Son o número correcto para preguntar canto ocupado está un proceso no límite da chamada ao sistema, e non son unha factura de almacenamento.
Os contadores de almacenamento describen os bytes que o núcleo intentou mover cara a ou desde un dispositivo de bloques. Son o número correcto para planificar a capacidade, coa advertencia de que o núcleo documenta os seus propios límites de contabilidade: as lecturas na caché non se converten en lecturas de almacenamento, e unha escritura que logo se cancela non se converte nunha escritura de dispositivo completada.
| 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 |
Por que un descritor de ficheiro non é unha escritura en disco
Unha VPN de espazo de usuario intercambia paquetes co núcleo mediante un dispositivo TUN, que é un dispositivo de caracteres e non un ficheiro normal. Ler del entrega un paquete; escribir nel inxecta un. Non hai ningunha páxina de contido de ficheiro preparada para o almacenamento, nin ningunha ruta do sistema de ficheiros implicada.
Por iso un túnel ocupado pode mostrar contadores de caracteres enormes con case ningún contador de almacenamento. O proceso realmente moveu eses bytes, e o núcleo realmente non necesitou un disco para facelo.
cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0
Lea a primeira saída como acumulada desde o inicio do proceso, non como unha taxa. A segunda dá a vista de interface do mesmo tráfico. Unha fenda grande entre as dúas é esperable e non indica unha fuga, unha cola nin unha configuración incorrecta.
De onde veñen realmente os bytes
A saída persistente ten o seu propio orzamento, e impúlsano as operacións, non a carga útil. Un nivel de rexistro detallado, unha lista de clientes que cambia a miúdo ou un erro que se repite nun bucle pechado poden xerar escrituras considerables mentres o túnel transporta moi pouco.
Un ficheiro de estado é unha instantánea reescrita a un intervalo, así que o seu custo depende do intervalo e de cantos rexistros contén. Non é unha copia continua do tráfico de cada cliente, e acurtar o intervalo cambia o volume de escritura sen cambiar o volume de tráfico.
A propiedade importa cando busca esas escrituras. Se o servizo entrega mensaxes a un demo de rexistro, o diario ou o ficheiro escríbeo ese demo, e os bytes aparecen na contabilidade do demo e non nos contadores propios do proceso VPN. Mirar só o proceso VPN non explica nin a actividade de disco nin a súa ausencia.
Outros contribuíntes son fáciles de pasar por alto: lecturas de certificados e configuración ao arrincar, ganchos que escriben os seus propios rexistros, complementos de contabilidade, volcados de fallo e cargas non relacionadas no mesmo host. Ningún deles debería estimarse equiparando o tráfico do túnel cos bytes escritos.
Ler cada contador correctamente
Tres detalles deciden se unha comparación significa algo. A identidade do proceso importa, porque un servizo reiniciado reinicia os seus contadores. O intervalo de tempo importa, porque unha cifra acumulada e un gráfico por segundo son medicións distintas. E a unidade importa, porque o tamaño actual dun ficheiro de rexistro tampouco é unha 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 sospeita escrituras reais de carga útil, busque un compoñente cuxa tarefa sexa almacenar carga útil: unha ferramenta de captura de paquetes, un proxy que cachea corpos, un complemento que arquiva. Estes producen tráfico de almacenamento que escala co que se lles pide rexistrar, e pertencen a unha decisión de política separada sobre retención e acceso.
Planificar a capacidade co número correcto
Dimensione a ruta de paquetes con cifras de rede: caudal, procesamento criptográfico e movemento de memoria. Dimensione o almacenamento coas decisións de observabilidade que realmente tomou: nivel de rexistro, retención, intervalo de estado e calquera captura habilitada deliberadamente.
Manter eses dous orzamentos separados tamén fai máis fácil ler os incidentes. Un disco cheo cun tráfico de túnel modesto apunta a rexistros, capturas ou algo non relacionado, e o contador de interface nunca o explicará. Unha ligazón saturada cun rexistro silencioso apunta ao outro lado.
A comparación que paga a pena é entre medicións do mesmo tipo. Bytes de interface fronte a bytes de interface ao longo do tempo fálanlle da ruta. Escrituras en disco fronte a capacidade de almacenamento fálanlle da retención. A comparación cruzada, tráfico fronte a disco, só parece significativa e nunca o é.