Ведение журнала лучших практик для приложений .NET, работающих в нескольких потоках

Question

У нас есть приложение, которое регистрирует файлы, которые в данный момент используют streamwriter. Поскольку мы рассматриваем масштабирование приложения, мешает блок регистрации. Приложение является многопоточным и может работать с числом потоков, исчисляемым тысячами. Количество потоков не влияет на процессор, так как большая часть обязанностей заключается в обработке TCP-сокетов на лету. Но ведение журнала является проблемой, так как здесь происходит сближение, и производительность отдельных потоков в данном случае влияет на его TAT.

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

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

Должен ли я также взглянуть на технологии MSMQ для быстрого перемещения трафика?

Answer 1

Я хотел бы взглянуть на существующие каркасы ведения журналов, такие как log4net или Microsoft Блок приложения для ведения журнала библиотеки предприятия . (Я немного использовал log4net, но не блок приложения журналирования.)

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

Если вы делаете накатываете свои собственные и хотите модель производителя / потребителя, вы можете захотеть взглянуть на параллельные коллекции в .NET 4. Хотя, как упоминает mhenrixon, вам почти наверняка придется найти баланс между производительностью и надежностью. Если это только для журналов отладки, то, вероятно, не имеет большого значения, если вы потеряете несколько, если приложение внезапно завершит работу - но, очевидно, совсем другое дело, если журналы содержат записи аудита, которые имеют сохранялось.

Answer 2

Вы также должны рассмотреть NLog , особенно NLog 2.0 (в настоящее время в бета-версии - с сентября).Помимо прочего, в NLog 2.0 добавлена ​​возможность асинхронного ведения журнала .По сути, вы должны сконфигурировать Target (s) (эквивалентный log4net Appender), в который вы хотите войти (файл, база данных и т. Д.).Затем, также через конфигурацию, вы «оборачиваете» каждую цель асинхронной оболочкой цели.NLog также имеет опцию в файле конфигурации, чтобы сделать все ведение журнала асинхронным.

Пока мы занимаемся вопросами ведения журнала, вы можете также рассмотреть возможность использования абстракции ведения журнала, например Common.Logging for .NET .Это дает вам возможность отложить окончательное решение по вашей базовой структуре (log4net, NLog и т. Д.), А также дает возможность написать собственный регистратор (который может быть легко раскрыт с помощью Common.Logging).

Answer 3

Звучит так, как будто вы после чего-то, что в log4net называется Буфер Appender подумал, что это небезопасно, если ведение журнала не может быть "потерянным". Я считаю, что любой из каркасов ведения журналов можно легко расширить с помощью ведения журнала MSMQ.