Naplók: az egyetlen dolog, amely úgy nő, hogy senki nem döntött róla

Ami a lemezt megtölti, annak nagy részét valaki odatette: virtuális gépek, biztonsági mentések, telepítőképfájlok. Mindegyik egy döntés eredménye volt.

A naplók mások. Azért nőnek, mert a rendszer fut. Soha senki nem mondta, hogy "nőjön ez a fájl".

A növekedés lassú, de korlátlan

Egy naplófájl naponta néhány kilobájttal nőhet. Ez hónapokig fel sem tűnik. Egy évvel később még mindig kicsi.

Csakhogy nincs felső határa. A felső határ nélküli növekedés pedig, bármilyen lassú is, elég hosszú idő után gonddá válik.

A szorzó, amelyre senki nem számít: a hiba felgyorsítja az írást

Ez a cikk igazi lényege.

Egy rendben lévő rendszer keveset ír. Ha egy ellenőrzés minden futáskor hibára fut, minden futáskor bekerül egy sor ugyanabba a fájlba. Egy tizenöt percenként futó feladatnál ez napi kilencvenhat sor, és nem áll meg.

A napló tehát pont akkor nő a leggyorsabban, amikor a legkevésbé van mód ránézni: hiba közben.

És ennek a legrosszabb változata

Megjelenik egy hiba, a naplók felgyorsulnak, a lemez megtelik. A tele lemez új hibákat okoz. Az új hibák pedig további naplókat termelnek.

Ettől a ponttól nehezebb megtalálni az eredeti hibát, mert a képernyőn látható hibák nagy része nem az első bajból, hanem a tele lemezből következik.

A szabály: mindennek, ami ír, legyen felső határa

A "majd kitakarítjuk" nem terv. Gépies korlát kell, amely emlékezés nélkül is működik.

Ez a szabály nem csak a rendszernaplókra vonatkozik: minden fájlra érvényes, amelyet a futtatott szolgáltatások, az ütemezett feladatok és a gyűjtők állítanak elő.

Két gyakori hiba a naplóforgatás beállításakor

Egy: a szabály elhasal egy nem létező fájlon. Egyes fájlok csak akkor jelennek meg, amikor a hozzájuk tartozó funkciót használják. A szabályt úgy kell megírni, hogy hiányzó fájl esetén ne fusson hibára, különben egy soha nem használt funkció az egész forgatási munkát megállítja.

Kettő: rossz forgatási módszer. A fájl átnevezése és az író szolgáltatásnak küldött "nyisd újra" jelzés a szokásos módszer, de csak akkor működik, ha van hosszú életű szolgáltatás. Ha az írást rövid életű feladat végzi, amely minden alkalommal megnyit és lezár, nincs kinek jelezni. Ilyenkor a helyes módszer a tartalom átmásolása és a fájl helyben történő kiürítése.

Mindkettő csendes hiba: a szabály megvan, a fájl tovább nő, és senki nem veszi észre, hogy a szabály nem működik.

És a már telepített gépek kérdése

Ha a forgatási szabály csak a telepítőparancsfájlba kerül, soha nem jut el azokra a gépekre, amelyek a szabály előtt települtek. Azok a gépek évekig futnak nélküle.

A helyes megoldás az, hogy a szabály minden induláskor kiíródik: így a régebbi telepítések is megkapják, amikor új verzióra lépnek.

Mit csinál az Atlas

Ez az egész cikk az Atlas saját méréséből született, ezért őszintén kell elmondani.

Az Atlas root jogosultsággal fut az ügyfél gépén, és több naplófájlba ír: tizenöt percenként az őr összefoglalóját, minden futáskor a tervezett frissítések kimenetét, valamint a saját frissítésének nyilvántartását. A mérés azt mutatta, hogy egyiket sem forgatta senki, mert a telepítő sehová nem írt forgatási szabályt. Egy éles gépen az őr naplója harminckét nap alatt száznyolcvan kilobájtra nőtt, és nem volt mechanizmus a zsugorítására.

A szám kicsinek látszik, és aznap nem is jelentett gondot. Az jelentett gondot, hogy a növekedés korlátlan volt, ráadásul a fent leírt gyorsulással együtt. A tervezett frissítések naplói minden futáskor rögzítik a csomagkezelő teljes kimenetét, ami futásonként több megabájtot is elérhet.

A szabály mostanra megvan, és a fenti két csapdát szándékosan kezeli: a hiányzó fájlokat elviseli, a forgatás pedig a másolás utáni kiürítés módszerét használja, mert az írást ütemezett feladatból induló, rövid életű folyamatok végzik.

A szabály pedig induláskor íródik ki, nem a telepítőparancsfájlban. Az ok pontosan a fenti kérdés: hogy a korábban telepített gépek is megkapják a szabályt, amikor új verzióra lépnek.