Обработка сквозных проблем, таких как внутренняя статистическая отчетность для компонентов веб-приложения

Question

Я пытаюсь реализовать статистическую отчетность для внутренних компонентов веб-приложения OLTP. Например, я хочу отслеживать в режиме реального времени использование или производительность таких вещей, как: количество успешных / неудачных входов в систему, количество сеансов nhibernate, время для обработки HTTP-запроса, количество транзакций различных типов (заказов, обращений и т. Д.). Вся эта статистика отправляется через UDP на сервер statsd (https://github.com/etsy/statsd)) и отображается в виде графиков с Graphite.

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

Как вы подходите к внутреннему дизайну для такого запроса? Подойдете ли вы к внедрению конструктора, статическим методам (например, PerformanceCounters.Increment ("name.of.counter")), которые называются моими отслеживаемыми компонентами или как?

Если это помогает контексту, приложение создано на C # и использует ASP.NET и Castle Windsor в качестве IoC.

Спасибо, Роберт

Answer 1

Шаблон проектирования, о котором я думаю, вы имеете в виду: Аспектно-ориентированное программирование .Castle Windsor поддерживает AOP, как и большинство других IoC-контейнеров.

Как вы говорите, вы не внедряете экземпляр класса / интерфейса отчетов статистики в каждый компонент.Скорее, в вашей конфигурации вы заключаете каждый компонент в перехватчик.Компонент ничего не знает о статистике отчетности;перехватчик вызывается до и после каждого вызова вашего компонента и может решить, куда и куда отправлять информацию трассировки.Он идеально подходит для таких вещей, как ведение журнала, трассировка, подсчет производительности, обработка сбоев и все упомянутые междисциплинарные проблемы.

Answer 2

Я использую Spring.Net для чего-то подобного. Насколько я слышал, Spring очень похож на Castle Windsor для IoC, и Spring использует CastleWindsor для создания динамических прокси. Эти вы можете использовать для AOP, который поддерживается Spring. Кривая обучения короткая, рамки очень хорошо задокументированы. Как только ваш аспект производительности настроен, применить его к вашим методам должно быть более чем легко. Дайте мне знать, если вы хотите небольшой образец.