Ответ 1
Я поместил свою конфигурацию в пакет по умолчанию: src/
и войдите в файлы с использованием системного свойства ${catalina.home}:
log4j.appender.???.file=${catalina.home}/logs/system.log
Я планирую внедрить протоколирование в веб-приложение, над которым я сейчас работаю, но я борюсь с некоторыми деталями. Каков наилучший способ ведения журнала веб-приложения Java?
В частности,
В настоящее время я использую Log4J, но я полагаю, что лучшие практики будут применяться повсеместно ко всем реализациям ведения журнала.
РЕДАКТИРОВАТЬ:
Одно дополнение к вопросам вверх.
В традиционном приложении я делаю это в точке входа;
DOMConfigurator.configureAndWatch("log4j.xml");
Каким будет эквивалент веб-приложения?
Я поместил свою конфигурацию в пакет по умолчанию: src/
и войдите в файлы с использованием системного свойства ${catalina.home}:
log4j.appender.???.file=${catalina.home}/logs/system.log
Я бы рекомендовал вам использовать SLF4J. Это простой фасад регистрации, который поддерживает большинство популярных систем ведения журналов (Log4j, commons-logging, API регистрации Java и Logback). Используя , вы сможете заменить свою систему подписи на любое другое, простым обновлением CLASSPATH.
Другим преимуществом SLF4J являются параметризованные вызовы, что уменьшает уродливый код ведения журнала.
Собственно, они рекомендуют использовать SLF4J с Logback. Logback является преемником Log4J. И он был разработан тем же автором.
Где файл конфигурации входит в файл .war package? Корень пути к классам.
Где люди регистрируются, относительный или абсолютный путь к файлу или базу данных? Зависит от необходимости. Всегда лучше использовать относительные пути. Базы данных хороши, если вы реализуете другое приложение, которое будет извлекать журналы из него и отправлять их по электронной почте /sms
Записывается ли журнал Log4J непосредственно в файл журнала сервера приложений или что-то, что вам нужно настроить? В этом случае я использую Tomcat, но я часто использую Jrun. Если вы используете консольный appender, да, он будет зарегистрирован в вашем файле журнала контейнера сервлета.
Любые другие ошибки, о которых я должен знать для ведения журнала веб-приложений? Если вы регистрируетесь из разных потоков, используйте logback, он поточно-безопасен и предоставляет параметризованные сообщения журнала.
Вход в БД добавляет еще одну точку отказа. У нас была ситуация, когда серверы prod регистрировались в БД, а кто-то запускал дорогостоящий запрос в этой БД, что замедляло его настолько, что prod-серверы были очень медленными. Вход в файл может привести к проблемам, если у вас закончилось свободное место, но, похоже, меньше вероятность замедления работы всего приложения.
Это может быть хорошей идеей разместить файл конфигурации где-нибудь, где администратор может изменить его, не перестраивая ваше веб-приложение (например, чтобы они могли включать подробное ведение журнала, не пробуждая вас посреди ночи).
К сожалению, нет "официального" способа поиска внешних ресурсов из веб-приложения (исправьте меня, если я ошибаюсь). Самый распространенный способ сделать это я видел - это просмотреть каталоги в пути к классам.
Лично я помещаю log4j.properties в каталог WEB-INF и использую сервлет init со следующим кодом:
public class InitServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {
private static final String LOG4J_FILE = "WEB-INF/log4j.properties";
public InitServlet() {
super();
}
@Override
public void init() throws ServletException {
super.init();
PropertyConfigurator.configure(getServletContext().getRealPath(LOG4J_FILE));
LogFactory.getLog(InitServlet.class).info("LOG 4J configured");
}
}
В корне пути к классам, но... Не помещайте файл конфигурации в военный пакет. Вы не хотите переупаковывать и повторно развертывать приложение, если вы измените конфигурацию ведения журнала, не так ли? Лучшей практикой было бы поставить файл конфигурации где-нибудь в пути класса за пределами войны.
Обычно я регистрирую файловую систему на отдельном разделе (файлы журналов могут расти очень быстро и никогда не должны блокировать приложение или операционную систему, если они становятся слишком большими). Я использую большую часть времени абсолютный путь на основе следующей модели:/var/projects/<PROJECT_NAME > /<PRODUCT> /<CLUSTER_NAME > /logs/<INSTANCE_NAME > .log где < ИМЯ_ПРОЕКТ > это имя проекта, <PRODUCT> могут быть Apache, Tomcat, Weblogic,..., <CLUSTER_NAME > имя кластера и <INSTANCE_NAME > имя экземпляра внутри кластера. Вход в файловую систему происходит быстрее, чем в базе данных. Недостатком является то, что журналы не централизованы, если вы используете несколько экземпляров и физические машины. Но слияние может быть легко выполнено с помощью script.
Журналы сервера приложений - это журналы сервера приложений, а не журналы приложений. Не пишите им, а настраивайте инструмент регистрации (например, log4j) и записывайте в журналы приложений (понимайте выделенные).
Если вы используете log4j, не забудьте использовать isDebugEnabled() перед записью:
if(logger.isDebugEnabled()) {
logger.debug("Bla Bla Bla");
}
Обычно я не размещаю конфигурацию регистрации в приложении, а оставляю это для администраторов приложений для настройки ведения журнала на сервере. В редких случаях я хочу, чтобы конфигурация log4j была развернута с помощью webapp, WEB-INF - это обычный путь.
Опять же, это зависит от настроек сервера приложений. Обычным является обычный файл журнала для сервера приложений и ежедневный поворот. Если есть какие-либо специфические для приложения потребности, администратор может настроить отдельный файл журнала для приложения (отличающийся именами пакетов/классов).
См. выше. Для tomcat, используемого для целей разработки, я просто ищу его конфигурацию ведения журнала (log4j) и добавлю конкретную специфику приложения.
if (log.isDebugEnabled()) { log.debug("..."); }
и аналогичные конструкции в вашем коде.Я рекомендую вызывать log API (log4j) через slf4j. Даже если вы используете log4j, веб-контейнер или зависимые модули могут использовать разные API журналов, такие как Java.util.logging или Jakarta commons logging. Slf4j предоставляет мостовые модули, которые перенаправляют их на slf4j API. В результате все сообщения журнала записываются log4j в этом случае.
Обратите внимание: если вам просто нужно немного вести журнал, стандарт сервлета указывает, что вы можете получить ServletContext и использовать там методы журнала. Это общий эквивалент сервлета System.out.println.
Отличная бумага Как правильно вести регистрацию приложений имеет кучу gotchas.
Я считаю, что на ваши другие вопросы были ответы другие люди на этой странице.
Я также рекомендую использовать SLF4J.
Последнее: говорящие представления объектов может сэкономить некоторое время.