Compteurs de trafic OpenVPN et E/S disque : trois nombres différents

Faites passer un gros fichier dans un tunnel et le compteur d’interface augmente de la taille du fichier. Rien dans ce nombre n’implique que le même volume ait atteint un disque. Trois mesures différentes sont comparées dans ces discussions, et elles répondent à trois questions différentes : quelle quantité de trafic a traversé une couche réseau, combien d’octets un processus a lus et écrit via des appels système, et quelle quantité de travail a atteint la couche de stockage.

Comparer la première à la troisième est l’erreur habituelle, et elle produit soit un problème de disque fantôme, soit un plan de capacité qui ignore les écritures qui ont réellement lieu. Les trois sont séparables, et chacune a un usage correct.

Trois nombres que l’on confond

Les compteurs d’interface décrivent le trafic traité au niveau d’une couche réseau. Ils constituent le bon nombre pour la bande passante, pour la taille d’un tunnel et pour les modèles de facturation qui tarifent le transit.

Les compteurs de caractères d’un processus décrivent les octets déplacés par des appels de lecture et d’écriture sur n’importe quel descripteur, y compris les tubes, les terminaux et les périphériques de caractères. Ils constituent le bon nombre pour demander à quel point un processus est occupé à la frontière de l’appel système, et ce n’est pas une facture de stockage.

Les compteurs de stockage décrivent les octets que le noyau a tenté de déplacer vers ou depuis un périphérique bloc. Ils constituent le bon nombre pour planifier la capacité, avec la réserve que le noyau documente ses propres limites de comptabilité : les lectures mises en cache ne deviennent pas des lectures de stockage, et une écriture annulée plus tard ne devient pas une écriture de périphérique achevée.

Pourquoi un descripteur de fichier n’est pas une écriture disque

Un VPN en espace utilisateur échange des paquets avec le noyau via un périphérique TUN, qui est un périphérique de caractères et non un fichier ordinaire. Lire depuis celui-ci remet un paquet ; y écrire en injecte un. Aucune page de contenu de fichier n’est préparée pour le stockage, et aucun chemin de système de fichiers n’est impliqué.

C’est pourquoi un tunnel actif peut afficher d’énormes compteurs de caractères avec presque aucun compteur de stockage. Le processus a réellement déplacé ces octets, et le noyau n’a réellement pas eu besoin d’un disque pour le faire.

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

Lisez la première sortie comme cumulée depuis le démarrage du processus, non comme un débit. La seconde donne la vue d’interface du même trafic. Un grand écart entre les deux est attendu et n’indique ni fuite, ni file d’attente, ni mauvaise configuration.

D’où viennent réellement les octets

La sortie persistante a son propre budget, et il est piloté par les opérations plutôt que par la charge utile. Un niveau de journal verbeux, une liste de clients qui change souvent ou une erreur qui se répète en boucle serrée peuvent générer des écritures substantielles alors que le tunnel ne transporte que très peu.

Un fichier d’état est un instantané réécrit à intervalle régulier, donc son coût dépend de l’intervalle et du nombre d’enregistrements qu’il contient. Ce n’est pas une copie continue du trafic de chaque client, et raccourcir l’intervalle change le volume d’écriture sans changer le volume de trafic.

La propriété compte lorsque vous cherchez ces écritures. Si le service remet les messages à un démon de journalisation, le journal ou le fichier est écrit par ce démon, et les octets apparaissent dans la comptabilité du démon plutôt que dans les compteurs propres du processus VPN. Regarder seulement le processus VPN n’explique ni l’activité disque ni son absence.

D’autres contributeurs sont faciles à négliger : lectures de certificats et de configuration au démarrage, crochets qui écrivent leurs propres enregistrements, greffons de comptabilité, vidages de plantage et charges de travail sans lien sur le même hôte. Aucun ne devrait être estimé en assimilant le trafic du tunnel aux octets écrits.

Lire chaque compteur correctement

Trois détails décident si une comparaison signifie quelque chose. L’identité du processus compte, car un service redémarré remet ses compteurs à zéro. L’intervalle de temps compte, car un chiffre cumulé et un graphique par seconde sont des mesures différentes. Et l’unité compte, car la taille actuelle d’un fichier de journal n’est pas non plus un débit.

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 vous soupçonnez de vraies écritures de charge utile, cherchez un composant dont le travail est de stocker la charge utile : un outil de capture de paquets, un proxy qui met les corps en cache, un greffon qui archive. Ceux-ci produisent du trafic de stockage qui évolue avec ce qu’on leur demande d’enregistrer, et ils relèvent d’une décision de politique distincte sur la rétention et l’accès.

Planifier la capacité avec le bon nombre

Dimensionnez le chemin des paquets avec des chiffres réseau : débit, traitement cryptographique et déplacement mémoire. Dimensionnez le stockage avec les choix d’observabilité que vous avez réellement faits : niveau de journal, rétention, intervalle d’état et toute capture volontairement activée.

Garder ces deux budgets séparés rend aussi les incidents plus faciles à lire. Un disque plein avec un trafic de tunnel modeste désigne les journaux, les captures ou autre chose sans rapport, et le compteur d’interface ne l’expliquera jamais. Un lien saturé avec un journal silencieux désigne l’inverse.

La comparaison qui vaut la peine est entre des mesures de même nature. Les octets d’interface contre les octets d’interface dans le temps vous parlent du chemin. Les écritures de stockage contre la capacité de stockage vous parlent de la rétention. La comparaison croisée, trafic contre disque, ne fait que sembler significative et ne l’est jamais.