Contadores de tráfico de OpenVPN frente a E/S de disco: tres números distintos

Haga pasar un archivo grande por un túnel y el contador de interfaz sube por el tamaño del archivo. Nada en ese número implica que el mismo volumen llegara a un disco. En estas conversaciones se comparan tres mediciones distintas, y responden a tres preguntas distintas: cuánto tráfico cruzó una capa de red, cuántos bytes leyó y escribió un proceso mediante llamadas al sistema, y cuánto trabajo llegó a la capa de almacenamiento.

Comparar la primera con la tercera es el error habitual, y produce o bien un problema de disco fantasma o bien un plan de capacidad que ignora las escrituras que realmente ocurren. Las tres son separables, y cada una tiene un uso correcto.

Tres números que se confunden

Los contadores de interfaz describen el tráfico gestionado en una capa de red. Son el número correcto para el ancho de banda, para el tamaño de un túnel y para los modelos de facturación que ponen precio al tránsito.

Los contadores de caracteres del proceso describen los bytes movidos por llamadas de lectura y escritura sobre cualquier descriptor, incluidas tuberías, terminales y dispositivos de caracteres. Son el número correcto para preguntar cuán ocupado está un proceso en el límite de la llamada al sistema, y no son una factura de almacenamiento.

Los contadores de almacenamiento describen los bytes que el núcleo intentó mover hacia o desde un dispositivo de bloques. Son el número correcto para planificar la capacidad, con la advertencia de que el núcleo documenta sus propios límites de contabilidad: las lecturas en caché no se convierten en lecturas de almacenamiento, y una escritura que luego se cancela no se convierte en una escritura de dispositivo completada.

Por qué un descriptor de archivo no es una escritura en disco

Una VPN de espacio de usuario intercambia paquetes con el núcleo mediante un dispositivo TUN, que es un dispositivo de caracteres y no un archivo normal. Leer de él entrega un paquete; escribir en él inyecta uno. No hay una página de contenido de archivo preparada para el almacenamiento, ni ninguna ruta del sistema de archivos implicada.

Por eso un túnel ocupado puede mostrar contadores de caracteres enormes con casi ningún contador de almacenamiento. El proceso realmente movió esos bytes, y el núcleo realmente no necesitó un disco para hacerlo.

cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0

Lea la primera salida como acumulada desde el inicio del proceso, no como una tasa. La segunda da la vista de interfaz del mismo tráfico. Una brecha grande entre las dos es esperable y no indica una fuga, una cola ni una configuración incorrecta.

De dónde vienen realmente los bytes

La salida persistente tiene su propio presupuesto, y lo impulsan las operaciones, no la carga útil. Un nivel de registro detallado, una lista de clientes que cambia a menudo o un error que se repite en un bucle cerrado pueden generar escrituras considerables mientras el túnel transporta muy poco.

Un archivo de estado es una instantánea reescrita a un intervalo, así que su coste depende del intervalo y de cuántos registros contiene. No es una copia continua del tráfico de cada cliente, y acortar el intervalo cambia el volumen de escritura sin cambiar el volumen de tráfico.

La propiedad importa cuando busca esas escrituras. Si el servicio entrega mensajes a un demonio de registro, el diario o el archivo lo escribe ese demonio, y los bytes aparecen en la contabilidad del demonio y no en los contadores propios del proceso VPN. Mirar solo el proceso VPN no explica ni la actividad de disco ni su ausencia.

Otros contribuyentes son fáciles de pasar por alto: lecturas de certificados y configuración al arrancar, ganchos que escriben sus propios registros, complementos de contabilidad, volcados de fallos y cargas no relacionadas en el mismo host. Ninguno debería estimarse equiparando el tráfico del túnel con los bytes escritos.

Leer cada contador correctamente

Tres detalles deciden si una comparación significa algo. La identidad del proceso importa, porque un servicio reiniciado reinicia sus contadores. El intervalo de tiempo importa, porque una cifra acumulada y un gráfico por segundo son mediciones distintas. Y la unidad importa, porque el tamaño actual de un archivo de registro tampoco es una tasa.

grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage

Si sospecha escrituras reales de carga útil, busque un componente cuya tarea sea almacenar carga útil: una herramienta de captura de paquetes, un proxy que cachea cuerpos, un complemento que archiva. Estos producen tráfico de almacenamiento que escala con lo que se les pide registrar, y pertenecen a una decisión de política separada sobre retención y acceso.

Planificar la capacidad con el número correcto

Dimensione la ruta de paquetes con cifras de red: caudal, procesamiento criptográfico y movimiento de memoria. Dimensione el almacenamiento con las decisiones de observabilidad que realmente tomó: nivel de registro, retención, intervalo de estado y cualquier captura habilitada deliberadamente.

Mantener esos dos presupuestos separados también hace más fácil leer los incidentes. Un disco lleno con un tráfico de túnel modesto apunta a registros, capturas o algo no relacionado, y el contador de interfaz nunca lo explicará. Un enlace saturado con un registro silencioso apunta al otro lado.

La comparación que vale la pena es entre mediciones del mismo tipo. Bytes de interfaz frente a bytes de interfaz a lo largo del tiempo le hablan de la ruta. Escrituras en disco frente a capacidad de almacenamiento le hablan de la retención. La comparación cruzada, tráfico frente a disco, solo parece significativa y nunca lo es.