Вопрос проверяет умение выбирать информативные метрики и визуализации для контроля высоконагруженных сервисов.
Имеет смысл строить дашборды вокруг latency, error rate, throughput и saturation. Они дают целостное понимание состояния сервиса. Метрики нужно агрегировать по endpoint и типам ошибок. Отдельно полезны дашборды по внешним зависимостям и БД. Хороший дашборд позволяет быстро ответить, «что сломалось и где».
Дашборд — это инструмент быстрого принятия решений, а не просто набор графиков.
Перед перечислением важно зафиксировать: дашборд должен отвечать на конкретные вопросы, а не показывать всё подряд.
Golden signals
latency (p50/p95/p99)
error rate
throughput
saturation
HTTP-уровень
распределение кодов ответов
latency по endpoint
Внешние зависимости
время ответа внешних сервисов
процент ошибок и таймаутов
База данных
количество запросов
время выполнения
использование пулов
Инфраструктура
CPU, memory
file descriptors, connections
Общий health сервиса
Проблемные endpoints
Узкие места зависимостей
Системные лимиты
Слишком много графиков
Отсутствие SLO/SLA контекста
Нет алертов, привязанных к дашборду
Хорошие дашборды фокусируются на ключевых сигналах нагрузки и позволяют за минуты локализовать проблему в высоконагруженном backend-сервисе.
