Как настроить счетчики производительности для реального мониторинга системы — без воды и теории

Как настроить счетчики производительности для реального мониторинга системы — без воды и теории

Вы сидите перед монитором, смотрите на графики производительности, а система всё равно тормозит. Счетчики — в красном, но вы не понимаете, что именно ломается. CPU? Память? Диск? Сеть? Или всё сразу? Вы не один. Большинство админов настраивают счетчики производительности «по умолчанию», потом удивляются, что ничего не видно. Я покажу, как настроить их так, чтобы вы сразу видели проблему — без лишних данных, без перегрузки, без «всё подряд».

Зачем вообще настраивать счетчики? Не проще ли просто смотреть на CPU?

Да, CPU — это первое, что смотрят. Но если CPU на 30%, а система виснет — значит, проблема не в нём. Возможно, диск не справляется с запросами. Или память исчерпана, и система постоянно свопит. Или сеть перегружена. Или кто-то запустил скрипт, который читает 500 ГБ логов в секунду. Без правильных счетчиков вы просто гадаете.

Настоящая цель — не собрать данные. А поймать аномалию в момент её возникновения. Чтобы когда утром приходит звонок: «Сервер не отвечает!», вы не бегаете по панелям 15 минут, а сразу знаете: «О, это снова диск. Снова резервное копирование в рабочее время».

Что именно смотреть: 5 ключевых счетчиков

Не надо ставить 50 счетчиков. Вы не будете их читать. Вы будете их игнорировать. Вот те пять, которые реально работают в 90% случаев:

• Processor(_Total)\% Processor Time — нагрузка CPU. Если выше 80% постоянно — проблема есть. Но не всегда это причина.
• Memory\Available MBytes — свободная память. Если меньше 10% от общего объёма — это тревожный звоночек. Если падает до 500 МБ на сервере с 32 ГБ — уже критично.
• PhysicalDisk(_Total)\Avg. Disk Queue Length — очередь диска. Это ключевой счетчик. Если значение выше 2 на одном диске — диск не справляется. На RAID-массиве — выше 4 уже тревожно.
• Network Interface(*)\Bytes Total/sec — трафик. Смотрите не на пиковые значения, а на средние за час. Если в 9:00 резко вырос трафик в 3 раза — ищите, что запустилось.
• System\Processor Queue Length — очередь процессов, ожидающих CPU. Если больше 2–3, а CPU не нагружен — значит, что-то блокирует (часто — диск или сеть).

Эти пять — ваш базовый набор. Они покрывают 95% проблем на Windows-серверах. Не надо ничего больше, пока не появится конкретная проблема.

Как настроить сбор данных — шаг за шагом

Вот как сделать это правильно — без лишних кликов и ошибок:

1. Откройте «Счетчики производительности» (perfmon.exe).
2. Нажмите «Создать настройку данных производительности» → «Данные производительности».
3. В «Добавить счетчики» введите по одному из пяти перечисленных выше. Не копируйте сразу все — добавляйте по одному, проверяйте, что они есть.
4. Выберите «Сохранить в файл» (не в журнал, не в базу). Файл будет .blg — его можно потом открыть в perfmon, Excel или PowerShell.
5. Установите интервал сбора: 15 секунд. Меньше — перегружает систему. Больше — пропустите кратковременные всплески.
6. Установите длительность: 24 часа. Это минимум, чтобы увидеть пиковые нагрузки в рабочее время.
7. Запустите. Не забудьте сохранить настройку как шаблон — назовите «Baseline_Server01».

Почему 15 секунд? Потому что если вы ставите 60 секунд, вы пропускаете кратковременные всплески. Например, резервное копирование может занимать 3 минуты — и если вы смотрите только на среднее за час, вы ничего не увидите. 15 секунд — это компромисс: достаточно часто, чтобы поймать проблему, но не перегружает систему.

Что смотреть в разных сценариях

Ситуации бывают разные. Вот как действовать в каждом случае:

Ситуация	Что смотреть	Что делать
Сервер тормозит утром в 9:00	Processor Time, Disk Queue Length, Memory	Проверьте, не запускается ли резервное копирование или обновление антивируса. Перенесите на нерабочее время.
Постоянно высокая нагрузка на диск	Avg. Disk Queue Length, Disk Reads/sec, Disk Writes/sec	Проверьте, нет ли утечки памяти (система свопит). Проверьте логи приложений — возможно, они пишут слишком много в логи.
CPU на 20%, но очередь процессов >5	Processor Queue Length, Memory\Available MBytes	Скорее всего, диск не справляется. Или есть блокировки в приложении (например, SQL-запросы без индексов).
Сеть перегружена	Network Interface\Bytes Total/sec, TCP Connections	Проверьте, не гуляет ли кто-то по сети с брутфорсом. Или не запущен ли торрент-клиент на сервере.
Память падает, а CPU не нагружен	Memory\Available MBytes, Memory\Pages/sec	Утечка памяти в приложении. Перезапустите службу. Если проблема повторяется — ищите баг в ПО.

Важно: не сравнивайте показатели разных серверов. У одного сервера 16 ГБ памяти, у другого — 128. Норма для одного — катастрофа для другого. Сравнивайте только самого себя — по дням, по часам, по неделям.

Частые ошибки (и как их избежать)

Вот что ломает мониторинг у 8 из 10 админов:

• Собирают всё подряд. 100 счетчиков — это не «безопасно». Это мусор. Вы не сможете найти нужное. Оставьте только пять ключевых.
• Собирают данные слишком часто. Каждую секунду — перегружает систему. Каждые 5 минут — пропускаете критичные всплески. 15 секунд — оптимум.
• Смотрят только на пиковые значения. Пик в 90% CPU — это плохо. Но если он длится 2 минуты, а потом падает — это не критично. Смотрите на длительность и частоту.
• Не сохраняют базовые показатели. Без «до» и «после» вы не знаете, что изменилось. Всегда сохраняйте шаблон на «нормальном» сервере — как эталон.
• Игнорируют диск. Большинство проблем — не в CPU, а в диске. Если вы не смотрите Avg. Disk Queue Length — вы слепы.
• Не настраивают алерты. Если вы смотрите на графики только вручную — вы уже опоздали. Настройте предупреждения: если Disk Queue Length > 3 в течение 5 минут — отправлять email.

Как лучше сделать — практические рекомендации

Вот что я делаю на своих серверах:

• На каждом сервере — один шаблон сбора: «Baseline_ServerName». Он всегда одинаковый — пять счетчиков, 15 секунд, 24 часа.
• Сохраняю файлы на сетевой диск. Никогда не храню на самом сервере — если он упадёт, данные пропадут.
• Проверяю данные раз в неделю. Не каждый день. Если ничего не изменилось — не надо копаться. Но если что-то изменилось — вы сразу это увидите.
• Когда появляется новая задача (например, запускаем новое приложение) — запускаю сбор данных на 24 часа до и после. Так я вижу, как оно влияет на систему.
• Настроил автоматическую отправку email, если Disk Queue Length > 3 в течение 10 минут. Это сработало 3 раза — и я устранил проблему до того, как пользователи пожаловались.

Не надо «оптимизировать мониторинг». Надо сделать его надёжным и простым. Если вы не смотрите на него неделю — значит, он не работает.

Что выбрать: Windows, Linux, облачные серверы?

Счетчики производительности — это Windows-термин. На Linux вы используете top, htop, iostat, vmstat, netstat. Но суть та же.

На облачных серверах (AWS, Azure, GCP) вы можете использовать встроенные метрики — CPU Utilization, Disk Queue Length, Memory Usage. Но там часто не показывают очередь диска — это критично. Если вы не видите очередь диска — используйте iostat -x 1 на Linux или установите агент (например, Prometheus + Node Exporter).

В любом случае — принцип один: смотрите на диск, память, процессор, сеть и очередь. Остальное — детали.

Итог: что делать прямо сейчас

Вот ваш план на сегодня:

1. Откройте perfmon.exe на одном из серверов.
2. Создайте новую настройку данных производительности.
3. Добавьте только пять счетчиков:
   — Processor(_Total)\% Processor Time
   — Memory\Available MBytes
   — PhysicalDisk(_Total)\Avg. Disk Queue Length
   — Network Interface(*)\Bytes Total/sec
   — System\Processor Queue Length
4. Сохраните в файл, интервал — 15 секунд, длительность — 24 часа.
5. Запустите. Забудьте про это на сутки.
6. Завтра утром откройте файл. Посмотрите: где были пики? Что было в 9:00? Что в 14:00?
7. Настройте алерт на Avg. Disk Queue Length > 3.

Это всё. Никаких сложных формул, никаких «оптимизаций», никаких «инструментов для анализа». Только пять счетчиков, которые реально показывают, что происходит.

Если вы сделаете это — вы перестанете гадать. Вы будете знать. И когда система начнёт тормозить — вы скажете: «Диск. Проверьте резервное копирование». И всё. Не 15 минут поиска. Не паника. Просто знание.

Информация в статье носит ознакомительный характер. Настройка мониторинга и интерпретация показателей требуют понимания конкретной инфраструктуры. Перед внесением изменений в рабочую среду рекомендуется проконсультироваться с системным администратором или специалистом по эксплуатации ИТ-инфраструктуры.