Коммерческое предложение готовится слишком долго. Команда каталога отвечает, что поиск оборудования быстрый. Расчёт скидки тоже укладывается в норму. Сервис доставки вообще вызывается параллельно. По отдельности всё выглядит приемлемо, а менеджер перед клиентом ждёт результат и не понимает, можно ли продолжать разговор.
Distributed Tracing помогает восстановить измеренный путь одной операции через приложения и зависимости. Вместо сравнения чужих средних показателей команда получает конкретное выполнение: какие шаги начались, сколько длились и как были связаны. Но слово «измеренный» здесь важно. Неинструментированную часть работы трасса сама не дорисует.
Из каких частей собирается история
Отдельный измеряемый шаг называют span. Это может быть обработка входящего запроса, обращение к базе или вызов сервиса расчёта. У шага есть начало, конец и контекст связи с другими шагами. Вместе они образуют трассу, по которой можно пройти от внешнего запроса к внутренним действиям.
Автоматическая инструментация библиотек часто показывает сетевые вызовы и запросы к базе. Но она не обязана понимать, что приложение между ними ждёт свободное соединение или выполняет важную бизнес-проверку. Для таких мест нужны дополнительные измерения. Модель шагов описана в документации OpenTelemetry.
Не стоит записывать каждый внутренний метод. Начать полезнее с границ, на которых действительно теряется объяснение: ожидание ресурса, дорогой расчёт, внешний вызов. Иначе длинная история с тысячами мелких шагов затруднит поиск почти так же, как полное отсутствие истории.
Время на диаграмме нельзя просто сложить
Каталог и доставка могут запрашиваться одновременно. Складывая их длительности, мы посчитаем часть ожидания дважды. Вложенные шаги также входят во время родительского шага. Для задержки клиента важна последовательность, определяющая момент готовности всего ответа, а не сумма всех полосок.
Длинный span не обязательно означает долгую работу процессора. Он может включать ожидание соединения, блокировки или удалённого ответа. И даже видимый длинный вызов партнёра не доказывает неисправность его сервера: без измерений на другой стороне мы знаем только время, наблюдаемое нашим приложением.
Пустой промежуток тоже нельзя автоматически назвать «проблемой сети». Возможно, там просто нет измерения. При сопоставлении времён разных машин нужно учитывать синхронизацию часов. Трасса помогает сузить поиск; окончательное объяснение иногда потребует метрик ресурсов, журналов или профилирования кода.
Очередь не должна обрывать связь
Допустим, предложение рассчитывают в фоне. Приём запроса завершается раньше, чем начинается обработка задания. Можно сохранить связь через метаданные сообщения, а отдельные выполнения связать ссылками между spans. Для долгой цепочки не требуется держать один родительский запрос открытым до самого конца.
Нужно различать время в очереди и длительность обработки. Если измеряется только работа исполнителя, трасса покажет быстрый расчёт, хотя клиент долго ждал свободного обработчика. Повторные попытки также должны быть различимы, а не сливаться в одно неясное обращение.
Идентификатор предложения полезно сохранить независимо от trace ID: разные попытки одной бизнес-операции могут иметь разные трассы. Такой идентификатор помогает найти выполнение, но не даёт прав читать чужое предложение. Контекст не заменяет авторизацию. Принципы его передачи разобраны в руководстве OpenTelemetry.
Почему нужной трассы может не оказаться
При большом потоке обычно сохраняют выборку. Head sampling принимает решение в начале и ещё не знает, закончится ли запрос ошибкой. Tail sampling выбирает по собранным шагам, например по длительности или ошибке, но требует ресурсов и времени ожидания. Он не вернёт данные, уже отброшенные раньше. Ограничения обоих подходов описаны в документации по sampling.
Поэтому отсутствие трассы не доказывает отсутствие операции. И доля ошибок среди специально отобранных неудачных запросов не показывает качество всей системы. Для общей оценки нужны показатели с известным охватом, а не статистика удобной диагностической выборки.
Особенно важно проверить этот разрыв на редкой проблеме. Сможет ли поддержка хотя бы найти статус предложения, если подробная трасса не сохранена? Учёт бизнес-операций должен оставаться доступным независимо от политики хранения диагностики.
Где заканчивается полезная подробность
В атрибуты легко случайно отправить весь запрос вместе с ценами, персональными данными или токеном. Для поиска причины обычно достаточно названия операции, версии сервиса и разрешённых признаков. Правила удаления чувствительных данных нужно применять и к автоматически собранным полям, а не только к собственным сообщениям.
Нужны наблюдение за потерями телеметрии и проверка, что отправка трасс не блокирует основную работу. Сбой диагностического хранилища не должен останавливать расчёт предложений. При этом команда должна видеть, что часть доказательств сейчас недоступна.
Что показать при приёмке
Попросите показать медленное тестовое предложение целиком: приём, ожидание, расчёт, повторы и публикацию результата. Затем измените одну зависимость в контролируемом испытании и проверьте, видно ли отличие. Если связность теряется на очереди, первым исправлением должна стать передача контекста, а не замена хранилища трасс.
Когда причина найдена, решение может оказаться продуктовым: предварительно готовить часть расчёта, не ждать необязательных данных или убрать повторное обращение. Именно такие изменения и стоит сравнивать по времени получения результата. Количество сохранённых spans само по себе менеджеру перед клиентом не помогает.