Honnan nő a VPN-kiszolgáló lemezhasználata, és hogyan lehet megfékezni

Az alagút felhagy a kapcsolatok fogadásával, a szolgáltatás kétszer újraindul, aztán semmi sem jelenik meg a naplójában. Ez a csend a nyom, mert a napló töltötte meg a lemezt, és a démonnak nincs hova írnia a hibát, amelyre vár. Bármely hosszú ideig futó szolgáltatás eljuthat ebbe az állapotba, és a logs nevű könyvtár törlése ritkán javítja meg. A tartós megoldás tudni, melyik tároló nőtt meg, ki felel a megőrzési szabályáért, és hogy az író valóban elengedte-e a helyet.

Keresse meg a megnőtt tárolót és a növekedés ütemét

Kezdje két könnyen elfelejthető számmal: szabad blokkok és szabad inode-ok. Egy fájlrendszer bőséges helyet jelenthet, és mégis elutasíthat egy írást, mert elfogytak az inode-ok, ami akkor fordul elő, amikor egy szolgáltatás munkamenetenként egy fájlt hoz létre. Kérje mindkét értéket ugyanazon a köteten, mert a válaszok ugyanazon a délutánon eltérhetnek. Tegye ezt addig, amíg a gazdagép egészséges, hogy a számok a normál működést írják le, nem egy kiesést.

df -h /var
df -i /var

Ezután rendelje a növekedést egy tulajdonoshoz. A journal saját használati adata csak a journalt fedi le, és soha nem fog látni egy démont, amely a konfigurációs fájljából származó útvonalra ír.

journalctl --disk-usage

Az időbeli növekedés többet mond bármely egyedi mérésnél. Egy bekapcsolva hagyott hibakeresési szint, minden kísérletet naplózó újrapróbálkozási ciklus vagy egy senki által meg nem állított rögzítési fájl: mindegyik szokásosnak tűnhet egy pillanatban és riasztónak egy órával később. Vegyen egy mérést, várjon át egy forgalmas időszakot, vegyen egy másikat, és ossza el az intervallummal. Az a ráta, amelyet meg tud nevezni, döntéssé teszi a kapacitást tűz helyett.

Mit tesz a rotáció egy nyitott fájllal

A naplófájl egy inode-ra mutató név, és a hely csak az utolsó nyitott leíró bezárásakor tér vissza. Nevezze át a fájlt, és az író tovább tölti ugyanazt az inode-ot; törölje, és az író tovább tölt egy inode-ot mindenféle név nélkül. Ez az állapot az oka annak, hogy a „töröltem a fájlt, és a lemez tele maradt” mondat fájlleírókat ír le, nem tönkrement fájlrendszert. Az író újraindítása vagy egy olyan rotációs mód választása, amely újra megnyitja a fájlt, az, ami valóban visszaadja a blokkokat.

lsof +L1 | head

A szabályzat ahhoz az összetevőhöz tartozik, amely a fájlt írja. A journal a saját konfigurációs fájljából kényszeríti a tárolási korlátait, míg a fájlalapú szolgáltatás általában a logrotate-re támaszkodik, vagy létrehozási szabállyal és újranyitási jellel, vagy helyben csonkítási móddal, amikor az író nem tud újranyitni. Először erősítse meg a döntést anélkül, hogy bármit változtatna:

logrotate -d /etc/logrotate.conf

Hová tartozik a korlát, és mekkorának kell lennie

A korlátot oda tegye, ahol az író konfigurálva van, ne a csatlakozási pontra. A teljes kötetre vonatkozó kvóta védi a gazdagépet, de nem mondja meg, melyik szolgáltatás esik el először, a globális tisztító szkript pedig hajlamos törölni a következő incidenshez szükséges bizonyítékokat. A journal korlátja, a maximális mérettel rendelkező rotációszám és az alkalmazásszintű megőrzés egyenként egy termelőt határol. Együtt az összességet határolják; külön-külön mindegyik találgatás.

Ezt a korlátot a megvédhető megőrzési időből méretezze, ne a szabad helyből. Ha egy felülvizsgálathoz egy hét kapcsolódási kísérlet kell, a journalnek egy hetet kell tartania a legforgalmasabb várható ütemben, és ez az ütem a korábban mért szám.

A hibakeresési naplózás ideiglenes mód rögzített kezdési idővel, nem tárolási terv. Tartsa a magánélet kérdését ugyanabban a döntésben, mert a kapcsolati naplók címeket és azonosítókat hordoznak. A hosszabb megőrzés adatkezelési választás is, és annak kell meghoznia, aki mindkét korlátot ismeri.

Ellenőrizze a korlátot újraindítás után

Az a megőrzési változás, amely a következő újraindításig tart, nem változás. Indítsa újra az írót, erősítse meg, hogy az új korlát érvényesül, és ellenőrizze, hogy a rotáció utána is fut. A journal esetében egy újraindítás és egy használati mérés mindkét kérdésre válaszol:

systemctl restart systemd-journald
journalctl --disk-usage

Fájlalapú szolgáltatásnál futtassa a rotációs feladatot egyszer kézzel, és erősítse meg, hogy a fájl lecserélődött és a leíró újranyílt. Az író, amely megtartja a régi leírót, átmegy egy felületes ellenőrzésen, és elbukik legközelebb, amikor a kötet megtelik. Figyelje a szabad helyet a teszt alatt, mert egy fájl, amely kisebb lett, miközben a hely nem tért vissza, azt jelenti, hogy a régi inode-ot még mindig fogja.

Hasonlítsa össze a következő mérést ezzel

Térjen vissza egy hét múlva, és hasonlítsa össze a növekedési rátát a rögzítettel. Az egyező ráta azt jelenti, hogy a korlát tart, és a terhelés stabil; a megduplázódott ráta azt, hogy valami megváltozott, és a hasznos kérdés az, hogy mi. Először a napló tartalmát olvassa át ismétlődő hibákért, mert az újrapróbálkozási ciklus egyszerre tünet és a mennyiség oka. Ezután ellenőrizze, mi kapcsolódott be újonnan, beleértve az incidens alatt bekapcsolt és soha ki nem kapcsolt hibakeresési szinteket.

Tartsa a biztonsági mentéseket ugyanazon köteten kívül, vagy fogadja el, hogy egy tele lemez magával viszi a mentést. A védett gazdagépre írt másolat nem helyreállítási terv, és a megőrzése saját választ kíván.

Írja le, mi marad meg, hol, mennyi ideig, és ki távolítja el. Ez a mondat a szállítandó eredmény, és ez az egyetlen része ennek a munkának, amely túléli a következő újraindítást.