Exportación de Trazas de TrueFoundry AI Gateway a SigNoz a través de OTLP

El TrueFoundry AI Gateway genera spans de OpenTelemetry para cada solicitud de LLM y los publica de forma asíncrona a través de NATS. SigNoz Cloud acepta estos spans a través de OTLP/HTTP en un punto final de ingesta regional autenticado mediante una clave de ingesta por espacio de trabajo. Para conectar ambos se requiere configurar el exportador OTEL del gateway con la URL de ingesta de SigNoz y añadir el signoz-ingestion-key encabezado. No se requieren cambios en la instrumentación a nivel de aplicación.

Esta publicación cubre la ruta de generación de trazas OTEL dentro del TrueFoundry AI Gateway y la tubería de ingesta y almacenamiento que utiliza SigNoz Cloud, así como la superficie de configuración para interconectar ambos sistemas. No es una guía de configuración. Es una explicación de cómo funciona la integración a nivel de arquitectura.

Cómo el TrueFoundry AI Gateway genera y exporta trazas

El TrueFoundry AI Gateway está construido sobre el framework Hono y se ejecuta como un pod sin estado. Un solo pod con 1 vCPU y 1 GB de RAM maneja más de 250 solicitudes por segundo con aproximadamente 3 ms de latencia adicional. Ese rendimiento es posible porque el gateway no realiza ninguna llamada externa en la ruta de la solicitud. La autenticación se realiza contra claves públicas cacheadas, descargadas una vez del proveedor de identidad. Las comprobaciones de autorización se ejecutan contra un mapa en memoria de usuarios a modelos sincronizados a través de NATS. La lógica de enrutamiento de modelos se ejecuta completamente en memoria contra una copia local de la configuración de enrutamiento.

La generación de trazas OTEL sigue el mismo principio de cero llamadas externas. Cuando una solicitud se completa, el gateway publica los datos del span de forma asíncrona en NATS. El exportador OTEL lee de esta ruta asíncrona y reenvía el span al punto final externo configurado. El exportador nunca interfiere con la ruta de la solicitud. Un backend OTEL lento o inalcanzable nunca detiene una solicitud y nunca añade latencia visible para el cliente.

El gateway genera spans en varios puntos del ciclo de vida de la solicitud. El manejo de HTTP entrante, la autenticación, la resolución de modelos y la llamada al proveedor saliente producen spans que se ensamblan en una traza. Los spans llevan un conjunto específico de atributos. El tfy.input atributo contiene el cuerpo completo de la solicitud enviado al LLM. El tfy.output atributo contiene el cuerpo completo de la respuesta. El tfy.input_short_hand atributo contiene un resumen condensado de la entrada con indicadores booleanos para contenido de archivo, imagen y audio. El tfy.span_type atributo identifica el tipo de operación como ChatCompletion o AgentResponse o MCPGateway, dependiendo de qué ruta de la pasarela gestionó la solicitud. Las gen_ai.* convenciones semánticas también se incluyen, cubriendo los recuentos de tokens de prompt, los recuentos de tokens de finalización, los identificadores de modelo y las razones de finalización.

La pasarela también expone un Excluir Datos de Solicitud conmutador en la configuración de OTEL. Cuando está habilitado, el exportador elimina tfy.input y tfy.output y tfy.input_short_hand de los spans antes de reenviarlos. Esta es la configuración correcta para los equipos que necesitan visibilidad completa de los rastreos para el análisis de latencia y errores, pero que no deben transmitir el contenido del prompt o de la respuesta a una plataforma externa.

La exportación es aditiva. Habilitar un SigNoz destino OTEL no reemplaza ni interrumpe el almacenamiento interno de rastreos de TrueFoundry. Ambas rutas reciben los mismos spans de la misma publicación asíncrona de NATS.

Qué hace SigNoz con los rastreos

SigNoz se basa en un OpenTelemetry Collector personalizado que acepta datos de telemetría y los escribe en ClickHouse. El colector está configurado para ingerir datos a través de protocolos OTLP estándar y proporciona traducción de protocolos para una integración perfecta con las herramientas de monitoreo existentes y procesa los datos con enriquecimiento de metadatos antes de escribirlos en el almacenamiento.

La tubería de ingesta sigue la arquitectura de OpenTelemetry Collector con receptores, procesadores y exportadores. El receptor OTLP acepta spans de rastreo tanto a través de gRPC en el puerto 4317 como de HTTP en el puerto 4318. Un procesador por lotes agrupa los spans para mayor eficiencia antes de la exportación. El signozspanmetrics el procesador genera métricas RED (Tasa, Error y Duración) directamente a partir de los datos de span para que la tasa de solicitudes, la tasa de errores y los percentiles de latencia estén disponibles como métricas consultables sin necesidad de instrumentación adicional. Los spans de traza se escriben en la distributed_signoz_index_v3 tabla en ClickHouse. Las métricas generadas fluyen hacia la signoz_metrics.distributed_samples_v4 tabla.

SigNoz Cloud utiliza una arquitectura por inquilino. Cada inquilino obtiene su propia instancia de SigNoz, su propio ClickHouse para almacenar datos de telemetría, su propio colector OTel para la ingesta y su propio punto final regional. La infraestructura compartida gestiona la ingesta inicial: una pasarela OpenTelemetry recibe la telemetría, la agrupa y la reenvía a un búfer de streaming de Redpanda antes de que la instancia de SigNoz por inquilino la consuma y la escriba en ClickHouse. Esto significa que el ingest.<region>.signoz.cloud:443 punto final es una capa de ingesta compartida. El signoz-ingestion-key encabezado enruta los datos a la canalización por inquilino correcta después de la ingesta.

El servicio de consulta de SigNoz lee de ClickHouse utilizando consultas SQL optimizadas que aprovechan el formato de almacenamiento columnar para la agregación sobre grandes volúmenes de datos de span. El explorador de trazas muestra spans individuales filtrables por nombre de servicio, operación, estado y duración, como se muestra a continuación.

‍

El explorador de métricas acepta consultas compatibles con PromQL contra las métricas RED generadas. Dado que la pasarela emite atributos estándar gen_ai.* junto con los atributos tfy.* SigNoz puede mostrar tanto datos genéricos de rendimiento HTTP como datos específicos de LLM en la misma vista de traza.

La superficie de integración

El TrueFoundry AI Gateway se conecta a SigNoz a través de dos configuraciones de exportador OTEL: una para trazas y otra para métricas. Ambas utilizan codificación HTTP y Proto. El signoz-ingestion-key encabezado es necesario en ambos exportadores. El formato del punto final incluye la región como un subdominio y se conecta en el puerto 443 a través de HTTPS. La configuración es accesible en AI Gateway → Controles → Configuración → Configuración OTEL en el panel de control de TrueFoundry, como se muestra a continuación.

‍

Configuración del exportador de trazas OTEL

Configuración del exportador de métricas OTEL

La región se deriva de la URL de ingesta de SigNoz Cloud visible en la configuración de la cuenta. Para una URL de ingesta de https://ingest.in2.signoz.cloud la región es in2 y el punto final de trazas se convierte en https://ingest.in2.signoz.cloud:443/v1/traces. La clave de ingesta es una credencial con ámbito de espacio de trabajo disponible en Configuración → Configuración de ingesta en el panel de control de SigNoz Cloud.

A diferencia de los objetivos de observabilidad autoalojados donde el tráfico permanece dentro del clúster a través de HTTP simple, SigNoz Cloud es un punto final externo accesible a través de internet público. El exportador de la pasarela establece una conexión TLS al puerto 443 y envía tramos en lotes OTLP/HTTP codificados en protobuf. La ruta de exportación asíncrona basada en NATS en la pasarela significa que, incluso si el punto final de ingesta de SigNoz no está disponible temporalmente, la pasarela continúa procesando las solicitudes normalmente. Los tramos que no se pueden entregar se descartan a nivel del exportador y se registran sin mostrar errores al llamador.

Ambos exportadores se pueden habilitar de forma independiente. Habilitar solo el exportador de trazas envía datos de tramos a SigNoz mientras se mantiene deshabilitada la exportación de métricas. Habilitar ambos envía datos de tramos a la distributed_signoz_index_v3 datos de tabla y métricas a la signoz_metrics.distributed_samples_v4 tabla desde la cual SigNoz genera las vistas de métricas RED en el explorador de métricas.

Filtrado por servicio en SigNoz

El gateway establece service.name en tfy-llm-gateway en todos los spans como un atributo de recurso. En el explorador de trazas de SigNoz, filtrar por service.name = tfy-llm-gateway aísla todo el tráfico del gateway. Filtrar por tfy.span_type = ChatCompletion reduce aún más la búsqueda a las solicitudes de inferencia de LLM. El atributo tfy.data_routing.destination identifica qué modelo o modelo virtual manejó la solicitud y se puede usar para agrupar las distribuciones de latencia por modelo.

Resumen de la arquitectura

Una solicitud entra en el TrueFoundry AI Gateway y se procesa completamente en memoria. El gateway reenvía la solicitud al proveedor de LLM y transmite la respuesta de vuelta al cliente. Una vez completada la respuesta, el gateway publica un span en NATS que contiene los atributos completos de la solicitud y la respuesta, el recuento de tokens y la latencia. El exportador de OTEL recoge el span de NATS de forma asíncrona y lo reenvía a través de OTLP/HTTP con el signoz-ingestion-key encabezado al punto de ingesta regional de SigNoz en el puerto 443. La pasarela OTel compartida de SigNoz recibe el span y lo agrupa en Redpanda. El colector por inquilino de SigNoz consume de Redpanda y aplica el procesador signozspanmetrics para generar métricas RED y luego escribe los spans en distributed_signoz_index_v3 y las métricas en signoz_metrics.distributed_samples_v4 en la instancia de ClickHouse por inquilino. El servicio de consulta de SigNoz lee de ClickHouse y muestra el rastro en el explorador de Rastros y las métricas generadas en el explorador de Métricas.

No se requieren sidecars. No se requieren cambios en el SDK. No se añade código de instrumentación a ninguna aplicación. El único cambio de configuración es añadir dos puntos finales de exportación OTEL en la configuración OTEL de TrueFoundry AI Gateway. La pasarela ya genera y publica los spans. La configuración del exportador y la clave de ingesta determinan a dónde van.

El principio arquitectónico que hace que esta integración funcione es la separación completa entre la ruta de solicitud y la ruta de exportación de telemetría. La pasarela publica la telemetría en NATS una vez que la respuesta ya está en la red. El punto final de ingesta de SigNoz puede ser lento, estar temporalmente no disponible o geográficamente distante sin ningún efecto en la latencia o fiabilidad de la pasarela. La portabilidad de OTEL significa que los mismos datos de span que fluyen a SigNoz hoy pueden fluir a cualquier otro backend compatible con OTLP sin cambiar la configuración de la pasarela más allá de la URL del punto final y el encabezado de autenticación.

‍