Logfiler: det eneste, der vokser, uden at nogen har besluttet det

Det meste af det, der fylder din disk, har du selv lagt der: virtuelle maskiner, sikkerhedskopier, installationsbilleder. Hver af dem var en beslutning.

Logfiler er anderledes. De vokser, fordi systemet kører. Ingen har nogensinde sagt "lad denne fil blive større".

Væksten er langsom, men uden grænse

En logfil vokser måske et par kilobyte om dagen. Det vækker ingen opmærksomhed i månedsvis. Et år senere er den stadig lille.

Men den har intet loft. Og vækst uden loft bliver, hvor langsom den end er, et problem, hvis du venter længe nok.

Multiplikatoren, ingen venter: fejl får skrivningen til at gå hurtigere

Her ligger artiklens egentlige pointe.

Et sundt system skriver lidt. Giver en kontrol fejl ved hver kørsel, falder der en linje i den samme fil ved hver kørsel. For et job, der kører hvert kvarter, bliver det seksoghalvfems linjer om dagen, og det holder ikke op.

Logfilen vokser altså hurtigst netop, når du mindst kan se på den: mens en fejl står på.

Og den værste udgave

Et problem opstår, logfilerne går hurtigere, disken fyldes. Den fyldte disk skaber nye problemer. De nye problemer giver flere logfiler.

Fra det punkt bliver det sværere at finde den oprindelige fejl, for de fleste fejl på skærmen er ikke følgen af det første problem, men af den fyldte disk.

Reglen: alt, der skriver, skal have et loft

"Vi rydder op senere" er ingen plan. Det, der er brug for, er en mekanisk grænse, der virker, uden at nogen skal huske det.

Reglen gælder ikke kun systemlogfiler: den gælder enhver fil, som dine tjenester, planlagte job og indsamlere frembringer.

To fejl, når man opsætter rotation

Et: reglen går i stykker på en fil, der ikke findes. Nogle filer opstår først, når den tilhørende funktion bruges. Reglen skal skrives, så den ikke giver fejl, når en fil mangler; ellers standser en funktion, du aldrig bruger, hele rotationen.

To: den forkerte rotationsmetode. At omdøbe filen og sende den skrivende tjeneste et "åbn igen"-signal er den almindelige metode, men den virker kun, hvis der findes en langlivet tjeneste. Er skriveren et kortlivet job, der åbner og lukker hver gang, er der ingen at signalere til; da er den rigtige metode at kopiere indholdet og tømme filen på stedet.

Begge er tavse fejl: reglen står der, filen bliver ved med at vokse, og ingen bemærker, at reglen ikke virker.

Og spørgsmålet om den allerede installerede maskine

Skriver du en rotationsregel kun i installationsskriptet, når den aldrig frem til maskiner, der er installeret før reglen fandtes. De maskiner kører i årevis uden den.

Det rigtige er at skrive reglen ved hver opstart: sådan får ældre installationer den, når de går over til en ny version.

Hvad Atlas gør

Hele denne artikel kom ud af en måling, Atlas foretog på sig selv, så den skal fortælles ærligt.

Atlas kører med rodrettigheder på kundens maskine og skriver til flere logfiler: vagtsammendraget hvert kvarter, uddata fra planlagte opdateringer ved hver kørsel, sin egen selvopdateringsnotits. Det blev målt, og ingen af dem blev roteret, fordi installationen ikke skrev nogen rotationsregel nogen steder. På en maskine i drift havde vagtlogfilen nået ethundredeogfirs kilobyte på toogtredive dage, og der fandtes ingen mekanisme til at formindske den.

Tallet ser lille ud, og den dag var det ikke noget problem. Problemet var, at væksten var uden grænse, plus accelerationen ovenfor. Logfilerne fra planlagte opdateringer opfanger hele pakkeforvalterens uddata ved hver kørsel, hvilket kan nå megabyte per kørsel.

Nu skrives reglen, og begge fælder ovenfor er bevidst håndteret: manglende filer tolereres, og rotationen bruger metoden kopiér og dernæst tøm, fordi skriverne er kortlivede processer, der køres fra et planlagt job.

Og reglen skrives ved opstart, ikke i installationsskriptet. Grunden er netop spørgsmålet ovenfor: så også tidligere installerede maskiner får reglen, når de går over til en ny version.