L'intestazione x-b3-sampled è sempre impostata su 0 quando si accede al servizio tramite il controller di ingresso

Aug 20 2020

Ho installato Kubernetes 1.17.5 e Istio 1.6.8 con profilo demo.

Ed ecco la mia configurazione di test [nginx-ingress-controller] -> [proxy<->ServiceA] -> [proxy<->ServiceB]

  • I proxy per serviceA e serviceB vengono inseriti automaticamente da Istio (istio-injection=enabled)
  • Il controller di ingresso Nginx non ha la traccia abilitata e non ha un proxy inviato come sidecar
  • ServiceA passa le intestazioni di tracciamento a ServiceB
  • Sto cercando di tracciare le chiamate da ServiceA a ServiceB e al momento non mi interessa l'intervallo Ingress->ServiceA

Quando invio richieste al controller di ingresso, posso vedere che ServiceA riceve tutte le intestazioni di traccia richieste dal proxy

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

Il problema è che x-b3-sampled è sempre impostato su 0 e nessuna estensione/traccia viene inviata a Jaeger

Poche cose che ho provato

  1. Ho aggiunto Gateway e VirtualService a ServiceA per esporlo tramite Istio ingressgateway. Quando invio il traffico attraverso il gateway di ingresso, tutto funziona come previsto. Vedo tracce [ingress-gateway]->[ServiceA]->[ServiceB] nella JaegerUI
  2. Ho anche provato a installare Istio con la configurazione personalizzata e giocare con i parametri relativi al tracciamento senza fortuna.

Ecco la configurazione che ho provato ad usare

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

Risposte

3 arkadi4 Aug 25 2020 at 22:46

Dopo alcuni giorni di scavo l'ho capito. Il problema è nel formato x-request-iddell'intestazione utilizzata dal controller di ingresso nginx.

Il proxy Envoy si aspetta che sia un UUID (ad esempio x-request-id: 3e21578f-cd04-9246-aa50-67188d790051) ma il controller ingrex lo passa come una stringa casuale non formattata ( x-request-id: 60e82827a270070cfbda38c6f30f478a). Quando passo l'intestazione x-request-id correttamente formattata nella richiesta al controller di ingresso, viene passata al proxy inviato e la richiesta viene campionata come previsto. Ho anche provato a rimuovere l'intestazione x-request-id dalla richiesta dal controller di ingresso a ServiceA con un semplice EnvoyFilter. E funziona anche come previsto. Il proxy Envoy genera un nuovo x-request-id e la richiesta viene tracciata.