Dzienniki: jedyna rzecz, która rośnie, choć nikt tak nie zdecydował

Większość tego, co zapełnia twój dysk, dodałeś ty: maszyny wirtualne, kopie zapasowe, obrazy instalacyjne. Każda z tych rzeczy była decyzją.

Z dziennikami jest inaczej. Rosną, bo system działa. Nikt nigdy nie powiedział, żeby ten plik się powiększał.

Wzrost jest powolny, ale nieograniczony

Plik dziennika może rosnąć o kilka kilobajtów dziennie. Przez miesiące nie przyciąga to uwagi. Rok później nadal jest mały.

Ale nie ma sufitu. A wzrost bez sufitu, choćby powolny, staje się problemem, jeśli poczekasz wystarczająco długo.

Mnożnik, którego nikt się nie spodziewa: awaria przyspiesza pisanie

To jest właściwa myśl tego wpisu.

Zdrowy system pisze niewiele. Jeśli kontrola zgłasza błąd przy każdym uruchomieniu, do tego samego pliku spada linia przy każdym uruchomieniu. Dla zadania działającego co piętnaście minut to dziewięćdziesiąt sześć linii dziennie, i nie ustaje.

Dziennik rośnie więc najszybciej dokładnie wtedy, gdy najmniej możesz na niego patrzeć: w trakcie trwania awarii.

I najgorsza wersja tego

Pojawia się problem, dzienniki przyspieszają, dysk się zapełnia. Pełny dysk powoduje nowe problemy. Nowe problemy produkują więcej dzienników.

Od tego momentu trudniej znaleźć pierwotną awarię, bo większość błędów na twoim ekranie jest skutkiem nie pierwszego problemu, tylko pełnego dysku.

Reguła: wszystko, co pisze, musi mieć sufit

Zdanie, że posprzątamy później, nie jest planem. Potrzebny jest mechaniczny limit, który działa bez konieczności pamiętania o nim przez kogokolwiek.

Ta reguła nie dotyczy tylko dzienników systemowych: obowiązuje każdy plik wytwarzany przez uruchamiane przez ciebie usługi, przez zaplanowane zadania i przez kolektory.

Dwa błędy popełniane przy konfigurowaniu rotacji

Pierwszy: reguła psująca się przez nieistniejący plik. Część plików pojawia się dopiero wtedy, gdy używana jest powiązana funkcja. Regułę trzeba napisać tak, by nie zgłaszała błędu przy braku pliku; inaczej funkcja, z której nigdy nie korzystasz, zatrzymuje całą pracę rotacji.

Drugi: niewłaściwa metoda rotacji. Zmiana nazwy pliku i wysłanie piszącej usłudze sygnału ponownego otwarcia jest metodą powszechną, ale działa tylko wtedy, gdy istnieje długo żyjąca usługa. Jeśli piszącym jest krótko żyjące zadanie otwierające i zamykające plik za każdym razem, nie ma komu wysłać sygnału; wtedy właściwą metodą jest skopiowanie zawartości i opróżnienie pliku w miejscu.

Oba są awariami cichymi: reguła jest na miejscu, plik dalej rośnie, a nikt nie zauważa, że reguła nie działa.

I pytanie o zainstalowaną maszynę

Jeśli regułę rotacji zapiszesz tylko w skrypcie instalacyjnym, nigdy nie dotrze ona do maszyn zainstalowanych przed powstaniem reguły. Te maszyny latami działają bez niej.

Właściwym sposobem jest zapisywanie reguły przy każdym starcie: wtedy starsze instalacje przejmują ją przy przejściu na nową wersję.

Co robi Atlas

Cały ten wpis wyszedł z własnego pomiaru Atlasa, więc trzeba go opowiedzieć uczciwie.

Atlas działa na maszynie klienta jako root i pisze do kilku plików dziennika: podsumowanie wartownika co piętnaście minut, wyjście planowanych aktualizacji przy każdym uruchomieniu, własny zapis samoaktualizacji. Zmierzono i żaden z nich nie był rotowany, bo instalator nigdzie nie zapisywał reguły rotacji. Na działającej maszynie dziennik wartownika osiągnął sto osiemdziesiąt kilobajtów w trzydzieści dwa dni, a mechanizmu jego zmniejszenia nie było.

Liczba wygląda mało i tamtego dnia nie była problemem. Problemem było to, że wzrost był nieograniczony, plus opisane wyżej przyspieszenie. Dzienniki planowanych aktualizacji chwytają przy każdym uruchomieniu całe wyjście menedżera pakietów, które potrafi sięgać megabajtów na uruchomienie.

Teraz reguła jest zapisana, a obie powyższe pułapki obsłużono celowo: brak plików jest tolerowany, a rotacja używa metody kopiuj i opróżnij, bo piszącymi są krótko żyjące procesy uruchamiane z zaplanowanego zadania.

I reguła zapisywana jest przy starcie, a nie w skrypcie instalacyjnym. Powodem jest dokładnie powyższe pytanie: żeby maszyny zainstalowane wcześniej też przejęły regułę przy przejściu na nową wersję.