Авто следы следов в посланнике - PullRequest
Новая
       86

Авто следы следов в посланнике

0 голосов
/ 21 января 2020

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

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

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

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

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

Ответы [ 2 ]

3 голосов
/ 05 февраля 2020

При выполнении трассировки в сервисе me sh, за прокси, traceID, сгенерированный при первоначальном клиентском вызове, распространяется автоматически только до тех пор, пока вызов идет от proxy-> proxy.

Итак:

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

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

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

0 голосов
/ 21 января 2020

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

Поэтому он предупреждает против ситуаций, когда:

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

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

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

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

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

Служба A -> Служба B # использование запроса http, идентификатор трассировки направляется в службу B.

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

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

...