Ведение журнала против.Отладка

Question

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

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

Примеры:

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

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

---

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

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

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

Answer 1

Абсолютно самая ценная вещь, реализованная в любой системе ведения журналов, — это инструмент «в один клик», который собирает все журналы и отправляет их мне по почте, даже если приложение развернуто на машине, принадлежащей клиенту.

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

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

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

Answer 2

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

Кодирование Ужасный парень получил интересный пост о проблема с регистрацией и почему злоупотребление лесозаготовками может оказаться пустой тратой времени в определенных условиях.

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

Итак, я думаю, что мое мнение по этому поводу следующее:

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

API

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

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

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

Answer 6

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