Ведение журнала против отладки - PullRequest
7 голосов
/ 06 марта 2009

Справочная информация: Я унаследовал веб-приложение, которое предназначено для создания соединений на лету между локальным и удаленным оборудованием. В последнее время появилось огромное количество движущихся частей: само приложение значительно изменилось; набор инструментов разработки был только что обновлен; и локальное, и удаленное оборудование были «модифицированы» для поддержки этих изменений.

Хорошей стороной является то, что он имеет разумную систему ведения журнала, которая будет записывать сообщения отладки в файл, и он будет вести запись как в файл, так и на экран пользователя в реальном времени. У меня есть возможность переделать весь механизм log / debug.

Примеры:

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

Вопрос: Какие лучшие практики вы использовали как разработчик или как потребитель, которые генерируют полезные журналы и отладки?


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

Что из лучших журналов, которые вы видели, делало их наиболее полезными?

Спасибо за вашу помощь!

Ответы [ 6 ]

8 голосов
/ 24 января 2013

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

Coding Horror guy получил интересный пост о проблеме с журналированием и о том, почему злоупотребление регистрацией может быть потерей времени в определенных условиях.

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

Так что я думаю, что мое мнение по этому поводу:

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

Код ужаса сказал: противостоять тенденции регистрировать все . Это верно, но я уже видел приложение hudge, которое довольно точно делает обратное (и через базу данных) ...

7 голосов
/ 06 марта 2009

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

Если я хочу, чтобы все было взбито, я делюсь на следующее:

  • Трассировка -> Сбрасывает каждое действие и шаг с отметкой времени, с вводом и выходные данные этой стадии (самые уродливые и самый большой файл)
  • Регистрация -> Регистрировать только шаги бизнес-процесса, клиент делает запрос, поэтому регистрируйте критерии запроса и выходные данные больше ничего.
  • Отчеты об ошибках / отладка -> В журнале исключений указано, где оно произошел, отметка времени, ввод / вывод данные, если возможно, информация о пользователе и т. д.

Таким образом, если возникли какие-либо ошибки и журнал ошибок / отладок не содержит достаточно информации для моего вкуса, я всегда могу сделать grep -A 50 -B 50 'timestamp' tracing_file, чтобы получить более подробную информацию.

EDIT: Как уже было сказано, всегда полезно придерживаться стандартных пакетов, таких как встроенный модуль журналирования для Python, в качестве примера. Свертывание собственного - не лучшая идея, если у языка его нет в стандартной библиотеке. Мне нравится оборачивать запись в маленькую функцию, обычно принимая сообщение и значение для определения, в какие журналы он поступает, т.е. 1 - трассировка, 2 - регистрация, 4 - отладка, поэтому отправка значения 7 сбрасывается на все 3 и т. Д.

7 голосов
/ 06 марта 2009

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

И сделайте правильный выбор того, что регистрировать, чтобы вы могли приблизительно следовать основным путям в вашем приложении.

В качестве фреймворков я использовал стандарты (log4net, log4java, log4c ++)

НЕ реализуйте свою собственную структуру ведения журналов, если она уже есть в наличии. Большинство людей, которые просто изобретают велосипед.

3 голосов
/ 06 марта 2009

Некоторые общие эмпирические правила, которые я нашел полезными для серверных приложений:

  • requestID - назначьте идентификатор запроса для каждого входящего (HTTP) запроса, а затем записывайте его в каждой строке журнала, чтобы впоследствии можно было легко выполнить поиск этих журналов по этому идентификатору и найти все соответствующие строки. Если вы считаете, что добавлять этот идентификатор в каждый оператор журнала очень утомительно, то, по крайней мере, каркасы ведения журналов Java сделали его прозрачным с помощью Отображенный контекст диагностики (MDC).
  • objectID - если ваше приложение / служба имеет дело с манипулированием некоторыми бизнес-объектами, имеющими первичный ключ, то полезно также присоединить этот первичный ключ к диагностическому контексту. Позже, если кто-то придет с вопросом "когда манипулировали этим объектом?" Вы можете легко выполнить поиск по objectID и просмотреть все записи журнала, связанные с этим объектом. В этом контексте (иногда) полезно использовать вложенный диагностический контекст вместо MDC.
  • когда регистрироваться? - по крайней мере, вы должны регистрироваться всякий раз, когда вы пересекаете важную границу службы / компонента. Таким образом, позже вы сможете восстановить поток вызовов и перейти к конкретной базе кода, которая, похоже, вызывает ошибку.

Поскольку я являюсь разработчиком Java, я также поделюсь своим опытом работы с API-интерфейсами и платформами Java.

API

Я бы рекомендовал использовать Simple Logging Facade для Java (SLF4J) - по моему опыту, это лучший фасад для регистрации:

  • полнофункциональный: он не придерживается подхода наименьшего общего знаменателя (например, регистрация общего достояния); вместо этого он изящно ухудшает подход.
  • имеет адаптеры практически для всех популярных сред ведения журналов Java (например, log4j)
  • предлагает решения о том, как перенаправить все устаревшие API ведения журналов (log4j, commons-logging) на SLF4J

Осуществление Лучшая реализация для использования с SLF4J - logback - написана тем же парнем, который также создал SLF4J API.

3 голосов
/ 06 марта 2009

Я бы просто настроил вашу систему ведения журнала так, чтобы она имела несколько уровней ведения журнала. В службах, которые я пишу, я веду ведение журнала / аудита почти для каждого действия, и ему присваивается уровень аудита 1-5, чем выше число, тем больше событий аудита вы получаете ,

  1. Очень простое ведение журнала: запуск, остановка и перезапуск
  2. Базовое ведение журнала: обработка x файлов и т. Д.
  3. Стандартное ведение журнала: начало обработки, окончание обработки и т. Д.
  4. Расширенное ведение журнала: начало и конец каждого этапа обработки
  5. Все: каждое предпринятое действие

вы устанавливаете уровень аудита в файле конфигурации, чтобы его можно было изменить на лету.

0 голосов
/ 06 марта 2009

Используйте существующий формат ведения журнала, например, используемый Apache, и затем вы сможете использовать множество инструментов, доступных для анализа формата.

...