Dlaczego większość plików dziennika używa zwykłego tekstu zamiast formatu binarnego?

Rejestrowanie jest czymś, co jest konieczne, ale jest (stosunkowo) rzadko używane. Jako taki może być znacznie bardziej kompaktowy pod względem przechowywania.

Na przykład dane najczęściej rejestrowane, takie jak ip, data, godzina i inne dane, które mogą być reprezentowane jako liczby całkowite, są przechowywane jako tekst.

Gdyby rejestrowanie było przechowywane jako dane binarne, można by zaoszczędzić dużo miejsca, co wymagałoby mniejszej rotacji i wydłużenia żywotności dysku, szczególnie w przypadku dysków SSD, w których zapisy są ograniczone.

Niektórzy mogą powiedzieć, że jest to tak niewielka kwestia, że ​​tak naprawdę nie ma to znaczenia, ale biorąc pod uwagę wysiłek potrzebny do zbudowania takiego mechanizmu, nie ma sensu tego nie robić. Każdy może to zrobić przez dwa dni w wolnym czasie, dlaczego ludzie tego nie robią?

systemdsłynie przechowuje swoje pliki dziennika w formacie binarnym. Główne problemy, które z tym słyszałem, to:

1. jeśli dziennik zostanie uszkodzony, trudno go odzyskać, ponieważ wymaga specjalistycznego oprzyrządowania
2. nie są one czytelne dla człowieka, więc nie można używać standardowych narzędzi takich jak vi, grep, tailitp do ich analizy

Głównym powodem używania formatu binarnego (o ile mi wiadomo) było to, że łatwiej było tworzyć indeksy itp., Tj. Traktować go bardziej jak plik bazy danych.

Twierdziłbym, że przewaga miejsca na dysku jest w praktyce stosunkowo niewielka (i maleje). Jeśli chcesz przechowywać duże ilości rejestrowania, wówczas spakowanie zwiniętych logów jest naprawdę całkiem wydajne.

Podsumowując, zalety oprzyrządowania i znajomości prawdopodobnie w większości przypadków byłyby błędne po stronie rejestrowania tekstu.

Dlaczego większość plików dziennika używa zwykłego tekstu zamiast formatu binarnego?

Wyszukaj słowo „tekst” w artykule Wikipedii poświęconym filozofii uniksowej , na przykład znajdziesz następujące stwierdzenia:

McIlroy, wówczas szef CSRC Bell Labs (Computing Sciences Research Center) i wynalazca potoku Unix, [9] podsumował filozofię Unix w następujący sposób: [10]

Oto filozofia Uniksa: pisz programy, które robią jedną rzecz i robią to dobrze. Pisz programy do współpracy. Pisz programy do obsługi strumieni tekstowych, ponieważ jest to uniwersalny interfejs.

Lub na przykład z Basics of the Unix Philosophy ,

Reguła składu: Projektuj programy, które mają być połączone z innymi programami.

Trudno uniknąć programowania nadmiernie skomplikowanych monolitów, jeśli żaden z waszych programów nie może ze sobą rozmawiać.

Tradycja uniksowa zdecydowanie zachęca do pisania programów, które odczytują i piszą proste, tekstowe, zorientowane na strumień formaty niezależne od urządzenia. W klasycznym systemie Unix jak najwięcej programów jest zapisywanych jako proste filtry, które pobierają prosty strumień tekstu na wejściu i przetwarzają go w inny prosty strumień tekstu na wyjściu.

Pomimo popularnej mitologii praktyka ta nie jest preferowana, ponieważ programiści uniksowi nie znoszą graficznych interfejsów użytkownika. Jest tak, ponieważ jeśli nie piszesz programów, które akceptują i emitują proste strumienie tekstowe, znacznie trudniej jest połączyć programy razem.

Strumienie tekstowe są skierowane do narzędzi uniksowych, podobnie jak wiadomości do obiektów w ustawieniach obiektowych. Prostota interfejsu strumienia tekstu wymusza enkapsulację narzędzi. Bardziej rozbudowane formy komunikacji międzyprocesowej, takie jak zdalne wywołania procedur, wykazują tendencję do zbyt częstego angażowania programów w elementy wewnętrzne.

Każdy może to zrobić przez dwa dni w wolnym czasie, dlaczego ludzie tego nie robią?

Przechowywanie pliku dziennika w formacie binarnym to tylko początek (i trywialność). Musisz wtedy napisać narzędzia do:

• Wyświetl cały plik dziennika ( edit)
• Wyświetl koniec dziennika bez czytania jego początku ( tail -f)
• Szukaj rzeczy w pliku ( grep)
• Filtruj, aby wyświetlać tylko wybrane / interesujące rzeczy (używając arbitralnie skomplikowanego wyrażenia filtrującego)
• Prześlij dziennik e-mailem do kogoś innego, kto nie ma Twojego oprogramowania do dekodowania plików dziennika
• Skopiuj i wklej fragment pliku dziennika
• Czytaj plik dziennika, gdy program (który tworzy plik dziennika) jest nadal rozwijany i debugowany
• Czytaj pliki dziennika ze starych wersji oprogramowania (które są wdrażane w witrynach klientów i działają).

Oczywiście oprogramowanie może i używa również formatów plików binarnych (np. W relacyjnych bazach danych), ale nie jest to opłacalne (w sensie YAGNI ), zwykle nie warto robić, dla plików dziennika.

Istnieje tutaj wiele spornych domniemań.

Logowanie było nieodłączną częścią (prawie) każdej pracy, jaką miałem. Jest to niezbędne, jeśli chcesz mieć jakikolwiek wgląd w kondycję swoich aplikacji. Wątpię, aby było to „grzywka”; większość organizacji, z którymi byłem zaangażowany, uważa dzienniki za bardzo ważne.

Przechowywanie dzienników jako plików binarnych oznacza, że ​​musisz je odkodować, aby móc je odczytać. Dzienniki tekstowe mają zaletę prostoty i łatwości użytkowania. Jeśli zastanawiasz się nad ścieżką binarną, możesz równie dobrze przechowywać dzienniki w bazie danych, gdzie możesz je przesłuchać i przeanalizować statystycznie.

Dyski SSD są obecnie bardziej niezawodne niż dyski HDD, a argumenty przeciwko wielu zapisom są w dużej mierze dyskusyjne. Jeśli naprawdę się o to martwisz, przechowuj dzienniki na zwykłym dysku twardym.

Pliki dziennika są krytyczną częścią każdej poważnej aplikacji: jeśli logowanie w aplikacji jest dobre, pozwalają zobaczyć, które kluczowe zdarzenia miały miejsce i kiedy; jakie błędy wystąpiły; i ogólną kondycję aplikacji wykraczającą poza to, co zostało zaprojektowane w monitorowaniu. Często słyszy się o problemie, sprawdza wbudowaną diagnostykę aplikacji (otwórz konsolę internetową lub użyj narzędzia diagnostycznego, takiego jak JMX), a następnie skorzystaj ze sprawdzenia pliki dziennika.

Jeśli używasz formatu nietekstowego, natychmiast stajesz przed przeszkodą: jak czytasz dzienniki binarne? Dzięki narzędziu do odczytu dzienników, którego nie ma na serwerach produkcyjnych! A może tak, ale och, dodaliśmy nowe pole i to jest stary czytelnik. Nie testowaliśmy tego? Tak, ale nikt go tu nie wdrożył. W międzyczasie ekran zaczyna się świecić, a użytkownicy pingują Cię.

A może to nie jest twoja aplikacja, ale robisz wsparcie i myślisz, że wiesz, że to ten inny system i WTF? dzienniki są w formacie binarnym? Ok, zacznij czytać strony wiki i od czego zacząć? Teraz skopiowałem je na lokalną maszynę, ale - są zepsute? Czy wykonałem jakiś transfer niebinarny? A może narzędzie do odczytu dzienników jest popsute?

W skrócie, narzędzia do czytania tekstu są wieloplatformowe i wszechobecne, a dzienniki są często długotrwałe i czasem trzeba je czytać w pośpiechu . Jeśli wymyślisz format binarny, zostaniesz odcięty od całego świata dobrze zrozumiałych i łatwych w użyciu narzędzi. Poważna utrata funkcjonalności właśnie wtedy, gdy jej potrzebujesz.

Większość środowisk rejestrowania zawiera kompromis: bieżące dzienniki powinny być czytelne i obecne, a kompresować starsze. Oznacza to, że zyskujesz na kompresji - tym bardziej, że format binarny nie zmniejszyłby komunikatów dziennika. Jednocześnie możesz użyć mniej i grep i tak dalej.

Jakie więc potencjalne korzyści mogą wynikać z używania plików binarnych? Niewielka oszczędność miejsca - coraz mniej ważne. Mniej (lub mniej) pisze? Cóż, może - w rzeczywistości liczba zapisów będzie się odnosić do liczby zatwierdzeń na dysku, więc jeśli linie logów są znacznie mniejsze niż rozmiar bloku na dysku, to i tak dysk SSD przypisywałby nowe bloki w kółko. Binarny jest więc właściwym wyborem, jeśli:

• piszesz ogromne ilości ustrukturyzowanych danych
• dzienniki muszą być tworzone szczególnie szybko
• prawdopodobnie nie będzie trzeba ich analizować w „warunkach wsparcia”

ale to mniej przypomina zapisywanie aplikacji; są to pliki wyjściowe lub rekordy aktywności. Umieszczenie ich w pliku jest prawdopodobnie tylko krok od zapisania ich w bazie danych.

EDYTOWAĆ

Wydaje mi się, że istnieje ogólne zamieszanie między „logami programu” (zgodnie ze strukturami rejestrowania) a „rekordami” (jak w logach dostępu, logach logowania itp.). Podejrzewam, że pytanie to jest najbardziej związane z tym ostatnim, a w takim przypadku kwestia jest znacznie mniej precyzyjnie zdefiniowana. Jest całkowicie akceptowalne, aby zapis wiadomości lub dziennik aktywności miał kompaktowy format, zwłaszcza że może być dobrze zdefiniowany i używany do analizy zamiast rozwiązywania problemów. Narzędzia, które to robią, obejmują tcpdumpmonitor systemu Unix sar. Z drugiej strony dzienniki programów są znacznie bardziej ad hoc.

Przykładem nieco binarnego dziennika jest szeroko rozpowszechniony: dziennik zdarzeń systemu Windows. Z drugiej strony, pozwala to, aby komunikaty dziennika były dość nieporadne (a zatem miejmy nadzieję pomocne) praktycznie bez żadnych kosztów, być może coś w rodzaju

Ostrzeżenie: kolejka foobarów do zrobienia wzrosła o 517 pozycji w ciągu ostatnich 90 sekund. Jeśli zdarza się to raz dziennie, nie ma się o co martwić. Jeśli zdarza się to częściej lub w krótkich odstępach czasu, możesz sprawdzić ilość pamięci RAM dostępnej dla aplikacji foobar. Jeśli jednak wystąpi to razem ze zdarzeniem 12345, wydaje się, że korzystasz z przestarzałej bazy danych i lepiej zadzwoń do wsparcia pod numer + 1-555-12345, aby zapobiec utracie danych.

Główna część tego komunikatu istnieje tylko raz jako zasób zainstalowany w aplikacji. Jeśli jednak ten zasób nie zostanie poprawnie zainstalowany (na przykład, ponieważ w międzyczasie została zainstalowana nowsza wersja, która nie obsługuje już tej przestarzałej wiadomości), wszystko, co widzisz w dzienniku zdarzeń, to standardowy komunikat, który jest tylko wymyślnym sformułowaniem

Nie wiem, coś z „517” i „90”.

i nie są już w żaden sposób pomocne.

Dwa główne pytania, które chciałbyś zadać przed wybraniem tekstu lub pliku binarnego to:

• Kim jest moja publiczność?
• Jakie treści muszę przekazać?

Powszechnie uważa się, że odbiorcą wiadomości dziennika jest człowiek. To oczywiście nie jest idealne założenie, ponieważ istnieje wiele skryptów indeksujących dzienniki, ale jest to powszechne. W takim przypadku sensowne jest przekazywanie informacji na nośniku, z którym ludzie czują się komfortowo. Tekst ma długą tradycję bycia tym medium.

Jeśli chodzi o treść, należy wziąć pod uwagę, że dziennik binarny musi mieć dobrze zdefiniowany format. Format musi być wystarczająco zdefiniowany, aby inne osoby mogły pisać oprogramowanie działające na tych dziennikach. Niektóre dzienniki mają dość dobrą strukturę (kilka pytań zawiera kilka pytań). Inne dzienniki potrzebują możliwości przekazywania treści w mniej zrozumiałej formie języka naturalnego. Takie przypadki języka naturalnego nie pasują do formatów binarnych.

W przypadku dzienników, które można dobrze opisać w postaci binarnej, musisz dokonać wyboru. Ponieważ tekst działa dla wszystkich, często jest postrzegany jako domyślny wybór. Jeśli logujesz swoje wyniki w tekście, ludzie mogą pracować z twoimi logami. Zostało to udowodnione tysiące razy. Pliki binarne są trudniejsze. W rezultacie programiści mogą wyprowadzać tekst po prostu dlatego, że wszyscy wiedzą, jak będzie się zachowywać.

TL; DR: Rozmiar tak naprawdę nie ma znaczenia, ale wygoda użytkowania ma znaczenie

Przede wszystkim, chociaż porównanie odpowiednich zalet formatów tekstowych i binarnych do krótkotrwałego przechowywania dzienników jest ważnym pytaniem, rozmiar tak naprawdę nie ma znaczenia. Dwa powody tego są następujące:

1. Dzienniki są bardzo redundantnymi informacjami, które bardzo dobrze się kompresują: z mojego doświadczenia wynika, że ​​nie jest rzadkością zobaczyć skompresowane pliki dziennika, których rozmiar wynosi 5% lub mniej niż rozmiar oryginalnego pliku. W związku z tym użycie tekstu lub formatu binarnego nie powinno mieć żadnego wymiernego wpływu na długotrwałe przechowywanie dzienników.

2. Niezależnie od wybranego formatu dzienniki szybko wypełnią dysk serwera, jeśli nie zaimplementujemy „ujścia plików dziennika”, który kompresuje i wysyła pliki dziennika do platformy długoterminowej pamięci masowej. Użycie formatu binarnego może to nieco spowolnić, ale nawet zmiana o współczynnik 10 nie miałaby tak wielkiego znaczenia.

Tekst a binarne formaty dziennika

Obietnicą systemów uniksowych jest to, że jeśli nauczymy się korzystać ze standardowego zestawu narzędzi działającego na plikach tekstowych o strukturze liniowej - takich jak grep , sortuj , łącz , sed i awk - będziemy mogli ich używać do szybkiego składania prototypów wykonujących dowolne zadanie chcemy, choć powoli i nieuprzejmie. Gdy prototyp wykaże swoją przydatność, możemy go przekształcić w naprawdę zaprojektowane oprogramowanie w celu zwiększenia wydajności lub dodania innych przydatnych funkcji. Jest to, przynajmniej w moim rozumieniu, esencja filozofii uniksowej.

Innymi słowy, jeśli prawdopodobnie będziemy musieli wykonać zabiegi i analizy, nie możemy dzisiaj ustalić, jeśli nie wiemy, kto powinien wdrożyć tę analizę itp., To jesteśmy na etapie, w którym należy zastosować prototypy i formaty tekstowe dzienniki są prawdopodobnie optymalne. Jeśli musimy wielokrotnie wykonywać niewielki zestaw dobrze zidentyfikowanych zabiegów, to jesteśmy w sytuacji, w której powinniśmy zaprojektować odwieczny system oprogramowania, aby przeprowadzić tę analizę, a formaty binarne lub strukturalne dzienników, takie jak relacyjne bazy danych, prawdopodobnie będą optymalny.

(Jakiś czas temu napisałem na ten temat post na blogu .)

Pliki dziennika są w formacie tekstowym, ponieważ można je łatwo odczytać za pomocą dowolnego edytora tekstu lub wyświetlając zawartość za pomocą polecenia konsoli.

Jednak niektóre pliki dziennika mają format binarny , jeśli jest dużo danych. Na przykład produkt, nad którym pracuję, przechowuje maksymalnie 15 000 rekordów. Aby przechowywać rekordy w jak najmniejszej ilości miejsca, są one przechowywane w formacie binarnym. Należy jednak napisać specjalną aplikację, aby wyświetlić rekordy lub przekonwertować je na format, którego można użyć (np. Arkusze kalkulacyjne).

Podsumowując, nie wszystkie pliki dziennika mają format tekstowy. Format tekstowy ma tę zaletę, że niestandardowe narzędzia nie są potrzebne do przeglądania treści. W przypadku dużej ilości danych plik może być w formacie binarnym . Format binarny będzie wymagał (niestandardowej) aplikacji do odczytu danych i wyświetlania w formacie czytelnym dla człowieka. Więcej danych można spakować do formatu binarnego. To, czy użyć formatu tekstowego, czy binarnego, zależy od ilości danych i łatwości przeglądania zawartości.

W systemach wbudowanych, w których może nie być dostępny kanał wyjściowy w czasie wykonywania, aplikacja nie może sobie pozwolić na szybkość uderzenia narzuconą przez rejestrowanie lub rejestrowanie zmieniałoby lub maskowało efekt, który próbuję zarejestrować, często uciekł się do upychania danych binarnych do tablicy lub bufora pierścieniowego i albo printf () na końcu uruchomienia testowego, albo zrzucił go na surowo i napisał interpreter, aby wydrukował go jako czytelny. Tak czy inaczej, chcę uzyskać czytelne dane.

Dlaczego w systemach z większą ilością zasobów wymyślają schematy optymalizacji, które nie wymagają optymalizacji?

Pliki dziennika mają na celu ułatwienie debugowania problemów. Zazwyczaj miejsce na dysku twardym jest znacznie tańsze niż czas projektowania. Pliki dziennika używają tekstu, ponieważ istnieje wiele narzędzi do pracy z tekstem (takich jak tail -f). Nawet HTTP używa zwykłego tekstu (zobacz także dlaczego nie wysyłamy binarnych zamiast tekstu na http ).

Ponadto taniej jest opracować system rejestrowania w postaci zwykłego tekstu i sprawdzić, czy działa, łatwiej debugować, jeśli pójdzie źle, i łatwiej odzyskać przydatne informacje w przypadku awarii systemu i uszkodzenia części dziennika.

Uszkodzony plik tekstowy jest nadal czytelny wokół uszkodzonej części. Uszkodzony plik binarny może być możliwy do odtworzenia, ale może nie być. Nawet jeśli można go odtworzyć, wymagałoby to nieco więcej pracy. Innym powodem jest to, że binarny format rejestrowania zmniejsza prawdopodobieństwo, że podczas pośpiechu w celu utworzenia „tymczasowej poprawki” (inaczej „najbardziej trwałej ze wszystkich poprawek”) rozwiązanie rejestrujące zostanie użyte zamiast czegoś, co można szybciej utworzyć.

Liczymy na testy jednostkowe w celu uzyskania i utrzymania niezawodności naszego oprogramowania. (Większość naszego kodu działa na serwerze, bez głowy; kluczową strategią jest analiza plików dziennika po operacji). Prawie każda klasa w naszej implementacji wykonuje pewne logowanie. Ważną częścią naszych testów jednostkowych jest użycie „próbnych” rejestratorów używanych podczas testów jednostkowych. Test jednostkowy tworzy próbny rejestrator i dostarcza go do testowanego elementu. Następnie (gdy jest to użyteczne / odpowiednie) analizuje to, co zostało zarejestrowane (zwłaszcza błędy i ostrzeżenia). Korzystanie z formatu dziennika tekstowego znacznie ułatwia to z tych samych powodów, dla których analizy przeprowadzane są na „prawdziwych” dziennikach: do dyspozycji jest więcej narzędzi, które można szybko używać i dostosowywać.

Historycznie dzienniki były oficjalnymi, ręcznie pisanymi i sekwencyjnymi zapisami zdarzeń. Kiedy maszyny stały się zdolne do rejestrowania zdarzeń, były one zapisywane na drukowanym urządzeniu wyjściowym, takim jak drukarka teletypowa, które tworzyło stały sekwencyjny zapis, ale które mogło jedynie przetwarzać tekst i czasami dzwonić DZWONEK ...

W czasach, gdy grałem na komputerze mainframe, użyliśmy niestandardowego formatu dziennika binarnego. Głównym powodem nie była oszczędność miejsca, ponieważ chcieliśmy, aby dziennik zajmował skończoną przestrzeń, zastępując stare wpisy nowymi; ostatnią rzeczą, jakiej chcieliśmy, była niemożność zdiagnozowania problemów spowodowanych zapełnianiem się dysków (w 1980 r. miejsce na dysku kosztowało 1000 USD / Mb, więc ludzie nie kupowali więcej, niż potrzebowali).

Teraz nadal podoba mi się pomysł okrągłego pliku dziennika, a jeśli systemy operacyjne oferowałyby taką bestię, skorzystałbym z niej bez wahania. Ale binarny był złym pomysłem. Naprawdę nie chcesz tracić czasu na znalezienie odpowiednich poleceń do odszyfrowania pliku dziennika, gdy masz krytyczny problem do rozwiązania.