Подтвердить что ты не робот

Мониторинг производительности/показатели в приложении .NET

Мы хотим собрать данные о производительности нашего приложения (скажем, 80% WinApp), как внутри, так и на сайтах клиентов. Наши цели заключаются в следующем:

  • Он должен быть очень быстро
  • Он должен быть легким
  • Он должен позволять отслеживать/синхронизировать и подсчитывать множество различных событий в наших приложениях.
  • Он должен быть способен собрать (эффективно) достаточное количество данных, таких как Domain, ComputerName, User, OS, Memory и т.д.
  • Все собранные данные должны быть проанализированы (после того, как они были переданы нашей внутренней базе данных BI) по всем упомянутым выше размерам.

В идеале, он был бы идеально конфигурирован для всего сайта или для каждого пользователя:

  • Если эти показатели производительности даже собраны
  • Как подробно их собирать
  • Сообщить о результатах нам

Мы планировали, по сути, написать нашу собственную систему, чтобы сделать большую часть этого. Затем мы рассмотрим несколько разных моделей "персистентности", в том числе двоичное форматирование "пакетов производительности", XmlSerialization и функции отслеживания трассировки, которая уже является частью платформы .NET, просто для обозначения нескольких.

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

Спасибо заранее.

4b9b3361

ОТВЕТЫ

Ответ 1

Посмотрите Metrics.NET, относительно новый проект, который должен охватывать большинство этих потребностей. Это порт проекта "метрики" Java.

(Добавлен март 2016 г.) Проект Metrics.NET был перенесен на новые люди после длительного периода отсутствия обновлений.

Ответ 2

Вы можете взглянуть на создание чего-то сверху StatD:

https://github.com/etsy/statsd/

Там пакет .NET для этого можно найти здесь:

https://github.com/robbihun/NStatsD.Client

Он легкий, поскольку он в основном просто отключает UDP-пакет на удаленный сервер. Затем этот удаленный сервер агрегирует его и сохраняет в Graphite, который хорош в использовании этих данных и превращает их в графики, и он управляет такими вещами, как сохранение данных для вас. Для анализа Graphite также позволяет выводить данные как JSON (который в основном превращает ваши метрики в массив удвоений) и имеет множество функций и фильтров, которые вы можете применить к записанным метрикам, которые вы могли бы затем передать в ваши другие системы.

См. здесь некоторые примеры того, что возможно с графитом:

http://matt.aimonetti.net/posts/2013/06/26/practical-guide-to-graphite-monitoring

Однако он не отвечает всем вашим требованиям, таким как возможность записи данных о клиенте, таких как имена компьютеров. Но вы, вероятно, можете достичь этой цели, используя namespacing в ваших метрических именах; поэтому вы записываете свой показатель с помощью ключа, такого как "client567.orders.loadtime", а "client567" - это запись в другой базе данных, которая хранит, например, что клиент567 использует IE11 для Windows 7.

Таким образом, это не полное готовое решение, но оно создает хорошую основу, я думаю.

Другой вариант - использовать коммерческую платформу, такую ​​как NewRelic:

http://newrelic.com/

Он поставляется с контролем производительности для многих технологий (от ASP.NET до SQL Server до Solr). Тем не менее, для этого требуется агентский процесс (служба в Windows), работающий в фоновом режиме, который обрабатывает мониторинг для вас, что может быть или не быть вариантом для вас. Это более или менее предназначено для веб-серверов и, вероятно, не очень подходит для мониторинга клиентского приложения WPF.

Ответ 3

Следуя вашему плану, я бы взял такой подход:

  • Вы собираетесь записать все данные о производительности в файл журнала. Используйте одну из быстрых библиотек журналов С#, таких как log4net или nlog. Эти рамки поддерживают двоичные приложения, если необходимо.
  • Когда приложение начнет записывать доступную оперативную память, CPU и т.д.
  • Используйте инжектор аспектов, такой как PostSharp, чтобы автоматически добавлять таймер к каждому (не встроенному) методу в вашем приложении. Класс "Секундомер" не приведет к существенному результату. Чтобы сделать эту конфигурацию, инжектор аспекта изменит уровень журнала в соответствии с оцененным приоритетом метода (или используйте его собственные атрибуты, чтобы указать это).
  • Запросить пользователя при выходе (или запуске) для отправки записанных данных производительности на ваш веб-сервер.
  • Заблокируйте данные на выходе.

Вы также можете захотеть написать свой собственный класс блокировки. Вместо использования lock(blah) или Monitor.Enter(blah) завершите Monitor.Enter/Exit в своем собственном одноразовом классе, который регистрирует, сколько времени вам нужно было ждать, чтобы ввести блокировку.

Ответ 4

Я бы начал с тестирования, будет ли проблема с помощью EventLog решить мою проблему. Сообщения EventLog содержат много информации, и вы можете добавить свои собственные.

Для некоторой диагностики я бы посмотрел на (пользовательские) счетчики производительности. Моя ставка заключается в том, что трудно создать что-то, что превосходит производительность счетчиков производительности Windows.

Написание этого снова и снова может не стоить того.

Может потребоваться создать специальные фильтры в средстве просмотра событий, чтобы получить результат, который вы ищете, или собирать события на компьютерах (вы можете даже написать свой собственный просмотрщик)