Arize-integratie met TrueFoundry

Elk LLM-verzoek dat door de TrueFoundry AI Gateway gaat, genereert een trace. Die trace legt de volledige span-tree van het verzoek vast: gateway-afhandeling, JWT-validatie, autorisatie-afhandeling, provider-routing, de uitgaande model-call en de gestreamde respons. Deze traces worden intern opgeslagen voor de TrueFoundry Monitor UI. Ze kunnen echter ook via standaard OpenTelemetry-protocollen worden geëxporteerd naar externe observability-backends. Arize is zo'n backend.

In dit artikel leggen we op architectuurniveau uit hoe de trace-export werkt: welke OTEL-primitieven erbij betrokken zijn, hoe de gateway traces uitzendt zonder latentie toe te voegen aan het verzoekpad en wat Arize doet met de trace-data zodra deze aankomt. Ook behandelen we het configuratie-oppervlak en de privacy-instellingen waarmee u prompt-inhoud kunt strippen voordat deze uw infrastructuur verlaat.

OpenTelemetry en LLM Observability

OpenTelemetry definieert een leveranciersneutraal netwerkformaat voor gedistribueerde traces. Een trace is een boomstructuur van spans die verbonden zijn door ouder-kindrelaties. Elke span vertegenwoordigt een afzonderlijke eenheid van werk: één HTTP-handler, één LLM-call of één tool-invocatie. Spans bevatten getypeerde sleutel-waarde-attributen die operationele context zoals latentie, statuscodes en token-aantallen coderen.

De standaard OTEL semantische conventies dekken gedistribueerde systemen voor algemeen gebruik goed af, maar ze zijn niet ontworpen voor LLM-workloads. LLM-calls bevatten gestructureerde inputs (message-arrays voor meerdere turns met systeemprompts, tooldefinities en multimodale inhoud) en gestructureerde outputs (completions met finish reasons en functie-calls). Token-economics zijn eersteklas operationele metrieken: prompt-tokens, completion-tokens, gecachte tokens en reasoning-tokens moeten allemaal per span worden bijgehouden. Eén enkel input.value string-attribuut is onvoldoende.

Dit is waar LLM-specifieke semantische conventies om de hoek komen kijken. Arize onderhoudt de OpenInference-specificatie, die een concreet attribuutschema en span-kind-taxonomie bovenop OTEL-spans definieert. Elke OpenInference-trace is een geldige OTLP-trace. De conventies geven attribuutnamen hun AI-specifieke betekenis. Span-kinds zoals LLM, CHAIN, RETRIEVER, TOOL en EMBEDDING categoriseren operaties, zodat observability-platforms traces kunnen weergeven met AI-bewuste visualisaties en aggregaties.

TrueFoundry AI Gateway zendt traces uit met behulp van een eigen attribuut-namespace (tfy.input, tfy.output en tfy.input_short_hand, samen met standaard gen_ai.* attributen voor token-aantallen, model-metadata en completion finish reasons). Arize verwerkt deze als geldige OTLP-traces en koppelt de attributen aan de eigen trace-UI.

Hoe de Gateway Traces Genereert

TrueFoundry AI Gateway maakt gebruik van een gesplitste architectuur: een control plane die de configuratie beheert en een gateway plane die inference-verzoeken verwerkt. De gateway plane is gebouwd op het Hono-framework, een ultrasnelle, voor edge geoptimaliseerde HTTP-runtime. Eén enkele gateway pod op 1 vCPU en 1 GB RAM verwerkt meer dan 250 verzoeken per seconde met ongeveer 3 ms aan toegevoegde latentie.

Het cruciale ontwerpprincipe is dat er geen externe calls in het verzoekpad zitten, behalve de daadwerkelijke LLM provider-call. Wanneer een verzoek binnenkomt bij een gateway pod, gebeurt het volgende volledig in het geheugen:

1. De pod valideert het JWT-token aan de hand van gecachte publieke sleutels die zijn gedownload van uw IdP. Geen externe auth-call.
2. Hij controleert de autorisatiekaart in het geheugen (gesynchroniseerd vanaf de control plane via NATS) om te verifiëren of de gebruiker toegang heeft tot het gevraagde model.
3. Hij zet de model-id om naar een specifiek provider-endpoint. Als het model een Virtual Model is met routingregels, past de gateway hier op prioriteit, gewicht of latentie gebaseerde selectielogica toe.
4. Een adapter vertaalt het verzoek van het OpenAI-compatibele formaat naar het native formaat van de doelprovider.
5. Het verzoek wordt doorgestuurd naar de provider en de respons wordt gestreamd teruggeschreven naar de client.

Trace-generatie vindt asynchroon plaats naast deze stroom. De gateway maakt OTEL-spans aan voor elke fase van de levenscyclus van het verzoek: de inkomende HTTP-handler, de authenticatiecontrole, de modelomzetting, de uitgaande provider-call en de streaming respons. Deze spans bevatten attributen die token-gebruik, latentie, modelnaam, provider, kostenschatting en verzoek-metadata vastleggen. Nadat het verzoek is voltooid, publiceert de gateway de trace-data naar een NATS-message-queue. Dit is dezelfde NATS-bus die de configuratiesynchronisatie tussen de control plane en de gateway pods afhandelt.

De OTEL-exporter haalt de trace-data op uit dit asynchrone pad en stuurt deze door naar het geconfigureerde externe endpoint. Omdat de trace-export is losgekoppeld van het verzoekpad, voegt deze nul latentie toe aan inference-verzoeken. De gateway laat een verzoek nooit mislukken, zelfs niet als het externe OTEL-endpoint onbereikbaar is.

Wat Arize Doet met de Traces

Arize is een AI-observability- en evaluatieplatform dat specifiek is gebouwd voor LLM- en agent-workloads. Het accepteert OTEL-traces via gRPC op otlp.arize.com:443 en biedt verschillende analyselagen bovenop de ruwe trace-data.

Trace-visualisatie. Arize geeft volledige trace-waterfalls weer die de span-tree voor elk verzoek tonen. U kunt individuele spans inspecteren om het token-gebruik, de latentieverdeling, de input/output-inhoud en de model-metadata te bekijken. Voor agent-workflows waarbij één enkel gebruikersverzoek meerdere LLM-calls en tool-invocaties veroorzaakt, maakt deze waterfall-weergave het uitvoeringspad inzichtelijk.

Performance-analytics. Arize berekent geaggregeerde metrieken over uw trace-stream: latentieverdelingen per model en per provider, foutpercentages in de loop van de tijd en throughput-trends. U kunt waarschuwingsregels instellen die afgaan wanneer er anomalieën in deze verdelingen optreden. Dit is nuttig om prestatieverlies bij providers op te sporen voordat eindgebruikers er last van ondervinden.

LLM-evaluatie. Naast ruwe tracing ondersteunt Arize geautomatiseerde evaluatiepipelines. U kunt LLM-as-a-Judge-workflows uitvoeren die completions beoordelen op dimensies zoals relevantie, coherentie en feitelijkheid. U kunt ook menselijke annotatieworkflows toevoegen voor een meer genuanceerde kwaliteitsbeoordeling. De traces leveren de ruwe data (inputs, outputs en modelparameters) die deze evaluatieloops voeden.

De belangrijkste onderscheidende factor is dat Arize LLM-specifieke semantiek native begrijpt. Het haalt token-aantallen, model-id's en prompt-inhoud uit span-attributen en toont deze in speciaal daarvoor gebouwde weergaven, in plaats van ze te behandelen als generieke string-sleutel-waardeparen.

Het Integratie-oppervlak

De integratie is een directe gRPC-export van de gateway naar Arize. Er is geen collector sidecar nodig. Er is geen aangepaste SDK bij betrokken. U configureert de OTEL-exporter in het TrueFoundry-dashboard en de traces beginnen te stromen.

U kunt de integratiestappen hier volgen: https://www.truefoundry.com/docs/ai-gateway/arize

Resource-attributen

U kunt extra resource-attributen toevoegen aan elke geëxporteerde trace. Dit zijn sleutel-waardeparen die op trace-niveau worden toegevoegd en nuttig zijn voor filteren en groeperen in Arize.

Het meest gebruikelijke attribuut om in te stellen is model_id. Arize gebruikt dit om traces te groeperen per model in de dashboard-weergaven. Als u productieverkeer routeert via een gefinetuned Llama-model, kunt u model_id instellen op finetuned-llama-3-production. U kunt ook model_version toevoegen als u parallelle implementaties uitvoert en de prestaties tussen versies wilt vergelijken in Arize.

Data Privacy Controls

Er zijn implementatiescenario's waarin prompt-inhoud en completion-inhoud uw infrastructuur niet mogen verlaten. Compliance-vereisten kunnen het verzenden van verzoekteksten naar diensten van derden verbieden. PII in prompts kan externe export onmogelijk maken.

TrueFoundry pakt dit aan met de optie Exclude Request Data in de configuratie van de OTEL-exporter. Wanneer deze is ingeschakeld, verwijdert de gateway drie span-attributen vóór de export: tfy.input, tfy.output en tfy.input_short_hand. Arize ontvangt nog steeds de structurele trace-data (latentie, token-aantallen, model-metadata en foutstatus), maar ziet nooit de daadwerkelijke inhoud van prompts of completions.

Dit is een belangrijk architecturaal detail. De filtering vindt plaats op gateway-niveau voordat de trace-data de gRPC-exporter bereikt. De inhoud verlaat de gateway pod nooit. U krijgt volledige observability over prestaties, kosten en betrouwbaarheid zonder gevoelige inhoud bloot te stellen aan een extern platform.

De Integratie Verifiëren

Nadat u de OTEL-configuratie hebt opgeslagen, stuurt u een paar LLM-verzoeken door de gateway. Open vervolgens het Arize-dashboard en navigeer naar Traces. Zoek naar traces van de dienst tfy-llm-gateway. Elke trace moet de volledige span-tree tonen met gateway-afhandelingsspans en de uitgaande LLM provider-call span. Klik op individuele spans om te verifiëren dat token-gebruik, latentie en model-metadata correct zijn ingevuld.

Als u resource-attributen hebt geconfigureerd, moet u deze terugzien in de trace-metadata. Gebruik het attribuut model_id om de trace-lijst te filteren en te controleren of traces correct per model worden gegroepeerd.

Overzicht van de Architectuur

De datastroom is eenvoudig. Applicaties sturen LLM-verzoeken naar TrueFoundry AI Gateway. De gateway verwerkt het verzoek in het geheugen (authenticatie, autorisatie, routing en rate limiting) en stuurt het door naar de geconfigureerde modelprovider. Parallel daaraan genereert de gateway OTEL-spans voor de levenscyclus van het verzoek en publiceert deze asynchroon naar de NATS-message-queue. De OTEL-exporter leest uit deze queue en stuurt traces via gRPC naar otlp.arize.com:443. Arize verwerkt de OTLP-traces en maakt ze beschikbaar voor visualisatie, analyse en evaluatie.

Er worden geen externe calls toegevoegd aan het inference-pad. Er hoeven geen collector sidecars te worden geïmplementeerd. Er zijn geen wijzigingen in de applicatiecode vereist. De gateway is het enkele instrumentatiepunt en de OTEL-export is een aanvulling op de eigen interne trace-opslag van de gateway. U kunt naar Arize exporteren terwijl u de ingebouwde Monitor UI van TrueFoundry blijft gebruiken voor dezelfde trace-data.

Dit is het patroon dat OTEL waardevol maakt als protocolkeuze. De gateway zendt standaard OTLP-traces uit. Arize accepteert standaard OTLP-traces. Als u morgen besluit om van observability-backend te veranderen, wijzigt u het endpoint en de headers in de gateway-configuratie en verwijst u naar een andere OTLP-receiver. Uw applicatiecode, uw gateway-configuratie en uw trace-instrumentatie blijven exact hetzelfde.