Централизованное ведение журнала Java

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

Сейчас ситуация такова, что несколько приложений Java -используют log4j, который записывает свои данные в локальные файлы, поэтому, если у клиента возникают проблемы, команде поддержки -приходится запрашивать журналы, что не всегда легко и занимает много времени. много времени. В случае сбоя сервера -проблема с диагностикой -не так велика, так как в любом случае есть удаленный -доступ, но даже несмотря на то, что мониторинг всего через сервер регистрации -по-прежнему создает много проблем. смысл.

Пока я просматривал вопросы, касающиеся «централизованного ведения журнала», я нашел еще один вопрос (. на самом деле единственный с (в данном случае )полезным ответом. Проблема в том, что все приложения работают в закрытой среде (внутри одной сети ), а правила безопасности -не разрешают никакому внутреннему программному обеспечению выходить за пределы сети среды.

Я также нашел замечательную статью о том, как можно реализовать такой сервер регистрации -. Поскольку статья была написана в 2001 году, я бы подумал, что кто-то, возможно, уже решил эту конкретную проблему. Но мои результаты поиска -ничего не дали.

Мой вопрос:Существует ли структура ведения журнала -, которая обрабатывает ведение журнала по сети с помощью централизованного сервера, к которому может получить доступ группа поддержки -?

Спецификация:

• Наличие
• Сервер должен быть запущен нами.
• Совместимость с Java 1.5
• Совместимость с гетерогенной сетью.
• Лучший -случай :Протокол использует HTTP для отправки журналов (, чтобы избежать проблем с брандмауэром -)
• Лучший -случай :Использует log4j или LogBack или вообще что-нибудь, что реализует slf4j

Не обязательно, но приятно иметь

• Аутентификация и безопасность, конечно, проблема, но их можно было бы отложить как минимум на некоторое время (, если это открытое -программное обеспечение, мы бы расширили его для наших нужд OT :мы всегда возвращаем проекты).
• Добыча и анализ данных — это то, что очень полезно для улучшения программного обеспечения, но это также может быть внешнее приложение.

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

Заранее спасибо

Обновление:Решение должно работать на нескольких платформах с поддержкой Java -. (В основном Windows, Linux, некоторые HP Unix)

Обновление:После долгих исследований мы действительно нашли решение, которое мы смогли приобрести. кластерлог.нет(отключен как минимум с середины -2015 года )предоставляет услуги ведения журнала для распределенного программного обеспечения и совместим с log4j и logback (, который совместим с slf4j ). Это позволяет нам анализировать каждого пользователя через приложение. Таким образом, очень легко воспроизводить ошибки, о которых сообщалось (, или даже ошибки, о которых не сообщалось ). Он также уведомляет нас о важных событиях по электронной почте и имеет систему отчетов, в которой журналы одного и того же происхождения обобщаются в легкодоступном формате. Они развернули (, который был безупречен )всего пару дней назад, и он работает отлично.

Обновление (2016 ):этот вопрос по-прежнему получает много трафика, но сайт, на который я ссылался, больше не существует.