Kiedy korzystać z różnych poziomów dziennika

Chcesz, aby wiadomość wyciągnęła administratora systemu z łóżka w środku nocy?

• tak - > błąd
• no - > warn

Bardziej pomocne wydaje mi się myślenie o trudnościach z perspektywy oglądania pliku dziennika.

Fatal / Critical: całkowita awaria aplikacji lub systemu, którą należy natychmiast zbadać. Tak, Obudź Sysadmina. Ponieważ preferujemy naszych sysadminów czujnych i wypoczętych, ta surowość powinna być używana bardzo rzadko. Jeśli dzieje się to codziennie i to nie jest BFD, to traci swoje znaczenie. Zazwyczaj Błąd krytyczny występuje tylko raz w ciągu życia procesu, więc jeśli dziennik plik jest powiązany z procesem, zazwyczaj jest to ostatnia wiadomość w dzienniku.

Błąd: zdecydowanie problem, który należy zbadać. SysAdmin powinien być powiadamiany automatycznie, ale nie musi być wyciągany z łóżka. Filtrując dziennik, aby spojrzeć na błędy i powyżej, otrzymujesz przegląd częstotliwości błędów i możesz szybko zidentyfikować inicjującą awarię, która mogła spowodować kaskadę dodatkowych błędów. Śledzenie wskaźników błędów w porównaniu z wykorzystaniem aplikacji może przynieść przydatne wskaźniki jakości, takie jak MTBF, które mogą być wykorzystane do oceny ogólnej jakości. Na przykład ten wskaźnik może pomóc w podjęciu decyzji o konieczności przeprowadzenia kolejnego cyklu beta testów przed wydaniem.

Warning: to może być problem, lub nie. Na przykład oczekiwane przejściowe warunki środowiskowe, takie jak krótka utrata połączenia z siecią lub bazą danych, powinny być rejestrowane jako ostrzeżenia, a nie Błędy. Przeglądanie dziennika filtrowane, aby pokazać tylko ostrzeżenia i błędy mogą dać szybki wgląd w wczesne wskazówki dotyczące przyczyny kolejnego błędu. Ostrzeżenia powinny być stosowane oszczędnie, aby nie stały się bezsensowne. Na przykład utrata dostępu do sieci powinna być ostrzeżeniem, a nawet błędem w aplikacji serwerowej, ale może to być tylko Informacja w aplikacji komputerowej przeznaczonej dla użytkowników komputerów przenośnych, którzy są odłączeni od sieci.

Info: jest to ważna informacja, która powinna być rejestrowana w normalnych warunkach, takich jak pomyślna inicjalizacja, uruchamianie usług i zatrzymanie lub pomyślne zakończenie znaczących transakcji. Przeglądanie dziennika pokazującego informacje i powyżej powinno dać szybki przegląd głównych zmian stanu w procesie zapewniając kontekst najwyższego poziomu dla zrozumienia wszelkich ostrzeżeń lub błędów, które również występują. Nie ma zbyt wielu wiadomości informacyjnych. Zazwyczaj mamy

Trace : Trace jest zdecydowanie najczęściej używanym znaczeniem i powinien zapewniać kontekst, aby zrozumieć kroki prowadzące do błędów i ostrzeżenia. Posiadanie odpowiedniej gęstości komunikatów śledzenia sprawia, że oprogramowanie jest znacznie łatwiejsze do utrzymania, ale wymaga pewnej staranności, ponieważ wartość poszczególnych instrukcji śledzenia może się zmieniać w czasie, gdy programy ewoluują. Najlepszym sposobem na osiągnięcie tego celu jest wprowadzenie zespołu programistów w nawyk regularnego przeglądania dzienników jako standardowej części rozwiązywania problemów zgłaszanych przez klientów. Zachęcanie zespołu do usuwania wiadomości śledzenia, które nie zapewniają już użytecznego kontekstu i dodawania wiadomości, gdy jest to konieczne zrozumieć kontekst kolejnych komunikatów. Na przykład często pomocne jest rejestrowanie danych wejściowych użytkownika, takich jak zmiana wyświetlaczy lub kart.

Debug : rozważamy Debug

Jeśli możesz odzyskać po problemie, to Ostrzeżenie. Jeśli uniemożliwia kontynuowanie wykonywania, to jest to błąd.

Zalecam przyjęcie poziomów nasilenia Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Zobacz http://en.wikipedia.org/wiki/Syslog#Severity_levels

Powinny zapewnić wystarczającą ilość drobnoziarnistych poziomów nasilenia dla większości przypadków użycia i są rozpoznawane przez istniejące parsery logów. Podczas gdy masz oczywiście swobodę tylko zaimplementować podzbiór, np. DEBUG, ERROR, EMERGENCY w zależności od wymagań aplikacji.

Ustandaryzujmy coś, co istnieje od wieków, zamiast wymyślać własny standard dla każdego inna aplikacja, którą tworzymy. Gdy zaczniesz agregować dzienniki i próbujesz wykryć wzorce w różnych przypadkach, to naprawdę pomaga.

Oto lista tego, co mają" drwale".

Apache log4j: §1, §2

1. FATAL:

   [v1. 2 : ..] bardzo poważne błędy, które prawdopodobnie doprowadzą aplikację do przerwania.

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

2. ERROR:

   [v1. 2 : ..] zdarzenia błędów dzięki temu aplikacja może nadal działać.

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

3. WARN:

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

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

4. INFO:

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

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

5. DEBUG:

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

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

6. TRACE:

   [v1. 2 : ..] drobniejsze wydarzenia informacyjne niż DEBUG.

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

Apache Httpd (jak zwykle) lubi przesadzać: §

1. :

   Awaryjne-system jest bezużyteczny.

2. Alert :

   Akcja musi zostać podjęta natychmiast [ale system jest nadal użyteczny].

3. Crit :

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

   • "socket: nie udało się uzyskać gniazda, opuszczając dziecko "

4. Błąd :

   Warunki błędu [ale nie krytyczne].

   • "przedwczesny koniec nagłówków skryptu "

5. Warn :

   Warunki ostrzegawcze. [close to error, but not error]

6. Notice:

   Normal but significant [godne uwagi] warunek.

   • "httpd: caught SIGBUS, próba zrzutu rdzenia ..."

7. Info :

   Pouczające [i niezauważalne].

   • ["serwer działa od x godzin."]

8. Debug :

   Debug-level messages [, tj. wiadomości rejestrowane w celu de-bugging )].

   • "Otwieranie pliku konfiguracyjnego ..."

9. Trace1 → trace6 :

   Śledzenie wiadomości [, tj. wiadomości rejestrowanych w celu śledzenia].

   • "proxy: FTP: Kontrola połączenia complete "
   • "proxy: CONNECT: wysyłanie żądania połączenia do zdalnego serwera proxy "
   • "openssl: Handshake: start "
   • "odczyt z buforowanej brygady SSL, Tryb 0, 17 bajtów "
   • "nieudane wyszukiwanie mapy: map=rewritemap key=keyname"
   • "wyszukiwanie w pamięci podręcznej nie powiodło się, wymuszając wyszukiwanie nowej mapy "

10. Trace7 → trace8 :

    Trace messages, dumping dużych 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 |"

Apache commons-logowanie: §

1. Fatal :

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

2. Błąd :

   Inne błędy uruchomieniowe lub nieoczekiwane warunki. Spodziewaj się, że będą one natychmiast widoczne na konsoli stanu.

3. Warn :

   Używanie przestarzałych interfejsów API, słabe korzystanie z API, błędy "prawie", inne sytuacje, które są niepożądane lub nieoczekiwane, ale niekoniecznie "złe". Spodziewaj się, że będą one natychmiast widoczne na konsoli stanu.

4. Info :

   Ciekawe zdarzenia uruchomieniowe (startup/shutdown). Expect są one natychmiast widoczne na konsoli, więc zachowaj ostrożność i ogranicz do minimum.

5. Debug :

   Szczegółowe informacje o przepływie przez system. Spodziewaj się, że będą one zapisywane tylko do dzienników.

6. Ślad :

   Bardziej szczegółowe informacje. Spodziewaj się, że będą one zapisywane tylko do dzienników.

Apache commons-rejestrowanie "najlepszych praktyk" do użytku korporacyjnego rozróżnia pomiędzy debug i info na podstawie 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.

Ostrzeżenia, z których możesz wyzdrowieć. To moja heurystyka, inni mogą mieć inne pomysły.

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

Kontrastuje to z próbą napisania tej informacji do bazy danych i wysyłanie wiadomości z sieci na 60 sekund. To bardziej błąd niż Ostrzeżenie.

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

W rozwoju często używam ostrzeżeń, gdzie mogę umieścić odpowiednik niepowodzenia twierdzenia, ale aplikacja może nadal działać; to pozwala mi dowiedzieć się, czy taki przypadek rzeczywiście się wydarzy, lub czy to moja wyobraźnia.

Ale tak, sprowadza się to do aspektów odzyskiwania i aktualności. Jeśli można odzyskać, to prawdopodobnie ostrzeżenie; jeśli to powoduje, że coś faktycznie nie działa, to błąd.

Myślę, że poziomy syslog NOTICE i ALERT / EMERGENCY są w dużej mierze zbędne do logowania na poziomie aplikacji-podczas gdy CRITICAL/ALERT / EMERGENCY mogą być użytecznymi poziomami alertów dla operatora, który może wyzwalać różne akcje i powiadomienia, dla administratora aplikacji to wszystko jest takie samo jak FATAL. I po prostu nie mogę wystarczająco rozróżnić pomiędzy otrzymaniem powiadomienia, a jakąś informacją. Jeśli informacja nie jest godna uwagi, to tak naprawdę nie jest to informacja:)

I like Jay Cincotta ' s interpretacja najlepsza-śledzenie wykonania kodu jest czymś bardzo przydatnym w pomocy technicznej, a umieszczanie instrukcji trace w kodzie powinno być zachęcane-szczególnie w połączeniu z dynamicznym mechanizmem filtrowania do rejestrowania wiadomości trace z określonych komponentów aplikacji. Jednak poziom debugowania dla mnie wskazuje, że wciąż jesteśmy w trakcie zastanawiania się, co się dzieje - widzę wyjście poziomu debugowania jako opcję Tylko dla rozwoju, a nie jako coś, co powinno się kiedykolwiek pojawić w dzienniku produkcji.

Istnieje jednak poziom logowania, który lubię widzieć w moich dziennikach błędów, gdy noszę kapelusz sysadmina, tak samo jak wsparcie techniczne, a nawet deweloper: OPER, dla komunikatów operacyjnych. Używam tego do rejestrowania znacznika czasu, rodzaju wywołanej operacji, podanych argumentów, ewentualnie (unikalnego) identyfikatora zadania i zakończenia zadania. Jest on używany, gdy np. samodzielne zadanie jest zwolniony, coś, co jest prawdziwe wywołanie z wewnątrz większej długo działającej aplikacji. To jest coś, co chcę zawsze zalogowany, 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żna go wyłączyć tylko przechodząc w tryb całkowicie cichy. I to znacznie więcej niż tylko dane dziennika informacyjnego - poziom dziennika często wykorzystywany do spamowania dzienników z drobnymi komunikatami operacyjnymi bez żadnej wartości historycznej.

W zależności od przypadku informacje te mogą być kierowane do osobnego dziennika wywołania lub mogą być uzyskane przez odfiltrowanie o dużym zapisie dziennika więcej informacji. Ale zawsze jest potrzebne, jako historyczne informacje, aby wiedzieć, co zostało zrobione - bez zejścia do poziomu audytu, inny całkowicie oddzielny poziom dziennika, który nie ma nic wspólnego z awariami lub działaniem systemu, tak naprawdę nie pasuje do powyższych poziomów (ponieważ potrzebuje własnego przełącznika sterowania, a nie klasyfikacji ważności) i który zdecydowanie potrzebuje własnego oddzielnego pliku dziennika.

Błąd jest czymś, co jest złe, zwyczajnie złe, nie da się go obejść, trzeba go naprawić.

Ostrzeżenie jest znakiem wzorca, który Może być zły, ale wtedy też może nie być.

Powiedziawszy to, nie mogę wymyślić dobrego przykładu ostrzeżenia, które nie jest również błędem. Chodzi mi o to, że jeśli zadasz sobie trud logowania Ostrzeżenia, równie dobrze możesz naprawić podstawowy problem.

Jednak rzeczy takie jak "wykonanie sql trwa zbyt długo" mogą być uwaga, podczas gdy "blokady wykonania sql" to błąd, więc być może jednak są pewne przypadki.

Zawsze uważałem Ostrzeżenie za pierwszy poziom dziennika, który na pewno oznacza, że jest problem(na przykład, być może plik konfiguracyjny nie jest tam, gdzie powinien być i będziemy musieli uruchomić z ustawieniami domyślnymi). Błąd oznacza, dla mnie, coś, co oznacza, że główny cel oprogramowania jest teraz niemożliwy i zamierzamy spróbować zamknąć czysto.

From Ietf - Strona 10

Each message Priority also has a decimal Severity level indicator.

Są one opisane w poniższej tabeli wraz z ich numerycznymi wartości. Wartości dotkliwości muszą mieścić się 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

G ' Day,

Jako następstwo tego pytania, przekaż swoje interpretacje poziomów dziennika i upewnij się, że wszyscy ludzie w projekcie są wyrównani w ich interpretacji poziomów.

To bolesne widzieć ogromną różnorodność komunikatów dziennika, gdzie ciężkości i wybrane poziomy dziennika są niespójne.

Podaj przykłady, jeśli to możliwe, różnych poziomów logowania. I bądź konsekwentny w informacjach, aby być zalogowanym w wiadomości.

HTH

Zbudowałem już wcześniej systemy:

1. błąd-oznacza, że coś jest poważnie nie tak i ten konkretny wątek / proces/Sekwencja nie może kontynuować. Wymagana jest interwencja użytkownika/administratora
2. Ostrzeżenie-coś jest nie tak, ale proces może trwać tak jak wcześniej (np. jedno zadanie w zestawie 100 nie powiodło się, ale reszta może być przetworzona)

W systemach, które zbudowałem administratorzy mieli instrukcje reagowania na błędy. Z drugiej strony obserwuj ostrzeżenia i ustalaj dla każdego przypadku, czy jakiś system się zmienia, rekonfiguracje itp. były wymagane.

Btw, jestem wielkim fanem przechwytywania wszystkiego i filtrowania informacji później.

Co by się stało, gdybyś nagrywał na poziomie ostrzeżenia i potrzebował informacji o debugowaniu powiązanym z ostrzeżeniem, ale nie był w stanie odtworzyć Ostrzeżenia?

Przechwyć Wszystko i filtruj później!

Dotyczy to nawet oprogramowania wbudowanego, chyba że okaże się, że Twój procesor nie nadąża, w takim przypadku możesz chcieć przeprojektować śledzenie, aby było bardziej wydajne, lub śledzenie zakłóca czas (możesz } rozważyć debugowanie na mocniejszym procesorze, ale to otwiera całą puszkę robaków).

Przechwyć Wszystko i filtruj później!!

(btw, capture everything jest również dobry, ponieważ pozwala rozwijać narzędzia, aby zrobić więcej niż tylko pokazać ślad debugowania (rysuję wykresy sekwencji wiadomości z mojego i histogramy zużycia pamięci. Daje również podstawę do porównania, jeśli coś pójdzie nie tak w przyszłości (zachować wszystkie dzienniki, czy pass lub fail, i pamiętaj, aby uwzględnić numer kompilacji w pliku dziennika)).

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

Wszystko, co mogę dodać, to to, że te poziomy generalnie odpowiadają ich słownikowym definicjom, więc nie może to być takie trudne. W razie wątpliwości traktuj to jak zagadkę. Dla Twojego konkretnego projektu, pomyśl o wszystkim, co możesz chcieć zarejestrować.

Teraz, możesz dowiedzieć się, co może być śmiertelne? Wiesz, co znaczy fatale, prawda? Więc, które pozycje na twojej liście są fatalne.

Ok, to jest fatalne z, teraz spójrzmy na błędy ... spłukać i powtórzyć.

Poniżej Fatal, a może błąd, sugerowałbym, że więcej informacji jest zawsze lepsze niż mniej, więc błądzić "w górę". Nie jesteś pewien, czy to informacja czy Ostrzeżenie? Więc niech to będzie ostrzeżenie.

Myślę, że Fatal i błąd powinny być jasne dla nas wszystkich. Inne mogą być bardziej fuzzier, ale jest prawdopodobnie mniej istotne, aby je dobrze.

Oto kilka przykładów:

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

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

Debug - zrzut wewnętrznej struktury danych, dowolnego poziomu śledzenia z nazwą pliku numer & linii.
Trace-action successed / failed, D / B updated.