Есть ли надежная реализация обработчика java.util.logging системного журнала?

Question

Я собираюсь подключить стороннее Java-приложение к нашему решению для агрегации / анализа журналов (вероятно, Splunk, хотя мы еще не завершили наш выбор). Кажется, проще всего подключить агент Splunk к системному журналу, поэтому я ищу способ перенаправить журналы приложений на локальный демон системного журнала на сервере.

Java-приложение использует java.util.logging, который, к сожалению, не имеет встроенного обработчика системного журнала (хотя я считаю, что log4j поддерживает). Есть ли проверенные библиотеки для этого? Загрузка журнала невелика (вероятно, 10-20 сообщений в минуту от каждого процесса, до 6 процессов на хост), но меня беспокоит надежность и долговечность (например, что происходит, когда демон отключен? ...)

Любая помощь будет оценена ...

Answer 1

SLF4J имеет мост для передачи java.util.logging событий в SLF4J (и, следовательно, в log4j или logback), которые вы можете использовать. Это снижает производительность (см. Ссылку), но, учитывая вашу нагрузку, это не должно иметь большого значения. Таким образом, вы можете использовать Log4J SyslogAppender (или лучше его преемника, logback , который также имеет SyslogAppender). У меня нет опыта работы с этим приложением (так что для этого может потребоваться некоторое тестирование), но logback - это, безусловно, надежная библиотека, и я знаю, что ее можно настроить так, чтобы она не печатала следы стека с использованием преобразования «nopexception» или «nopex» слово (в случае отправки сообщений, когда демон выключен, возникнет какое-то исключение). Сопряжение этого приложения с другим (например, на основе файлов) позволит не потерять ни одного сообщения.

Answer 2

В нашем проекте также используется механизм java.util.Logging, поэтому, потратив некоторое время на поиск готовой реализации Handler для протокола syslog, я в итоге прочитал RFC 3164 и создал собственную реализацию http://code.google.com/p/agafua-syslog/

Мы используем его в производстве, как с UDP, так и с TCP. В нашем случае поток сообщений журнала составляет приблизительно 1-2 мсг в секунду, поэтому я думаю, что он, вероятно, применим для ваших нужд.