В чем смысл удаленных событий для зрителя цепной пилы log4j?

Question

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

Первая функция.

Я закончил урок, он просто показал, как визуально использовать графический интерфейс, он совсем не вдавался в подробности относительно этой новой функции. Лучшая документация, которую я нашел, это:

Так же, как Appenders отправляют события журналирования вне среды log4j (в файлы, в smtp, в сокеты и т. Д.), Receivers переносит события журналирования в среду log4j.

Получатели предназначены для поддержки получения событий удаленной регистрации от другого процесса. Например, SocketAppender «добавляет» событие регистрации в сокет, настроенный для определенного хоста и номера порта. На принимающей стороне сокета может находиться объект SocketReceiver. Объект SocketReceiver получает событие регистрации и затем «отправляет» его в среду log4j (LoggerRepository) на принимающем компьютере для обработки настроенными приложениями и т. Д. Различные параметры в этой среде (уровни Logger, фильтры и пороги Appender ) применяются к полученному событию регистрации.

Приемники также можно использовать для «импорта» сообщений журнала из других пакетов журналов в среду log4j.

Приемники можно настроить для публикации событий в заданном LoggerRepository.

Итак ...

Какую стратегию ведения журналов я могу достичь, используя этот новый компонент, который я не смог использовать, просто используя цепную пилу + простые файловые дополнения log4j?

Answer 1

Это много интересных вещей, которые вы можете сделать с удаленными событиями:
- Избегайте создания файлов на серверах приложений. Файлы плохие.
- Централизация журналов в случае нескольких серверов приложений.
- Просмотр журналов реального производства из вашей локальной среды, даже если бензопила не очень привлекательна, возможности фильтрации более удобны, чем обычный vi / grep.
- Вход в базу данных вместо файлов. Файлы плохие.

И, вероятно, намного больше!

Answer 2

В прошлом я использовал удаленные события с сеткой.

Почему? Потому что мы не знали, где будет выполняться наш код. Мы будем развертывать 'n' заданий, а сеточная инфраструктура будет выбирать, на каких машинах запускать эти задания. Без удаленных событий нам пришлось бы отслеживать, куда делись эти задания, а затем иметь трудности с входом, поиском журналов и т. Д. Поскольку сетка состояла из машин, используемых для других целей, мы не могли гарантировать, что машины будет позже для диагностики проблем.

Таким образом, все было настроено для потоковой передачи событий журнала обратно на сервер, где мы могли бы создавать файлы журналов для каждого исходного сервера и сами управлять этими журналами. Существуют такие проблемы, как управление количеством потоковой передачи данных по сети на один сервер, но если вам это известно, это нормально.