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

81

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ą?

php_nub_qq
źródło
20
Zakwestionowałbym twoje twierdzenie, że ludzie tego nie robią. Wielu tak. Niektórzy nie, jasne, ale wiele.
Servy
44
> Jeśli rejestrowanie było przechowywane jako dane binarne, można by zachować dużo miejsca Cóż, stare dzienniki są zwykle kompresowane.
leonbloy
89
Czytanie dziennika tekstowego na maszynie, która jest w połowie uszkodzona, może być ogromną przewagą nad potrzebowaniem pliku binarnego do jego analizy.
tofro
23
Po miesiącach modyfikacji, aby poprawnie wykonać algorytm w dużym klastrze, nadal nie mogliśmy zaobserwować znacznego wzrostu wydajności, ale kiedy zmieniliśmy przechowywanie plików dziennika w plikach binarnych? Święta krowa, nigdy nie odważyliśmy się marzyć, że wydajność może być na tym poziomie. Jak wiarygodna jest tego rodzaju historia?
null

Odpowiedzi:

163

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.

Alex
źródło
3
Słuszna uwaga. Natychmiast pomyślałem o systemd. Jeszcze ważniejsze jest to, że aplikacja nie musi wiedzieć, jak są przechowywane dane dziennika. Może być świadczony jako usługa systemowa.
5gon12eder
97
„słynny”, bardziej jak „niesławny”
nazywa
4
pf (zapora ogniowa) loguje się również w formacie binarnym, a konkretnie do formatu tcpdump
Neil McGuigan,
3
@Hatshepsut Rolled logs: dane wyjściowe dziennika są zapisywane w jednym pliku, powiedzmy myapp.logdo północy, a następnie przenoszone do tego pliku myapp.log.1i rozpoczynają zapisywanie w nowym myapp.logpliku. A stary myapp.log.1zostaje przeniesiony myapp.log.2i tak dalej, wszyscy się toczą. Tak więc myapp.logzawsze jest obecny. Lub mogą się zmienić po osiągnięciu określonego rozmiaru. Może wstawili datę / czas w nazwie pliku. Wiele platform rejestrowania obsługuje tego rodzaju rzeczy od razu po wyjęciu z pudełka.
SusanW,
13
@ Hatszepsut Termin ten rotatingjest również używany z tego, co wiem.
George D
89

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.

ChrisW
źródło
24
Nie zapomnij o dokumentacji! Kilka lat temu napisałem binarny rejestrator wiadomości dla systemu, który rejestrował przychodzące żądania regresji / odtwarzania. Teraz jedynym sposobem na zrozumienie tych okropnych plików jest przyjrzenie się kodowi, który je odczytuje / zapisuje, a jeszcze inne zespoły używają ich i zadają pytania na ich temat. Okropne rzeczy.
SusanW,
2
Szczerze mówiąc, przechowywanie twojego loginu w bazie danych SQLite w połączeniu z podstawowymi narzędziami do czytania do odczytu zapewni wszystkie te funkcje, o których wspominasz po wyjęciu z pudełka. ;)
jpmc26
3
@ jpmc26 Tak, możesz odczytać plik dziennika tak długo, jak to możliwe, w jakiś sposób przekonwertować go na format tekstowy ...
ChrisW
1
jak powiedziano w innych komentarzach: pliki tekstowe mogą być łatwo kompresowane i wydajne. Ale kompresja nie musi znajdować się w „danych”. Kompresję można wykonać w systemie plików. dzięki czemu możesz używać zwykłego tekstu dla wszystkich narzędzi i nie marnować miejsca na dysku.
Bernd Wilke z
2
@ JefréN. Jeśli uruchomię tail -fplik dziennika z wieloma gigabajtami, przeskakuje on na koniec pliku (używając „seek” bez „read”), a następnie odczytuje i wyświetla tylko koniec pliku. Nie musi dekompresować / dekodować całego pliku.
ChrisW,
49

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.

Robert Harvey
źródło
19
„równie dobrze możesz przechowywać dzienniki w bazie danych, gdzie możesz je przesłuchiwać i analizować statystycznie”. W poprzednim zadaniu mieliśmy niestandardowe narzędzie, które importuje nasze dzienniki (tekstowe) do bazy danych właśnie w tym celu.
Mason Wheeler,
5
Rozmyślam nad tym, co OP rozumie przez „SSD, gdzie zapisy są ograniczone”, to fakt, że na SSD mają ograniczone cykle zapisu / kasowania, a zbyt dużo zapisu w sektorze skróciło żywotność urządzenia. Nie miała na myśli, że zapisy przepadły.
Tulains Córdova
4
@ TulainsCórdova: Tak, wiedziałem, co miała na myśli.
Robert Harvey
2
@DocSalvager: Nie twierdziłem inaczej.
Robert Harvey
2
@ TulainsCórdova - limity cykli zapisu SSD są obecnie bardzo wysokie. Nawet niedrogie dyski SSD klasy konsumenckiej mają gwarancje producenta na cykle zapisu, które sięgają setek razy większego rozmiaru urządzenia, oraz MTBF, które pokryją Cię przy zapisie tysiące razy większym niż pojemność urządzenia. A w warunkach komercyjnych powinieneś używać wyższej klasy urządzeń, które mają znacznie większe limity cyklu zapisu i powinieneś je wymieniać co najmniej przez okres 5 lat, więc chyba, że ​​piszesz> 10% pojemności pamięci na dzień, nie sądzę nie ma się czym martwić.
Jules
36

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.

SusanW
źródło
1
Nawet Unix /var/log/utmp/ wtmp są binarne . Rejestrują, kto jest aktualnie zalogowany na którym tty (więc nie tylko rosną), ale są formą logowania. (Przydatne jest, aby móc je tanio parsować, ponieważ różne popularne polecenia tak whowłaśnie robią.)
Peter Cordes,
1
@PeterCordes Very true. Znowu dobrze zdefiniowane dane. ustrukturyzowane rekordy. I oczywiście szybkość i rozmiar na wszystkich skalach były w tamtych czasach kluczowymi kwestiami.
SusanW,
9

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.

Hagen von Eitzen
źródło
9
Nie wspominając o tym, że znalezienie czegoś w dzienniku zdarzeń Windows może być koszmarem. Z pewnością sprawia, że ​​tęsknię za prostym plikiem tekstowym.
Michael Hampton,
4
Czekać. Czy chcesz widzieć jednocześnie dwa (lub więcej) wpisów w dzienniku? Cóż to niedobrze.
Eric Towers,
2
Moja odpowiedź miała brzmieć: „Dzienniki zdarzeń systemu Windows, wystarczy powiedzieć”.
Craig,
Moje doświadczenia z brakującymi zasobami w Podglądzie zdarzeń były z narzędziami, które nie mają zasobów do zainstalowania, ale w takim przypadku, AFAIR, nadal jest wiersz rzeczywistych informacji z programu raportującego, na dole, po zakończeniu przez Windows „ zasób może być brakujący lub uszkodzony. ”
podkreślenie_d.
5

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ć.

Cort Ammon
źródło
5

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 .)

Michael Le Barbier Grünewald
źródło
4

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.

Thomas Matthews
źródło
3

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?

JRobert
źródło
1
Podobnie, gdy próbujesz zalogować się w czasie rzeczywistym z urządzenia osadzonego na komputerze PC za pośrednictwem portu szeregowego o wartości 9600 bodów, często zaleca się kompresowanie danych lub użycie formatu binarnego, aby zapobiec przepełnieniu.
Mawg
3

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.

Casey Kuball
źródło
2
Ponieważ został przywołany przez kogoś innego, chciałem zauważyć, że HTTP / 2 (patrz!) Pozwala na binarną, dwukierunkową, multipleksowaną komunikację. Każdy deweloper, który ma ochotę na elitę, powinien nauczyć się tego naprawdę szybko, a następnie zadać sobie pytanie, dlaczego nie stało się to wcześniej.
Shaun Wilson,
3

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ć.

Dmitrij Rubanowicz
źródło
2

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ć.

Art Swri
źródło
2
chociaż ktoś inny zlekceważył, chciałbym zauważyć, że tego rodzaju odpowiedź wciąż zapewnia wartość, pokazuje, że dzienniki tekstowe mogą być przydatne nawet na najgorszych poziomach praktyki w sposób, którego przeciętny programista tak naprawdę nie obchodzi, ale powinien. +1
Shaun Wilson
Dziękuję za komentarz do pomocy technicznej. Staram się podawać informacje, które moim zdaniem będą przydatne przynajmniej niektórym osobom. Tego właśnie chcę i oczekuję, kiedy pójdę do SO.
Art Swri,
2

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 ...

Chris_F
źródło
2

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.

Michael Kay
źródło