Консультации по уровням журнала приложений

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

Я и моя команда управляем и настраиваем приложения в системе с необходимыми исправлениями ошибок и запросами на изменение. Система интенсивно используется, и приложения используют большое количество журналов.

Типичный пример:

Клиент сообщений

public void save(final Message message) {
   logger.info("Trying to save message: {}", message);

   boolean result = false;
   try {         
     result = messageService.save(message);
   } catch (final MessageStoreException e) {          
      logger.warn("Unable to save message {}", message, e);
      throw e;
   } catch (final Exception e) {
      logger.error("Unknown error when trying to save message!", e);
   }

   if (!result) {
      logger.warn("Could not save the message!");
   }
}

Служба сообщений

public boolean save(final Message message) throws MessageStoreException {  
   if (message == null) {
      throw new IllegalArgumentException("message!");
   } 

   final boolean result = messageStore.store(message);
   if (result) {
      logger.info("Stored: {}", message.getId());
   } else {
      logger.warn("Unable to store: {}", message.getId());
   }

   return result; 
}

ПРИМЕЧАНИЕ. Я знаю, что пример кода не обеспечивает наилучшей обработки ошибок, но именно так он выглядит во многих приложениях, которыми мы управляем.

Конечно, это делает лог-файлы ОЧЕНЬ большими.

Я хотел бы включить уровень журнала info и уровень журнала warn в производственной среде и оставить включенным только уровень error, чтобы файлы журналов содержали только непредвиденные ошибки, требующие внимания, и ничего больше.

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

Я понимаю эти аргументы и чувствую, что мне нужен вклад сообщества.

Итак, что здесь лучше всего? Должны ли мы использовать уровни журнала информации/предупреждения в производственной среде или мы должны использовать только регистрацию ошибок? Или, может быть, оба?

Спасибо!

ОБНОВЛЕНИЕ: приложения работают на нескольких серверах, и в настоящее время мы регистрируем все в файл (обычно один файл журнала для каждого приложения с RollingFileAppender). Чтобы начать регистрацию в базе данных, требуется много работы, поэтому это не вариант.

ЗАКЛЮЧЕНИЕ. Ведение журнала — не совсем тривиальная задача. Мы не будем отключать уровни информации и предупреждений (это было довольно резкое действие), а вместо этого, как говорит @jgauffin, пройдем и проанализируем бизнес-правила для приложений, которые печатают «ненужные» сообщения журнала.

Дело закрыто! Спасибо всем за отличный вклад и хорошие советы.


person nekman    schedule 26.10.2012    source источник
comment
Взгляните на этот ответ, поскольку он (хотя и связано с .NET) очень применимо к вашему вопросу.   -  person Steven    schedule 27.10.2012


Ответы (5)


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

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

Это типичная проблема. Проанализируем логирование:

final boolean result = messageStore.store(message);
   if (result) {
      logger.info("Stored: {}", message.getId());
   } else {
      logger.warn("Unable to store: {}", message.getId());
   }

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

Однако подобное ведение журнала обычно указывает на то, что бизнес-правила неясны. Таким образом, гораздо лучшим решением, вероятно, будет заставить команду проанализировать, почему журналирование настолько тяжелое. Приложение требует большого объема обслуживания? Тогда, вероятно, лучше удалить ведение журнала и дополнительные проверки ошибок (например, проверку аргументов метода) вместо включения уровней журнала.

Замечание команд о том, что они не могут следить за потоком без ведения журнала, указывает на то же самое: аргументы не проверяются, поэтому ошибка появляется глубоко внутри, а не в начале приложения.

person jgauffin    schedule 27.10.2012
comment
Спасибо! Пройдемся по заявкам, разберем правила домена и удалим лишнее логирование. - person nekman; 29.10.2012

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

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

person Roland    schedule 28.10.2012
comment
Спасибо за хороший ответ, Роланд! :) Нет, отключение уровней журналов было радикальным действием (хотя должно работать в некоторых приложениях...) В любом случае, я добавил вывод. - person nekman; 29.10.2012

Вы можете войти в базу данных. (Не должно быть так сложно настроить приличную структуру ведения журнала.)

Оттуда вы можете удалять записи в зависимости от уровня и возраста. Обновление: сначала вы регистрируете все (включая DEBUG, если хотите). Скажем, через неделю вы удаляете сообщения DEBUG. Через месяц вы удаляете сообщения INFO. На данный момент у вас есть все, что сейчас хранится в ваших файлах.

Бонус: при подозрении на ошибку вы на время приостанавливаете удаление.

После, может быть, на год удаляешь остальные.

Таким образом, вы сможете удовлетворить обе потребности: необходимое пространство и сохраненную информацию. Это можно отрегулировать по мере необходимости.

person DerMike    schedule 26.10.2012
comment
Спасибо за ваш вклад, но проблема все еще остается. Должны ли мы заполнить базу данных информационными и предупреждающими уровнями, или мы должны отключить эти уровни? Сегодня мы используем RollingFileAppender. который хранит файлы журнала в течение 30 дней. - person nekman; 27.10.2012

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

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

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

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

person Tom Anderson    schedule 27.10.2012
comment
Спасибо за ваш вклад! Это не проблема размера диска. Но файлы журнала содержат много ненужной информации, более подходящей для среды разработки/тестирования. Стоит ли знать, что SomeMethod был вызван из SomeOtherMethod? В некоторых случаях, может быть. Мне просто любопытно узнать, должны ли мы сохранять информацию и предупреждать уровни в продакшене или просто показывать там ошибки? - person nekman; 27.10.2012
comment
Я написал немного больше. Не знаю, поможет ли! - person Tom Anderson; 27.10.2012
comment
Спасибо за подсказку про logstash, обязательно посмотрю. Я добавил заключение. - person nekman; 29.10.2012

Для производственной среды рекомендуется хранить отдельные файлы журналов для уровней регистратора TRACE и ERROR.

В файле журнала TRACE вы можете определить нежелательные сообщения и удалить эти сообщения.

person atish shimpi    schedule 31.07.2017