Assurer l'intégrité des traces avec OpenTelemetry : StatefulSets, Helm et équilibrage de charge

Pourquoi le routage de TraceID échoue dans Kubernetes

Dans Kubernetes, les collecteurs OpenTelemetry sont généralement déployés en tant que déploiement, avec des pods derrière un service à charge équilibrée. Cela permet une bonne mise à l'échelle, mais crée un chaos pour l'échantillonnage de queue. Pourquoi ? L'échantillonnage de queue évalue les traces après avoir collecté toutes les portées, ce qui nécessite que chaque portée pour un TraceID atteigne le même pod collecteur. En l'absence d'un routage cohérent, les travées se dispersent entre les pods, ce qui conduit à des traces incomplètes dans les backends tels que Google Cloud Trace ou Jaeger.

Le coupable ? La nature sans état des déploiements, où les pods n'ont pas d'identités stables. Pour garantir l'intégrité des traces, les travées doivent atteindre de manière fiable le même collecteur backend, en particulier pour la détection des erreurs ou l'analyse des temps de latence élevés.

Une solution robuste : StatefulSets et collecteurs à équilibrage de charge

Notre solution déploie les collecteurs OpenTelemetry dans une architecture à deux niveaux : collecteurs d'équilibrage de charge (frontend) et collecteurs backend en tant que StatefulSet. Associée à un service sans tête et à Helm, cette configuration garantit un routage cohérent des TraceID et prend en charge l'échantillonnage de queue. Les composants clés sont les suivants

• OpenTelemetry Operator : Automatise le déploiement des collecteurs, l'instrumentation des charges de travail et les pipelines de télémétrie pour une observabilité transparente de Kubernetes.

• Collecteurs à équilibrage de charge : Déployés en tant que déploiementCes collecteurs reçoivent des travées et utilisent la fonction loadbalancing pour les acheminer par TraceID vers un pod backend spécifique.

• Collecteurs backend (StatefulSet) : Configuré comme un StatefulSet, chaque pod a un nom DNS stable (par exemple, dev-opentelemetry-backend-collector-0), ce qui garantit un routage fiable.

• Service sans tête: A ClusterIP : Aucun expose les noms DNS des pods backend, ce qui permet un ciblage précis par l'exportateur d'équilibrage de charge.

• Correspondance des noms de service: Le nom du service headless (par exemple, dev-opentelemetry-backend-collector-headless) doit correspondre au nom du service StatefulSet's serviceName pour la résolution DNS de Kubernetes.

• Échantillonnage de queue: Les collecteurs dorsaux appliquent des politiques (100 % pour les erreurs/la latence élevée, 10 % pour les traces normales) pour donner la priorité aux données critiques.

• Déploiement de Helm: L'outil opentelemetry-collector Helm simplifie la configuration des deux niveaux de collecteurs.

Contournement des limites de l'opérateur OpenTelemetry

Le tableau de bord de l'opérateur d'OpenTelemetry OpenTelemetry Operator simplifie la gestion, mais ne prend pas en charge le paramètre statefulset.serviceName nécessaire pour les services sans tête. Notre solution ? Associer l'opérateur à l'outil opentelemetry-helm-charts qui offre un contrôle total sur les paramètres de StatefulSet et de service, garantissant un routage correct basé sur le DNS.

Comment ça marche : Détails de la configuration

Nous implémentons ceci en utilisant deux configurations : le collecteur d'équilibrage de charge (operator-collector.yaml) et le collecteur backend (backend-collector.yaml). Vous trouverez ci-dessous des extraits clés d'une configuration testée.

Collecteur à équilibrage de charge (operator-collector.yaml) :

open_telemetry_collectors:
  main:
    name: "dev-opentelemetry-main"
    replicas: 9
    config:
      receivers:
        otlp:
          protocols:
            grpc:
              endpoint: 0.0.0.0:4317
      processors:
        batch:
          send_batch_size: 20000
          timeout: 5s
      exporters:
        loadbalancing:
          routing_key: "traceID"
          protocol:
            otlp:
              tls:
                insecure: true
          resolver:
            k8s:
              service: dev-opentelemetry-backend-collector-headless.otel-dev
      service:
        pipelines:
          traces:
            receivers: [otlp]
            processors: [batch]
            exporters: [loadbalancing]

Collecteur dorsal (backend-collector.yaml) :

opentelemetry-collector:
  nameOverride: "dev-opentelemetry-backend-collector"
  mode: statefulset
  replicaCount: 9
  serviceName: dev-opentelemetry-backend-collector-headless
  service:
    type: ClusterIP
    clusterIP: None
  config:
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
    processors:
      tail_sampling:
        num_traces: 10000
        decision_wait: 10s
        policies:
          - name: error-policy
            type: and
            and_sub_policy:
              - name: error-status
                type: status_code
                status_codes: [ERROR]
              - name: error-sampling
                type: probabilistic
                sampling_percentage: 100
          - name: latency-policy
            type: latency
            latency:
              threshold_ms: 1000
            probabilistic:
              sampling_percentage: 100
          - name: normal-policy
            type: probabilistic
            probabilistic:
              sampling_percentage: 10
      batch:
        send_batch_size: 20000
    exporters:
      googlecloud:
        project: gcp-dev-otel
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [tail_sampling, batch]
          exporters: [googlecloud]

Notes sur les clés:

• Le collecteur d'équilibrage de charge achemine les travées par TraceID vers les pods backend via le service headless.

• Le StatefulSet du backend correspond à son serviceName au service sans tête pour la résolution DNS.

• L'échantillonnage de queue garantit que les erreurs et les traces à forte latence sont entièrement capturées, avec un échantillonnage efficace des traces normales.

• Le traitement par lots optimise le débit pour le traçage à grande échelle.

La preuve en action : Résultats des tests

Pour valider cette configuration, nous avons utilisé telemetrygen pour générer 100 traces (15 portées chacune) dans les catégories erreurs, haute latence (>1,5s) et normale, en visant un échantillonnage de 100% pour les erreurs/latence et de 10% pour les traces normales. Les tests ont comparé deux environnements : dev (avec équilibrage de charge et collecteurs backend) et tst (échantillonnage de queue sans collecteurs d'équilibrage de charge).

Environnement dev:

• Erreurs: 1500 travées (100% collectées).

• Haute latence: 1500 travées (100% collectées).

• Normal: 195 travées (13 % collectées, légèrement au-dessus de l'objectif, en cours d'examen).

• À emporter: Alignement presque parfait des traces, toutes les travées d'une TraceID atteignant le même pod backend, ce qui garantit des traces complètes.

Environnement Tst:

• ErreursTraceID : 988 travées (65 % collectées, 35 % perdues).

• Haute latence: 988 travées (65% collectées, 35% perdues).

• Normal : 90 portées (6% collectées, 40% perdues).90 travées (6 % collectées, 40 % perdues).

• A emporter: Perte importante de travées due à l'absence de collecteurs d'équilibrage de charge, ce qui entraîne une fragmentation de la trace car les travées sont dispersées dans les pods.

Aperçu clé: L'échantillonnage de queue dans Kubernetes échoue sans collecteurs d'équilibrage de charge, comme le montre l'exemple suivant tstde 35 à 40 %. Le collecteur dev prouve la fiabilité de l'architecture pour le traçage des microservices.

Pourquoi cette solution est gagnante

Cette approche permet d'obtenir

• Des traces complètes: Les collecteurs à équilibrage de charge garantissent l'intégrité des traces pour un échantillonnage précis de la queue.

• Échantillonnage intelligent: Donne la priorité aux erreurs et aux traces à forte latence tout en échantillonnant efficacement les traces normales.

• Évolutivité: StatefulSets et la mise à l'échelle automatique (9-30 répliques) gèrent sans effort le traçage à grande échelle.

• Facilité d'utilisation: Helm et OpenTelemetry Operator simplifient le déploiement, en contournant les limitations de l'opérateur.

• Des résultats éprouvés: Les tests confirment que devpar rapport à tstvalidant ainsi la configuration de l'observabilité de Kubernetes.

Cas d'utilisation

Parfait pour :

• Surveillance des microservices: Visibilité complète des systèmes distribués.

• DevOps et SRE: Débogage plus rapide grâce à des traces fiables.

• Clusters à grande échelle: Gestion de gros volumes de traces dans Kubernetes.

• Échantillonnage de queue: Analyse avancée des erreurs et de la latence.

Commencez dès aujourd'hui

Ne laissez pas fragmentation des traces ralentir votre équipe. Avec OpenTelemetry, StatefulSetset les collecteurs collecteurs d'équilibrage de chargeGrâce à ces outils, vous pouvez maîtriser l'observabilité de Kubernetes. l'observabilité de Kubernetes.

Nos configurations testées (operator-collector.yaml, backend-collector.yaml) et Helm-font de la mise en œuvre un jeu d'enfant.

Explorez les Graphiques Helm d'OpenTelemetry ou la documentation OpenTelemetry pour aller plus loin.

Vous voulez booster votre traçage de microservices ? Contactez nos experts en observabilité pour une assistance pratique !