Что я должен войти в систему производственное приложение
Я запускаю новый проект и думаю о том, какие вещи я должен регистрировать. Файл журнала только предназначается, чтобы помочь разработчикам найти ошибки. Вариант использования - то, что, когда необработанное исключение брошено, уведомление, отправляют разработчику, у кого есть доступ к файлу журнала и stacktrace.
Какие вещи я должен включать в файл журнала? Вход всего не собирается работать. Я знаю, что трудно сказать, поскольку ответ, вероятно, требует глубоких знаний о системе. Таким образом, я предполагаю, что действительно прошу "лучшие практики". Дайте определенные примеры.
Также это зависит от типа приложения, такого как настольное клиентское приложение, настольный сервер или веб-сервер?
7 ответов
В общем
- Если вы записываете в журнал значения DateTime (не говоря о полях заголовка timestamp фреймворков логирования), убедитесь, что вы записываете их в осмысленном формате. "ToString()" обычно не достаточно, если вам нужна информация о Local vs. Utc или о миллисекундах (я использую "yyyy-MM-dd HH:mm:ss.fff zzz", YMMV)
- Если вы регистрируете исключения, используйте "ToString()", а не что-либо другое. Возможно, спорно, но посмотрите здесь на причины.
Насчет чувствительной или подробной информации, как уже сказали другие, нужно быть осторожным. Дело не только в том, что люди, имеющие право читать ваши производственные журналы, получают больше информации, чем нужно, но и в том, что любой злоумышленник может получить ценную информацию из слишком подробных журналов (вот почему я не стал бы записывать в журнал набор прав пользователя с ошибкой, что у него нет определенного права, как было предложено в другом ответе).
Это может зависеть от вашей среды или клиента, что считать чувствительным, но примеры таковы: - Фактический ввод пользователя в сообщениях об ошибках. - Наборы разрешений пользователя и т.д. - SQL-запросы, особенно с фактическими параметрами - XML-структуры запросов/ответов
Поиск правильной гранулярности информации для регистрации - это всегда компромисс между количеством регистрируемой информации, производительностью, которая требуется не только для записи, но и для создания этой информации в коде, и чувствительностью этой информации. И именно по этой причине в любой серьезной системе протоколирования существуют "уровни" или "категории".
Вы можете регистрировать потенциально сензитивную информацию на "уровне" или в "категории", которая может быть включена в разработке, но выключена в производстве. Если вы действительно хотите переборщить, вы можете написать запись в EventLog, когда ваше приложение обнаружит, что такое протоколирование включено, чтобы оно не "проскочило" в производстве.
Наконец, рассмотрите возможность использования фреймворка протоколирования, который позволяет изменять эти уровни или категории во время выполнения. Таким образом, вы можете включить больше информации, если это необходимо, контролируемым образом, не нарушая работу приложения и не сбрасывая ситуацию, которую вы хотели проверить, из-за необходимости перезапуска приложения.
Первое правило: «Не записывать конфиденциальную информацию!» . Например: номер социального страхования, номера кредитных карт, пароли и т. Д. Вы не знаете, кто может получить разрешение на его просмотр, и это может вызвать некоторые юридические проблемы.
Полезно протоколировать обмен данными со сторонними компонентами (например, веб-службами и т. Д.). Вы сможете предоставить полезную информацию стороннему поставщику или вам в случае возникновения проблемы.
Полезно очень кратко отслеживать действия, которые пользователи совершают ... переходят на определенную страницу ... делают что-то. Поэтому, если клиент звонит вам по телефону и говорит, что с вашим продуктом что-то не так, вы можете проверить, что он делает сейчас.
В нашей компании принято отслеживать, сколько времени требуется для выполнения запроса к базе данных. Это способ когда-нибудь выявить узкие места или выявить некоторые проблемы с вашей системой (сервером приложений или сервером базы данных).
Вы также можете отслеживать некоторые попытки взломать вашу систему DOS-атаки, боты грубой силы ... и так далее.
Надеюсь, это поможет!
Ведение журнала - это ваш Спаситель, когда дело доходит до ситуации «весь ад сломался» в производстве. Как вы сказали, это требует больше знаний о приложении, но над всеми вашими должны думать о нескольких вещах.
- Регистрируйте все исключения и ошибки. Ничто не должно спасаться.
- Рассмотрите возможность регистрации входа и выхода пользователя. Это хорошая информация для мониторинга вашего приложения на наличие вредоносных атак и прочее.
- Вы можете не регистрировать каждый метод, но если система разработана правильно и если у вас есть одна точка входа для связи между n уровнями, то вы можете регистрировать этот метод. То есть Сохранить, Удалить, Обновить методы и т.д.
- Также обеспечьте некоторые ведение журнала, если # debug code , чтобы можно было включить отладку в производстве и при необходимости создать дополнительные журналы. Это особенно полезно при работе в среде разработки и отладке производственной базы данных.
У меня есть две отдельные среды, в которых требования к протоколированию полностью различаются.
- Office приложение
Здесь мы регистрируем исключения, такие как вход в систему, запуск приложения и т.д., а также редактирование/удаление/вставку объектов. Достаточно, чтобы проверить, что случилось, когда всё зашло в бум. Мы регистрируемся достаточно, чтобы воспроизвести дело. Журнал может расти неограниченно в нашем случае, так что мы можем проверить на наличие проблем пути назад.
- Промышленное применение.
Здесь мы записываем почти все вместе с кухонной раковиной. Это мягкость, которая должна работать 24/7, так что даже простое предупреждение может быть намеком на грядущую катастрофу. Примером является то, что у нас были какие-то странные тайм-ауты и мы не соблюдали некоторые требования к ограничению времени. В конце концов файл журнала дал нам информацию: сохранение текстового файла в несколько 100 байт иногда занимает более 5 секунд. Обычно проблемы, которые возникают сами по себе, это вещи, о которых вы вообще не думали, поэтому ведение журнала, ведение журнала - это то, что вы должны делать! Журналы автоматически очищаются через несколько дней.
Мы также внедрили уровень журнала, который может быть установлен конечным пользователем: если установлено значение verbose, мы сохраняем все журналы, если установлено значение minimal only errors come through. Так что после нескольких недель стабильного бега мы медленно снижаем уровень регистрации к минимуму и останавливаемся, если мы совместимы с.
Поэтому я бы сказал: Это зависит от вашей заявки.
Посмотрите документацию на что-то вроде nLog. Это даст вам некоторые идеи относительно того, что вы должны регистрировать и как это можно контролировать.
Запишите имя метода, вызвавшего исключение, и все параметры, которые он использовал (т.е. состояние). Зарегистрируйте идентификатор и права пользователя. В веб-сценарии зарегистрируйте IP-адрес и заголовки.
Регистрация делает код длиннее и менее понятным. Так что ленитесь, ничего не записывайте, пока не понадобится.
Было бы неплохо посылать письма с необработанными исключениями непосредственно разработчикам и вообще ничего не заносить в журнал.
Логирование - это ваш спаситель, когда дело доходит до ситуации "весь ад разразился" на производстве. Как вы сказали, это требует большего знания приложения, но в целом вам следует подумать о нескольких вещах.
- Записывайте в журнал все исключения и ошибки. Ничто не должно ускользнуть.
- Рассмотрите возможность протоколирования действий пользователя при входе и выходе из системы. Это хорошая информация для мониторинга приложения на предмет вредоносных атак и прочего.
- Вы, конечно, не можете регистрировать каждый метод, но если система спроектирована правильно и у вас есть единая точка входа для связи между n уровнями, то вы можете регистрировать этот метод. Например, методы сохранения, удаления, обновления и т.д.
- Также обеспечьте логирование внутри кода if#debug, чтобы вы могли включить отладку в продакшене и производить больше логирования при необходимости. Это очень полезно, особенно при работе в dev-среде и отладке производственной базы данных.