Следы автораспространения в посланнике

На основе документации envoy может создавать и распространять следы до сервисного кластера Jaeger.

В нем также говорится, что

Чтобы в полной мере воспользоваться преимуществами трассировки, приложение должно распространять заголовки трассировки, которые Envoy генерирует при обращении к другим службам.

Предположим, что если клиент звонит - ›служба A -› вызывает службу B, служба A находится за посланником. Если служба A вызывает службу B, этот вызов от A к B также должен пройти через право посланника. Таким образом, отслеживаемый идентификатор, который изначально был сгенерирован посланником, когда клиент вызвал службу A, не будет распространен на службу B.

Почему приложению (службе A) необходимо пересылать эти заголовки?


istio envoyproxy distributed-tracing opentracing distributed
person Vipin Menon    schedule 21.01.2020    source источник
comment
Только приложение может знать, является ли клиентский вызов от A к B результатом предыдущего вызова или чего-то другого / несвязанного. Посланник не может сделать этого предположения. Вот почему вам нужно распространять заголовки.   -  person Joel    schedule 21.01.2020

Ответы (2)


arrow_upward
3
arrow_downward

При выполнении трассировки в служебной сетке за прокси-серверами идентификатор трассировки, сгенерированный при первоначальном вызове клиента, автоматически распространяется только до тех пор, пока вызов идет от прокси-> прокси.

So:

  1. Клиент отправляет запрос
  2. Запрос попадает в какой-либо входящий прокси. Идентификатор трассировки генерируется
  3. Запрос направляется на прокси-сервер A перед услугой A. Идентификатор трассировки распространяется от входящего прокси-сервера к прокси-серверу A.
  4. Запрос попадает в микросервис A. Идентификатор трассировки передается сюда в заголовках.
  5. Микросервис A теперь полностью контролирует запрос. Если служба отбрасывает все заголовки HTTP при отправке исходящего запроса службе B, то идентификатор трассировки также будет отброшен.

Чтобы обойти это, микросервису A просто нужно знать, какие заголовки представляют идентификаторы трассировки, как добавить в них и какое состояние, чтобы убедиться, что он попадает в исходящие запросы. Тогда вы получите полную цепочку транзакций.

Без службы, распространяющей заголовки, трассировка в основном дает вам каждый путь, который заканчивается микросервисом. По-прежнему полезно, но не так полно.

person justincely    schedule 05.02.2020

arrow_upward
0
arrow_downward

Я интерпретирую это так: нам нужно иметь в виду, что связь между службами должна поддерживать пересылку / передачу идентификаторов трассировки, чтобы трассировка работала правильно.

Таким образом, он предостерегает нас от ситуаций, когда:

Клиентские вызовы - ›Служба A # с использованием HTTP-запроса с идентификатором трассировки в заголовке.

Служба A - ›Служба B # при использовании запроса TCP, который не поддерживает заголовки, и заголовок идентификатора трассировки теряется.

Эта ситуация может нарушить или ограничить функциональность трассировки.

С другой стороны, если у нас есть ситуация, когда:

Клиентские вызовы - ›Служба A # с использованием HTTP-запроса с идентификатором трассировки в заголовке.

Служба A - ›Служба B # с помощью HTTP-запроса идентификатор трассировки пересылается в службу B.

В этой ситуации заголовок идентификатора трассировки может присутствовать в обоих соединениях, поэтому трассировку можно регистрировать, а затем просматривать на панели мониторинга службы трассировки. Затем мы можем изучить путь, пройденный запросом, и просмотреть задержку, возникающую на каждом переходе.

Надеюсь, поможет.

person Piotr Malec    schedule 21.01.2020