Поделитесь опытом, кто внедрял у себя готовые решения для distributed tracing?

Они разве на стэк технологий не завязаны? Зипкин и жагер у джавистов вроде (для примеру).

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

есть у нас егерь, показался наиболее удобным с точки зрения UI и производительности. но мы туда довольно мало пишем, поэтому, вряд ли наш опыт репрезентативен

Мы джагер используем в php и go, правда хранилище in memory, касандра и эластик не оч работали, когда мы их пробовали. Даже на небольшом количестве сервисов удобно смотреть сквозные трейсы и понимать кто вносит наибольший вклад в тормоза.

Юзаем джагер(python/go/ruby), интегрируется довольно просто, удобно смотреть как конкретный запрос по микросервисам прошел(плюсом показывается время запросов в базу, и свои какие-то метрики).<br>Но UI показался не очень - фильтровать запросы порой неудобно, общую статистику по запросам не посмотреть(например сколько запросов какого типа было, какой запрос тормознее всего).

Mike Kabischev

Используем егерь.<br>В девел-среде in memory, в прод планируем эластику.<br><br>Без егеря разбирать проблемы бекенда в SOA — адова Сатана. Trace-request-Id является обязательным для всех, кто приходит с вопросами в бекенд. Начинали мы без трассировки и достаточно быстро поняли, что это очень не удобно. Изобрели свой велосипед, но потом отказались от него в пользу стандартного opentracing <br><br>Также во все логи пишется этот сквозной идентификатор, потому посмотрев в UI на проблемную точку, всегда можно найти детали в логах.<br><br>Нужно понимать, что трассировка — не бесплатна, потому сервисы должны иметь возможность:<br>1) отключать трассировку<br>2) настраивать тротлинг

Во многом service-mesh может многие вопросы закрыть, при этом без инструментирования кода (это может быть проблемой в случае, если сервисов много и они на разных стеках).