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

Question

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

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

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

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

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

Подходят ли счетчики производительности?

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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