Jak obsługiwać awarie rejestratora?

12

W kilku aplikacjach naszej firmy korzystamy z niestandardowego rejestratora. Jest dość solidny, choć w przyszłości możemy go zastąpić czymś takim jak NLog. Jednym z zadań rejestratora jest rejestrowanie wyjątków napotkanych w aplikacji.

Jedną z moich obaw było to, że obsługa wyjątków w programie rejestrującym pozwala na cichą awarię. To znaczy, jeśli dziennik nie jest zapisany dla danego wyjątku (z powodu błędu w rejestratorze), jak mam go obsłużyć i (jakoś) zarejestrować wyjątek w samym rejestratorze ?

Powiedzmy, że funkcja WriteLog zgłasza wyjątek. Czy powinienem próbować wywoływać tę funkcję kilka razy, czy dopóki wyjątek nie zostanie zgłoszony? Czy powinienem spróbować zapisać zgłoszony wyjątek za pomocą programu rejestrującego (co prawdopodobnie doprowadziłoby do wyjątków od samego początku ...)? Miałem szczęście, że nie spotkałem się z tą sytuacją, z wyjątkiem pierwszego wdrożenia niestandardowego programu rejestrującego. Z drugiej strony nie mam obecnie możliwości dowiedzieć się, czy program rejestrujący nie zarejestrował wyjątków aplikacji (z powodu własnych wyjątków).

Próbowałem wyszukiwać online i na niektórych stronach SE, ale do tej pory było to bezowocne, ponieważ wszystkie posty dotyczą błędów w rejestratorze (ale nie potencjalnych wyjątków i sposobu ich rejestrowania) lub wyjątków poza rejestratorem.

— Zairja
źródło

2

„Powinieneś być defensywny, ale do pewnego stopnia ...”

— komara

5

Zaloguj się, stderrże Twój nośnik wyjściowy zawiódł lub że stało się „niemożliwe”.

— Doval,

1

Wyślij wiadomość e-mail do programistów lub po prostu wyświetl błąd z adresem e-mail i pozwól użytkownikowi skopiować i wkleić błąd.

— Chloe,

17

W przypadku napotkania wyjątków w samym rejestratorze nie należy używać rejestratora do rejestrowania własnych wyjątków. Powodem tego jest to, że:

Możesz utknąć w nieskończonej pętli. Wyobraź sobie, że w twoim loggerze masz gałąź warunkową, która nie została przetestowana (i generuje wyjątek). Wyobraź sobie, że po spełnieniu warunku, każdy kolejny zgłoszony wyjątek jest obsługiwany przez ten sam oddział. Oznacza to, że od momentu wykonania gałęzi jesteś w nieskończonej pętli.
Możesz utknąć w tymczasowej pętli, generując tysiące wyjątków na sekundę. Wyobraź sobie, że zgłaszasz wyjątki na zdalnym serwerze. Problem z serwerem powoduje kolejny wyjątek, który powoduje kolejny itd., Dopóki połączenie nie zostanie przywrócone.

Zamiast tego powinieneś wrócić do bezpieczniejszego sposobu rejestrowania wyjątków. Na przykład, jeśli program rejestrujący wysyła wyjątki do zdalnego serwera, syslogzamiast tego wyślij wyjątki w programie rejestrującym . Jeśli program rejestrujący rejestruje wyjątki w zdarzeniach systemu Windows, a to działanie kończy się niepowodzeniem, zapisz wyjątek niepowodzenia w prostym pliku tekstowym.

Gdy już to zrobisz, następne pytanie brzmi: skąd wiesz, że wystąpiły te wyjątki: jeśli masz dziesiątki aplikacji działających na tysiącach serwerów, nie możesz SSH każdej z nich regularnie, aby sprawdzić, czy logują się one lokalnie .

Jednym ze sposobów jest posiadanie zadania cron, które sprawdza te „wyjątkowe dzienniki” i wypycha je do miejsca, w którym przechowywane są inne wyjątki (ewentualnie przy użyciu rejestratora, ale uważaj na nieskończone lub tymczasowe pętle!).

— Arseni Mourzenko
źródło

Napotkałem ten sam problem z moim rejestratorem wyjątków, który trafił na e-mail. Jeśli nie udało się połączyć z serwerem, wpadł w straszną nieskończoną pętlę. Zamiast tego zaznaczam pole wyboru, aby przekierować do dziennika zdarzeń i zapobiec wysyłaniu nowych wiadomości e-mail, dopóki nie będzie można nawiązać nowego połączenia.

— mgw854,

Myślę, że postaramy się wdrożyć awarię, jak sugerujesz. Sugestia Jona Raynora, aby zatrzymać aplikację (w krytycznej sytuacji logowania), jest jedną z tych, które możemy realizować, których nie rozważaliśmy.

— Zairja,

Co się stanie, jeśli skończy się limit czasu wysyłania do syslog lub błędów we / wy podczas zapisywania do pliku? Problem może się jeszcze pogłębiać, jeśli awarie są spowodowane przeciążeniem sieci lub brakiem miejsca na dysku. To nie jest dokładnie holistyczne rozwiązanie; należy wziąć pod uwagę możliwość, że nie będzie żadnego bezpiecznego sposobu rejestrowania błędów. Logowanie do własnego rejestratora nie jest tak niebezpieczne, o ile obejmuje się wykrywanie cyklu, wykładnicze wycofanie itp.

— Aaronaught,

11

Jeśli rejestrowanie ma krytyczne znaczenie dla aplikacji, należy zatrzymać aplikację, jeśli rejestracja się nie powiedzie.

Jeśli nie jest to krytyczne, to będąc nieco defensywnym, można mieć dodatkowy komponent do obsługi błędów rejestrowania, które rejestrują / alarmują do dodatkowego źródła. Ale nawet to nie jest głupi dowód i będziesz musiał rozważyć, co się stanie, jeśli drugi rejestrator zawiedzie podczas monitorowania głównego rejestratora.

Dobrą strategią jest logowanie do pliku lokalnego, a jeśli to się nie powiedzie, być może rejestrowanie tego niepowodzenia w dzienniku zdarzeń, generowanie powiadomienia e-mail, zapisywanie w bazie danych itp. Przy dostępnych ramach rejestrowania powinno to być niezawodne, chyba że maszyna uruchomi się brak miejsca na dysku lub inny rzadki stan.

Najlepiej byłoby, gdybyś po cichu zawiódł, ponieważ spowoduje to, że aplikacja będzie mniej złożona.

Co ważniejsze, w celu obsługi błędów rejestrowania należy monitorować dzienniki od strony trzeciej. Z czasem powinieneś być w stanie rozpoznać, ile zdarzeń rejestruje zdrowa aplikacja. Jeśli zacznie rejestrować niski poziom lub nie będzie żadnych zdarzeń, wówczas poprzez monitorowanie możesz zobaczyć występujący problem i potencjalnie zaalarmować przez ten mechanizm innej firmy.

— Jon Raynor
źródło

1

+1 za dokonanie rozróżnienia między rejestrowaniem krytycznym i niekrytycznym, a także zwrócenie uwagi na znaczenie liczby logów w określonym czasie. Jestem rozczarowany, że nie myślałem o tych dwóch aspektach, od lat używam rejestrowania awaryjnego.

— Arseni Mourzenko,