Implementación de Rastreo Distribuido con OpenTelemetry en Telefónica Kernel

Cuando se opera y evoluciona un sistema complejo, la observabilidad es imprescindible. Normalmente, muchos componentes y capas de software se entrelazan en flujos complejos. Como resultado, es difícil extraer algunas ideas valiosas para diagnosticar y abordar los principales cuellos de botella en el rendimiento o reducir el retraso e2e. En la misma dirección, poder rastrear solicitudes específicas a través del sistema e2e es clave para una depuración adecuada de errores o escenarios hipotéticos. 

Tradicionalmente, la observabilidad de los sistemas se basa en tres pilares principales: Registros, Métricas y Rastreo (aunque se pueden considerar algunos pilares extra, los mantendremos fuera del ámbito de este post). En este contexto de observabilidad, OpenTelemetry ha conseguido muchos adeptos y se presenta como una opción tentadora que merece la pena probar. Nos gustaría compartir contigo cómo lo estamos utilizando en nuestra plataforma. 

• Exposición de API basadas en OAuth y OpenID de un amplio conjunto de API de fácil uso para desarrolladores . Estas API dan acceso a varias capacidades y datos de las telcos que pueden utilizarse para ofrecer nuevos servicios o mejorar la experiencia de los ya existentes.
• Conformidad con el RGPD acceso a la información personal del usuario con el consentimiento explícito proporcionado por el usuario en relación con el uso autorizado (finalidad) de sus datos por cada servicio solicitante.
• Capacidades de big data y SDK, por ejemplo, para construir y ejecutar algoritmos personalizados sobre una amplia cartera de conjuntos de datos existentes de la red y los sistemas de telecomunicaciones, también aplicando el consentimiento del usuario RPGD cuando sea necesario, como mantra de la plataforma Telefónica Kernel . 

Puedes encontrar información detallada sobre la plataforma Telefónica Kernel en el siguiente enlace. Telefónica Kernel es también la plataforma subyacente compatible con GSMA Iniciativa Open Gateway en la huella de Telefónica, como se ha demostrado recientemente durante el MWC 2023 en Barcelona. Puedes consultar las API que ofrece Open Gateway aquí.

Telefónica Kernel se compone de varios subsistemas (no se necesitan más detalles en este punto) y se integra tanto hacia el norte, con servicios que consumen las API y SDK de Telefónica Kernel ; como hacia el sur, con redes y sistemas locales de telco mediante API e interfaces nativas de telco proporcionadas localmente por cada operación de Telefónica. En este contexto, como en cualquier otro escenario de sistema complejo, la observabilidad e2e tiene un gran valor.

En este post nos centraremos en el pilar de la observabilidad del rastreo distribuido pilar. La plataforma Telefónica Kernel ya cuenta con registros sólidos de última generación y subsistemas de métricas construidos sobre ElasticSearch y pilas Prometheus/Grafana respectivamente. Pero no existía un soporte actual para el rastreo en toda la plataforma, así que trabajamos duro para solucionarlo.

En el sitio web Datadog, el rastreo distribuido podría definirse como:

"El rastreo distribuido es un método de rastreo de las solicitudes de las aplicaciones a medida que fluyen desde los dispositivos frontend hasta los servicios backend y las bases de datos"

Un rastro está compuesto por un trace-id, que lo identifica de forma única en todo el sistema, y un conjunto de tramos. Cada 'tramo' representa el paso de la solicitud por cada componente implicado en el procesamiento e2e y contiene un conjunto de atributos con información útil (tiempo de duración, id, etc.).

• Capacidad para equipar todas las tecnologías de desarrollo utilizadas actualmente en Telefónica CDO Engineering, de forma que se pueda utilizar un único enfoque de rastreo distribuido en todos los componentes del software proporcionadas (tanto Kernel como los servicios basados en las API de Telefónica Kernel ) por nuestro equipo.
  
  
• Posibilidad de rastrear de forma transparente aquellos componentes que no se pudieron o no se quisieron equipar desde el día 0. Concretamente, el rastreo dentro de Telefónica Kernel no debe requerir ningún impacto en el código durante las primeras etapas.
  
  
• Capacidad de integración con las soluciones de rastreo existentes utilizadas actualmente por los equipos de operaciones locales de Telefónica, de forma que el rastreo interno de Telefónica Kernel podría exportarse a los sistemas de rastreo locales.

Es importante aclarar en este punto que Telefónica Kernel es una plataforma multilocal desplegada en la nube Azure, basada en Azure managed Kubernetes Service (AKS), como infraestructura de computación subyacente. Es "global" porque está disponible en toda la huella de Telefónica pero lo hace con un despliegue específico por país donde opera Telefónica (en la región correspondiente de Azure ). 

De esta forma, los servicios construidos sobre las API de Telefónica Kernel pueden ser accesibles a cualquier cliente de Telefónica (por lo que son globales en la huella de Telefónica), pero esto se hace mediante un despliegue local dedicado por operación local, que es operado como cualquier otro sistema o red local por la operación local. Hay varias razones para ese enfoque multilocal, no solo técnicas, pero esto también queda fuera del alcance de este post. 

El enfoque seguido para habilitar el rastreo distribuido de forma transparente en Telefónica Kernel fue aprovechar la capacidad de rastreo proporcionada por la malla de servicios. Internamente en Telefónica Kernel, se estaba integrando una malla de servicios en el momento en que se evaluaba el rastreo distribuido. Los objetivos iniciales de la malla de servicios eran proporcionar capacidades de gestión del tráfico necesarias en la interconexión de los distintos componentes de la plataforma. Nosotros "secuestramos" esa actividad en curso y ampliamos su alcance para incluir el rastreo distribuido como una de sus primeras características aplicables. 

• Malla basada en sidecar de Envoy: Istio y malla de servicios abierta.
• Malla ligera basada en sidecar: Linkerd, con microsidecar desarrollado por Rust.
• Malla sin sidecar: Malla basada en eBPF del núcleo de Cilium.

Para el análisis de rendimiento de la lista de seleccionados, hemos utilizado la misma prueba de rendimiento utilizada en el proyecto Linkerd para compararla con Istio (llamada emojivoto aplicación), así podemos tener algo común para comparar entre ellos. 

• Sin rastreo habilitado, el sidecar pod web de Istio requirió 0,63 vCPU(recuerda, normalizado a 1K/s) y 50 MB RAM. El retraso añadido e2e causado por la adición de la malla de servicios Istio y Linkerd fue de 2 ms (en comparación con emojivoto ejecutado solo, sin malla de servicios).
  
  
• En el mismo escenario de configuración, Linkerd proporcionó un retraso similar, pero solo se utilizaron los recursos0,46 vCPU (-27 %) y 17 MB (-66 %) RAM en comparación con las vCPU de Istio.

• En cuanto a OSM, presentó +50 % de retraso extra, +40 % de vCPU, +40 % de memoria, comparado con Istio durante las pruebas realizadas sin rastreo, por lo que decidimos sacarlo de la lista de seleccionados en este punto y centrarnos en Istio como Envoy basado en malla.
  
  
• Cuando se habilita el rastreo en la malla de servicios, (con un muestreo del 1 %),el retraso añadido de Istio se incrementa de 2 ms a 4 ms y la vCPU (normalizada) se incrementa a 0,81 (+27 %). En el caso de Linkerd, el aumento del retraso es menor que el observado con Istio (de 2 ms a 3 ms) y la vCPU normalizada se mantiene constante (pero eso no significa que no aumente el uso de vCPU; si eliminamos el efecto de normalización, la Linkerd se reduce en un 20 % al activar el rastreo).

• La memoria RAM utilizada por sidecar no se ve afectada aparentemente por la activación del rastreo. Además, el consumo de memoria no depende de la tasa de entrada, sino sobre todo del número de extremos de la malla. La siguiente imagen presenta los resultados con el conjunto mínimo de puntos finales. Este valor puede ser incluso el doble o el triple cuando se prueba en despliegue real.

• En cuanto a Cilium, el impacto de la malla en el retraso y los recursos fue insignificante. Al no existir sidecar, la sobrecarga de Cilium eBPF se contabiliza directamente en los procesos de los contenedores proxy. No pudimos apreciar un aumento apreciable de los recursos de los contenedores pod en las pruebas en comparación con el escenario sin malla de servicios.
  
  
• El impacto en el rendimiento del rastreo activado en la malla de servicios depende de dónde se realice realmente el muestreo. Para que el muestreo realmente reduzca el consumo de recursos en el sidecar de malla de servicios que tiene que realizarse antes de llegar a OpenTelemetry, por ejemplo, en proxy sidecar o incluso antes. El muestreo realizado en OpenTelemetry en realidad no ahorra recursos en la malla de servicios ni en el recolector OTEL ya que los rastros tienen que enviarse realmente al Recolector
  OpenTelemetry para ser descartados (por lo que el "daño" al rendimiento ya está hecho). En nuestras pruebas, el muestreo del 1 % se realizó en Istio Envoy o en el Controlador de ingreso Kubernetes para las pruebas de Linkerd (ya que el proxy sidecar de Linkerd no admite muestreo).
  
  
• Por último, el impacto de mTLS en Istio y Linkerd es mínimo, por lo que su activación no requiere una asignación extra de recursos.
  Teniendo en cuenta los resultados de las pruebas de Istio para los componentes que actúan como destino de las solicitudes, el sidecar de malla requeriría 0,4vCPU (50 % de 0,81 vCPU) y 50 MB de RAM para gestionar solicitudes de 1 K/s, comparado con los 0,23 vCPU y 17 MB si se utiliza Linkerd. En el caso de los componentes que reenvían solicitudes, el sidecar de la malla de Istio necesitaría las 0,8 vCPU observadas para el pod web en la aplicación emojivoto (que se encuentra en medio de la herramienta de carga y los pods "backend" de emojivoto ). Los resultados obtenidos coinciden con los publicados en las páginas web de Istio y de Linkerd .
  Dado que el consumo de recursos realizado por la malla de servicios es relevante, el enfoque sin sidecar de Cilium es muy convincente en términos de recursos. Pero tiene algunos inconvenientes que no podemos omitir fácilmente:
  
  
• El alto rendimiento de Cilium proviene de la implementación basada en eBPF del sidecar (en realidad no se utiliza ningún sidecar), pero algunas de las capacidades de gestión de tráfico aún no están implementadas en eBPF, por lo que sigue siendo necesario utilizar el sidecar de Envoy en caso de que se necesiten. Así pues, los resultados observados en nuestras pruebas son el mejor de los casos (ya que en nuestras pruebas de emojivoto no se utilizó ninguna función de gestión del tráfico). Un uso real de la malla de servicios en nuestro despliegue requerirá en algún momento algunas características de Gestión del tráfico implementadas actualmente mediante Envoy, rompiendo así la "promesa" de no utilizar sidecar.
  
  
• Actualmente Azure no incluye Cilium en la lista de CNI oficialmente compatibles, por lo que tiene que ser utilizado bajo el modo Bring-Your-Own-CNI de Azure lo que limita el soporte proporcionado por Microsoft. La otra opción es utilizar Cilium mediante la concatenación CNI, de modo que la lógica eBPF se aplique sobre la conectividad proporcionada por los CNI compatibles oficialmente con AKS.
  
  
• Por último, el subsistema de observabilidad de Cilium, Hubble, no incluye soporte nativo para OTLP y depende de un adaptador de OpenTelemetry todavía no compatible oficialmente con OpenTelemetry (disponible en un repo github independiente ).

En estas circunstancias, preferimos mantener Cilium como una opción prometedora para seguir rastreando (los beneficios potenciales en términos de retraso y consumo de recursos son enormes) pero centrarnos en Linkerd e Istio inicialmente como enfoque de menor riesgo.

En cuanto a Linkerd, durante los preparativos de la prueba encontramos una limitación de bloqueo sobre la capacidad del proxy de Linkerd para incluir una lista configurable de cabeceras HTTP como parte de los atributos de rastreo (que en realidad es compatible con Envoy). Necesitamos esa característica para poder añadir la cabecera de Telefónica Kernel e2e Correlator-Id a los atributos de rastreo, de forma que podamos usarlo como clave para emparejar el rastreo y el registro realizado en la plataforma para la misma solicitud. Esta limitación nos impidió aprovechar un consumo menor de recursos del proxy de Linkerd en comparación con Istio Envoy.

Por último, Istio se estaba utilizando actualmente en otros equipos de Telefónica CDO Engineering. Teniendo todo esto en cuenta, decidimos seguir adelante con Istio como el enfoque con mejor relación riesgo/rendimiento. De todas formas esta es una decisión a corto plazo que podría ser revertida en caso de cualquier cambio relevante sobre Cillium de Linkerd, o cualquier otra malla relevante.

Una vez que hemos decidido utilizar Istio como malla de servicios, tenemos que construir realmente la infraestructura de rastreo que se alimentará con el rastreo generado por la malla. Ahí es donde Recolector OpenTelemetry entra en la ecuación. Necesitamos desplegar el Recolector OTEL en nuestra plataforma, pero tenemos que hacerlo de forma que se cubran algunos requisitos:

• Necesitamos combinar información de rastreo en diferentes formatos/protocolos: Zipkin, OpenCensus y OTLP es nuestra lista inicial de seleccionados. 
  
  
• Necesitamos proporcionar un muestreo de rastreo e2e "coherente".
  
  
• Además, debemos exportar el rastreo de Telefónica Kernel al backend de rastreo local de Telefónica para que el equipo de operaciones local pueda operar y rastrear Kernel como cualquier otra plataforma local.
  
  
• Tenemos que alojar un backend de rastreo desplegado dentro de Telefónica Kernel que, en el futuro, podría recoger rastros generados por Telefónica Kernel y los servicios de Telefónica sobre las API de Kernel y cualquier otra fuente de rastreo relevante de los sistemas operativos locales.
  
  
• Debemos hacer todo lo posible para garantizar la persistencia de las muestras de rastreo en los backends de rastreo y evitar cualquier pérdida de tramos de rastreo causada por la sobrecarga del Recolector OpenTelemetry que podría resultar en rastreo parcial de una solicitud (tramos perdidos ).

El primer requisito lo cumple el Recolector OpenTelemetry porque proporciona una extensa lista de recolectores y exportadores en diferentes formatos y protocolos, incluidos los mencionados explícitamente en el requisito.

A efectos del requisito de muestreo "coherente", la propagación del contexto de rastreo garantiza que la decisión de muestreo pueda progresar entre servicios basados en Telefónica Kernel, componentes internos de Telefónica Kernel y plataformas y sistemas locales. Los componentes de Telefónica Kernel reenvían este contexto (inicialmente Cabecera B3 y W3C en un futuro a corto plazo) cuando el tráfico cruza la plataforma, por lo que la decisión de muestreo tomada en algún punto del flujo será reenviada.

• Los recolectores se encargarán de recibir los rastros en diferentes formatos y protocolos y transformarlas en formato OTLP común.
  
  
• Una vez en el formato común OTLP, los procesadores ejecutarán acciones sobre los tramos de rastros, como modificar/mejorar la información de rastreo o definir cómo se agrupan/empaquetan los tramos de rastreo al enviarlos a los sistemas de destino.
  
  
• Por último, los exportadores se encargarán de exportar los tramos de rastreo resultantes, adaptándolos (si es necesario) al formato/protocolo del sistema receptor. En esta fase, podría aplicarse alguna política de reintento en caso de que falle la entrega del rastreo (sobrecarga del sistema de destino, problema de comunicación, incidente con la infraestructura de la nube, etc.).

Las acciones realizadas en estos pasos de canalización (qué recolectores, procesamiento y exportaciones se utilizan) se define como configuración del despliegue de OTEL mediante la definición de la canalización que será ejecutada por el despliegue del Recolector OTEL.

Cada instancia del Recolector OpenTelemetry es una canalización completa e independiente. Aumentar el número de instancias de despliegue del Recolector OpenTelemetry aumentará el rendimiento solo si equilibramos la carga de los tramos de rastreo entrante al conjunto de instancias disponibles. Pero este equilibrio de tramos debe hacerse teniendo en cuenta cómo afectará a la forma de realizar el muestreo.

Si no se toman medidas especiales, podría ocurrir que los tramos de rastreo generados por diferentes componentes al gestionar la misma solicitud sean procesados por diferentes instancias del Recolector OpenTelemetry (no se utiliza el equilibrio de carga basado en trace-id). Un escenario específico al que hay que prestar especial atención es cuando se utiliza políticas de "muestreo de cola" que retrasarán la decisión de muestreo hasta que se hayan recibido todos los componentes del rastro(tramos).

Un ejemplo de política de "muestreo de cola" es muestrear solo las solicitudes fallidas. Para ello sería necesario que todos los tramos de un rastro fueran gestionados por la misma instancia del recolector. Esa instancia esperaría a ver el resultado de la solicitud para decidir si esta tiene que ser muestreada o no. El equilibrio de carga de rastreo debe garantizar que se tenga en cuenta el trace-id para que todos los tramos del mismo trace-id terminen en la misma instancia del recolector.

En el escenario de Telefónica Kernel no tenemos actualmente ningún plan de "muestreo de cola". No confiamos en el muestreo realizado en OpenTelemetry debido al impacto que tiene tanto en el Recoletor OpenTelemetry como en los sidecars de malla de servicios (como se ha explicado anteriormente). El muestreo es ejecutado mediante servicios externos de invocación o, en caso de que no se aplique ese muestreo externo, será realizado por el controlador de ingreso de Telefónica Kernel, Traefik. 

Debido al volumen de tráfico gestionado por el controlador de ingreso, como criterio de diseño, decidimos evitar la inyección de sidecar a Traefik y confiar en las capacidades nativas de rastreo proporcionadas por Traefik incluyendo OpenCensus (precursor de OTLP) y OTLP en la última versión principal (v3.0, actualmente en beta).

Combinando todo, decidimos dividir la canalización de OpenTelemetry en dos subcanalizaciones diferentes, cada una ejecutada por distintos despliegues de OpenTelemetry (con su propia definición de canalización y conjunto de instancias) desacopladas por una cola tipo Kafka entre ellos. Definimos 2 despliegues OTEL independientes:

• Despliegue del Recolector : Despliegue del Recolector OTEL para gestionar los tramos de rastreo entrante y almacenarlos temporalmente en una cola de transmisión(tipo Kafka) en formato común OTLP.
  
  
• Despliegue del Exportador : El despliegue del Recolector OTEL se encarga del procesamiento y distribución del rastreo a los sistemas de destino (tanto Telefónica Kernel como los backends de rastreo de operación locales de Telefónica).

Además, la capacidad de transmisión(cola Kafka ) utilizada entre ambos despliegues es una capacidad de transmisión SaaS(Azure Eventhubs) proporcionada por el proveedor de infraestructura en la nube. Esta decisión(streaming SaaS) se tomó para poder escalar adecuadamente sin restricciones en las primeras fases. Una vez adquirida experiencia en la producción, podrían estudiarse otras opciones para aplicarlo. 

En nuestro caso, HPA(Horizontal Pod Autoscaling) para la canalización del recolector se basa en la CPU y la memoria utilizadas por los contenedores, pero HPA, para la distribución de la canalización incluye también métricas de transmisión(desfase de la cola Kafka) como criterio de escalado, mediante soluciones HPA como Keda. Con Keda podemos definir reglas de escalado basadas en las métricas recopiladas por Prometheus, incluidas las generadas por el propio Recolector OpenTelemetry . El escalado de ambos despliegues de Recolector OTEL es independiente el uno del otro.

Este desacoplamiento de la exportación de la recolección nos permite mantener la política de reintentos activada en nuestra canalización de exportación, sin preocuparnos de perder el rastreo entrante debido a la sobrecarga causada por los reintentos. Esta política de reintentos nos ayudará a cumplir el requisito de minimizar la pérdida de información de los rastros debido a fallos en la entrega sin causar una sobrecarga que pueda afectar al manejo en la recepción de los rastros(protección de contrapresión ).

Los despliegues de Telefónica Kernel tienen (inicialmente) 2 destinos diferentes para los rastros: un despliegue local Jaeger que forma parte de la plataforma Telefónica Kernel y un backend de rastros remoto proporcionado por la operación local de Telefónica. Para esto último, se acordó utilizar el formato OTLP ya que se verificó que las soluciones comerciales de rastreo desplegadas en la huella de Telefónica son compatibles con este formato común no bloqueado por el proveedor. Para esta integración, actualmente utilizamos el enlace GRPC OTLP, protegido con TLS.

Como complemento al subsistema OTEL, también desplegamos una solución de backend de rastreo como parte de la plataforma Telefónica Kernel . Actualmente estamos utilizando el backend de rastreo Jaegertracing, que persiste en la misma infraestructura de ElasticSearch que también es compatible con nuestro subsistema de registro de Telefónica Kernel . En realidad, es la implementación actual del subsistema de registro de Telefónica Kernel que inspiró este enfoque de dos canalizaciones para el subsistema de rastreo.

Como se mencionó al principio del post, actualmente planeamos utilizar OpenTelemetry solo para fines de rastreo. Los registros y métricas son gestionados por su correspondiente subsistema de plataforma. En cuanto a los registros, la posibilidad de incluir cabeceras HTTP en los atributos de rastreo es la clave que permite la comprobación cruzada de registros y rastros de la misma solicitud. Además, en el momento de la elaboración de este post, solo se declaró una capacidad de rastreo como estable en el Recolector OpenTelemetry, con registros y métricas presentadas como beta en muchos procesadores recoletores y exportadores OTEL .

En el despliegue en Telefónica Kernel de Jaeger, como rastreo de backend interno de la plataforma, obtuvimos un beneficio extra derivado del enfoque de 2 canales para el despliegue de OpenTelemetry . Como ya disponemos de un paso de transmisión en la canalización de rastreo, no es necesario desplegar Jaeger con Kafka interno. Como la canalización del exportador de OTEL implementa reintentos en caso de error, es posible desplegar Jaeger sin Kafka interno, y dejar que HPA Jaeger Ingest escale adecuadamente, sin preocuparse de rastrear tramos perdidos en la canalización interna Jaeger .

Esperamos que nuestras experiencias te sean de utilidad. ¡¡Te deseamos un feliz rastreo!!