Logger: det eneste som vokser uten at noen har bestemt det

Det meste som fyller disken din har du lagt dit: virtuelle maskiner, sikkerhetskopier, installasjonsbilder. Hver av dem var en beslutning.

Logger er annerledes. De vokser fordi systemet kjører. Ingen har noen gang sagt "la denne filen bli større".

Veksten er langsom, men uten grense

En loggfil kan vokse noen kilobyte om dagen. Det vekker ingen oppmerksomhet på måneder. Et år senere er den fortsatt liten.

Men den har intet tak. Og vekst uten tak blir, uansett hvor langsom, et problem hvis du venter lenge nok.

Multiplikatoren ingen venter seg: feil får skrivingen til å gå fortere

Her ligger artikkelens egentlige poeng.

Et friskt system skriver lite. Gir en sjekk feil ved hver kjøring, faller det en linje i den samme filen ved hver kjøring. For en jobb som kjører hvert kvarter blir det nittiseks linjer om dagen, og det stopper ikke.

Loggen vokser altså raskest nettopp når du minst kan se på den: mens en feil pågår.

Og den verste varianten

Et problem dukker opp, loggene går fortere, disken fylles. Den fulle disken skaper nye problemer. De nye problemene gir flere logger.

Fra det punktet blir det vanskeligere å finne den opprinnelige feilen, for de fleste feilene på skjermen er ikke følgen av det første problemet, men av den fulle disken.

Regelen: alt som skriver må ha et tak

"Vi rydder senere" er ingen plan. Det som trengs, er en mekanisk grense som virker uten at noen må huske det.

Regelen gjelder ikke bare systemlogger: den gjelder enhver fil som tjenestene dine, planlagte jobber og innsamlere lager.

To feil når man setter opp rotasjon

Én: regelen ryker på en fil som ikke finnes. Noen filer oppstår først når den tilhørende funksjonen brukes. Regelen må skrives slik at den ikke gir feil når en fil mangler; ellers stanser en funksjon du aldri bruker hele rotasjonen.

To: feil rotasjonsmetode. Å gi filen nytt navn og sende den skrivende tjenesten et "åpne på nytt"-signal er den vanlige metoden, men den virker bare om det finnes en langlivet tjeneste. Er skriveren en kortlivet jobb som åpner og lukker hver gang, finnes det ingen å signalisere til; da er riktig metode å kopiere innholdet og tømme filen på stedet.

Begge er stille feil: regelen står der, filen fortsetter å vokse, og ingen merker at regelen ikke virker.

Og spørsmålet om den allerede installerte maskinen

Skriver du en rotasjonsregel bare i installasjonsskriptet, når den aldri maskiner som er installert før regelen fantes. De maskinene kjører i årevis uten den.

Riktig er å skrive regelen ved hver oppstart: slik får eldre installasjoner den når de går over til en ny versjon.

Hva Atlas gjør

Hele denne artikkelen kom ut av en måling Atlas gjorde på seg selv, så den må fortelles ærlig.

Atlas kjører med rotrettigheter på kundens maskin og skriver til flere loggfiler: vaktsammendraget hvert kvarter, utdata fra planlagte oppdateringer ved hver kjøring, sin egen selvoppdateringsnotis. Det ble målt, og ingen av dem ble rotert, fordi installasjonen ikke skrev noen rotasjonsregel noe sted. På en maskin i drift hadde vaktloggen nådd ett hundre og åtti kilobyte på trettito dager, og det fantes ingen mekanisme for å krympe den.

Tallet ser lite ut, og den dagen var det ikke noe problem. Problemet var at veksten var uten grense, i tillegg til akselerasjonen over. Loggene fra planlagte oppdateringer fanger hele utdataen fra pakkeforvalteren ved hver kjøring, noe som kan nå megabyte per kjøring.

Nå skrives regelen, og begge fellene over er bevisst håndtert: manglende filer tolereres, og rotasjonen bruker metoden kopier og deretter tøm, fordi skriverne er kortlivede prosesser kjørt fra en planlagt jobb.

Og regelen skrives ved oppstart, ikke i installasjonsskriptet. Grunnen er nettopp spørsmålet over: slik at også tidligere installerte maskiner får regelen når de går over til en ny versjon.