Регистрация, когда и что?

Question

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

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

Answer 1

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

Реализуйте свою структуру ведения журналов в вашем источнике. Как минимум, вы должны искать записи, а затем «добавлять ценность» к исключениям, которые могут возникнуть в вашем приложении. Запись трассировки стека в файл журнала - это хорошо, но очень редко бывает достаточно, чтобы можно было диагностировать проблему - рассмотрите возможность регистрации таких вещей, как значение параметров метода в подвохе {}.

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

Answer 2

1 - сделать один журнал, со стандартным форматом. Не имеет большого значения, что это, но убедитесь, что когда-либо запись имеет те же основные поля. Просто вызов «printf», вероятно, не обрезает его (замените System.err.println или что-то еще, в зависимости от ситуации)

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

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

4 - Если возможно, укажите файл и номер строки источника ошибки. Это легко в C, и немного боли в Java. Но это невероятно полезно позже, особенно когда люди начинают вырезать + вставлять код, включая сообщения об ошибках.

5 - Убедитесь, что журнал находится в том месте, где его может использовать любой уровень кода.

6 - Я часто использовал теги ошибок «Primary» и «Secondary», где «Primary» означает «Я парень, который обнаружил проблему», а «Secondary» означает «Я вызвал функцию, которая сообщил об ошибке ". Это позволяет легко найти источник проблемы («Основной: файл не найден») и по-прежнему сообщать о значении ошибки («Вторичный: невозможно загрузить таблицу калибровки»).

7 - включает некоторые возможности для регистрации ошибок и ошибок.

Самое сложное, что я нахожу, это когда ошибка не обязательно является ошибкой. Если вы вызываете функцию с файлом, а файл не существует, это ошибка, которая должна быть зарегистрирована или нет? Иногда это критический сбой, а иногда и ожидаемый. Это в значительной степени зависит от API функции; если у функции есть способ вернуть ошибку, я обычно делаю это без регистрации; тогда задача кода более высокого уровня состоит в том, чтобы решить, нужно ли сообщать об этой ошибке или ожидаемо.

Answer 3

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

Answer 4

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

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

Answer 5

Мы разрабатываем большую систему телефонии, которая используется во всем мире, и годами используем нашу собственную систему регистрации для приложений. Уровни отладки очень важны, и наши приложения поставляются с отладкой, установленной на «только ошибки», с включенным журналом в файл для всех, кроме наиболее чувствительных ко времени. Мы также поддерживаем перенаправление нашего вывода в систему трассировки отладки (это Windows, так что это простой вызов OutputDebugString, и наши инженеры имеют доступ к отладчику отладчиков DBWIN32). Это важно, потому что некоторые классы ошибок требуют, чтобы вы могли видеть вывод из нескольких приложений, сериализованных. С помощью этой техники я решил несколько серьёзных ошибок взаимодействия с несколькими приложениями. Приложения обычно добавляют к выводу понятный человеку тег, чтобы мы могли определить, какая строка пришла из какого приложения, для этого сценария.

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

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

Answer 6

До тех пор, пока вам не нужно много платить за производительность, ведение журнала важно.

По моему опыту, наиболее важные вещи, которые вы хотите записать, - это такие предупреждения, упс, ошибки проверки работоспособности, сценарии дождливых дней и т. Д., Которыми обычно пренебрегают при кодировании сценариев солнечного дня, а иногда отказываются от них с надписью «Мы не должны попасть сюда» и т. д. Эти вещи имеют тенденцию не появляться во время тестирования, а появляться во время развертывания, где они, конечно, не захвачены.

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

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

Наконец, будьте предельно осторожны при регистрации ошибок, если ваши пользователи используют Mac OS X: по какой-то странной причине, даже в Leopard, механизм ведения журналов по умолчанию обрабатывается дорого и может нагружать тонны ЦП.