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

Question

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

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

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

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

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

Answer 1

Я использую Spring.NET что-то вроде этого. Весна очень похожа на замок Виндзор для IoC, насколько я слышал, а Spring использует CastleWindsor для создания динамических прокси. Эти, которые вы можете использовать для АОП, который поддерживается весной. Кривая обучения коротка, структура очень хорошо документирована. Как только ваш аспект производительности настроен, применение его к вашим методам должно быть более чем простым. Дайте мне знать, если вы хотите небольшой образец.

Answer 2

Образец дизайна, я думаю, вы имеете в виду Aspect Oriented Programming. Castle Windsor поддерживает АОП, как и большинство других контейнеров IoC.

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