Küldjön át egy nagy fájlt egy alagúton, és az interfész számlálója a fájl méretével nő. Ebben a számban semmi sem jelenti azt, hogy ugyanaz a mennyiség elérte a lemezt. Ezekben a beszélgetésekben három különböző mérést hasonlítanak össze, és azok három különböző kérdésre válaszolnak: mennyi forgalom haladt át egy hálózati rétegen, hány bájtot olvasott és írt egy folyamat rendszerhívásokon keresztül, és mennyi munka ért el a tárolási rétegig.

Az elsőt a harmadikkal összehasonlítani a szokásos hiba, és vagy fantomlemez-problémát, vagy olyan kapacitástervet eredményez, amely figyelmen kívül hagyja a valóban bekövetkező írásokat. A három szétválasztható, és mindegyiknek megvan a helyes használata.

Három szám, amit összekevernek

Az interfész számlálói a hálózati rétegen kezelt forgalmat írják le. Ezek a helyes szám a sávszélességhez, az alagút méretéhez és a tranzitot árazó számlázási modellekhez.

A folyamat karakterszámlálói bármely leíróra irányuló olvasási és írási hívásokon át mozgatott bájtokat írják le, beleértve a csöveket, terminálokat és karakteres eszközöket. Ezek a helyes szám arra a kérdésre, mennyire elfoglalt egy folyamat a rendszerhívás határán, és nem tárolási számla.

A tárolási számlálók azokat a bájtokat írják le, amelyeket a kernel blokk-eszközre vagy onnan próbált mozgatni. Ezek a helyes szám a kapacitástervezéshez, azzal a fenntartással, hogy a kernel dokumentálja a saját elszámolási korlátait: a gyorsítótárazott olvasások nem válnak tárolási olvasásokká, és a később visszavont írás nem válik befejezett eszközírássá.

MeasurementQuestion it answers
Interface bytesHow much traffic crossed this layer
rchar and wcharHow much data the process moved through system calls
read_bytes and write_bytesHow much work reached the storage layer

Miért nem lemezírás a fájlleíró

A felhasználói térben futó VPN TUN-eszközön keresztül cserél csomagokat a kernellel, amely karakteres eszköz, nem szabályos fájl. Az olvasás abból átad egy csomagot; az írás bele egy csomagot injektál. Nincs tárolásra előkészített fájltartalom-oldal, és nincs érintett fájlrendszer-útvonal.

Ezért mutathat egy forgalmas alagút hatalmas karakterszámlálókat szinte tárolási számlálók nélkül. A folyamat valóban mozgatta azokat a bájtokat, és a kernelnek valóban nem kellett lemez ehhez.

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

Az első kimenetet a folyamat indítása óta halmozott értékként olvassa, nem rátaként. A második ugyanannak a forgalomnak az interfész-nézetét adja. A kettő közötti nagy különbség várható, és nem jelez szivárgást, sort vagy hibás konfigurációt.

Honnan jönnek valójában a bájtok

A tartós kimenetnek saját költségvetése van, és azt műveletek hajtják, nem a hasznos teher. Egy részletes naplószint, egy gyakran változó ügyféllista vagy egy szoros ciklusban ismétlődő hiba jelentős írásokat generálhat, miközben az alagút nagyon keveset szállít.

Az állapotfájl egy pillanatkép, amelyet időközönként újraírnak, ezért költsége az időköztől és a benne lévő rekordok számától függ. Nem minden ügyfél forgalmának futó másolata, és az időköz rövidítése az írás mennyiségét változtatja meg anélkül, hogy a forgalom mennyisége változna.

A tulajdonjog számít, amikor ezeket az írásokat keresi. Ha a szolgáltatás üzeneteket ad át egy naplózó démonnak, a naplót vagy a naplófájlt az a démon írja, és a bájtok a démon elszámolásában jelennek meg, nem a VPN-folyamat saját számlálóiban. Ha csak a VPN-folyamatra néz, sem a lemezaktivitást, sem annak hiányát nem magyarázza meg.

Más hozzájárulókat könnyű figyelmen kívül hagyni: tanúsítvány- és konfigurációolvasás indításkor, saját rekordokat író horgok, elszámolási bővítmények, összeomlási memóriaképek és független munkaterhelések ugyanazon a gazdagépen. Egyiket sem szabadna úgy becsülni, hogy az alagút forgalmát egyenlővé tesszük az írt bájtokkal.

Minden számláló helyes olvasása

Három részlet dönti el, hogy van-e értelme az összehasonlításnak. A folyamat azonossága számít, mert egy újraindított szolgáltatás nullázza a számlálóit. Az időköz számít, mert a halmozott szám és a másodpercenkénti grafikon különböző mérések. És a mértékegység számít, mert egy naplófájl jelenlegi mérete sem ráta.

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

Ha valódi hasznosteher-írásokat gyanít, keressen olyan komponenst, amelynek feladata a hasznos teher tárolása: csomagrögzítő eszköz, a törzseket gyorsítótárazó proxy, archiváló bővítmény. Ezek a tárolási forgalmat a rögzítendő mennyiséggel arányosan növelik, és a megőrzésről és hozzáférésről szóló külön szakpolitikai döntéshez tartoznak.

Kapacitástervezés a helyes számmal

A csomagútvonalat hálózati számokkal méretezze: átviteli teljesítmény, kriptográfiai feldolgozás és memóriamozgás. A tárolást azokkal a megfigyelhetőségi döntésekkel méretezze, amelyeket ténylegesen meghozott: naplószint, megőrzés, állapotidőköz és minden szándékosan engedélyezett rögzítés.

A két költségvetés szétválasztása az incidensek olvasását is megkönnyíti. Egy tele lemez szerény alagútforgalom mellett naplókra, rögzítésekre vagy valami függetlenre utal, és az interfész számlálója soha nem fogja megmagyarázni. Egy telített kapcsolat csendes naplóval az ellenkező irányba mutat.

Az összehasonlítás, amit érdemes megtenni, azonos fajtájú mérések között van. Az interfészbájtok az interfészbájtokkal szemben időben az útvonalról mondanak valamit. A tárolási írások a tárolókapacitással szemben a megőrzésről mondanak valamit. A kereszt-összehasonlítás, forgalom a lemezzel szemben, csak értelmesnek látszik, és soha nem az.

Kapcsolódó cikkek