Comments 6
можно взять инстанс и сопоставить его с запущенным процессом, а лучше всего это делать в момент его запуска
Один раз взять не получится, выше там уже сказано, что инстанс ид могут сдвинуться. Хуже того, в .NET-категориях, например, наоборот, при запуске нового процесса (а точнее при первом GC в новом процессе, т.к. значения в .NET-категориях обновляются после GC) номера уже запущенных инстансов увеличиваются.
Если хочется прочитать что-то из категории Process, то это, имхо, лучше всего сделать добавив в PdhQuery сразу нужный каунтер и ID Process. Или пойти в обход каунтеров и вызывать напрямую NtQuerySystemInformation(5) (5 — это SystemProcessInformation). Так или иначе вся категория Process сведётся к этому вызову. На практике же хватает периодического обновления мапа между инстансами и process id.
Но т.к. NtQuerySystemInformation(5)работает за O(processes+threads), то при утечке потоков или их некорректном завершении из-за кривых драйверов, например, имеет огромные шансы добить систему окончательно, имхо лучше вообще категории Process и Thread избегать по возможности. Например использовать более легкие функции GetProcessMemoryInfo, GetProcessTime/GetSystemTime для мониторинга метрик по памяти/cpu одного процесса. IO метрики по диску надо придумать, откуда ещё можно вытащить, если они нужны. В IPHlpApi можно взять метрики по сетевой активности.
Если начинать использовать ETW — то логично это делать не только для отслеживания запуска/завершения процессов, а извлекать куда более интересные метрики из эвентов. Сходу не скажу, но скорее всего через ETW можно вытащить большинство метрик, что есть в перф каунтерах (как минимум стоит в PerfView протыкать IIS и MemInfo), но тут опять надо смотреть, из насколько медленных источников эти метрики попадают в ETW, не из того же ли NtQuerySystemInformation в случае метрик по памяти.
А для мониторинга бизнес-логики по типу запросов, имхо, нет ничего надёжнее ручной отправки из приложения
Все сводится к одной хотелке - соответствие инстанса и процесса должно быть атомарной операцией. Я бы тоже по возможности избегал сбор performance по процессу через категорию process. И, конечно, самый простой способ переложить это на плечи программиста, ибо ему доступно все это из домена приложения, но все-равно в таком подходе все сводится к дорогому "NtQuerySystemInformation", будь то точка входа .net.process или более низко уровневое api. Можно пойти по пути ETW,начать отлавливать переключения контекста между потоками и калькулировать performance, но это значительно увеличит кодовую базу.
Я выбрал реактивный подход, когда ETW не генерит события какой-то определенное время после последнего события, то запускается процесс пересборки коллекторов, это минимизировало количество ошибок, но иногда можно наблюдать скачи того же CPU в 100000%
А так, вы все верно пишите.
Атомарность есть на уровнях NtQuerySystemInformation и Pdh, если в один query добавить сразу несколько каунтеров, включая ID Process.
.net.process — это тот, что System.Diagnostics.Process? Дотнетные обёртки что для процесса, что для перфкаунтеров сами по себе тяжеловесные. В версии 4.7.2 и Core частично исправили ситуацию, но все равно.
Hard-way ETW, конечно, не предлагаю, но там есть и эвенты с уже готовыми метриками, перформанс их конечно надо исследовать. Hard-way с ручным подсчётом если и использовать, то, например, для метрик по времени работы GC, которые не вытащить другими способами.
А какие уникальные метрики нужны из категории Process?
Проблема не в том, какие метрики нужны и не в том, что закинуть в query. Необходимо инстанс сопоставить с тем именем, который понятный людям, но это не PID, не имя процесса, не бинарь - это имя сайта или пула, имя службы, консоли и того сложнее, ибо бинарь зачастую не коррелирует с названием приложения.
Я конкретно о категории Process, которая собирает данные медленно. Соответствие между инстансами в ней и PID как-то применимо в других категориях? Выглядит так, что в других категориях — свои имена инстансов, а в самой категории Process нет метрик, без которых нельзя обойтись или извлечь другим способом
Подводные камни сбора метрик в Windows (часть 1)