Почему у вас всё «зелёное», а пользователи уходят: как трейсинг находит скрытые деградации
У вас есть метрики, алерты и дашборды. Всё зелёное. SLA соблюдается. Но пользователи жалуются на тормоза, а бизнес-метрики проседают. В статье разберём, почему классическая observability не показывает реальную картину и как distributed tracing помогает находить скрытые деградации в микросервисах.
Когда «всё работает», но на самом деле - нет
Типичная ситуация в микросервисной системе:
- CPU, память в норме
- ошибок немного
- алерты молчат
- SLA формально соблюдается
И при этом:
- пользователи жалуются на медленные ответы
- конверсия падает
- команда не понимает, где проблема
На практике это особенно болезненно в ключевых пользовательских сценариях: логин, поиск, оформление заказа. Именно там даже небольшая задержка напрямую влияет на деньги.
Главная причина — отсутствие end-to-end видимости одного запроса. Мы наблюдаем систему «снаружи» (метрики) или «по кускам» (логи), но не видим, как конкретный запрос проходит через все сервисы.
Почему метрики не спасают
Метрики - это агрегаты. Они дают удобную, но упрощённую картину.
Что идёт не так:
1. Средние значения скрывают хвосты Latency может быть 100 мс в среднем, но p95 уже 1–2 секунды. Пользователь попадает именно в хвост распределения, а не в «среднее».
2. Нет причинно-следственной связи Метрики показывают, что «где-то стало хуже», но не объясняют:
- почему
- из-за какого сервиса
- из-за какого конкретного вызова
3. Сложно анализировать распределённые цепочки В микросервисах один запрос - это десятки вызовов. Метрики не показывают, как они связаны между собой.
4. «Мягкие деградации» остаются незамеченными Нет ошибок, нет падений, но есть:
- ретраи
- таймауты на грани
- постепенное замедление
И всё это не триггерит алерты.
Что меняет distributed tracing
Distributed tracing даёт недостающий уровень - уровень одного запроса.
Каждый запрос превращается в trace, где видно:
- последовательность вызовов
- длительность каждого шага
- вложенность (кто кого вызвал)
- параллельные и последовательные операции
Это позволяет ответить на ключевой вопрос: «где именно пользователь теряет время?»
Как выглядит trace на практике
В метриках всё может выглядеть нормально. Но trace сразу показывает: проблема в конкретном сервисе и конкретном вызове.
Пример кейса (синтетический, но реалистичный)
Сценарий: оформление заказа.
Было
- p95 latency вырос с 300 мс до 1.5 секунды
- метрики сервисов в норме
- ошибок нет
- алерты не срабатывают
Команда подозревает «что-то в сети» или «нагрузка выросла», но это только догадки.
Сделали
Включили distributed tracing для критического флоу.
Начали анализировать:
- самые медленные трейсы
- повторяющиеся паттерны
- вклад каждого сервиса в общий latency
Что нашли
- N+1 вызовы Один сервис делал несколько последовательных запросов вместо одного агрегированного.
- Скрытые ретраи Retry-механизм увеличивал latency, но не считался ошибкой.
- Деградация внешнего сервиса Он укладывался в таймаут, но стал медленнее в 3 раза.
- Потеря параллелизма Часть вызовов выполнялась последовательно из-за особенностей реализации.
Получили
- latency снизился до ~400 мс
- RCA (root cause analysis, анализ первопричин) сократился с часов до минут
- уменьшилась нагрузка на систему
- стало понятно, куда инвестировать время команды
Анти-паттерны, которые хорошо видны через трейсинг
Это отдельная ценность tracing - он вскрывает архитектурные проблемы.
Часто встречаются:
- N+1 запросы (например, сначала делаем 1 агрегирующий запрос к базе данных, а затем N запросов на каждую из N полученных сущностей для получения недостающих данных)
- чрезмерные ретраи
- длинные цепочки синхронных вызовов
- блокирующие операции в критическом пути
- зависимость от медленных внешних API
Без трейсинга такие проблемы могут жить месяцами.
Метрики vs логи vs трейсинг
Важно: это не замена, а дополнение. Полноценная observability - это комбинация всех трёх.
Что это даёт SRE
Для SRE tracing - это не «ещё один инструмент», а способ сократить неопределённость.
Он даёт:
- быстрый RCA
- понимание системы на уровне взаимодействий
- возможность анализировать реальные user journey
- снижение MTTR (mean time to recovery, среднее время восстановления системы от начала инцидента)
И самое важное - уменьшает количество «гипотез наугад».
Как внедрять tracing без боли
Частая ошибка — пытаться внедрить всё сразу.
Лучше идти по шагам:
1. Выбрать 1-2 критических флоу. Например: checkout или login.
2. Включить трейсинг только для них. Не нужно сразу покрывать всю систему.
3. Добавить базовую инструментацию. Через OpenTelemetry (обычно уже есть автоконфигурация).
4. Начать анализировать tail latency. Искать самые медленные трейсы.
5. Постепенно расширять покрытие
Ограничения и нюансы
Важно понимать, что tracing, как и любой другой инструмент, это не серебряная пуля:
- есть overhead
- нужно хранение данных
- требуется правильная агрегация и sampling
- без культуры анализа пользы будет мало
Но даже базовое внедрение даёт сильный эффект.
Бизнес-ценность
Tracing напрямую влияет на бизнес:
- быстрее устраняются проблемы → меньше потерь
- снижается latency → растёт конверсия
- лучше приоритизация задач → выше эффективность команды
И главное - появляется прозрачность: где именно теряются деньги.
Практические рекомендации
- Смотрите на p95/p99, а не на average
- Анализируйте медленные трейсы, а не все подряд
- Используйте sampling, чтобы не перегружать систему
- Связывайте трейсы с логами и метриками
- Делайте tracing частью процесса RCA
Выводы
- Метрики не дают полной картины в микросервисах
- Основная проблема - отсутствие сквозной видимости запроса
- Distributed tracing решает эту задачу
- Его ключевая ценность 0 понимание причин, а не симптомов
Если у вас «всё зелёное», но пользователи недовольны, то почти наверняка вы просто не видите проблему на уровне одного запроса.
Полезные ссылки
OpenTelemetry: https://opentelemetry.io/
Jaeger: https://www.jaegertracing.io/
OpenTelemetry документация: https://opentelemetry.io/docs/
Jaeger документация: https://www.jaegertracing.io/docs/
Google SRE Book (база SRE): https://sre.google/sre-book/table-of-contents/