Log4net/Logging - Что Вы нашли, чтобы быть полезными?
Если вы видите эту ошибку из библиотеки, установленной через CocoaPods, попробуйте pod update <OFFENDING POD NAME>
. Это решило проблему для меня.
8 ответов
Я основываю свой ответ на превосходном ответе Роберта Козака, хотя я не совсем использую свое журналирование одинаково
Я использую пять типов операторов журнала:
- DEBUG
- INFO
- WARNING
- ERROR
- FATAL
DEBUG - это операторы, которые полезны, когда вы все еще пишете приложение и когда вам необходимо полное понимание того, что и где ваш поток выполнения Вы можете использовать операторы DEBUG, чтобы измерить очередь перед блокировкой, или проверить имена пользователей, вошедших в систему, или даже параметры для определенного вызывающего вызов SQL, который вызывает беспокойство. DEBUG предназначен для операторов, которые обычно не нужны, чтобы быть известными.
INFO следует использовать всякий раз, когда есть информация, которая будет очень полезна, если что-то пойдет не так, но не означает, что что-то пошло не так. Если вы используете слишком много операторов INFO, ваши журналы станут раздутыми и бесполезными, поэтому будьте осторожны. Используйте INFO для любой важной информации, которая вам понадобится при возникновении ошибки, и она не находится рядом с тем местом, где будет выброшена ошибка.
Используйте уровень WARN , если вы обнаружили восстанавливаемую, но все еще неожиданную (при хотя бы немного ожидал, потому что вы это поймали). Это указывает на то, что ваше приложение МОЖЕТ находиться в нерабочем состоянии, но вы считаете, что можете восстановить / продолжить текущий путь выполнения.
ERROR предупреждения предназначены для случаев, когда вы обнаружите непредвиденное исключение. Если вы восстанавливаете / повторяете текущий метод, я бы предложил использовать WARN. Если вы отменяете / выручаете, используйте ОШИБКУ. Даже если ваша программа может продолжаться, ОШИБКА означает, что вы пытались что-то сделать и были отклонены, и поэтому переходите к другим вещам.
FATAL предназначен для использования, когда вы ловите что-то на уровне намного ниже того, где оно было брошено, и вы, по сути, понятия не имеете, что происходит. Это означает, что вы даже не пытаетесь продолжить выполнение, вы просто регистрируете все возможные биты информации, которые есть в вашем распоряжении, а затем пытаетесь выйти изящно. ФАТАЛЬНЫЕ ошибки используются нечасто, потому что, как правило, если вы обнаружите ошибку, у вас будет достаточно информации, чтобы попытаться продолжить выполнение. Но в тех случаях, когда может произойти повреждение, если вы попытаетесь продолжить, зарегистрируйте ошибку FATAL, а затем убежите.
Относительно того, куда вы входите. Мне обычно нравится входить в «общую» папку на серверах моих приложений (будьте осторожны с разрешениями, чтобы они не были общедоступными), чтобы журналы были очень легко доступны и всегда были моим первым шагом для отладки. Если возможно, настройте его так, чтобы любые ошибки, такие как ПРЕДУПРЕЖДЕНИЕ, ОШИБКА или ФАТАЛЬНО, отправлялись по электронной почте, чтобы вы получили «расширенное» предупреждение.
Приветствия
Я использую четыре типа операторов журнала:
- DEBUG
- INFO
- WARNING
- ERROR
Я использую DEBUG для операторов, которые хочу проверить во время сеанса отладки. Обычно это не для сборки выпуска. Здесь я проверяю значение переменной или регистрирую вход и выход метода.
Я использую INFO для строк подключения, конфигурации и общих битов информации, которые я всегда хочу видеть в журнале.
ПРЕДУПРЕЖДЕНИЕ редко используется для вещей, в которых я не уверен, или из-за потенциальных ошибок, или, возможно, даже для проверки исключения, которое, как я знаю, будет обработано в стеке.
Обычно я использую ERROR только в блоке Catch для сообщения об исключении и в ExceptionHandler, который вызывается, когда никакой другой метод не обработал исключение.
Log4Net with Apache Chainsaw. Chainsaw is a dashboard for viewing your log messages from realtime. It can handle multiple apps, perform on-the-fly filtering, and a few other handy features.
If in doubt, log it (preferrably at a higher level like DEBUG or INFO or create your own level). You can configure what gets output in the config file.
- Все исключения регистрируются на уровне
ОШИБКАна самом высоком уровне в стеке вызовов, который возможен (обычно в обработчиках событий и т. Д.) - Ввод пользователя, который вызывает проблему регистрируется на уровне
WARN(поскольку это может указывать на то, что нам нужно улучшить наш пользовательский интерфейс, чтобы лучше ориентировать пользователя) - «Значимые» действия регистрируются на уровне
INFO(т.е. который включает в себя выставление счетов по кредитной карте клиента, запросы к стороннему API и т. д.), включая соответствующие данные (обычно сериализованные в формате XML, с удалением любой конфиденциальной информации) - Очень подробные действия могут регистрироваться на уровне
DEBUG
Мы редко используем протоколирование уровня FATAL .
Обычно мы используем развертывание RollingLogFileAppender на уровне INFO ,и SmtpAppender на уровне ОШИБКА .
Существует также еще одна среда журналирования для ASP.NET, которая называется ELMAH . Хотя это не настоящая среда ведения журналов, а скорее структура исключений.
К классным функциям относятся:
- 0 кодов / перекомпиляция для его реализации
- имеет веб-интерфейс для просмотра ошибок
- RSS-канал для ошибок
- может настроить его на сброс ошибок в SQL
Я обнаружил, что получаю ценные данные, настраивая проекты для использования Log4PostSharp в начале разработки. По сути, в сочетании с механизмом PostSharp вы можете поместить атрибут в методы, и он будет регистрировать все вызовы с параметром и возвращаемыми значениями. Я установил его на уровне отладки в файле Assembly.cs, чтобы по умолчанию регистрировались все вызовы методов, которые не являются получателями или установщиками свойств.
Если не контролировать, это может привести к огромному количеству данных (я уверен, что Я не регистрирую ничего другого на уровне отладки, чтобы его можно было легко включать и выключать и полностью удалять из сборок релиза, если производительность является проблемой), но с хорошим средством просмотра журнала - я использую BareTail - Вы можете определить сложные ошибки очень быстро. Это' Он особенно хорош в определении метода, в котором находились все ваши потоки, в момент возникновения проблемы.
Я использую метод добавления файлов, так что самые последние данные всегда доступны, а файлы не достигают смешных размеров.
Есть еще одна программа просмотра журналов log4net (отличная от Apache Chainsaw), которую моя компания использует в течение некоторого времени, она называется «log4net Dashboard» и разрабатывается норвежской компанией (я думаю) называется FaktNet, его веб-сайт http://www.l4ndash.com .
Он предоставляет веб-панель управления, которая довольно интуитивно понятна и обеспечивает хороший обзор журнала, может использоваться с множеством различных appenders (такие как Rolling File или SQL-server appender), но они не бесплатны, как Apache Chainsaw. У них действительно есть лицензия разработчика, которая бесплатна и допускает только локальное использование, что было бы достаточно, например, для фрилансера, желающего отслеживать свои сайты (одна l4n-панель может подключаться к нескольким источникам журналов).
FaktNet имеет различные лицензии, в зависимости от того, сколько пользователей должны иметь доступ к панели управления, и их лицензия Enterprise не очень дорогая (я думаю, это 600 долларов). Учитывая его способность получать доступ к нескольким журналам, он может быть важным активом для команды разработчиков, которая разрабатывает и отслеживает множество средних и крупных веб-сайтов.
Другим действительно полезным аппаратом является DBAppender , который может регистрировать информацию в базе данных, которая, очевидно, невероятно полезна, чтобы запросить журнал.
Подробнее об этом в в этой статье .