Ответ 1
Журналы и трассировка - это (IMO) изобразительное искусство, зная, что нужно регистрировать и где берет опыт.
Я обнаружил, что лучший (худший?) способ обучения искусству ведения журнала - это испытывать боль от попыток диагностировать проблемы с неряшливым протоколированием!
Все, что я могу вам предложить, - это несколько советов:
Подумайте, как будет использоваться сообщение журнала.
Клавиша для хорошего ведения журнала - это думать о том, как будет использоваться сообщение журнала, если есть проблема, наоборот, худшая вещь о плохом протоколировании - это то, что вы только когда-нибудь поймете это, когда у вас есть проблема, и у вас недостаточно информации!
Всегда думайте о , что сообщение журнала говорит человеку, который его читает, например:
- Сбой вызова Windows API? Если это так, вам, вероятно, нужно будет записать результат
HRESULT
иGetLastError
(если таковой имеется) для его использования. - Не удалось найти запись в коллекции? Без имени записи, которая не была найдена, действительно не так много людей может вывести - было бы также полезно узнать счетчик коллекции, чтобы вы могли определить, пуста ли коллекция.
Общей ошибкой является не думать о том, какая информация требуется при регистрации, однако вы должны также тщательно подумать о том, когда сообщение будет зарегистрировано, - если сообщение регистрируется часто при нормальной работе, то в лучшем случае это полезность вызывает сомнения и при худшее, что сообщение журнала может вводить в заблуждение.
Кроме того, убедитесь, что вы можете определить, что запустило сообщение. Если все, что вы можете видеть в журнале, это строка, которая появляется в вашей базе кода много раз (или, что еще хуже, совсем не так!), Тогда вам нужно будет вычитать и хитрости, чтобы выяснить, откуда это сообщение журнала (и без зная, откуда приходит сообщение, у вас мало надежды понять это)
- В многопоточных/многопроцессорных приложениях всегда регистрируйте идентификатор потока и идентификатор процесса.
- Если у вас есть идентификатор запроса любого типа, зарегистрируйте его тоже.
- Если вы считаете, что собираетесь потратить разумный промежуток времени на просмотр файлов журналов, вам следует настоятельно рассмотреть возможность отправки любых файлов pdb и т.д., чтобы просмотреть исходные файлы и номера строк.
Ведение журнала используется только при возникновении проблемы
Не путайте журнал с обработкой ошибок. Обработка ошибок - это ответ на эту ошибку и разрешение этой ошибки (например, отображение сообщения пользователю), журналы (обычно) используются только тогда, когда что-то пошло не так, и причина неясна.
Например: если использование пытается открыть файл, который не существует, то, если ошибка корректно обрабатывается (сообщая пользователю, что файл не может быть найден), не должно быть необходимости регистрировать эту ошибку.
(Возможное исключение может быть, если вам нужны статистические данные о том, как часто эта ошибка произошла или что-то в этом роде - это возвращается к размышлению о том, как будет использоваться журнал.)
В общем случае правильная обработка ошибки предпочтительнее регистрации, однако хорошая обработка ошибок еще сложнее, чем хорошая регистрация - это случаи, когда необходима дополнительная информация, предлагаемая в журналах.
Вы также не должны путать ведение журнала с аудитом (хотя во многих системах два перекрываются).
Еще лучше!
Единственный способ, с помощью которого вы можете регистрировать слишком много, - это:
- У вас закончилось место для хранения.
- Вы существенно влияете на производительность своего приложения.
- Вы получаете болотистые журналы, которые вы не можете легко обработать в случае ошибки.
-
Вы регистрируете профанации, направленные на вашего босса.
Ведение журнала существует исключительно для диагностики причины проблем (не путайте протоколирование с аудитом) - если у вас нет проблем, никто не будет смотреть ваши журналы, и никакого вреда не будет! Пока у вас не возникнет проблема, и в этом случае вам потребуется столько информации, сколько вы можете получить.
Если у вас есть сомнения относительно того, нужно ли что-то записывать, запишите его.
Выполнять только однократные исключения из журнала.
Сказав вышеизложенное, я чувствую необходимость уточнить регистрацию исключений.
В общем случае вы должны только регистрировать исключение один раз (в тот момент, когда он обрабатывается). Не испытывайте соблазн регистрировать исключение, которое позднее высылаете вызывающему абоненту "на всякий случай", вызывающий не регистрирует исключение должным образом - все, что происходит, - это то, что вы заканчиваете тем же самым исключением, которое регистрируется много раз по мере его прохождения от уровня к уровню (я видел, как это происходит, и это затрудняет просмотр количества ошибок на самом деле).
Ответственность за регистрацию ошибки - это единственное возможное исключение, которое может проходить между границами системы (например, веб-службами), где невозможно передать все детали ошибки.
Регистрировать все, что имеет значение, везде, где это необходимо для его регистрации.
Например, если вы пишете серверное приложение, то ваши файлы журналов должны быть на сервере, где sysadmins могут их читать, - если, однако, существует вероятность возникновения ошибок на клиенте (например, в JavaScript), то ваш код регистрации должен быть в JavaScript. Решение? Ваш журнал JavaScript должен отправиться на сервер (ala log4js)
Не беспокойтесь о том, где вы должны, и не должен ставить ведение журнала - просто поместите его там, где это необходимо.