<b>Мониторинг без диагностики — это просто шум: где искать узкое место</b>

<b>Мониторинг без диагностики — это просто шум: где искать узкое место</b>

Коллеги, давайте разберем план выполнения. Метрика сама по себе ничего не лечит: CPU 90% может быть нормой, а 20% — признаком ожидания на диск или блокировки. Сначала фиксируем базовую картину: нагрузка на CPU, I/O, память, сеть, latency запросов, число активных сессий.

Дальше смотрим не на среднее, а на хвосты. Если p95/p99 растут, а средняя «красивая», значит страдает часть запросов, и именно они роняют SLA. Схема простая, но дьявол кроется в статистике: отдельно проверяем ожидания по типам — lock, io, cpu, temp, network.

Чтобы найти bottleneck, идем от симптома к источнику:
— долгое чтение с диска: ищем тяжелые планы, missing/unused index, full scan;
— блокировки: смотрим цепочки ожиданий и длинные транзакции;
— память: spill в temp, рост сортировок, вытеснение буферов;
— сеть и приложение: не тащим лишние данные и не делаем N+1.

Золотое правило: сначала мониторинг, потом индексы. Иначе получаем «лечили» запрос, а уперлись в чужой lock или в медленный storage. В продакшене так лучше не делать, и вот почему: оптимизация не в том, чтобы ускорить один запрос, а в том, чтобы убрать общий предел системы.