Счётчики трафика 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

Если вы подозреваете настоящие записи полезной нагрузки, ищите компонент, чья задача — хранить нагрузку: средство захвата пакетов, прокси, кэширующий тела, модуль, который архивирует. Они создают трафик хранения, растущий с тем, что их просят записать, и относятся к отдельному политическому решению о хранении и доступе.

Планирование ёмкости с правильным числом

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

Разделение этих двух бюджетов также упрощает чтение инцидентов. Полный диск при скромном трафике туннеля указывает на журналы, захваты или что-то несвязанное, и счётчик интерфейса никогда этого не объяснит. Насыщенный канал с тихим журналом указывает в другую сторону.

Сравнение, которое стоит делать, — между измерениями одного вида. Байты интерфейса против байтов интерфейса во времени говорят о пути. Записи хранения против ёмкости хранения говорят о сроке хранения. Перекрёстное сравнение, трафик против диска, только выглядит осмысленным и никогда им не является.