Как объединить разрозненные трейсы Istio и OpenTelemetry¶
7.0/10
Контекст¶
Istio и Kiali быстро дают метрики и топологию трафика, но при добавлении OpenTelemetry-инструментации трейсы могут распадаться на отдельные деревья. Авторы описывают случай, когда после установки Istio поверх OpenTelemetry Demo один и тот же запрос выглядел как два независимых набора спанов: от приложения и от Envoy-sidecar.
Суть¶
Причина разрыва — несовпадение механизмов распространения trace-контекста: приложения используют W3C Trace Context, а встроенный OTel-трейсер Envoy, по словам авторов, не читает входящий traceparent и создаёт новый корневой спан. Решение состоит в том, чтобы перевести Envoy на Zipkin-трейсер, который извлекает B3-контекст, и направить его спаны в Zipkin-ресивер OpenTelemetry Collector на порту 9411. Одновременно приложениям добавляют propagator b3multi рядом с tracecontext и baggage, чтобы они продолжали передавать W3C-заголовки, но также отправляли B3-заголовки, понятные Envoy. Collector здесь выступает точкой интеграции: он принимает телеметрию в разных форматах, нормализует её и отправляет в один backend. После этих изменений вместо кластеров примерно из 2 или 14 спанов авторы получили единый трейс checkout на 51–75 спанов, включающий и прикладную логику, и сетевые hop’ы прокси.
Вывод¶
Авторы утверждают, что в смешанных средах проблема не в отсутствии телеметрии, а в её фрагментации из-за несовместимого context propagation. Практический вывод — использовать OpenTelemetry Collector как центр нормализации форматов и явно согласовывать propagation между mesh-прокси и приложениями.