Critical path, ошибки и сравнение трейсов

Три продвинутых приёма анализа: критический путь (что реально тормозит запрос), работа с ошибками и сравнение двух трейсов «было/стало».

Critical path

Трейс из 40 спанов, а общая длительность — 2 секунды. Какая часть спанов реально влияет на итог? Критический путь — цепочка спанов, определяющая общее время: тот, кто занял корень, пока не начинался следующий шаг.

• В UI включите отображение критического пути (кнопка Critical Path / трассировка подсветит сегменты): видно, например, что «ждать кеш» + «банк-API» = 90% времени, а остальное «параллельно и бесплатно»;
• Оптимизировать надо сначала критический путь: ускорение не-критических сегментов не изменит p99 вообще;
• Если два сегмента идут параллельно, критичным становится медленнейший — ещё один аргумент за fan-out вместо последовательных вызовов.

Последовательно:  A(200ms) → B(300ms) → C(100ms)  = 600ms
Параллельно:      A(200ms) ∥ (B(300ms), C(100ms)) = 500ms  ← критический путь = max(A,B)

Ошибки в трейсе

• Спаны со статусом ERROR подсвечены красным; у корневого спана — итог запроса;
• Событие exception (record_exception, урок 2.1) содержит тип и стектрейс — читается в панели спана;
• Отличайте «ошибку» от «неудачи»: 404 для отсутствующей записи может быть легитимным бизнес-исходом — не помечайте ERROR там, где инцидента нет, иначе алерты на error=true замылятся;
• Поиск ошибочных: error=true (урок 4.1) + фильтр сервиса.

Сравнение трейсов (Trace Comparison)

В UI выберите два трейса одной операции (например, «быстрый» и «медленный» экземпляр) — Jaeger покажет их рядом с разницей длительностей сегментов:

• Появилась лишняя нога (новый вызов кеша, retry) — сразу видна;
• Один сегмент вырос в N раз — локализован;
• Сравнение до/после релиза — быстрый способ увидеть регресс;
• Сравнивайте операции одного типа и близкие по времени, иначе различия параметров замутнят картину.

Гистограммы и статистика

Таб «Trace Stats» в UI раскладывает трейс: сколько спанов у каждого сервиса, суммарное время, число ошибок. Полезно для «трейс-в-отчёт»: одна строка «payments: 3 спана, 350мс, 1 ошибка» говорчивее списка из 40 строк.

Мини-методика анализа (сводная)

1. Открыть трейс → flame graph → какое поддерево доминирует;
2. Включить critical path → что реально в бюджете;
3. Сравнить с «хорошим» трейсом той же операции;
4. Развернуть атрибуты спана-виновника (параметры запроса, размер батча, кеш-хит);
5. Перейти в логи по trace_id (урок 2.4) → найти причину в тексте;
6. Сформулировать вывод: «80% времени — HTTP к X; параллелизовать или кешировать».

Практика

1. Постройте трейс с двумя последовательными внешними вызовами; включите critical path и убедитесь, что он оба включил; затем распараллельте вызовы и посмотрите, как путь «сжался».
2. Сгенерируйте ошибку в глубоком спане — найдите в UI: красный спан, exception-событие, корневой ERROR.
3. Сделайте две версии одного endpoint'а (с кешем/без) и сравните трейсы в UI; зафиксируйте разницу сегментов.