Я хочу создать более продвинутый механизм ведения журналов для моих веб-приложений Java, подобных журналам приложений. Моих потребностей:Расширенное ведение журналов для веб-приложений Java
- журналы потока в базу данных (. Для бывшей SQL, BigQuery или что-то еще)
- Автоматически входить важные данные (например, контекст приложения, URL запрос, идентификатор запрос, браузер агент пользователя, пользователь id и т. д.)
Для пункта 1 я использую реализацию «буферизации», где журналы помещаются в разные списки, а периодически cron (thread) собирает все журналы в памяти и записывает их в базу данных (который также может быть на другом сервере)
Для точки 2 единственный способ сделать это - вставить нужные объекты в мои классы (подсистемы), такие как ServletContext, HttpServletReqest, текущий пользователь и т. Д., Все моделируются в пользовательский класс (скажем, AppLogContext), который затем может используется механизмом каротажа.
Проблема в том, что я не знаю, является ли это хорошей практикой. Например, это означает, что многие классы должны будут содержать этот объект, который имеет доступ к объектам сервлета и объектам HTTP-запроса, и я думаю, что это может создать архитектурные проблемы (при создании модулей, слоев и т. Д.) Или даже в вопросах безопасности.
App Engine автоматически регистрирует эту информацию (и многое другое, например, задержки, использование процессора и т. Д., Но это более сложно), и его можно найти в журналах консоли проекта (также он может дублировать журналы на большой запрос таблицы), и мне нужно что-то для Jetty или других серверов веб-приложений Java.
Итак, есть ли другой способ сделать это, другие шаблоны, разные подходы? (не удалось найти сторонние библиотеки для любой из этих точек)
Спасибо.
Ну, чтобы дать вам кусок в головоломки, кажется, вам не быть: App Engine регистрирует запросы. Вы можете добиться этого, добавив фильтры. Вы можете создать фильтр, предоставляющий экземпляр журнала, который используется только для текущего запроса, а затем обрабатывает завершение записи по запросу. Это плохая практика? Да, потому что вы добавляете много накладных расходов на каждый запрос. Я рекомендую вам проверить рамки логатора ususal (log4j и т. Д.) И посмотреть, что возможно, прежде чем пытаться использовать свой собственный журнал, который не будет таким зрелым. – konqi
Что касается использования фильтров, я не уверен, что полностью понимаю, но разве это не значит, что мне все еще нужно создать объект журнала и передать его всем подсистемам? Итак, в пользовательском MyClass я все равно не могу назвать что-то вроде Log.getLog(). Print (myMessage) правильно? –
Мне бы как-то понадобился объект Logger со статическим методом для создания, но с областью запроса ... в противном случае, не передавая данные requst (context) в используемые классы, какой способ сопоставления (привязки) сообщений журналов к запросить идентификаторы у меня? Это очень полезно при отслеживании множества шагов, сложных операций, выполняемых в одном запросе, и я не мог найти способ добиться чего-то подобного, с библиотеками протоколирования. Возможно, мне что-то не хватает ... –