Где/на каком уровне должен регистрироваться код?

Ответ 1

Журналы и трассировка - это (IMO) изобразительное искусство, зная, что нужно регистрировать и где берет опыт.

Я обнаружил, что лучший (худший?) способ обучения искусству ведения журнала - это испытывать боль от попыток диагностировать проблемы с неряшливым протоколированием!

Все, что я могу вам предложить, - это несколько советов:

Подумайте, как будет использоваться сообщение журнала.

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

Всегда думайте о , что сообщение журнала говорит человеку, который его читает, например:

• Сбой вызова Windows API? Если это так, вам, вероятно, нужно будет записать результат HRESULT и GetLastError (если таковой имеется) для его использования.
• Не удалось найти запись в коллекции? Без имени записи, которая не была найдена, действительно не так много людей может вывести - было бы также полезно узнать счетчик коллекции, чтобы вы могли определить, пуста ли коллекция.

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

Кроме того, убедитесь, что вы можете определить, что запустило сообщение. Если все, что вы можете видеть в журнале, это строка, которая появляется в вашей базе кода много раз (или, что еще хуже, совсем не так!), Тогда вам нужно будет вычитать и хитрости, чтобы выяснить, откуда это сообщение журнала (и без зная, откуда приходит сообщение, у вас мало надежды понять это)

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

Ведение журнала используется только при возникновении проблемы

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

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

(Возможное исключение может быть, если вам нужны статистические данные о том, как часто эта ошибка произошла или что-то в этом роде - это возвращается к размышлению о том, как будет использоваться журнал.)

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

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

Еще лучше!

Единственный способ, с помощью которого вы можете регистрировать слишком много, - это:

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

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

Если у вас есть сомнения относительно того, нужно ли что-то записывать, запишите его.

Выполнять только однократные исключения из журнала.

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

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

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

Регистрировать все, что имеет значение, везде, где это необходимо для его регистрации.

Например, если вы пишете серверное приложение, то ваши файлы журналов должны быть на сервере, где sysadmins могут их читать, - если, однако, существует вероятность возникновения ошибок на клиенте (например, в JavaScript), то ваш код регистрации должен быть в JavaScript. Решение? Ваш журнал JavaScript должен отправиться на сервер (ala log4js)

Не беспокойтесь о том, где вы должны, и не должен ставить ведение журнала - просто поместите его там, где это необходимо.

Ответ 2

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

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

Обратите внимание, что разные сообщения журнала могут иметь разные цели даже в пределах одного приложения:

• Чтобы предоставить информацию о (нормальном) потоке событий в приложении (то есть приложение пакетной обработки может регистрировать, что оно было запущено и завершено, возможно, краткий результат обработки и т.д.). Такие сообщения предпочтительно должны быть относительно небольшими, содержащими ограниченный объем информации, поскольку они часто предназначены для чтения людьми (например, системный администратор, чтобы утром проверить, что приложение успешно работает). Так как это "обычные" сообщения, их приоритет находится в середине шкалы, например. INFO.
• Чтобы предупредить об исключительных событиях (например, ошибки, сбои, отсутствующие файлы,...). Эти сообщения должны быть редкими (в обычном приложении), но могут содержать чрезмерное количество информации (например, трассировки стека, дампы ядра и т.д.), Которые могут помочь выявить базовую ошибку. Однако, когда они происходят, мы почти всегда хотим их видеть, поэтому они имеют высокий приоритет, например, ERROR или FATAL.
• Чтобы предоставить подробную информацию о том, что происходит в определенной части приложения (обычно для целей отладки). Эти сообщения, как правило, являются настоящими свиньями, часто генерируя гигабайты данных журнала. Поэтому мы хотим видеть их только при определенных обстоятельствах, поэтому он может установить свой уровень на низкий уровень, например. DEBUG.

Современные структуры ведения журнала, такие как семейство Log4J, позволяют очень гибко обрабатывать различные типы (уровни) сообщений из разных частей приложения. Тем не менее, рекомендуется планировать схему ведения журнала, прежде чем добавлять в код множество сообщений журнала. То есть какие типы сообщений вы планируете регистрировать в каких частях приложения и как вы собираетесь использовать эти сообщения? Сколько и каких целей журнала (консоль, файл, БД) вам нужно?

Ответ 3

Я нашел руководство по архитектуре Microsoft хорошим чтением. http://msdn.microsoft.com/en-us/library/ff650706.aspx

Регистрация - это сквозная забота всех слоев

Ответ 4

Для того, что я реализовал до сих пор, я использовал стратегию "черного ящика". Каждая часть кода (функция или/или класс) несет во многом свою ответственность: входное тестирование, выполнение того, что он должен делать, обработка ошибок, информация о регистрации. Поэтому, если ваш фрагмент кода находится в бизнес-слое, он должен бросить деловые ошибки, а также вести бизнес-мудрую информацию

Ответ 5

Общая обработка ошибок, я думаю, очень важна в приложении.

Из JavaWorld следуют причины, почему важна общая обработка ошибок:

• Swollen logs: каждый блок catch содержит оператор журнала, приводящий к раздутым и избыточным записям журнала, вызванным загрязненным исходным кодом.

• Резервированные реализации. Тот же тип ошибок имеет разные представления, что усложняет обработку.

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

• Некомбинированное объявление исключений: подпись метода обобщается, чтобы выбросить java.lang.Exception. Таким образом, клиентам гарантировано не иметь наименьшего представления о семантике ошибки метода.