OpenVPN-trafiktællere kontra disk-I/O: tre forskellige tal

Send en stor fil gennem en tunnel, og interfacetælleren stiger med filens størrelse. Intet ved det tal betyder, at samme volumen nåede en disk. I disse diskussioner sammenlignes tre forskellige målinger, og de svarer på tre forskellige spørgsmål: hvor meget trafik der krydsede et netværkslag, hvor mange bytes en proces læste og skrev gennem systemkald, og hvor meget arbejde der nåede lagringslaget.

At sammenligne det første med det tredje er den sædvanlige fejl, og den giver enten et fantomdiskproblem eller en kapacitetsplan, der ignorerer de skrivninger, der faktisk sker. De tre er adskillelige, og hver har en korrekt brug.

Tre tal, der bliver rodet sammen

Interfacetællere beskriver trafik, der håndteres på et netværkslag. De er det rigtige tal for båndbredde, for tunnelens størrelse og for faktureringsmodeller, der prissætter transit.

Processens tegntællere beskriver bytes flyttet gennem læse- og skrivekald på enhver deskriptor, herunder rør, terminaler og tegnenheder. De er det rigtige tal til at spørge, hvor travlt en proces har ved systemkaldets grænse, og de er ikke en lagerregning.

Lagringstællere beskriver bytes, som kernen forsøgte at flytte til eller fra en blokenhed. De er det rigtige tal til kapacitetsplanlægning, med forbeholdet at kernen dokumenterer sine egne grænser for regnskab: cachede læsninger bliver ikke lagerlæsninger, og en skrivning, der senere annulleres, bliver ikke en fuldført enhedsskrivning.

Hvorfor en fildeskriptor ikke er en diskskrivning

En VPN i brugerrum udveksler pakker med kernen gennem en TUN-enhed, som er en tegnenhed snarere end en almindelig fil. Læsning fra den afleverer en pakke; skrivning til den injicerer en. Der er ingen side med filindhold, der gøres klar til lagring, og ingen filsystemsti involveret.

Derfor kan en travl tunnel vise enorme tegntællere næsten uden lagringstællere. Processen flyttede virkelig de bytes, og kernen havde virkelig ikke brug for en disk for at gøre det.

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

Læs det første output som kumulativt siden processens start, ikke som en rate. Det andet giver interfacevisningen af den samme trafik. Et stort gab mellem de to er forventeligt og tyder ikke på en lækage, en kø eller en fejlkonfiguration.

Hvor bytesene virkelig kommer fra

Vedvarende output har sit eget budget, og det styres af operationer snarere end af nyttelasten. Et ordrigt logniveau, en klientliste, der ofte ændrer sig, eller en fejl, der gentages i en stram løkke, kan generere betydelige skrivninger, mens tunnelen bærer meget lidt.

En statusfil er et øjebliksbillede, der genskrives med et interval, så dens pris afhænger af intervallet og af, hvor mange poster den indeholder. Det er ikke en løbende kopi af hver klients trafik, og et kortere interval ændrer skrivevolumen uden at ændre trafikvolumen.

Ejerskab betyder noget, når du leder efter de skrivninger. Hvis tjenesten overdrager beskeder til en logdaemon, skrives journalen eller logfilen af den daemon, og bytesene dukker op i daemonens regnskab snarere end i VPN-processens egne tællere. At se kun på VPN-processen forklarer hverken diskaktiviteten eller dens fravær.

Andre bidragydere er lette at overse: certifikat- og konfigurationslæsninger ved opstart, hooks der skriver deres egne poster, regnskabsplugins, crashdumps og urelaterede arbejdsbelastninger på samme vært. Ingen af dem bør estimeres ved at sidestille tunneltrafik med skrevne bytes.

At læse hver tæller korrekt

Tre detaljer afgør, om en sammenligning betyder noget. Processens identitet betyder noget, fordi en genstartet tjeneste nulstiller sine tællere. Tidsintervallet betyder noget, fordi et kumulativt tal og et diagram per sekund er forskellige målinger. Og enheden betyder noget, fordi en logfils aktuelle størrelse heller ikke er en rate.

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

Hvis du har mistanke om rigtige nyttelastskrivninger, så led efter en komponent, hvis opgave er at lagre nyttelast: et værktøj til pakkefangst, en proxy, der cacher kroppe, et plugin, der arkiverer. De producerer lagringstrafik, der skalerer med det, de bliver bedt om at registrere, og de hører til en særskilt politikbeslutning om opbevaring og adgang.

Dimensionér kapacitet med det rigtige tal

Dimensionér pakkestien med netværkstal: gennemstrømning, kryptografisk behandling og hukommelsesbevægelse. Dimensionér lagring med de observerbarhedsvalg, du faktisk har truffet: logniveau, opbevaring, statusinterval og enhver fangst, der bevidst er aktiveret.

At holde de to budgetter adskilt gør også hændelser lettere at læse. En fuld disk med beskeden tunneltrafik peger på logfiler, fangster eller noget urelateret, og interfacetælleren vil aldrig forklare det. Et mættet link med en stille log peger den anden vej.

Den sammenligning, der er værd at lave, er mellem målinger af samme slags. Interfacebytes mod interfacebytes over tid fortæller dig om stien. Lagringsskrivninger mod lagerkapacitet fortæller dig om opbevaring. Krydssammenligningen, trafik mod disk, ser kun meningsfuld ud og er det aldrig.