Kiedy używać różnych poziomów dziennika

520

Istnieją różne sposoby rejestrowania wiadomości w porządku śmiertelnym:

  1. FATAL

  2. ERROR

  3. WARN

  4. INFO

  5. DEBUG

  6. TRACE

Jak zdecydować, kiedy użyć którego?

Jaka jest dobra heurystyka w użyciu?

raoulsson
źródło
11
Całkiem szerokie pytanie. Możliwa jest więc więcej niż jedna odpowiedź, w zależności od faktycznych okoliczności logowania. Ktoś będzie tęsknił noticew tej kolekcji, ktoś nie będzie ...
Wolf
@Wolf, gdzie „zauważanie” należałoby do tej hierarchii? Dla
przypomnienia
1
noticemoże również brakować, ponieważ niektóre popularne usługi rejestrowania, takie jak log4j, nie korzystają z niego.
pgblu,

Odpowiedzi:

749

Ogólnie zgadzam się na następującą konwencję:

  • Śledzenie - tylko wtedy, gdy „śledzę” kod i próbuję znaleźć konkretną część funkcji.
  • Debugowanie - informacje, które są diagnostycznie pomocne dla ludzi nie tylko programistów (IT, sysadmins itp.).
  • Informacje - Ogólnie przydatne informacje do rejestrowania (uruchomienie / zatrzymanie usługi, założenia konfiguracji itp.). Informacje Chcę zawsze mieć dostępne, ale zwykle nie dbam o to w normalnych okolicznościach. To jest mój gotowy poziom konfiguracji.
  • Ostrzegaj - wszystko, co może potencjalnie powodować nieprawidłowości w działaniu, ale które automatycznie odzyskuję. (Na przykład przejście z serwera głównego na serwer zapasowy, ponawianie operacji, brak danych dodatkowych itp.)
  • Błąd - jakikolwiek błąd krytyczny dla operacji , ale nie dla usługi lub aplikacji (nie można otworzyć wymaganego pliku, brakujących danych itp.). Błędy te wymuszą interwencję użytkownika (administratora lub użytkownika bezpośredniego). Są one zwykle zarezerwowane (w moich aplikacjach) na niepoprawne parametry połączenia, brakujące usługi itp.
  • Krytyczny - każdy błąd, który wymusza zamknięcie usługi lub aplikacji, aby zapobiec utracie danych (lub dalszej utracie danych). Zastrzegam je tylko dla najbardziej ohydnych błędów i sytuacji, w których istnieje gwarancja uszkodzenia lub utraty danych.
GrayWizardx
źródło
2
Dlaczego nie możesz scalić informacji i ostrzec! ??! Czy to nie ostrzeżenie o czymś „info”…
mP.
35
@mP Możesz scalić informacje i ostrzec, myślę, że ogólnie są one oddzielne z powodu zasady „paniki”. Jeśli mam kilka informacji, które są rutynowe i po prostu wymieniam stan, to naprawdę nie warto patrzeć na „pierwsze”, ale jeśli są tony „ostrzeżeń”, chcę zobaczyć te priorytety (po błędach i fatalach), żebym mógł zajrzeć do im. Byłbym bardziej „spanikowany” wieloma ostrzeżeniami niż wieloma wiadomościami informacyjnymi.
GrayWizardx
3
@dzieciou to zależy od twoich szczególnych potrzeb. Czasami może to być śmiertelne, a czasem jedynie ostrzeżenie. Jeśli otrzymam 4xx z usługi krytycznej, na której polegam i nie mogę kontynuować, będzie to błąd / błąd krytyczny dla moich projektów. Gdybym próbował buforować niektóre dane do późniejszego wykorzystania, ale mógłbym bez nich żyć, byłoby to OSTRZEŻENIE. Jedyny raz, kiedy widzę, że są to informacje, byłaby czymś w rodzaju aplikacji monitorującej, która zgłasza status kontroli adresów URL. Chciałbym INFO zalogować, że dostałem 4xx z adresu URL i przejść dalej.
GrayWizardx
2
@GrayWizardx, myślę, że innym czynnikiem jest to, czy to klient otrzymał 4xx, czy serwer, który go wysłał. W pierwszym przypadku byłbym bardziej skłonny do użycia BŁĘDU (OMG, to moja wina, że ​​nie mogę przygotować właściwego żądania), podczas gdy w drugim przypadku zalogowałbym się OSTRZEŻENIE (to wina klientów, że nie mogą poprawnie sformułować żądań)
dzieciou
4
Podejrzewam, że to prawda Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).. Logger.Debug jest przeznaczony wyłącznie dla programistów, którzy mogą śledzić bardzo nieprzyjemne problemy w produkcji, np.If you want to print the value of a variable at any given point inside a for loop against a condition
RBT
303

Czy chcesz, aby wiadomość wyprowadziła administratora systemu z łóżka w środku nocy?

  • tak -> błąd
  • no -> warn
pm100
źródło
11
Tyle że większość ludzi nie dba o to, czy wyciągną ludzi z łóżka w nocy. Mieliśmy klientów, którzy podnieśli poziom ważności 1 (przeznaczony na 100% awarii, tj. Na poziomie krajowym), ponieważ jedna strona nie mogła wykonać swojej pracy (rozumowali, że jest to 100% tej witryny). Od tego czasu „edukowaliśmy” ich w tym zakresie.
paxdiablo
53
FATALgdy budzi się sysadmin, decyduje, że nie zapłacił za to wystarczająco dużo, i wraca do snu.
Mateen Ulhaq
134

Uważam, że bardziej pomocne jest myślenie o istotności z perspektywy przeglądania pliku dziennika.

Krytyczny / krytyczny : ogólna awaria aplikacji lub systemu, którą należy natychmiast zbadać. Tak, obudź SysAdmin. Ponieważ wolimy, aby nasze SysAdmins były czujne i wypoczęte, tego poziomu ważności należy używać bardzo rzadko. Jeśli dzieje się to codziennie i nie jest to BFD, traci sens. Zazwyczaj błąd krytyczny występuje tylko raz w całym cyklu życia procesu, więc jeśli plik dziennika jest powiązany z procesem, zazwyczaj jest to ostatni komunikat w dzienniku.

Błąd : Zdecydowanie problem, który należy zbadać. SysAdmin powinien zostać powiadomiony automatycznie, ale nie trzeba go wyciągać z łóżka. Filtrując dziennik pod kątem błędów i wyżej, uzyskuje się przegląd częstotliwości błędów i można szybko zidentyfikować błąd inicjujący, który mógł spowodować kaskadę dodatkowych błędów. Śledzenie poziomów błędów w porównaniu do użycia aplikacji może dostarczyć użytecznych wskaźników jakości, takich jak MTBF, które można wykorzystać do oceny ogólnej jakości. Na przykład te dane mogą pomóc w podjęciu decyzji o tym, czy przed wydaniem potrzebny jest kolejny cykl testów beta.

Ostrzeżenie : może to być problem lub nie. Na przykład oczekiwane przejściowe warunki środowiskowe, takie jak krótka utrata łączności z siecią lub bazą danych, powinny być rejestrowane jako Ostrzeżenia, a nie Błędy. Wyświetlanie filtrowanego dziennika w celu wyświetlenia tylko ostrzeżeń i błędów może dać szybki wgląd we wczesne wskazówki dotyczące pierwotnej przyczyny kolejnego błędu. Ostrzeżenia należy stosować oszczędnie, aby nie stały się bez znaczenia. Na przykład utrata dostępu do sieci powinna być ostrzeżeniem, a nawet błędem w aplikacji serwera, ale może być tylko informacją w aplikacji komputerowej przeznaczonej dla użytkowników laptopów, którzy czasami nie są podłączeni.

Informacje : Jest to ważna informacja, którą należy rejestrować w normalnych warunkach, takich jak pomyślna inicjalizacja, uruchomienie i zatrzymanie usług lub pomyślne zakończenie znaczących transakcji. Przeglądanie dziennika zawierającego informacje i powyżej powinno dać szybki przegląd głównych zmian stanu w procesie, zapewniając kontekst najwyższego poziomu do zrozumienia wszelkich pojawiających się ostrzeżeń lub błędów. Nie masz zbyt wielu wiadomości informacyjnych. Zwykle mamy <5% wiadomości informacyjnych w odniesieniu do śledzenia.

Śledzenie : Śledzenie jest zdecydowanie najczęściej używaną dotkliwością i powinno zapewniać kontekst umożliwiający zrozumienie kroków prowadzących do błędów i ostrzeżeń. Właściwe zagęszczenie komunikatów śledzenia sprawia, że ​​oprogramowanie jest łatwiejsze w utrzymaniu, ale wymaga pewnej staranności, ponieważ wartość poszczególnych instrukcji śledzenia może zmieniać się w czasie w miarę ewolucji programów. Najlepszym sposobem na osiągnięcie tego jest skłonienie zespołu programistów do regularnego przeglądania dzienników jako standardowej części rozwiązywania problemów zgłaszanych przez klientów. Zachęcaj zespół do przycinania wiadomości Śledzenie, które nie zapewniają już użytecznego kontekstu, i dodawania wiadomości tam, gdzie jest to konieczne, aby zrozumieć kontekst kolejnych wiadomości. Na przykład często pomocne jest rejestrowanie danych wejściowych użytkownika, takich jak zmiana wyświetlaczy lub kart.

Debugowanie : Rozważamy Debugowanie <Śledzenie. Różnica polega na tym, że komunikaty debugowania są kompilowane z kompilacji wersji. To powiedziawszy, odradzamy korzystanie z wiadomości debugowania. Zezwalanie na wiadomości debugowania powoduje, że coraz więcej wiadomości debugowania jest dodawanych i nigdy nie jest usuwanych. Z czasem sprawia to, że pliki dziennika są prawie bezużyteczne, ponieważ zbyt trudno jest odfiltrować sygnał z szumu. To powoduje, że deweloperzy nie używają dzienników, które kontynuują spiralę śmierci. W przeciwieństwie do tego, ciągłe przycinanie wiadomości Trace zachęca twórców do korzystania z nich, co skutkuje cnotą spirali. Eliminuje to także możliwość wprowadzenia błędów z powodu wymaganych efektów ubocznych w kodzie debugowania, które nie są zawarte w kompilacji wydania. Tak, wiem, że to nie powinno się zdarzyć w dobrym kodzie, ale lepiej być bezpiecznym niż przepraszać.

Jay Cincotta
źródło
2
Podoba mi się to, że myślenie o publiczności jest bardzo stresujące. Kluczem w każdej komunikacji (a komunikaty dziennika są formą komunikacji) jest myślenie o odbiorcach i ich potrzebach.
sleske
18
Informacje o debugowaniu <-> Śledzenie: Zauważ, że przynajmniej w środowisku Java-land priorytetem jest „debugowanie> śledzenie”. Taką konwencję stosują wszystkie frameworki logowania (SLF4J, Logback, log4j, Apache Commons Logging, Log4Net, NLog). Debugowanie <Śledzenie wydaje mi się więc niezwykłe.
sleske
1
@Jay Cincotta Świetna odpowiedź. Myślę, że Debugowanie / Śledzenie jest kwestią preferencji, ale z pewnością tego rodzaju szczegóły są zazwyczaj specyficzne dla aplikacji / firmy, więc dobrze jest widzieć różne opinie.
GrayWizardx
5
Właśnie przeprowadziłem ankietę 7 struktur rejestrowania w kilku językach. Z trzech, które zawierają poziom ważności „śledzenia”, wszystkie mają mniej poważny niż debugowanie. tj. trace <debuguj; Nie mam rzeczywistych przypadków, w których prawda jest odwrotna. @RBT Nie zawsze jest możliwe włamanie się do debuggera. Np. Serwery WWW muszą obsługiwać żądania w skończonym czasie lub istnieć w środowiskach wielowątkowych i / lub serwerowych, które mogą być trudne w obsłudze, lub błąd może być na tyle rzadki, że debugger nie jest opcją. Lub nie wiesz, czego szukasz.
Thanatos
5
@RBT Pracuję z systemami Java od ponad 4 lat. Mogę powiedzieć, że to, o co prosisz, jest całkowicie niepraktyczne. Debugowanie IDE może zabrać Cię tylko do tej pory. W pewnym momencie, po prostu trzeba dzienniki debugowania z innego systemu (często produkcja serwera), aby zrozumieć, co się dzieje i naprawić błąd. Możesz pomyśleć, że powinno to być powtarzalne w twoim lokalnym IDE, ale jeśli pracujesz z prawdziwymi systemami, przekonasz się, że często wiele błędów jest unikalnych dla serwera produkcyjnego.
ADTC
30

Oto lista tego, co mają „loggery”.


Apache log4j: §1 , §2

  1. FATAL:

    [ v1.2 : ..] bardzo poważne zdarzenia błędów, które prawdopodobnie doprowadzą do przerwania aplikacji.

    [ v2.0 : ..] poważny błąd, który uniemożliwi kontynuowanie aplikacji.

  2. ERROR:

    [ v1.2 : ..] zdarzenia błędów, które mogą nadal umożliwiać działanie aplikacji.

    Błąd [ v2.0 : ..] w aplikacji, możliwe do odzyskania.

  3. WARN:

    [ v1.2 : ..] potencjalnie szkodliwe sytuacje.

    [ v2.0 : ..] zdarzenie, które może [ sic ] prowadzić do błędu.

  4. INFO:

    [ v1.2 : ..] komunikaty informacyjne, które podkreślają postęp aplikacji na poziomie gruboziarnistym.

    [ v2.0 : ..] wydarzenie w celach informacyjnych.

  5. DEBUG:

    [ v1.2 : ..] drobiazgowe zdarzenia informacyjne, które są najbardziej przydatne do debugowania aplikacji.

    [ v2.0 : ..] ogólne zdarzenie debugowania.

  6. TRACE:

    [ v1.2 : ..] bardziej szczegółowe wydarzenia informacyjne niż DEBUG.

    [ v2.0 : ..] drobnoziarnisty komunikat debugowania, zwykle przechwytujący przepływ przez aplikację.


Apache Httpd (jak zwykle) lubi przesadzać: §

  1. pojawi się :

    Nagłe wypadki - system nie nadaje się do użytku.

  2. ostrzeżenie :

    Działania należy podjąć natychmiast [ale system jest nadal użyteczny].

  3. kryt :

    Warunki krytyczne [ale działania nie muszą być podejmowane natychmiast].

    • gniazdo: nie można uzyskać gniazda, wychodzę z dziecka
  4. błąd :

    Warunki błędu [ale nie krytyczne].

    • Przedwczesny koniec nagłówków skryptu
  5. ostrzec :

    Warunki ostrzeżenia [blisko błędu, ale nie błędu]

  6. zauważ :

    Normalny, ale znaczący [ znaczący ] stan.

    • httpd: złapany SIGBUS, próba zrzucenia rdzenia w ...
  7. informacje :

    Informacyjny [i niezauważalny].

    • [„ Serwer działa od x godzin. ”]
  8. debugowanie :

    Komunikaty na poziomie debugowania [tj. Wiadomości zarejestrowane w celu usunięcia błędów )].

    • Otwieranie pliku konfiguracyjnego ...
  9. trace1trace6 :

    Śledzenie wiadomości [tj. Wiadomości rejestrowane w celu śledzenia ].

    • proxy: FTP: sterowanie połączeniem zakończone
    • proxy: CONNECT: wysyłanie żądania CONNECT do zdalnego proxy
    • openssl: Handshake: start
    • odczyt z buforowanej brygady SSL, tryb 0, 17 bajtów
    • wyszukiwanie mapy NIE powiodło się:map=rewritemap key=keyname
    • wyszukiwanie pamięci podręcznej nie powiodło się, wymuszając nowe wyszukiwanie mapy
  10. trace7trace8 :

    Śledź wiadomości, wyrzucając duże ilości danych

    • | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |
    • | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |

Wspólne logowanie Apache: §

  1. śmiertelne :

    Poważne błędy, które powodują przedwczesne zakończenie. Spodziewaj się, że będą natychmiast widoczne w konsoli stanu.

  2. błąd :

    Inne błędy w czasie wykonywania lub nieoczekiwane warunki. Spodziewaj się, że będą natychmiast widoczne w konsoli stanu.

  3. ostrzec :

    Używanie przestarzałych interfejsów API, słabe użycie interfejsu API, „prawie” błędy, inne sytuacje uruchomieniowe, które są niepożądane lub nieoczekiwane, ale niekoniecznie „złe”. Spodziewaj się, że będą natychmiast widoczne w konsoli stanu.

  4. informacje :

    Ciekawe zdarzenia uruchomieniowe (uruchomienie / zamknięcie). Spodziewaj się, że będą natychmiast widoczne na konsoli, więc zachowaj ostrożność i ograniczaj się do minimum.

  5. debugowanie :

    szczegółowe informacje o przepływie przez system. Spodziewaj się, że zostaną zapisane tylko w dziennikach.

  6. ślad :

    bardziej szczegółowe informacje. Spodziewaj się, że zostaną zapisane tylko w dziennikach.

„Sprawdzone metody” rejestrowania przez Apache commons do użytku korporacyjnego rozróżniają debugowanie i informacje w zależności od tego, jakie granice przekraczają.

Granice obejmują:

  • Granice zewnętrzne - oczekiwane wyjątki.

  • Granice zewnętrzne - nieoczekiwane wyjątki.

  • Granice wewnętrzne.

  • Znaczące granice wewnętrzne.

( Więcej informacji na ten temat można znaleźć w przewodniku dotyczącym wspólnego logowania ).

Pacerier
źródło
24

Jeśli możesz rozwiązać problem, jest to ostrzeżenie. Jeśli uniemożliwia kontynuowanie wykonywania, oznacza to błąd.

Ignacio Vazquez-Abrams
źródło
5
Ale jaka jest różnica między błędem a błędem krytycznym?
user192472
37
Błąd to coś, co robisz (np. Odczytujesz nieistniejący plik), błąd krytyczny to coś, co zostaje ci zrobione (np. Zabraknie pamięci).
Ignacio Vazquez-Abrams
@ IgnacioVazquez-Abrams Podoba mi się twój sposób wyróżnienia. Ale na czym opiera się twój komentarz? AFIAK wśród programistów iOS to konwencja, aby napisać twierdzenie, które odnosi się, fatalErrorgdy plik nie istnieje. Zasadniczo jest to przeciwieństwo tego, co powiedziałeś.
Honey,
@Honey: W sytuacji mobilnej uzasadnione jest uznanie brakującego pliku za błąd krytyczny.
Ignacio Vazquez-Abrams
23

Polecam przyjęcia poziomy ważności Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Zobacz http://en.wikipedia.org/wiki/Syslog#Severity_levels

Powinny one zapewniać wystarczająco szczegółowe poziomy istotności dla większości przypadków użycia i są rozpoznawane przez istniejące analizatory dzienników. Chociaż masz oczywiście swobodę implementowania tylko podzbioru, np. W DEBUG, ERROR, EMERGENCYzależności od wymagań aplikacji.

Ujednolicmy coś, co istnieje od wieków, zamiast opracowywać własny standard dla każdej innej aplikacji, którą tworzymy. Gdy zaczniesz agregować dzienniki i próbujesz wykryć wzorce w różnych, to naprawdę pomaga.

kvz
źródło
1
Potrzebuję dziennika śledzenia, ponieważ chcę zobaczyć, jak działają moje kody. Co robi syslog, aby to naprawić?
Karl Morrison,
Śledzenie zazwyczaj nie jest czymś, co chciałbyś przesyłać przez syslog i myślę, że możesz dodać ten poziom do własnych interaktywnych sesji debugowania?
kvz
2
Wszystkie te rozszerzone poziomy zwiększają złożoność logowania IMO. Najlepiej trzymać się najprostszego zestawu odpowiadającego potrzebom konkretnej aplikacji. Dla mnie, należy zacząć DEBUG, INFO, WARNINGi ERROR. Programiści powinni zobaczyć wszystkie poziomy. Administratorzy SysAdmin INFOi użytkownicy końcowi widzą ostrzeżenia i błędy, ale tylko wtedy, gdy istnieją odpowiednie ramy ostrzegające o nich .
ADTC
1
(kont.) W miarę dojrzewania aplikacji możesz w razie potrzeby rozwinąć się na więcej poziomów. Podobnie jak DEBUGi TRACEdla programistów, aby kontrolować ziarnistość. I ERRORrozszerzony na inne poziomy, takie jak CRITICAL, ALERTw EMERGENCYcelu rozróżnienia dotkliwości błędów i określenia działania na podstawie istotności.
ADTC
17

Ostrzeżenia, które możesz odzyskać. Błędy, których nie możesz. To moja heurystyka, inni mogą mieć inne pomysły.

Załóżmy na przykład, że wprowadzasz / importujesz nazwę "Angela Müller"do swojej aplikacji (zwróć uwagę na umlaut nad u). Twój kod / baza danych może być tylko w języku angielskim (choć prawdopodobnie nie powinien być w dzisiejszych czasach) i dlatego może ostrzegać, że wszystkie „niezwykłe” znaki zostały przekonwertowane na zwykłe angielskie znaki.

Porównaj to z próbą zapisania tych informacji w bazie danych i odzyskaniem komunikatu o awarii sieci na 60 sekund z rzędu. To bardziej błąd niż ostrzeżenie.

paxdiablo
źródło
Jeśli baza danych ma określony zestaw znaków, który nie zawiera umlaut, to dane wejściowe należy odrzucić.
Cochise Ruhulessin,
Cochise, świat rzadko jest tak czarno-biały :-)
paxdiablo
6

Jak powiedzieli inni, błędy są problemami; ostrzeżenia są potencjalnymi problemami.

Podczas programowania często używam ostrzeżeń, w których mogę umieścić odpowiednik błędu asercji, ale aplikacja może nadal działać; pozwala mi to dowiedzieć się, czy taka sprawa kiedykolwiek się wydarzyła, czy też jest to moja wyobraźnia.

Ale tak, sprowadza się to do aspektów związanych z odtwarzalnością i aktualnością. Jeśli możesz wyzdrowieć, to prawdopodobnie jest to ostrzeżenie; jeśli powoduje to awarię, oznacza to błąd.

Michael Ekstrand
źródło
5

Myślę, że poziomy SYSLOG NOTICE i ALERT / AWARYJNE są w dużej mierze zbędne do rejestrowania na poziomie aplikacji - podczas gdy KRYTYCZNE / ALERT / AWARYJNE mogą być przydatnymi poziomami alertów dla operatora, który może wyzwalać różne akcje i powiadomienia, dla administratora aplikacji to wszystko to samo, co FATALNY. I po prostu nie mogę wystarczająco rozróżnić między otrzymaniem zawiadomienia lub niektórych informacji. Jeśli informacje nie są godne uwagi, to tak naprawdę nie są to informacje :)

Najbardziej podoba mi się interpretacja Jaya Cincotty - śledzenie wykonania kodu jest bardzo przydatne w pomocy technicznej, a zachęcanie do wprowadzania instrukcji śledzenia w kodzie powinno być zachęcane - szczególnie w połączeniu z dynamicznym mechanizmem filtrowania do rejestrowania komunikatów śledzenia z określonych składników aplikacji. Jednak poziom DEBUGA dla mnie wskazuje, że wciąż zastanawiamy się, co się dzieje - widzę, że dane wyjściowe na poziomie DEBUG są opcją tylko dla programistów, a nie czymś, co powinno się kiedykolwiek pojawić w dzienniku produkcyjnym.

Istnieje jednak poziom rejestrowania, który lubię widzieć w dziennikach błędów, gdy noszę czapkę sysadmina tak samo, jak wsparcia technicznego, a nawet programisty: OPER, dla komunikatów OPERATIONAL. Używam tego do rejestrowania znacznika czasu, rodzaju wywoływanej operacji, dostarczonych argumentów, ewentualnie (unikalnego) identyfikatora zadania i zakończenia zadania. Jest używany, gdy np. Wystrzeliwane jest samodzielne zadanie, co jest prawdziwym wywołaniem z większej, długiej aplikacji. Jest to coś, co chcę zawsze rejestrować, bez względu na to, czy coś pójdzie nie tak, czy nie, więc uważam, że poziom OPER jest wyższy niż FATAL, więc możesz go wyłączyć, przechodząc do trybu całkowicie cichego. I to znacznie więcej niż zwykłe dane dziennika INFO - poziom dziennika często nadużywany do spamowania dzienników z niewielkimi komunikatami operacyjnymi bez żadnej wartości historycznej.

W zależności od przypadku informacja ta może zostać skierowana do osobnego dziennika wywołania lub może zostać uzyskana przez odfiltrowanie jej z dużego dziennika rejestrującego więcej informacji. Ale zawsze jest to potrzebne, jako informacja historyczna, aby wiedzieć, co zostało zrobione - bez zejścia do poziomu AUDIT, innego całkowicie oddzielnego poziomu dziennika, który nie ma nic wspólnego z usterkami lub działaniem systemu, tak naprawdę nie mieści się w powyższych poziomach ( ponieważ potrzebuje własnego przełącznika sterującego, a nie klasyfikacji istotności) i która zdecydowanie potrzebuje własnego oddzielnego pliku dziennika.

volkerk
źródło
5

Od RFC 5424, protokół Syslog (IETF) - Strona 10:

Priorytet każdej wiadomości ma również dziesiętny wskaźnik poziomu ważności. Są one opisane w poniższej tabeli wraz z ich wartościami liczbowymi. Wartości ważności MUSZĄ być w zakresie od 0 do 7 włącznie.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities
ThangTD
źródło
4

Dzień dobry

W następstwie tego pytania przekaż swoje interpretacje poziomów dziennika i upewnij się, że wszyscy ludzie w projekcie są zgodni w interpretacji poziomów.

Bolesne jest wyświetlanie szerokiej gamy komunikatów w dzienniku, w których nasilenia i wybrane poziomy dziennika są niespójne.

Podaj przykłady, jeśli to możliwe, różnych poziomów rejestrowania. I zachowaj spójność informacji, aby zalogować się w wiadomości.

HTH

Rob Wells
źródło
4

Całkowicie zgadzam się z innymi i uważam, że GrayWizardx powiedział to najlepiej.

Mogę tylko dodać, że poziomy te zasadniczo odpowiadają ich definicjom w słowniku, więc nie może być takie trudne. W razie wątpliwości potraktuj to jak zagadkę. W przypadku konkretnego projektu pomyśl o wszystkim, co chcesz zalogować.

Czy potrafisz wymyślić, co może być śmiertelne? Wiesz, co oznacza śmierć, prawda? Które pozycje na liście są śmiertelne.

Ok, to fatalnie rozwiązane, teraz spójrzmy na błędy ... spłucz i powtórz.

Poniżej poziomu krytycznego, a może błędu sugerowałbym, że więcej informacji jest zawsze lepsze niż mniej, więc błędnie „w górę”. Nie jesteś pewien, czy jest to informacja czy ostrzeżenie? Więc zrób to ostrzeżenie.

Uważam, że fatalne i błąd powinny być jasne dla nas wszystkich. Inni mogą być bardziej niespokojni, ale prawdopodobnie ich poprawienie jest mniej istotne.

Oto kilka przykładów:

Fatalne - nie można przydzielić pamięci, bazy danych itp. - nie można kontynuować.

Błąd - brak odpowiedzi na wiadomość, transakcja przerwana, nie można zapisać pliku itp.

Ostrzeżenie - alokacja zasobów osiąga X% (powiedzmy 80%) - to znak, że możesz chcieć zmienić swój wymiar.

Informacje - użytkownik zalogowany / wylogowany, nowa transakcja, skrzynka plików, nowe pole d / b lub pole usunięte.

Debugowanie - zrzut wewnętrznej struktury danych, poziom Anything Trace z nazwą pliku i numerem linii.
Trace - akcja zakończyła się powodzeniem / niepowodzeniem, d / b zaktualizowane.

Mawg mówi, że przywróć Monikę
źródło
3

Błąd to coś, co jest złe, po prostu złe, nie można go obejść, należy to naprawić.

Ostrzeżenie jest oznaką wzoru, który może być nieprawidłowy, ale może również nie być.

Powiedziawszy to, nie mogę wymyślić dobrego przykładu ostrzeżenia, które nie jest również błędem. Rozumiem przez to, że jeśli masz problem z zalogowaniem ostrzeżenia, równie dobrze możesz rozwiązać podstawowy problem.

Jednak takie rzeczy jak „wykonanie sql trwa zbyt długo” może być ostrzeżeniem, podczas gdy „zakleszczenia wykonania sql” to błąd, więc może jednak są pewne przypadki.

Lasse V. Karlsen
źródło
1
Dobrym przykładem ostrzeżenia jest to, że w MySQL domyślnie próba wstawienia większej liczby znaków varcharniż zdefiniowana, ostrzega, że ​​wartość została obcięta, ale nadal ją wstawia. Ale ostrzeżenie jednej osoby może być błędem innej osoby: w moim przypadku jest to błąd; oznacza to, że popełniłem błąd w kodzie sprawdzania poprawności, określając długość niezgodną z bazą danych. I nie byłbym strasznie zaskoczony, gdyby inny silnik DB uznał to za błąd i nie miałbym prawdziwego prawa do oburzenia, w końcu jest to błędne.
Crast
Też uważam to za błąd. W niektórych przypadkach zawartością jest „tekst” (nie w znaczeniu typu danych), co oznacza, że być może jest okrojone. W innym przypadku jest to kod, w którym odcięcie bitów spowoduje jego uszkodzenie lub zmianę jego znaczenia, co nie jest w porządku. Moim zdaniem to nie oprogramowanie próbuje zgadywać, co miałem na myśli. Jeśli spróbuję zmusić ciąg 200 znaków do kolumny, która zajmuje tylko 150 znaków, to jest problem, o którym chciałbym wiedzieć. Lubię jednak rozróżnienie dokonane przez innych tutaj, że jeśli możesz wyzdrowieć, jest to ostrzeżenie, ale wtedy ... czy musisz się zalogować?
Lasse V. Karlsen
Jednym z przykładów, o których mogłem pomyśleć, jest: Niektóre wiadomości trwają zaskakująco dłużej niż zwykle. Może to wskazywać, że coś jest nie tak (może jakiś inny system jest przeciążony lub zasoby zewnętrzne były chwilowo wyłączone).
Laradda,
3

Zawsze rozważałem ostrzeżenie pierwszego poziomu dziennika, co z pewnością oznacza problem (na przykład być może plik konfiguracyjny nie jest tam, gdzie powinien być i będziemy musieli działać z ustawieniami domyślnymi). Błąd oznacza dla mnie coś, co oznacza, że ​​główny cel oprogramowania jest teraz niemożliwy, a my postaramy się zamknąć całkowicie.

dicroce
źródło
1

Wcześniej zbudowałem systemy, używając następujących:

  1. BŁĄD - oznacza, że ​​coś jest naprawdę nie tak i ten konkretny wątek / proces / sekwencja nie może być kontynuowany. Wymagana jest interwencja użytkownika / administratora
  2. OSTRZEŻENIE - coś jest nie tak, ale proces może być kontynuowany jak poprzednio (np. Jedno zadanie z zestawu 100 nie powiodło się, ale resztę można przetworzyć)

W systemach, które zbudowałem, administratorzy mieli instrukcje reagowania na BŁĘDY. Z drugiej strony obserwowalibyśmy OSTRZEŻENIA i dla każdego przypadku ustalalibyśmy, czy wymagane są jakiekolwiek zmiany systemu, rekonfiguracje itp.

Brian Agnew
źródło
1

Przy okazji, jestem wielkim fanem robienia wszystkiego i filtrowania informacji później.

Co by się stało, jeśli przechwytujesz na poziomie Ostrzeżenie i chcesz uzyskać informacje dotyczące debugowania związane z ostrzeżeniem, ale nie możesz odtworzyć ostrzeżenia?

Uchwyć wszystko i przefiltruj później!

Dotyczy to nawet dla wbudowanego oprogramowania, chyba że okaże się, że procesor nie może nadążyć, w którym to przypadku może chcesz ponownie zaprojektować śledzenie aby uczynić go bardziej wydajne, czy śledzenie jest zakłócanie rozrządu (ty może rozważyć debugowanie mocniejszy procesor, ale to otwiera całą kolejną puszkę robaków).

Uchwyć wszystko i przefiltruj później !!

(btw, przechwytywanie wszystkiego jest również dobre, ponieważ pozwala opracować narzędzia do więcej niż tylko pokazania śladu debugowania (rysuję wykresy sekwencji wiadomości z moich i histogramy zużycia pamięci. Daje to również podstawę do porównania, jeśli coś pójdzie nie tak przyszłość (zachowaj wszystkie dzienniki, niezależnie od tego, czy pomyślnie przejdą, czy nie, i pamiętaj o dołączeniu numeru kompilacji do pliku dziennika)).

Mawg mówi, że przywróć Monikę
źródło
1

Moje dwa centy FATALi TRACEpoziomy dziennika błędów.

ERROR występuje, gdy wystąpi jakiś BŁĄD (wyjątek).

FATAL jest faktycznie PODWÓJNY BŁĄD: gdy wystąpi wyjątek podczas obsługi wyjątku.

Usługa sieci Web jest łatwa do zrozumienia.

  1. Wniosek przychodzi. Zdarzenie jest rejestrowane jakoINFO
  2. System wykrywa mało miejsca na dysku. Zdarzenie jest rejestrowane jakoWARN
  3. Niektóre funkcje są wywoływane w celu obsługi żądania. Podczas przetwarzania występuje podział na zero. Zdarzenie jest rejestrowane jakoERROR
  4. Program obsługi wyjątków usługi sieci Web jest wywoływany do obsługi dzielenia przez zero. Usługa sieci Web / framework będzie wysyłać wiadomości e-mail, ale nie może, ponieważ usługa poczty jest teraz offline. Ten drugi wyjątek nie może być obsługiwany normalnie, ponieważ moduł obsługi wyjątków usługi sieci Web nie może przetworzyć wyjątku.
  5. Wywołano inny moduł obsługi wyjątków. Zdarzenie jest rejestrowane jakoFATAL

TRACEkiedy możemy prześledzić wejście / wyjście funkcji. Tu nie chodzi o logowanie, ponieważ ten komunikat może zostać wygenerowany przez jakiś debugger, a twój kod w ogóle się nie wywołuje log. Dlatego wiadomości, które nie pochodzą z Twojej aplikacji, są oznaczone jako TRACEpoziom. Na przykład uruchom swoją aplikację przy pomocystrace

Więc ogólnie w programie robisz DEBUG, INFOi WARNrejestrowania. I tylko jeśli piszesz jakąś usługę / platformę internetową, której będziesz używać FATAL. A kiedy debugujesz aplikację, będziesz TRACElogować się z tego typu oprogramowania.

Eugen Konkov
źródło
0

Sugeruję użycie tylko trzech poziomów

  1. Fatal - co spowodowałoby uszkodzenie aplikacji.
  2. Informacje - informacje
  3. Debugowanie - mniej ważne informacje
użytkownik1782556
źródło