Что я должен войти в производственное приложение

Question

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

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

Также зависит ли это от типа приложения, такого как клиентское приложение для настольного компьютера, настольный сервер или веб-сервер?

Answer 1

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

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

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

В нашей компании принято отслеживать, сколько требуется для выполнения запроса к базе данных. Это способ иногда определять узкие места или определять проблемы с вашей системой (сервером приложений или сервером базы данных).

Вы также можете отследить некоторые попытки сломать системные атаки DOS, ботов-ботов ... и так далее.

Надеюсь, это поможет!

Answer 2

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

1. Офисное приложение

Здесь мы регистрируем исключения, общие вещи, такие как вход в систему, запуск приложения и т. Д. Плюсредактирование / удаление / вставка объектов.Достаточно проверить, что случилось, когда дела идут бум.Мы регистрируем достаточно, чтобы иметь возможность воспроизвести дело.В нашем случае журналу разрешено расти неограниченно, поэтому мы можем проверять наличие проблем в обратном направлении.

Промышленное применение.

Здесь мы записываем практически все, кроме кухонной раковины.Это программное обеспечение, которое должно работать круглосуточно, поэтому даже простое предупреждение может быть намеком на приближающуюся катастрофу.Примером является то, что у нас были некоторые странные таймауты и мы не соблюдали некоторые требования по временным ограничениям.В конце концов, лог-файл дал нам информацию: сохранение текстового файла размером в несколько байтов иногда занимало более 5 секунд.Обычно проблемы, с которыми вы сталкиваетесь, - это вещи, о которых вы вообще не задумывались, поэтому вам следует заняться регистрацией, регистрацией, регистрацией!Журналы автоматически очищаются через несколько дней.

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

Поэтому я бы сказал: это зависит от вашего приложения.

Answer 3

В общем случае

• Если вы регистрируете значения DateTime (не говоря о полях заголовка метки времени в каркасах журналирования), убедитесь, что вы записываете их в значимом формате.«ToString ()» обычно не достаточно, если вам нужна информация о Local против Utc или о миллисекундах (я использую «гггг-мм-дд ЧЧ: мм: ss.fff zzz», YMMV) * ​​1004 *
• Если выЗаписывать исключения, перейти к «ToString ()», а не что-нибудь еще.Может быть спорным, но посмотрите здесь по причинам.

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

Это может зависеть от вашей среды или клиента, что считается чувствительным, но примеры: - Фактический пользовательввод в сообщениях об ошибках.- наборы разрешений пользователей и т. Д. - операторы SQL, особенно с фактическими параметрами - структуры запросов / ответов XML

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

Вы можете регистрировать потенциально чувствительную информацию на "уровне" или "категории", которую можно включить в процессе разработки, но отключить впроизводство.Если вы действительно хотите переборщить, вы можете написать запись EventLog, когда ваше приложение обнаружит, что такое ведение журнала включено, чтобы оно не «проскальзывало» в работе.

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

Answer 4

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

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

Answer 5

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

Answer 6

Взгляните на документацию для чего-то вроде nLog. Это даст вам некоторые идеи относительно того, что вы должны регистрировать и как это можно контролировать.

Answer 7

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

1. Записывать каждое исключение и ошибки. Ничто не должно сбежать.
2. Рассмотрите возможность входа пользователя в систему и выхода из системы. Это хорошая информация для отслеживания вашего приложения на наличие вредоносных атак и прочего.
3. Вы можете регистрировать не каждый метод, но вы, если система спроектирована правильно и если у вас есть единственная точка входа для связи между n уровнями, вы можете зарегистрировать этот метод. т.е. методы сохранения, удаления, обновления и т. д.
4. Также обеспечьте некоторое ведение журнала внутри, если # отладочный код , чтобы вы могли включить отладку в производственной среде и производить больше журналирования при необходимости. Это особенно полезно при работе в среде разработки и отладке производственной базы данных.