OpenTelemetry на сто двадцать сервисов — это не техническая, а организационная задача. Расскажите, как вы убеждали команды, что трейсинг им нужен, почему вы выбрали tail-based sampling вместо head-based, как вы решили проблему с необходимостью доставлять все спаны одного трейса в один коллектор и что вы вынесли в готовую обёртку, чтобы порог входа был нулевой? Если бы трейсинг был провален в какой-то команде, что бы вы сделали по-другому?

Расскажите о реальном внедрении через пользу для команд, стандарт подключения и измеряемое покрытие. Tail sampling помогает сохранять ошибки и медленные трейсы, но требует доставки их спанов одному обработчику.

Не придумывайте опыт на 120 сервисах. Как план: начните с пилота на проблемном пути, покажите ускорение диагностики и подготовьте обёртку с propagation, ресурсными атрибутами, OTLP, редактированием чувствительных полей и безопасными defaults. При tail sampling маршрутизируйте по trace_id и учитывайте смену состава коллекторов, память, поздние спаны и потери. В отличие от head sampling решение принимает больше контекста, но весь входной поток всё равно нужно принять. Для отстающей команды выясните препятствие и помогите с интеграцией; не считайте установку SDK доказательством полезного трейсинга.

Источник: opentelemetry.io.