Почему первый шаг зависит от условий

В этом опросе нет одного универсально правильного варианта. Рост p95 latency фиксирует симптом, но сам по себе не показывает его причину. Выбор первой проверки зависит от архитектуры сервиса, доступных сигналов и того, что уже известно к началу расследования.

Метрики помогают определить масштаб проблемы: замедлились все эндпоинты или один, все экземпляры или отдельная группа, совпал ли рост задержки с изменением нагрузки или процентом ошибок. При этом агрегированные значения обычно не объясняют, что происходило внутри конкретного запроса.

Логи полезны, если по времени, эндпоинту или идентификатору запроса можно найти медленные операции и увидеть зафиксированные события. Их возможности ограничены тем, какие данные приложение записывает и насколько последовательно устроено логирование.

Трейсы позволяют сравнить путь медленного и обычного запроса и увидеть, на каком участке выросло время выполнения. Однако длинный span указывает на место задержки, но не обязательно на ее первопричину. Кроме того, нужный запрос может не попасть в выборку, а часть операций - остаться без инструментирования.

Проверка зависимостей оправданна, когда устройство сервиса или первые наблюдения указывают на базу данных либо другой компонент. Здесь важны тот же временной интервал и конкретный сценарий: нормальные показатели зависимости в целом не исключают замедления отдельного запроса или операции.

Релиз, изменение конфигурации или рост трафика тоже могут дать рабочую гипотезу, если совпадают по времени с началом деградации. Такое совпадение еще не доказывает причинную связь, поэтому его нужно проверить по другим данным.

Первым полезно выбирать действие, которое быстрее сузит область поиска или проверит наиболее вероятную гипотезу. Дальше расследование обычно требует сопоставить несколько сигналов по времени, эндпоинту, версии сервиса, request ID или trace ID.

Умение выбирать следующий сигнал и последовательно сужать область поиска - одна из базовых задач Observability.