Почему записи в log4net могут пропадать в некоторых слушателях?

Question

Этот действительно заставляет меня чесать голову ....

Я уже некоторое время использую log4net (в настоящее время версия 1.2.10) в приложении. При добавлении новой опции в приложение я заметил, что, хотя методы log4net Debug, Error и т. Д. Вызывали вызываемые элементы из этого источника журнала, не были обнаружены консольным приложением.

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

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

[Дополнительная информация добавлена ​​19 января 2010 г.]

Наконец, я внимательно посмотрел на объект ILog, возвращаемый в ответ на вызов

LogManager.GetLogger(typeof (MyTypeHere));

В некоторых случаях я получаю объект ILog с Debug, Info, Warning, Error и т.д., установленными в false. В других случаях объект ILog правильно устанавливает их в значение true. Поскольку мой код ничего не делает для манипулирования этими флагами, в случаях, когда мой код передается, «отключенные» сообщения объекта ILog из моего кода (по понятным причинам) не распространяются вообще.

Я до сих пор не могу объяснить очевидное расхождение между двумя прибавителями.

Answer 1

Правильно ли я понимаю, что некоторые сообщения, которые обычно регистрируются успешно, внезапно перестают появляться (регистрироваться) в какой-то момент? Если это так, то я бы предложил включить внутреннюю регистрацию log4net. Альтернативно отладьте проблему с помощью кода log4net (с вашей проблемой я бы предложил разбить где-нибудь метод CallAppenders в классе Logger. Он скажет вам, какие приложения будут фактически вызваны для события регистрации).

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

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

Answer 2

Мы регулярно используем приложения logfile, console и smtp вместе, и у нас, похоже, нет таких проблем. При определенных условиях некоторые пользователи могут потерять сообщения из-за присущей им природы. Например, UDP-приложение из-за транспортного механизма не гарантирует передачу всех сообщений. То же самое происходит с приложением SMTP. Если вы используете общий файл журнала, но ведете журнал из нескольких процессов, иногда файл блокируется другим процессом (обычно это вызывает исключение, но оно может попасть в ваш код), поэтому обязательно установите свойство Minimal Lock. в теме. Кроме того, приложения могут быть буферизованы, поэтому в случае сбоя процесса у log4net может не быть возможности очистить буферизованные данные.

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

Answer 3

Я знаю, что это старое, но у меня недавно такое было в приложениях asp.net mvc, и было очень сложно отследить. Похоже, это происходит с методами, которые используют атрибут ValidateInput(false).

Я предполагаю, что использование этого атрибута пропускает инициализацию некоторых данных, к которым log4net пытается получить доступ во время регистрации. Я обнаружил, что добавление следующего к моему web.config исправило проблему:

<httpRuntime requestValidationMode="2.0" />

Конечно, он имеет другие побочные эффекты (не связанные с ведением журнала).