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