Co powinienem się zalogować w aplikacji produkcyjnej

Question

Rozpoczynam nowy projekt i zastanawiam się, jakie rzeczy powinienem rejestrować. Plik logu jest przeznaczony tylko do tego, aby pomóc programistom znaleźć błędy. Przypadek użycia jest taki, że po zgłoszeniu nieobsługiwanego wyjątku wysyłane jest powiadomienie do programisty, który ma dostęp do pliku logu i stosu.

Co należy uwzględnić w pliku dziennika? Logowanie wszystkiego nie zadziała. Wiem, że trudno powiedzieć, ponieważ odpowiedź prawdopodobnie wymaga głębokiej wiedzy o systemie. Sądzę więc, że naprawdę pytam o "najlepsze praktyki". Podaj konkretne przykłady.

Czy zależy to od rodzaju aplikacji, np. Aplikacji klienckiej, serwera pulpitu lub serwera WWW?

Answer 1

W ogólnym

• Jeśli zalogujesz wartości DateTime (nie mówiąc o pól nagłówka datownika ram rejestrowania) upewnij się, że ich zalogować sensownego formatu. "ToString()" zwykle nie jest wystarczające, jeśli potrzebujesz informacji na temat Local vs. Utc lub około milisekund (ja używam "yyyy-MM-dd HH: mm: ss.fff zzz", YMMV)
• Jeśli logujesz się wyjątków, przejdź do "ToString()", a nie cokolwiek innego. Kontrowersyjny być może, ale z różnych powodów wyglądają na here.

Informacje o senstive lub szczegółowe informacje, o których inni już mówili, trzeba uważać. Nie chodzi tylko o ludzi, którzy są uprawnieni do odczytywania twoich dzienników produkcji, uzyskując więcej informacji niż to konieczne, pomyśl też o tym, że jakikolwiek intruz do systemu może uzyskać cenne informacje dla zbyt obszernych dzienników (dlatego nie rejestrowałbym zestawu uprawnień użytkowników z błędem, który nie ma konkretnego, zostało zasugerowane w innej odpowiedzi).

Może to zależeć od środowiska lub klienta, co jest uważane za poufne, ale przykłady są następujące: - Rzeczywiste wprowadzanie danych przez użytkownika w komunikatach o błędach. - Zestawy uprawnień użytkownika itp. - SQL, szczególnie z rzeczywistymi parametrami - Zapytanie XML/struktur reagowania

znalezienie odpowiedniego szczegółowość informacji do dziennika jest zawsze kompromis pomiędzy ilością rejestrowanych informacji, wydajność kosztuje nie tylko pisać, ale również do wytwarzają te informacje w kodzie i senstyczność tych informacji. I to jest powód, dla każdego poważnego systemu logowania sport "poziomy" lub "kategorie".

Można rejestrować potencjalnie uciążliwe informacje na "poziomie" lub "kategorii", które można włączyć w fazie rozwoju, ale wyłączyć w produkcji. Jeśli naprawdę chcesz przejść za burtę, możesz napisać wpis EventLog, gdy twoja aplikacja wykryje, że takie rejestrowanie jest włączone, więc nie "prześlizguje się" w trakcie produkcji.

Wreszcie, należy rozważyć zastosowanie struktury rejestrowania, która umożliwia zmianę poziomów lub kategorii podczas wykonywania. W ten sposób możesz włączyć więcej informacji w razie potrzeby, w kontrolowany sposób, bez zakłócania pracy aplikacji lub resetowania sytuacji, którą chcesz sprawdzić przez konieczność ponownego uruchomienia aplikacji.

Answer 2

Pierwsza zasada to "Nie rejestruj wrażliwych informacji!". Na przykład: numer ubezpieczenia społecznego, numery kart kredytowych, hasła itp. Nie wiesz, kto może uzyskać uprawnienia, aby go zobaczyć, a to może spowodować pewne problemy prawne.

Przydatny jest dziennik komunikacji z komponentami stron trzecich (na przykład usługi internetowe lub ...). Będziesz w stanie dostarczyć użytecznych informacji do dostawcy zewnętrznego lub do ciebie, jeśli wystąpi problem.

Bardzo przydatne jest śledzenie działań podejmowanych przez użytkowników ... przechodzenie do określonej strony ... wykonywanie różnych czynności. Jeśli więc klient dzwoni do ciebie przez telefon i mówi, że coś jest nie tak z twoim produktem - możesz sprawdzić, co teraz robi.

W naszej firmie powszechną praktyką jest śledzenie, ile zajmuje wykonanie zapytania do bazy danych. W ten sposób można czasem zidentyfikować wąskie gardła lub zidentyfikować pewne problemy z systemem (serwer aplikacji lub serwer bazy danych).

Możesz śledzić także niektóre próby złamania ataków systemu DOS, brutalnych botów ... i tak dalej.

Nadzieję, że pomaga!

Answer 3

Zobacz dokumentację podobną do nLog. Dadzą ci kilka pomysłów na temat tego, co powinieneś rejestrować i jak można to kontrolować.

Answer 4

Zapisz nazwę metody, która zwróciła wyjątek i wszelkie parametry, których używał (tj. Stan). Zaloguj się do ID użytkownika i jego uprawnień. W scenariuszu z siecią zarejestruj adres IP i nagłówki.

Answer 5

Rejestrowanie sprawia, że ​​kod jest dłuższy i mniej wyraźny. Bądź więc leniwy, nie rejestruj niczego, dopóki go nie potrzebujesz.

Może być dobrym pomysłem, aby wysyłać wiadomości e-mail z nieobsługiwanymi wyjątkami bezpośrednio do programistów i nie rejestrować niczego w ogóle.

Answer 6

Logowanie jest twoim Zbawicielem, jeśli chodzi o sytuację "wszystko, co się piekło rozpadło" w produkcji. Jak już powiedziałeś, wymaga to większej wiedzy na temat aplikacji, ale w przypadku wszystkich powinno się myśleć o kilku rzeczach.

1. Rejestruj wszystkie wyjątki i błędy. Nic nie powinno uciec.
2. Rozważ logowanie użytkownika i wylogowanie. To dobra informacja, aby monitorować swoją aplikację pod kątem złośliwych ataków i innych rzeczy.
3. Możesz głupio nie rejestrować każdej metody, ale jeśli system jest zaprojektowany prawidłowo i jeśli masz jeden punkt wejścia dla komunikacji między n warstwami, możesz zarejestrować tę metodę. tj. Zapisz, usuń, zaktualizuj metody itp.
4. Zapewnij również rejestrowanie wewnątrz , jeśli # kod debugowania, aby można było włączyć debugowanie w procesie produkcyjnym i w razie potrzeby wygenerować więcej rejestrowania. Jest to bardzo pomocne szczególnie podczas pracy w środowisku deweloperskim i debugowania bazy danych produkcji.

Answer 7

Mam dwa oddzielne środowiska, w których wymagania dotyczące rejestrowania są całkowicie różne.

1. aplikacji pakietu Office

Tu wyjątki, wspólne rzeczy jak zalogowania się zalogować, aplikacja rozpocznie etc plus edycja/usuwanie/wstawianie obiektów. Wystarczająco dużo, aby sprawdzić, co się stało, gdy sprawy się rozkwitają. Logujemy się na tyle, aby móc odtworzyć sprawę. W naszym przypadku dziennik może rosnąć bez ograniczeń, więc możemy sprawdzić, czy nie ma problemów z powrotem.

2. Aplikacja przemysłowa.

Tutaj rejestrujemy prawie wszystko plus zlew kuchenny. To jest softeare, które musi działać 24 godziny na dobę, więc nawet proste ostrzeżenie może być oznaką nadchodzącej katastrofy. Przykładem jest to, że mieliśmy pewne dziwne limity czasu i nie musieliśmy pokonywać wymagań dotyczących czasu. W końcu plik dziennika dał nam informację: zapisanie pliku tekstowego o wielkości kilku bajtów zajęło czasami więcej niż 5 sekund. Zwykle problemy, które się pojawiają, to rzeczy, o których w ogóle nie myśleliście, więc rejestracja, logowanie, rejestracja to to, co powinieneś zrobić! Logi są automatycznie czyszczone po kilku dniach.

To, co zrobiliśmy, to implementacja protokołu, który użytkownik końcowy może ustawić: jeśli ustawimy go na verbose, zapisujemy wszystkie rejestracje, jeśli ustawione na błędy minimalne tylko przechodzą. SO po kilku tygodniach stabilnego biegu powoli zmniejszamy poziom logu do minimum i zatrzymujemy się tam, z którym jesteśmy zadowoleni.

Powiedziałbym: To zależy od twojej aplikacji.