Использование счетчиков производительности для отслеживания служб Windows

Question

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

Службы Windows делают разные вещи в разное время, и я хотел бы их отслеживать. Это означает, что на некоторых развернутых системах мы видим, что машина работает высоко над процессором, мы видим, что процесс sql работает высоко, но мы не можем быть уверены в том, какая служба несет за это ответственность.

Мне интересно, подходят ли счетчики производительности для этой работы.

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

Мне кажется, что я могу получить perfcounter, который имеет только 0 или 1 значение для каждой услуги, чтобы показать, что она что-то делает, но это не похоже на нормальное использование для perfcounters.

Являются ли счетчики производительности подходящими?

Как вы думаете, я должен отслеживать это по-другому?

Answer 1

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

Лично я нахожу более подробные инструменты, необходимые для того, чтобы действительно понять, что происходит в моих сервисах (хотя, возможно, это связано с характером моих услуг).

Я использую .NET Logging Framework, потому что он прост и может записывать несколько целей, включая файлы журналов, журнал событий и сокет TCP (у меня есть простой монитор, который прослушивает сокет для ведения журнала для каждого сервера приложений и показывает мне в реальном времени, время, что происходит).

Answer 2

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

Если вам нужна дополнительная информация, вы должны прибегнуть к другим инструментам. В вашем случае это звучит так, как вам нужно больше в этом направлении.

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

API-интерфейс .NET Trace будет лучшим вариантом, если вы ожидаете, что инструментарий будет генерировать слишком много данных для обычного журнала событий. Вы можете настроить приложение (ы) для отслеживания или не на основе приложения/web.config, хотя для изменения потребуется перезагрузка приложения. Это хороший вариант, если вы хотите использовать прибор для устранения неполадок, но в противном случае генерирует слишком много данных или если трассировка сама по себе слишком сильно ухудшает производительность. Еще одна хорошая вещь в API трассировки заключается в том, что вы можете отслеживать на нескольких уровнях, поэтому даже если вы написали код в Trace очень подробно, вы увидите только подробные данные трассировки, если вы включите подробный трассировку. Это дает вам лучший контроль над тем, что отслеживается.

Answer 3

Eric J имеет хорошую точку. Я думаю, что если вы действительно хотите захватить «синхронизацию» производительности, вам придется использовать некоторые другие виды ведения журнала и использовать журналы запуска и остановки.Мне лично нравится log4net, хотя может быть больно настроить первый раз