Правильное использование позы для журналов Java

предисловие

По поводу лога у всех впечатление относительно простое, пока вводятся соответствующие пакеты зависимостей, остальное "наслаждаться" нужной нам информацией в проекте. Но часто нам легче игнорировать более простые вещи, что приводит к возникновению некоторых ошибок, которых не должно быть.Как мы, строгие программисты, можем допустить такое? Итак, давайте посмотрим на правильное использование журнала.

текст

спецификация журнала

название

Во-первых, это имена файлов журналов. Постарайтесь запомнить это имя. Команда также должна использовать унифицированное соглашение об именах. В противном случае «грязные» файлы журналов повлияют на эффективность устранения неполадок всеми участниками. Рекомендуется называть его "имя_проекта_имя_журнала_тип_журнала.log", чтобы можно было четко знать, к какому проекту относится лог-файл, какого типа и какую роль он играет. Например, в нашем проекте MessageServerмониторИмя файла журнала, связанного с потребителем Rabbitmq, можно определить как «messageserver_rabbitmqconsumer_monitor.log».

экономить время

Что касается времени хранения журнала, рекомендуется хранить обычные файлы журнала в течение 15 дней.Если это более важно, он может быть продлен в соответствии с реальной ситуацией.Подробности см. в дисковом пространстве соответствующего сервера и в журнале. размер файла, чтобы сделать лучший выбор.

уровень журнала

Общие уровни журнала следующие:

Уровень DEBUG: регистрирует информацию, относящуюся к отладчику.
Уровень INFO: регистрирует важную информацию о нормальной работе программы.
Уровень ПРЕДУПРЕЖДЕНИЯ: регистрирует информацию, которая может быть потенциально ошибочной.
Уровень ОШИБКИ: запишите информацию о текущей программной ошибке, которую необходимо обработать с вниманием.
Фатальный уровень: Указывает на то, что произошла серьезная ошибка, и программа будет прервана.

В проекте рекомендуется использовать эти четыре уровня: ERROR, WARN, INFO, DEBUG.

правильная осанка

1. Заранее определите уровень логирования

//条件判断
if(logger.isDebugEnabled){
    logger.debug("server info , id : " + id + ", user : " + user);
}

//使用占位符
logger.debug("server info , id : {}, user : {}",id,user);

Для журналов уровня DEBUG, INFO в нашей программе относительно высокая частота. Когда наш проект большой, количество журналов увеличивается. В настоящее время, чтобы программа работала эффективно, мы должны судить по условию или заполнителю. распечатать журнал. Зачем? Если уровень журнала, настроенный в нашем проекте, равен WARN, то для нашего следующего оператора вывода журнала 'logger.debug("информация о сервере, id: "+ id +", user: "+ user);', хотя журнал не будет печатается, но он будет выполнять операцию склеивания строк.Здесь наш пользователь является экземпляром объекта, поэтому также выполняется метод toString, который тратит много системных ресурсов.

2. Избегайте избыточного вывода журнала

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

Тогда пришло время научиться использовать атрибут аддитивности

<logger name="xx" additivity="true">

Если здесь установлено значение true, что является ситуацией по умолчанию, текущий Logger унаследует Appender родительского Logger.Проще говоря, вывод текущего журнала будет выводиться в родительский файл в дополнение к текущему журналу. файл. В общем, чтобы избежать повторной печати, мы установим для этого параметра значение false, чтобы уменьшить ненужный вывод.

3. Убедитесь, что информация записи журнала заполнена.

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

logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);

Помните, что при выводе экземпляра объекта убедитесь, что объект переопределяет метод toString, иначе будет выведено только его значение hashCode.

4. Определите переменную регистратора как статическую

private static final Logger logger = LoggerFactory.getLogger(XX.class);

Убедитесь, что объект использует только один объект Logger, чтобы избежать его повторного создания каждый раз, иначе это может привести к OOM.

5. Правильное использование уровней журнала

try{
    //..
}catch(xx){
    logger.info(..);
}

Таким образом, вся информация, которая изначально была ERROR, печатается в лог-файле INFO, а неосведомленные коллеги все равно будут пялиться в лог ошибок, и все равно не смогут найти проблему, что больше повлияет на эффективность работы, верно?

6. Рекомендуется использовать комбинацию slf4j+logback

В самой библиотеке logback реализован интерфейс slf4j, поэтому нет необходимости вводить избыточные адаптеры, да и logback имеет больше преимуществ, рекомендуется использовать эту комбинацию в новых проектах. Еще один момент, на который стоит обратить внимание, это то, что при введении slf4j обратите внимание на то, импортирована ли библиотека журналов, которую он фактически использует, нами, или она может использовать библиотеку журналов, предоставленную нашим сторонним пакетом зависимостей, что может привести к тому, что наш журнал неверный.

7. Совокупный анализ логов

Агрегация журналов может объединять журналы, расположенные между разными серверами, для анализа и обработки.Сегодня технологический стек ELK или EFG (fluentd+elasticsearch+grafana) является одним из зрелых решений с открытым исходным кодом.

Возьмите ELK в качестве примера, мы можем напрямую прочитать файл журнала, напечатанный приложением, через logstash на нашем сервере, или мы можем настроить соответствующую информацию о сокете в файле конфигурации журнала в нашем проекте и вывести информацию журнала непосредственно при печати в logstash. . Затем он сохраняется в elasticsearch и отображается kibana.

Эпилог

Что ж, давайте сначала поговорим о журнале ~ Если вам нужно добавить или пообщаться, вы можете оставить сообщение ниже.