Liczniki ruchu OpenVPN a dyskowe I/O: trzy różne liczby

Przepuść duży plik przez tunel, a licznik interfejsu wzrośnie o rozmiar pliku. Nic w tej liczbie nie oznacza, że ta sama objętość dotarła na dysk. W takich dyskusjach porównuje się trzy różne pomiary i odpowiadają one na trzy różne pytania: ile ruchu przekroczyło warstwę sieci, ile bajtów proces przeczytał i zapisał przez wywołania systemowe oraz ile pracy dotarło do warstwy przechowywania.

Porównywanie pierwszego z trzecim to typowy błąd, który daje albo widmowy problem z dyskiem, albo plan wydajności ignorujący zapisy, które naprawdę się dzieją. Te trzy są rozdzielne i każdy ma właściwe zastosowanie.

Trzy liczby, które się mylą

Liczniki interfejsu opisują ruch obsługiwany w warstwie sieci. To właściwa liczba dla przepustowości, dla rozmiaru tunelu i dla modeli rozliczeń, które wyceniają tranzyt.

Liczniki znaków procesu opisują bajty przeniesione przez wywołania odczytu i zapisu na dowolnym deskryptorze, w tym przez potoki, terminale i urządzenia znakowe. To właściwa liczba, gdy pytamy, jak zajęty jest proces na granicy wywołania systemowego, i nie jest to rachunek za przechowywanie.

Liczniki przechowywania opisują bajty, które jądro próbowało przenieść do urządzenia blokowego lub z niego. To właściwa liczba do planowania wydajności, z zastrzeżeniem, że jądro dokumentuje własne granice rozliczania: odczyty z pamięci podręcznej nie stają się odczytami z przechowywania, a zapis później anulowany nie staje się ukończonym zapisem urządzenia.

Dlaczego deskryptor pliku nie jest zapisem na dysk

VPN w przestrzeni użytkownika wymienia pakiety z jądrem przez urządzenie TUN, które jest urządzeniem znakowym, a nie zwykłym plikiem. Odczyt z niego przekazuje pakiet; zapis do niego wstrzykuje pakiet. Nie ma żadnej strony zawartości pliku przygotowywanej do przechowywania ani żadnej ścieżki systemu plików.

Dlatego zajęty tunel może pokazywać ogromne liczniki znaków przy prawie żadnych licznikach przechowywania. Proces naprawdę przeniósł te bajty, a jądro naprawdę nie potrzebowało dysku, żeby to zrobić.

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

Pierwsze wyjście czytaj jako narastające od startu procesu, a nie jako tempo. Drugie daje widok interfejsu tego samego ruchu. Duża różnica między nimi jest oczekiwana i nie oznacza wycieku, kolejki ani błędnej konfiguracji.

Skąd naprawdę pochodzą bajty

Trwałe wyjście ma własny budżet, a napędzają go operacje, a nie ładunek. Szczegółowy poziom logów, często zmieniająca się lista klientów albo błąd powtarzający się w ciasnej pętli mogą generować znaczne zapisy, gdy tunel przenosi bardzo mało.

Plik statusu to migawka przepisywana w odstępach, więc jego koszt zależy od odstępu i od liczby zawartych rekordów. To nie jest bieżąca kopia ruchu każdego klienta, a skrócenie odstępu zmienia wolumen zapisów bez zmiany wolumenu ruchu.

Własność ma znaczenie, gdy szukasz tych zapisów. Jeśli usługa przekazuje komunikaty demonowi logowania, dziennik lub plik logu zapisuje ten demon i bajty pojawiają się w jego rozliczeniu, a nie w licznikach samego procesu VPN. Patrzenie tylko na proces VPN nie wyjaśnia ani aktywności dysku, ani jej braku.

Innych współautorów łatwo przeoczyć: odczyty certyfikatów i konfiguracji przy starcie, hooki zapisujące własne rekordy, wtyczki rozliczeniowe, zrzuty awarii i niezwiązane obciążenia na tym samym hoście. Żadnego z nich nie należy szacować, przyrównując ruch tunelu do zapisanych bajtów.

Jak poprawnie czytać każdy licznik

Trzy szczegóły decydują, czy porównanie coś znaczy. Tożsamość procesu ma znaczenie, bo zrestartowana usługa zeruje swoje liczniki. Odstęp czasu ma znaczenie, bo liczba narastająca i wykres na sekundę to różne pomiary. A jednostka ma znaczenie, bo bieżący rozmiar pliku logu też nie jest tempem.

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

Jeśli podejrzewasz prawdziwe zapisy ładunku, poszukaj komponentu, którego zadaniem jest przechowywanie ładunku: narzędzia do przechwytywania pakietów, proxy buforującego treści, wtyczki archiwizującej. Wytwarzają one ruch do przechowywania, który skaluje się z tym, co mają zarejestrować, i należą do odrębnej decyzji politycznej o retencji i dostępie.

Planowanie wydajności z właściwą liczbą

Wymiaruj ścieżkę pakietów liczbami sieciowymi: przepustowością, przetwarzaniem kryptograficznym i ruchem pamięci. Wymiaruj przechowywanie wyborami obserwowalności, które naprawdę podjąłeś: poziomem logów, retencją, odstępem statusu i każdym świadomie włączonym przechwytywaniem.

Trzymanie tych dwóch budżetów osobno ułatwia też czytanie incydentów. Pełny dysk przy skromnym ruchu w tunelu wskazuje na logi, przechwytywania albo coś niezwiązanego, a licznik interfejsu nigdy tego nie wyjaśni. Zatłaczane łącze przy cichym logu wskazuje w drugą stronę.

Porównanie, które warto robić, jest między pomiarami tego samego rodzaju. Bajty interfejsu wobec bajtów interfejsu w czasie mówią o ścieżce. Zapisy na dysk wobec pojemności przechowywania mówią o retencji. Porównanie krzyżowe, ruch wobec dysku, tylko wygląda sensownie i nigdy takie nie jest.