Garantizar la integridad de las trazas con OpenTelemetry: StatefulSets, Helm y equilibrio de carga

¿Por qué el enrutamiento TraceID falla en Kubernetes?

En Kubernetes, los recolectores de OpenTelemetry son típicamente desplegados como un despliegue, con pods detrás de un servicio de carga balanceada. Esto escala bien, pero crea un caos para el muestreo de cola. ¿Por qué? El muestreo de cola evalúa las trazas después de recopilar todos los tramos, lo que requiere que cada tramo para un TraceID llegue al mismo pod colector. Sin un enrutamiento coherente, los tramos se dispersan por los pods, lo que da lugar a trazas incompletas en backends como Google Cloud Trace o Jaeger.

¿Cuál es la causa? La naturaleza apátrida de las implementaciones, en las que los pods carecen de identidades estables. Para garantizar la integridad de las trazas, los spans deben llegar de forma fiable al mismo recopilador backend, especialmente para la detección de errores o el análisis de alta latencia.

Una solución robusta: StatefulSets y recopiladores con equilibrio de carga

Nuestra solución despliega colectores OpenTelemetry en una arquitectura de dos niveles: colectores de equilibrio de carga (frontend) y colectores backend como un StatefulSet. Junto con un servicio headless y Helm, esta configuración garantiza un enrutamiento TraceID coherente y admite el muestreo de cola. Los componentes clave incluyen:

• OpenTelemetry Operator: Automatiza el despliegue de colectores, la instrumentación de cargas de trabajo y las canalizaciones de telemetría para una observabilidad de Kubernetes sin fisuras.

• Colectores de equilibrio de carga: Desplegados como DespliegueEstos recopiladores reciben tramos y utilizan la función de equilibrio de carga para dirigirlos por TraceID a un pod backend específico.

• Recolectores backend (StatefulSet): Configurados como StatefulSet, cada pod tiene un nombre DNS estable (por ejemplo, dev-opentelemetry-backend-collector-0), lo que garantiza un enrutamiento fiable.

• Servicio Headless: A ClusterIP: Ninguno expone los nombres DNS de los pods backend, lo que permite una orientación precisa por parte del exportador de equilibrio de carga.

• Coincidencia de nombres de servicio: El nombre del servicio headless (por ejemplo, dev-opentelemetry-backend-collector-headless) debe coincidir con el de StatefulSet's serviceName para la resolución DNS de Kubernetes.

• Muestreo de Cola: Los recolectores backend aplican políticas (100% para errores/alta latencia, 10% para trazas normales) para priorizar los datos críticos.

• Despliegue de Helm: La dirección opentelemetry-collector Helm simplifica la configuración de ambos niveles de colectores.

Eludir los límites del operador de OpenTelemetry

La página operador de telemetría abierta agiliza la gestión, pero carece de compatibilidad con statefulset.serviceName necesario para los servicios headless. ¿Nuestra solución? Emparejar el operador con el opentelemetry-helm-charts Helm chart, que ofrece un control total sobre StatefulSet y la configuración del servicio, asegurando un correcto enrutamiento basado en DNS.

Cómo funciona: Detalles de la configuración

Implementamos esto utilizando dos configuraciones: el recolector de equilibrio de carga (operator-collector.yaml) y el recopilador backend (recolector backend.yaml). A continuación se muestran extractos clave de una configuración probada.

Colector de equilibrio de carga (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]

Recolector backend (backend-colector.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]

Notas clave:

• El recolector de equilibrio de carga enruta los spans por TraceID a los pods backend a través del servicio headless.

• El StatefulSet del backend coincide con su serviceName con el servicio headless para la resolución DNS.

• El muestreo de cola garantiza que los errores y las trazas de alta latencia se capturen en su totalidad, con un eficiente muestreo de trazas normales.

• El procesamiento por lotes optimiza el rendimiento para el rastreo a gran escala.

Prueba en acción: Resultados de las pruebas

Para validar esta configuración, utilizamos telemetrygen para generar 100 trazas (15 tramos cada una) en las categorías de errores, alta latencia (>1,5 s) y normal, con un objetivo de muestreo del 100% para errores/latencia y del 10% para trazas normales. Las pruebas compararon dos entornos: dev (con equilibrio de carga y colectores backend) y tst (muestreo de cola sin colectores de equilibrio de carga).

Entorno dev:

• Errores: 1500 tramos (100% recogidos).

• Alta latencia: 1500 tramos (100% recogido).

• Normal: 195 tramos (13% recogidos, ligeramente por encima del objetivo, en revisión).

• Para llevar: Alineación de trazas casi perfecta, con todas las trazas de un TraceID llegando al mismo pod backend, asegurando trazas completas.

Entorno Tst:

• Errores988 tramos (65% recogidos, 35% perdidos).

• Alta latencia988 tramos (65% recogidos, 35% perdidos).

• Normal90 tramos (6% recogidos, 40% perdidos).

• Para llevar: Pérdida significativa de tramos debido a la falta de recopiladores de equilibrio de carga, lo que provoca la fragmentación de las trazas, ya que los tramos se dispersan por los pods.

Información clave: El muestreo de cola en Kubernetes falla sin colectores de equilibrio de carga, como se muestra en tstdel 35-40%. En dev demuestra la fiabilidad de la arquitectura para el rastreo de microservicios.

Por qué gana esta solución

Este enfoque ofrece:

• Trazas completas: Los recopiladores con equilibrio de carga garantizan la integridad de las trazas para un muestreo de cola preciso.

• Muestreo inteligente: Da prioridad a los errores y a las trazas de alta latencia a la vez que realiza un muestreo eficiente de las trazas normales.

• Escalabilidad: StatefulSets y el autoescalado (9-30 réplicas) gestionan el trazado a gran escala sin esfuerzo.

• Facilidad de uso: Helm y el Operador OpenTelemetry simplifican el despliegue, evitando las limitaciones del operador.

• Resultados probados: Las pruebas confirman devfrente a tstvalidando la configuración para la observabilidad de Kubernetes.

Casos de uso

Perfecto para:

• Monitorización de Microservicios: Visibilidad completa de sistemas distribuidos.

• DevOps y SRE: Depuración más rápida con trazas fiables.

• Clústeres a gran escala: Gestión de grandes volúmenes de trazas en Kubernetes.

• Muestreo de cola: Análisis avanzado de errores y latencia.

Empiece hoy mismo

No deje que fragmentación de trazas frene a su equipo. Con OpenTelemetry, StatefulSetsy colectores de equilibrio de cargapuede dominar observabilidad de Kubernetes.

Nuestras configuraciones probadas (operator-collector.yaml, backend-collector.yaml) y Helm-hacen que la implementación sea pan comido.

Explorar el OpenTelemetry Helm Gráficos o OpenTelemetry documentación para profundizar.

¿Quieres mejorar el seguimiento de tus microservicios? Póngase en contacto con nuestros expertos en observabilidad para obtener ayuda práctica.