Вопрос проверяет понимание роли метрик и наблюдаемости в поиске узких мест производительности.
Мониторинг показывает, где именно тратится время и ресурсы при обработке запросов. Метрики latency, error rate и saturation помогают быстро локализовать проблему. По распределениям (p95, p99) видно, какие запросы деградируют первыми. Сравнение компонентных метрик позволяет понять, это БД, сеть или приложение. Без мониторинга диагностика превращается в догадки.
Производительность нельзя эффективно улучшать без измерений. Мониторинг даёт объективную картину поведения системы под нагрузкой.
Мониторинг — это сбор и анализ метрик, логов и трассировок для оценки состояния и поведения сервиса во времени.
Перед перечислением важно отметить: одиночная метрика редко даёт полный ответ.
Latency
рост p95/p99 при стабильном среднем
Error rate
увеличение 5xx или timeout
Saturation
заполнение пулов соединений
рост очередей
Throughput
падение RPS при той же нагрузке
Сравнение компонент
app latency vs DB latency vs external latency
Трассировка запроса
видно, какой шаг самый медленный
Корреляция метрик
рост latency совпадает с saturation
http_request_duration_seconds_bucket
По гистограмме легко увидеть хвосты распределения.
Смотреть только средние значения
Отсутствие разбиения по endpoint
Нет метрик по внешним зависимостям
Мониторинг позволяет точно определить источник деградации, отделить симптомы от причины и принимать архитектурные решения на основе данных, а не предположений.
