Jaki jest sens zdalnych zdarzeń dla przeglądarki loga pilarki łańcuchowej?

Question

http://logging.apache.org/chainsaw/quicktour.html

Pierwsza funkcja.

Ukończyłem samouczek, po prostu pokazał, jak wizualnie korzystać z GUI, w ogóle nie wdawał się w szczegóły dotyczące tej nowej funkcji. Najlepszym dokumentacji znalazłem to:

Podobnie jak Appenders wysłać rejestrowanie zdarzeń spoza środowiska log4j (do plików, SMTP, do gniazd itp), Odbiorniki przynieść rejestrowanie zdarzeń wewnątrz środowiska log4j.

Odbiorniki służą do obsługi zdalnego rejestrowania zdarzeń z innego procesu. Na przykład SocketAppender "dołącza" zdarzenie rejestrowania do gniazda skonfigurowanego pod kątem określonego hosta i numeru portu. Po stronie odbiorczej gniazda może znajdować się obiekt SocketReceiver. Obiekt SocketReceiver odbiera zdarzenie rejestrowania, a następnie "publikuje" je do środowiska log4j (LoggerRepository) na komputerze odbierającym, do obsługi przez skonfigurowanych dostawców itd. Różne ustawienia w tym środowisku (poziomy rejestratora, progi Appender filtrów &) są stosowane do odebranego zdarzenia rejestrowania.

Odbiorniki mogą być również używane do "importowania" komunikatów dziennika z innych pakietów rejestrowania do środowiska log4j.

Odbiorniki można skonfigurować do wysyłania zdarzeń do danego LoggerRepository.

Więc ...

Jaką strategię rejestrowania mogę osiągnąć za pomocą tego nowego komponentu, że nie mogę korzystać tylko z użyciem piły łańcuchowe + proste appenders plików log4j?

Answer 1

Jest ich wiele interesujących rzeczy, które można wykonać zdalnymi zdarzeniami:
- Unikaj tworzenia plików na serwerach aplikacji. Pliki są złe.
- Centralizacja dzienników w przypadku wielu serwerów aplikacji.
- Wyświetl dzienniki produkcji na żywo ze swojego lokalnego środowiska, nawet jeśli piła łańcuchowa nie jest bardzo sexy, możliwości filtrowania są bardziej przydatne niż zwykły vi/grep.
- Zaloguj się do bazy danych zamiast plików. Pliki są złe.

I prawdopodobnie o wiele więcej!

Answer 2

Używałem zdalnych zdarzeń w przeszłości ze środowiskiem siatki.

Dlaczego? Ponieważ nie wiedzieliśmy, gdzie będzie działał nasz kod. Wdrażalibyśmy zadania "n", a infrastruktura sieci wybierałaby te maszyny, które będą je uruchamiać. Bez zdalnych zdarzeń musielibyśmy śledzić miejsca, w których te prace się udały, a następnie mieć kłopoty z zalogowaniem, znalezieniem dzienników itp. Ponieważ sieć składała się z maszyn używanych do innych celów, nie mogliśmy zagwarantować, że maszyny pojawi się w późniejszym terminie w celu zdiagnozowania problemów.

Tak więc wszystko zostało skonfigurowane, aby przesyłać zdarzenia dziennika z powrotem na serwer, na którym mogliśmy tworzyć pliki dziennika na serwer inicjujący i zarządzać nimi samodzielnie. Występują problemy, takie jak zarządzanie ilością danych przesyłanych strumieniowo przez sieć do jednego serwera, ale dopóki jesteś tego świadomy, to jest w porządku.