Мониторинг без поиска bottleneck — это просто дорогой сбор метрик

Мониторинг без поиска bottleneck — это просто дорогой сбор метрик

Коллеги, давайте разберем план выполнения: сначала фиксируем базовую линию, потом ищем отклонения. Если не знаете, что у системы «нормально», любой всплеск выглядит катастрофой, а любой спад — ложной победой.

Смотрите не на одну метрику, а на цепочку:
— CPU высокий, а I/O низкий? Ищите вычисления, сортировки, плохие планы.
— I/O высокий, а CPU скучает? Упёрлись в диск, кэш, блокировки или слишком широкий доступ.
— latency растет, а throughput стоит? Часто виноваты ожидания, очереди и contention, а не «медленный сервер».

Золотое правило: сначала мониторинг, потом индексы. Иначе вы легко «лечите» симптом, когда узкое место вообще в другом слое. План запроса, wait events, блокировки, размер рабочих наборов, очереди в пуле соединений — это не украшения дашборда, а карта местности. Посмотрим, что тут с I/O в реальности.

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

Если хотите находить bottleneck быстро, собирайте не «всё подряд», а три слоя: ресурс, ожидание, запрос. Тогда узкое место видно без шаманства, а не после очередного героического тюнинга вслепую.