El encabezado muestreado x-b3 siempre se establece en 0 cuando se accede al servicio a través del controlador de ingreso

Aug 20 2020

Tengo Kubernetes 1.17.5 e Istio 1.6.8 instalados con un perfil de demostración.

Y aquí está mi configuración de prueba [nginx-ingress-controller] -> [proxy <-> ServiceA] -> [proxy <-> ServiceB]

  • Istio inyecta automáticamente los proxies para serviceA y serviceB (istio-injection = habilitado)
  • El controlador de ingreso de Nginx no tiene el seguimiento habilitado y no tiene un proxy de enviado como sidecar
  • ServiceA pasa los encabezados de seguimiento a ServiceB
  • Estoy tratando de rastrear las llamadas de ServiceA a ServiceB y no me importa Ingress-> ServiceA span en este momento

Cuando envío solicitudes al controlador de entrada, puedo ver que ServiceA recibe todos los encabezados de seguimiento necesarios del 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

El problema es que x-b3-muestreado siempre se establece en 0 y no se envían intervalos / trazas a Jaeger

Pocas cosas he probado

  1. Agregué Gateway y VirtualService a ServiceA para exponerlo a través de Istio ingressgateway. Cuando envío tráfico a través de ingressgateway, todo funciona como se esperaba. Puedo ver rastros [entrada-puerta de enlace] -> [ServiceA] -> [ServiceB] en JaegerUI
  2. También intenté instalar Istio con una configuración personalizada y jugar con el rastreo de parámetros relacionados sin suerte.

Aquí está la configuración que intenté usar

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

Respuestas

3 arkadi4 Aug 25 2020 at 22:46

Después de unos días de excavación, lo he descubierto. El problema está en el formato del x-request-idencabezado que usa el controlador de entrada nginx.

El proxy Envoy espera que sea un UUID (por ejemplo x-request-id: 3e21578f-cd04-9246-aa50-67188d790051), pero el controlador ingrex lo pasa como una cadena aleatoria sin formato ( x-request-id: 60e82827a270070cfbda38c6f30f478a). Cuando paso el encabezado x-request-id con el formato adecuado en la solicitud al controlador de entrada, se transmite al proxy del enviado y la solicitud se muestra como se esperaba. También intenté eliminar el encabezado x-request-id de la solicitud del controlador de entrada a ServiceA con un EnvoyFilter simple. Y también funciona como se esperaba. El proxy de Envoy genera un nuevo x-request-id y se está rastreando la solicitud.