Не знаю, прав ли я, но на днях, столкнувшись с такой проблемой, решил все же написать свою собственную инфраструктуру. Убил на это 4 дня, получилось вроде неплохо. В стиле AOP. В существующих мне не нравится то, что они либо хотят серверную операционку (как Microsoft'ский logging application block), либо даже не делают попыток использовать то, что стало доступным в .NET — зачатки aspect-oriented programming.
Требования были такие:
1) должно работать везде, где работает .NET — вплоть до win98
2) логируемые ивенты могут иметь иерархическую структуру — отписываемый в лог ивент не происходит сразу, он можен начать и закончиться, а в процессе своего исполнения может породить другую тучу ивентов
3) эффективная и надежная работа в распределенной среде. Масштабируемость.
4) логи должны быть легко локализуемы — если их писал сервер с английскими настройками, то чтобы их мог прочесть и китайский администратор
В общем, вооружившсь статьей Тимофея Казакова о Контекстах и своим опытом построения систем логированя (это уже моя 3-я, предыдущие не то, чтобы были плохие, но были во-первых unmanaged, а во-вторых не реализовывали некоторых новых требований), сварганил подсистемку, где управление логированием ведется с 4 сторон:
1) декларативно из кода — контекстными атрибутами метятся классы и методы и определяется их logging-awareness, на подобие того, как поступают с транзакциями в System.EnterpriseServices. Но можно использовать и чисто императивный синтаксис, как в CAS.
2) императивно из кода — можете создать новую логовую сессию, ветвить существующую (тогда в таком случае получаются как гипертекст. В самом деле, не сваливать же информацию от параллельных процессов в один лог) ну и, конечно, собственно отписывать логовые сообщения
3) из файла политик — задает конфигурацию sink'ов (listener'ов или appender'ов как их тут принято называть), фильтры и прочую дребедень
4) из файлов опеределний — определения возможных логовых ивентов, их категоризацию (расширяемую) и стандартные хинты sink'ам (типа write through, write timing) + стандартные локализуемые файлы определений текстов сообщений.
Так как исходил из идеи, что лог — это не TRACE, и потому сообщения пишутся все же относительно нечасто, задействовал всякие извращенческие, как то stack walk с целью определения декларативных настроек логирования и выбора файла определений, приемо, чтобы максимально упрощающие жизнь использующим приемы. Так, например, чтобы отписать сообщение в текущую сессию, ассоциированную с CallContext (если таковую дали открыть), надо просто дернуть статический Log.Write( "event-id", param1, param2, ... ). Чтобы сделать ивент, внутри которого могут быть где-то далеко другие — using( IDisposable = Log.Start( "event-id", param1, param2, ... ) {...}
В общем, "своя Наташка ближе к телу". Может, я и не прав, но стандартные механизмы (как EventLog) я собираюсь использовать только как конкретные log sinks.
