Существует ли устойчивая java.util.logging реализация обработчика системного журнала?
Я изучаю присоединение стороннее JAVA-приложение к нашему решению для агрегирования/анализа журнала (вероятно, Splunk, мы еще не завершили наш выбор хотя). Это, кажется, является самым легким сцепить агент Splunk с системным журналом, таким образом, я ищу способ перенаправить журналы приложения локальному демону системного журнала на сервере.
JAVA-приложение использует java.util.logging, который, к сожалению, не показывает обработчик системных журналов из поля (я полагаю, что log4j делает, хотя). Там кто-либо - доказанные библиотеки, чтобы сделать это? Загрузка журнала не огромна (вероятно, 10-20 сообщений в минуту от каждого процесса, до 6 процессов на хост), но я обеспокоен надежностью и длительностью (например, что происходит, когда демон снижается?...).
Любая справка ценилась бы...
1 ответ
SLF4J имеет мост для передачи событий java.util.logging в SLF4J (и, следовательно, в log4j или logback), который вы можете использовать. У этого есть затраты на производительность (см. Ссылку), но с учетом вашей нагрузки это не должно иметь большого значения. Таким образом, вы можете затем использовать Log4J SyslogAppender (или, лучше, его преемник, logback , который также имеет SyslogAppender ). У меня нет опыта работы с этим приложением (так что это может потребовать некоторого тестирования), но логбэк определенно является надежной библиотекой, и я знаю, что его можно настроить так, чтобы не печатать трассировки стека с помощью преобразования «nopexception» или «nopex» word (в случае, если отправка сообщений при неработающем демоне вызовет какое-то исключение). Связывание этого приложения с другим (например, файловым) позволит не потерять ни одного сообщения.