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



Коллеги, добрый день ! Поделитесь опытом, кто внедрял у себя готовые решения для distributed tracing? Zipkin, Jaeger, Appdash? OpenTrace, OpenCensus? Много ли сил потратили? Довольны ли результатом? Плюсы, минусы, подводные грабли?

Спасибо!

685   8  

Comments

  1. Alexey Rybak
    Alexey Rybak 4 года назад
    Они разве на стэк технологий не завязаны? Зипкин и жагер у джавистов вроде (для примеру).
  2. Alexey Rybak
    Alexey Rybak 4 года назад
    меня вот в связи с твоим вопросом другое интересует: не кажется ли тебе, что если назрела необходимость в подобном анализе, то архитектура стала чересчур сложной? в тех некоторых примерах, о которых я слышал, я рискнул бы предположить, что архитектура была подозрительно "микросервисной", может быть более "микросервисной", чем нужно.
  3. Константин Замякин
    Константин Замякин 4 года назад
    есть у нас егерь, показался наиболее удобным с точки зрения UI и производительности. но мы туда довольно мало пишем, поэтому, вряд ли наш опыт репрезентативен
  4. Николай Рыбин
    Николай Рыбин 4 года назад
    Мы джагер используем в php и go, правда хранилище in memory, касандра и эластик не оч работали, когда мы их пробовали. Даже на небольшом количестве сервисов удобно смотреть сквозные трейсы и понимать кто вносит наибольший вклад в тормоза.
  5. Дмитрий Давыдов
    Дмитрий Давыдов 4 года назад
    Юзаем джагер(python/go/ruby), интегрируется довольно просто, удобно смотреть как конкретный запрос по микросервисам прошел(плюсом показывается время запросов в базу, и свои какие-то метрики).<br>Но UI показался не очень - фильтровать запросы порой неудобно, общую статистику по запросам не посмотреть(например сколько запросов какого типа было, какой запрос тормознее всего).
  6. Sergey Orlov
    Sergey Orlov 4 года назад
    Mike Kabischev
  7. Антон Герасимов
    Антон Герасимов 4 года назад
    Используем егерь.<br>В девел-среде in memory, в прод планируем эластику.<br><br>Без егеря разбирать проблемы бекенда в SOA — адова Сатана. Trace-request-Id является обязательным для всех, кто приходит с вопросами в бекенд. Начинали мы без трассировки и достаточно быстро поняли, что это очень не удобно. Изобрели свой велосипед, но потом отказались от него в пользу стандартного opentracing <br><br>Также во все логи пишется этот сквозной идентификатор, потому посмотрев в UI на проблемную точку, всегда можно найти детали в логах.<br><br>Нужно понимать, что трассировка — не бесплатна, потому сервисы должны иметь возможность:<br>1) отключать трассировку<br>2) настраивать тротлинг
  8. Стас Щетинников
    Стас Щетинников 4 года назад
    Во многом service-mesh может многие вопросы закрыть, при этом без инструментирования кода (это может быть проблемой в случае, если сервисов много и они на разных стеках).