Jaki jest najlepszy sposób zarządzania rejestrowaniem błędów dla wyjątków?

Wprowadzenie

Jeśli błąd wystąpi w witrynie internetowej lub systemie, warto go oczywiście zarejestrować i wyświetlić użytkownikowi uprzejmy komunikat z kodem referencyjnym błędu.

A jeśli masz wiele systemów, nie chcesz, aby te informacje były rozsypane - dobrze jest mieć jedno scentralizowane miejsce dla nich.

Na najprostszym poziomie wszystko, czego potrzeba, to rosnący identyfikator i zserializowany zrzut szczegółów błędu. (I być może „scentralizowane miejsce” to skrzynka odbiorcza e-mail.)

Na drugim końcu spektrum znajduje się być może w pełni znormalizowana baza danych, która umożliwia także naciśnięcie przycisku i wyświetlenie wykresu błędów na dzień lub określenie, jaki jest najczęstszy rodzaj błędu w systemie X, czy serwer A ma więcej baz danych błędy połączenia niż serwer B i tak dalej.

Odnoszę się tutaj do rejestrowania błędów / wyjątków na poziomie kodu przez zdalny system - a nie śledzenia problemów „na podstawie człowieka”, takich jak Jira, Trac itp.

pytania

Szukam uwag od programistów, którzy korzystali z tego typu systemu, w szczególności na temat:

• Jakie są podstawowe funkcje, bez których nie można się obejść?
• Jakie zalety mają funkcje, które naprawdę oszczędzają Twój czas?
• Jakie funkcje mogą wydawać się dobrym pomysłem, ale w rzeczywistości nie są tak przydatne?

Na przykład powiedziałbym, że funkcja „pokaż duplikaty”, która identyfikuje wielokrotne wystąpienie błędu (nie martwiąc się o „nieistotne” szczegóły, które mogą się różnić) jest bardzo istotna.
Przycisk „stwórz problem w [Jira / etc] dla tego błędu” brzmi jak dobra oszczędność czasu.

Chciałbym tylko powtórzyć, to, czego szukam, to praktyczne doświadczenia ludzi, którzy korzystali z takich systemów, najlepiej poparte tym, dlaczego funkcja jest niesamowita / okropna.
(Jeśli mimo to zamierzasz teoretykować, przynajmniej zaznacz swoją odpowiedź jako taką).

Byłem w projekcie, w którym zarejestrowałem błędy klienta przy użyciu biblioteki Microsoft Enterprise . Wszystkie wyjątki są wysyłane na naszą skrzynkę pocztową. W temacie wiadomości dodaliśmy kod skrótu z serializowanym błędem, aby uniknąć powielania wiadomości. Oczywiście można przechowywać serializowane wiadomości w bazie danych i tak dalej.

Polecam sprawdzić bibliotekę Microsoft Enterprise i Log4Net .

Niektóre funkcje Log4Net

• Obsługa wielu platform
• Dane wyjściowe do wielu celów rejestrowania
• Hierarchiczna architektura rejestrowania
• Konfiguracja XML
• Konfiguracja dynamiczna
• Kontekst rejestrowania
• Sprawdzona architektura
• Modułowa i rozszerzalna konstrukcja • Wysoka wydajność i elastyczność

W przypadku aplikacji bazodanowych <TABLE>:<PrimaryKeyID>istnieje pewien rodzaj identyfikatora (podobny ), który umożliwia śledzenie rekordów w bazie danych związanych z zakresem, w którym wychwycono wyjątek.

Zrobiłem to z Oracle i PL / SQL, rejestrując identyfikator w tabeli bazy danych w aplikacji, z modułu obsługi wyjątków.

Jak zauważył Amir Rezaei, wiele z tego, co opisujesz (tj. Części do logowania) jest zaimplementowanych w bibliotece przedsiębiorstwa. Wszystko inne wydaje się być bardziej częścią analityczną (tj. Co zrobić z logami później).

W moim przypadku stworzyłem małe aplikacje i skrypty SQL, które ułatwiły niektóre rzeczy. Oto niektóre rzeczy, które naprawdę mi się podobały:

• Grupowanie razem tych samych błędów (tj. 100 użytkowników, którzy doświadczyli tego samego błędu w tym samym czasie, to 1 raport o błędzie z notatką o liczbie wystąpień)
• Automatyczne składanie zgłoszenia w module śledzącym sprawy (nigdy nie udało się tego zrobić „jednym kliknięciem”, ale zawsze chciał)
• Nazwa użytkownika użytkownika oprogramowania (nie tylko maszyny, która jest dostępna w większości rejestratorów). W niektórych przypadkach zautomatyzowane konta użytkowników powodowały problemy, podczas gdy w innych przyczyną byli konkretni użytkownicy. „Muszę patrzeć, jak Mike wykonuje jakąś pracę, ciągle powoduje określony błąd”.
• „Akcje użytkownika” - miałem globalny stos, który przechowywałby ślad każdego kliknięcia przycisku / akcji, które wykonał użytkownik, i zrobił to w dziennikach błędów. Powtórzenie błędu często było przejściem tego śladu i wykonaniem tych samych kroków, co użytkownik (miałem nadzieję zbudować generator testowy CodedUI, który analizowałby ślad i wykonywał kroki automatycznie, ale nigdy tego nie zrobił)

Czasami informacje dziennika są zbyt obszerne, aby można je było zapisać na dysku. Jednym z podejść, jakie widziałem, jest zapisywanie wpisów do dziennika w węży ogniowej (np. Perl) mniej więcej tak:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

wtedy analityk może określić, na co chce spojrzeć.

Oto kilka rzeczy, których nauczyłem się z monitorowania błędów w naszych aplikacjach:

• Możliwość ogonienia kroczącego pliku dziennika (zazwyczaj używam log4net / log4j do logowania w aplikacjach i BareTail do śledzenia dziennika) jest naprawdę przydatna, aby móc sprawdzić bieżącą kondycję systemu
• Aby zobaczyć, kiedy pojawiły się problemy i częstotliwość ich występowania, dobrze jest mieć je w bazie danych ze znacznikami czasu, aby można było uruchamiać raporty.
• Możliwość wysyłania powiadomień e-mail / sms / głosowych jest bardzo pomocna w upewnianiu się, że systemy działają, ale musisz mieć możliwość łatwego dostosowywania rodzajów błędów, które Cię ostrzegają. Jeśli otrzymujesz 800 e-maili o błędach dziennie, z pewnością przegapisz wiadomość „O nie, centrum danych jest w ogniu”.

Mam świetne wyniki dla log4net, ponieważ sprawia, że ​​naprawdę łatwo logować się do wielu miejsc i łatwo wprowadzać zmiany w konfiguracji rejestrowania.

elmah to system rejestrowania błędów open source dla aplikacji ASP.NET i można go szybko i łatwo dodać do istniejącego systemu (za pomocą NuGet http://nuget.codeplex.com/ ). Obsługuje różne funkcje backendów i powiadomień.

Nie znam nikogo, kto dodałby ją do aplikacji komputerowej, ponieważ działa ona jako witryna internetowa, ale nic nie stoi na przeszkodzie, abyś uruchomił ją jako usługę i opublikował wyjątki w Internecie.

http://code.google.com/p/elmah/

ELMAH (moduły rejestrowania błędów i moduły obsługi) to narzędzie do rejestrowania błędów w całej aplikacji, które można całkowicie podłączyć. Można go dynamicznie dodawać do działającej aplikacji internetowej ASP.NET, a nawet wszystkich aplikacji internetowych ASP.NET na komputerze, bez potrzeby ponownej kompilacji lub ponownego wdrożenia.

Po upuszczeniu ELMAH do działającej aplikacji internetowej i odpowiedniej konfiguracji uzyskasz następujące ułatwienia bez zmiany jednego wiersza kodu:

• Rejestrowanie prawie wszystkich nieobsługiwanych wyjątków.
• Strona internetowa do zdalnego przeglądania całego dziennika przekodowanych wyjątków.
• Strona internetowa umożliwiająca zdalne wyświetlanie pełnych szczegółów każdego zarejestrowanego wyjątku, w tym śladów kolorowych stosów.
• W wielu przypadkach można przejrzeć oryginalny żółty ekran śmierci wygenerowany przez program ASP.NET dla danego wyjątku, nawet przy customErrorswyłączonym trybie.
• Powiadomienie e-mail o każdym błędzie w momencie jego wystąpienia.
• Kanał RSS ostatnich 15 błędów z dziennika ...