Лічильники трафіку OpenVPN і дискове введення-виведення: три різні числа

Пропустіть великий файл через тунель, і лічильник інтерфейсу зросте на розмір файлу. Ніщо в цьому числі не означає, що той самий обсяг дістався диска. У таких обговореннях порівнюють три різні вимірювання, і вони відповідають на три різні питання: скільки трафіку перетнуло мережевий рівень, скільки байтів процес прочитав і записав через системні виклики і скільки роботи дійшло до рівня зберігання.

Порівнювати перше з третім — звичайна помилка, і вона породжує або примарну проблему з диском, або план ємності, який ігнорує записи, що справді відбуваються. Ці три можна розділити, і кожне має правильне застосування.

Три числа, які плутають

Лічильники інтерфейсу описують трафік, який обробляється на мережевому рівні. Це правильне число для пропускної здатності, для розміру тунелю і для моделей тарифікації, які призначають ціну за транзит.

Лічильники символів процесу описують байти, переміщені через виклики читання та запису на будь-якому дескрипторі, включно з каналами, терміналами та символьними пристроями. Це правильне число для питання, наскільки зайнятий процес на межі системного виклику, і це не рахунок за зберігання.

Лічильники зберігання описують байти, які ядро намагалося перемістити в блоковий пристрій або з нього. Це правильне число для планування ємності, із застереженням, що ядро документує власні межі обліку: читання з кешу не стають читаннями зі сховища, а запис, скасований пізніше, не стає завершеним записом на пристрій.

Чому дескриптор файлу — не запис на диск

VPN у просторі користувача обмінюється пакетами з ядром через пристрій TUN, який є символьним пристроєм, а не звичайним файлом. Читання з нього передає пакет; запис у нього вставляє пакет. Немає ні сторінки вмісту файлу, що готується для зберігання, ні задіяного шляху файлової системи.

Тому зайнятий тунель може показувати величезні лічильники символів майже без лічильників зберігання. Процес справді перемістив ці байти, і ядру справді не потрібен був диск, щоб це зробити.

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

Перший вивід читайте як накопичений від запуску процесу, а не як швидкість. Другий дає уявлення інтерфейсу про той самий трафік. Великий розрив між ними очікуваний і не вказує на витік, чергу або неправильну конфігурацію.

Звідки насправді беруться байти

Постійний вивід має власний бюджет, і ним керують операції, а не корисне навантаження. Докладний рівень журналу, список клієнтів, який часто змінюється, або помилка, що повторюється в тісному циклі, можуть створювати значні записи, поки тунель переносить дуже мало.

Файл стану — це знімок, який перезаписується через інтервал, тому його вартість залежить від інтервалу та кількості записів у ньому. Це не поточна копія трафіку кожного клієнта, і скорочення інтервалу змінює обсяг запису, не змінюючи обсяг трафіку.

Володіння важливе, коли ви шукаєте ці записи. Якщо служба передає повідомлення демону журналювання, журнал або файл пише цей демон, і байти з’являються в його обліку, а не у власних лічильниках процесу VPN. Погляд лише на процес VPN не пояснює ні активність диска, ні її відсутність.

Інших учасників легко пропустити: читання сертифікатів і конфігурації під час запуску, хуки, що пишуть власні записи, модулі обліку, дампи під час збоїв і не пов’язані навантаження на тому самому хості. Жоден із них не слід оцінювати, прирівнюючи трафік тунелю до записаних байтів.

Як правильно читати кожен лічильник

Три деталі вирішують, чи означає порівняння щось. Ідентичність процесу важлива, бо перезапущена служба скидає свої лічильники. Часовий інтервал важливий, бо накопичене число й графік за секунду — різні вимірювання. І одиниця важлива, бо поточний розмір файлу журналу теж не швидкість.

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

Якщо ви підозрюєте справжні записи корисного навантаження, шукайте компонент, чиє завдання — зберігати навантаження: інструмент захоплення пакетів, проксі, що кешує тіла, модуль, який архівує. Вони створюють трафік зберігання, що зростає з тим, що їх просять записати, і належать до окремого політичного рішення про збереження та доступ.

Планування ємності з правильним числом

Вимірюйте шлях пакетів мережевими числами: пропускною здатністю, криптографічною обробкою та рухом пам’яті. Вимірюйте зберігання тими рішеннями про спостережуваність, які ви справді ухвалили: рівнем журналу, терміном збереження, інтервалом стану та будь-яким навмисно ввімкненим захопленням.

Розділення цих двох бюджетів також полегшує читання інцидентів. Повний диск за скромного трафіку тунелю вказує на журнали, захоплення або щось не пов’язане, і лічильник інтерфейсу ніколи цього не пояснить. Насичений канал із тихим журналом вказує в інший бік.

Порівняння, яке варто робити, — між вимірюваннями одного виду. Байти інтерфейсу проти байтів інтерфейсу в часі говорять про шлях. Записи зберігання проти ємності зберігання говорять про термін збереження. Перехресне порівняння, трафік проти диска, лише виглядає осмисленим і ніколи ним не є.