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

13

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ą).

Peter Boughton
źródło
2
Jedną rzecz do zapamiętania: jeśli coś logujesz, coś poszło nie tak i może być więcej niż jedna rzecz nie tak. Zachowaj czynności logowania po prostej stronie.
David Thornley,
logowanie na poziomie debugowania lub informacji niekoniecznie oznacza, że ​​coś jest nie tak. Może np. Zawierać informacje potrzebne do analizy poubojowej.
Widziałem rejestratory wyjątków, które same zgłaszają wyjątek na String.Format (C #) :). Zachowaj prostą rejestrację, najlepiej wolną od ryzyka, NIE dynamiczną (np. Nie analizuj pliku XML podczas próby zarejestrowania wyjątku). Jeśli to możliwe, unikaj dynamiki rejestrowania błędów. Jeśli masz coś skonfigurowanego w pliku xml, myślę, że lepiej jest wygenerować jakiś rzeczywisty kod na jego podstawie (ciągły), niż analizować ten plik konfiguracyjny w czasie wykonywania, gdy jesteś w trakcie zgłaszania błędu (dynamiczny ). To i tak było moje doświadczenie. Możesz chcieć mieć plan B do logowania - jeśli fantazyjne wyjście nie powiedzie się, zaloguj się prosto
Job

Odpowiedzi:

5

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ść
Amir Rezaei
źródło
1
dobry logger pozwoli ci popchnąć twoje błędy do trwałości twojego wyboru (e-mail, DB, plik itp.).
Ken Henderson
1

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.

Miguel Veloso
źródło
Zdecydowanie dobrze jest zarejestrować przynajmniej przetwarzaną tabelę i zapisy. Oczywiście jeszcze lepiej jest mieć próbę wykonania instrukcji SQL (i dowolnych parametrów).
Peter Boughton,
1

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ł)
Steven Evers
źródło
0

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

leed25d
źródło
3
Nie wiesz, co to jest „wąż ognia”? Biorąc pod uwagę pojemność dzisiejszych dysków, mam nadzieję, że błędy nie były tak częste, że rozmiar dziennika byłby problemem.
Peter Boughton,
0

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.

aubreyrhodes
źródło
0

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 ...
Bil Simser
źródło
ELMAH jest zawodny. Jeśli httpcontext ma wartość NULL ==> boom
Quandary
@Quandary Zastanawiam się, czy coś mi brakuje? Widzimy błąd podczas próby zalogowania się do ELMAH z aplikacji, a HttpContext ma wartość NULL, ale jeśli masz przechwytywanie na poziomie katalogu głównego -> utwórz nowy rejestrator Elmah z zerowym kontekstem i logiem, to działa dobrze. Czy w normalnej witrynie ASP.NET są miejsca, w których można by się zalogować, a HttpContext ma wartość NULL?
Ian Grainger