Monitorowanie błędów w aplikacji przy użyciu rejestrowania
Administratorzy systemu chcą, aby aplikacje oferowały jakąś formę rejestrowania, które ułatwia zarządzanie wydajnością aplikacji w środowisku produkcyjnym. Monitorowanie tych dzienników można zautomatyzować i ułatwić firmie identyfikację problemów dotyczących kondycji w obrębie zestawu jej aplikacji.
Rejestrowanie nie jest przydatne tylko wtedy, gdy aplikacja jest dostępna w środowisku produkcyjnym. Może ono również ułatwić programowanie. Większość języków, szczególnie C# i Java, ma dobrze zdefiniowane poziomy rejestrowania. Podjęto również próby standaryzacji rejestrowania z organizacji, takich jak Apache, które mają zewnętrzne biblioteki log4net i Log4j.
Poziomy rejestrowania
Istnieje wspólny zestaw poziomów rejestrowania, które języki implementują w pewnym stopniu. Poziomy grupowania to:
- Śledzenie lub najlepsze: ten poziom reprezentuje najniższy poziom informacji używany podczas rozwiązywania problemów z aplikacją. Tego poziomu nie należy używać w środowisku produkcyjnym, ponieważ dane osobowe mogłyby zostać uwzględnione w danych wyjściowych.
- Debugowanie: ten poziom jest zwykle używany podczas aktywnego programowania. Te komunikaty dziennika nie mają długoterminowej wartości i nie muszą być przechowywane po zakończeniu opracowywania.
- Informacje: można dołączyć, aby wyświetlić kondycję aplikacji.
- Ostrzeżenie: Te komunikaty są używane do pokazywania nietypowych i nieoczekiwanych przepływów w aplikacji. Wykonywanie aplikacji jest kontynuowane.
- Błąd lub krytyczne: jeśli aplikacja musi zamknąć lub uruchomić ją ponownie z powodu błędu, powinna ona zapisać te informacje w dzienniku. Poważne błędy, które wymagają natychmiastowej uwagi, powinny być zgłaszane jako krytyczne.
Ze względu na charakter błędów przejściowych aplikacja powinna rejestrować komunikaty o takich błędach na poziomie ostrzeżenia. Ten poziom można monitorować i jeśli błędy będą nadal występować, zespół może dokładniej zbadać problem.
Rejestrowanie informacji
Podczas pisania komunikatu dziennika warto zadać sobie następujące pytania: kto, co, dlaczego, gdzie i kiedy. Odpowiedzi na te pytania powinny ułatwić badanie i usuwanie błędów.
- Kto używał aplikacji? Błąd może być związany z uszkodzonymi danymi użytkownika, więc widzi je tylko kilka osób.
- Co robiła aplikacja? Ta informacja ułatwia osobom badającym błąd zawężenie wyszukiwania do stanu aplikacji w momencie, gdy wystąpił problem.
- Dlaczego wystąpił błąd? Zarejestruj wszelkie kody błędów lub inne informacje, które mogą pomóc w diagnostyce.
- W którym miejscu kodu wystąpił błąd? Lokalizacja w bazie kodu powiązana z napotkanym błędem może pomóc zawęzić badanie problemu.
- Kiedy to się stało? Informacje dotyczące czasu można skorelować z informacjami o czasie, gdy inne usługi nie działały.
Dobre rejestrowanie ma zdefiniowaną strukturę. Struktura może pozwolić na przyszłe indeksowanie i logistykę. W przypadku błędów przejściowych istnieją dwa dodatkowe typy przydatnych informacji:
- Czas odzyskiwania sprawności po błędzie
- Liczba ponownych prób przed rozwiązaniem problemu
Przechwytywanie tych informacji dla błędów przejściowych może wskazywać na występujące wzorce. Czy błąd jest zawsze usuwany po pierwszej próbie? Czy występuje problem z chronometrażem, a błąd zostanie rozwiązany po 1 minucie? Rozwiązaniem może być dodanie okresu oczekiwania, aby zmniejszyć prawdopodobieństwo wystąpienia błędu w pierwszej kolejności.
Dodanie rejestrowania do aplikacji czatu firmy umożliwia zarządzanie wydajnością w środowisku produkcyjnym.