Loggar: det enda som växer utan att någon bestämt det

Det mesta som fyller din disk har du lagt dit: virtuella maskiner, säkerhetskopior, installationsavbilder. Var och en var ett beslut.

Loggar är annorlunda. De växer för att systemet kör. Ingen har någonsin sagt "låt den här filen bli större".

Tillväxten är långsam men obegränsad

En loggfil kan växa några kilobyte om dagen. Det väcker ingen uppmärksamhet på månader. Ett år senare är den fortfarande liten.

Men den har inget tak. Och tillväxt utan tak blir, hur långsam den än är, ett problem om du väntar tillräckligt länge.

Multiplikatorn ingen väntar sig: fel accelererar skrivandet

Här ligger artikelns verkliga poäng.

Ett friskt system skriver lite. Ger en kontroll fel vid varje körning faller en rad i samma fil vid varje körning. För ett jobb som kör var femtonde minut blir det nittiosex rader om dagen, och det slutar inte.

Loggen växer alltså snabbast precis när du minst kan titta på den: medan ett fel pågår.

Och dess värsta variant

Ett problem dyker upp, loggarna accelererar, disken fylls. Den fulla disken skapar nya problem. De nya problemen ger fler loggar.

Från den punkten blir det svårare att hitta det ursprungliga felet, för de flesta felen på skärmen är inte följden av det första problemet utan av den fulla disken.

Regeln: allt som skriver måste ha ett tak

"Vi städar sedan" är ingen plan. Det som behövs är en mekanisk gräns som fungerar utan att någon behöver komma ihåg.

Regeln gäller inte bara systemloggar: den gäller varje fil som dina tjänster, schemalagda jobb och insamlare skapar.

Två misstag när man ställer in rotation

Ett: regeln går sönder på en fil som inte finns. Vissa filer uppstår först när den tillhörande funktionen används. Regeln måste skrivas så att den inte ger fel när en fil saknas; annars stoppar en funktion du aldrig använder hela rotationen.

Två: fel rotationsmetod. Att byta namn på filen och skicka den skrivande tjänsten en "öppna igen"-signal är den vanliga metoden, men den fungerar bara om det finns en långlivad tjänst. Är skrivaren ett kortlivat jobb som öppnar och stänger varje gång finns ingen att signalera; då är rätt metod att kopiera innehållet och tömma filen på plats.

Båda är tysta fel: regeln finns, filen fortsätter växa, och ingen märker att regeln inte verkar.

Och frågan om den redan installerade maskinen

Skriver du en rotationsregel bara i installationsskriptet når den aldrig maskiner som installerats innan regeln fanns. De maskinerna kör i åratal utan den.

Rätt sätt är att skriva regeln vid varje start: så får äldre installationer den när de går över till en ny version.

Vad Atlas gör

Hela den här artikeln kom ur en mätning Atlas gjorde på sig själv, så den bör berättas ärligt.

Atlas kör med rotträttigheter på kundens maskin och skriver till flera loggfiler: väktarsammanfattningen var femtonde minut, utdata från planerade uppdateringar vid varje körning, sin egen självuppdateringsnotering. Det mättes och ingen av dem roterades, eftersom installationen inte skrev någon rotationsregel någonstans. På en maskin i drift hade väktarloggen nått etthundraåttio kilobyte på trettiotvå dagar, och det fanns ingen mekanism att krympa den.

Siffran ser liten ut och den dagen var den inget problem. Problemet var att tillväxten var obegränsad, plus accelerationen ovan. Loggarna från planerade uppdateringar fångar hela paketförvaltarens utdata vid varje körning, vilket kan nå megabyte per körning.

Nu skrivs regeln, och båda fällorna ovan hanteras medvetet: saknade filer tolereras, och rotationen använder metoden kopiera och sedan tömma, eftersom skrivarna är kortlivade processer som körs från ett schemalagt jobb.

Och regeln skrivs vid start, inte i installationsskriptet. Skälet är precis frågan ovan: så att även tidigare installerade maskiner får regeln när de går över till en ny version.