Что регистрировать / отслеживать в производственной среде - PullRequest
7 голосов
/ 28 октября 2009

Мне интересно, какая информация должна регистрироваться в файле после перемещения приложения в рабочую среду? Помимо регистрации исключений и ошибок ...

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

Ответы [ 3 ]

4 голосов
/ 28 октября 2009

В производственной среде по умолчанию для ведения журналов установлено значение «INFO» (используется log4net), и на этом уровне я регистрирую достаточно информации, чтобы иметь очень хорошие шансы на диагностику любых ошибок. Так что же такое «достаточная» информация? Ну, это все зависит от вашей системы. В нашей системе я регистрирую точки входа и выхода из наиболее важных методов, включая их входные параметры и возвращаемые значения (если это не много данных). Я готов принять 5-10% накладных расходов на ведение журнала (но вы должны это измерить).

Мой предпочтительный формат такой:

Метод ввода:

-> MyMethod (1, "arg1")

Метод выхода:

<- MyMethod (1, "arg1") = true </p>

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

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

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

Я также использую уровень ведения журнала DEBUG, который регистрирует практически все. Это используется только в dev / test или, возможно, в производстве, но только после консультации с клиентом.

2 голосов
/ 28 октября 2009

Это действительно зависит от вас, нет жестких и быстрых правил.

Пару месяцев назад мы работали над этим Java-приложением и использовали log4j для ведения журнала, в log4j мы смогли определить в коде нашрегистрируется как отладка, предупреждение, ошибка, информация и т. д.

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

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

0 голосов
/ 28 октября 2009

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

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

K

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...