Заголовок x-b3-sampled всегда имеет значение 0 при доступе к службе через контроллер входящего трафика.

Aug 20 2020

У меня установлены Kubernetes 1.17.5 и Istio 1.6.8 с демо-профилем.

А вот и моя тестовая установка [nginx-ingress-controller] -> [прокси <-> ServiceA] -> [прокси <-> ServiceB]

  • Istio автоматически вводит прокси для serviceA и serviceB (istio-injection = enabled)
  • Контроллер входящего трафика Nginx не имеет включенной трассировки и не имеет прокси-сервера envoy в качестве сопутствующего компонента.
  • ServiceA передает заголовки трассировки в ServiceB
  • Я пытаюсь отследить звонки из ServiceA в ServiceB, и в данный момент мне не важен диапазон Ingress-> ServiceA.

Когда я отправляю запросы входящему контроллеру, я вижу, что ServiceA получает все необходимые заголовки трассировки от прокси.

x-b3-traceid: d9bab9b4cdc8d0a7772e27bb7d15332f
x-request-id: 60e82827a270070cfbda38c6f30f478a
x-envoy-internal: true
x-b3-spanid: 772e27bb7d15332f
x-b3-sampled: 0
x-forwarded-proto: http

Проблема в том, что x-b3-sampled всегда имеет значение 0, и никакие промежутки / следы не отправляются в Jaeger.

Мало что я пробовал

  1. Я добавил в ServiceA шлюз и VirtualService, чтобы открыть его через входной шлюз Istio. Когда я отправляю трафик через ingressgateway, все работает как положено. Я вижу следы [ingress-gateway] -> [ServiceA] -> [ServiceB] в JaegerUI
  2. Я также пытался установить Istio с настраиваемой конфигурацией и безуспешно поигрался с параметрами трассировки.

Вот конфигурация, которую я пытался использовать

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
  addonComponents:
    tracing:
      enabled: true
    grafana:
      enabled: false
    istiocoredns:
      enabled: false
    kiali:
      enabled: false
    prometheus:
      enabled: false
  values:
    tracing:
      enabled: true
    pilot:
      traceSampling: 100

Ответы

3 arkadi4 Aug 25 2020 at 22:46

После нескольких дней копания я понял это. Проблема в формате x-request-idзаголовка, который использует контроллер входящего трафика nginx.

Прокси-сервер Envoy ожидает, что это будет UUID (например x-request-id: 3e21578f-cd04-9246-aa50-67188d790051), но контроллер ingrex передает его как неформатированную случайную строку ( x-request-id: 60e82827a270070cfbda38c6f30f478a). Когда я передаю правильно отформатированный заголовок x-request-id в запросе на входной контроллер, он передается прокси-серверу, и запрос получает выборку, как ожидалось. Я также попытался удалить заголовок x-request-id из запроса от входящего контроллера к ServiceA с помощью простого EnvoyFilter. И это тоже работает, как ожидалось. Прокси-сервер Envoy генерирует новый идентификатор x-запроса, и запрос отслеживается.