LLM Monitoring met Bifrost: Prometheus en OpenTelemetry in de praktijk

Bifrost, de open-source gateway van Maxim AI, levert een verrassend complete LLM-monitoringstack in de gratis tier: een request log, een Prometheus /metrics endpoint en OpenTelemetry trace-export. Om van “het exposeert metrics” tot dashboards en alerts te komen die je kunt vertrouwen, zijn een paar beslissingen nodig die in de documentatie over meerdere pagina's verspreid staan. Deze gids brengt ze samen op één plek: wat je moet inschakelen, hoe je het moet scrapen, welke labels belangrijk zijn, de queries die het bewaren waard zijn, en de instellingen die stilzwijgend prompt-inhoud lekken of je counters breken.

Deze gids is opgebouwd uit de documentatie van Bifrost, plus een paar zaken die we uit de eerste hand hebben gezien bij het draaien van Bifrost OSS v2.0.0, die we vermelden waar ze aan bod komen.

Gateway-latency valt hier buiten de scope; onze Bifrost review behandeld de prestaties.

Één request, drie vlakken

Één enkele chat-request via Bifrost komt op drie plaatsen tegelijk terecht, allemaal beschikbaar in OSS (ingebouwde observability):

1. ‍‍Logs. De altijd ingeschakelde logging-plugin schrijft asynchroon een rij: input- en outputberichten, model, token-aantallen, berekende USD-kosten, latency, status en eventuele logging headers. De documentatie geeft aan dat de overhead onder 0,1 ms blijft. Je kunt dit zien in het dashboard op poort 8080 of er queries op uitvoeren via GET /api/logs.‍
2. Metrics. Counters zoals bifrost_upstream_requests_total, bifrost_input_tokens_total en bifrost_cost_total hoogten op met labels voor provider, model en virtual key, plus environment="production" uit de dimension-header.‍
3. Traces. Als de OTel-plugin is ingeschakeld, gaat er een span naar je collector in het trace-formaat dat je hebt gekozen, met dezelfde dimension zodat deze naast de traces van je applicatie kan staan.

De rest van deze gids gaat over het production-ready maken van elk vlak.

LLM-metrics met Prometheus

Inschakelen en scrapen

De telemetry-plugin is standaard ingeschakeld en serveert de Prometheus-expositie-indeling op /metrics op de gateway-poort (Prometheus). Voor een enkele node is een eenvoudige scrape job voldoende:‍


Twee dingen zorgen hier voor problemen.

Auth verandert de scrape. Wanneer auth_config.is_enabled true is, vereist /metrics Basic auth, en een scrape job zonder overeenkomende credentials mislukt met een 401-fout. Prometheus toont het target als down, dus je merkt het op, maar alleen als je de target-health in de gaten houdt. Het omgekeerde probleem is erger, en daar liepen we in onze eigen tests tegenaan: een verse OSS-installatie begint helemaal zonder authenticatie, dus /metrics, het dashboard en de admin API zijn toegankelijk voor iedereen die de poort kan bereiken totdat je een admin en een setup token configureert. Exposeer poort 8080 niet buiten het netwerk van de scraper.

Scrape niet via een load balancer. Elke replica houdt zijn eigen counters bij. Als Prometheus een load-balanced adres scrapet, komt elke scrape op een andere pod terecht en springen je counters heen en weer. Scrape elke pod rechtstreeks (Kubernetes service discovery op de pod-IP's), of gebruik de Push Gateway-modus, die door de documentatie van Bifrost wordt aanbevolen voor multi-node clusters achter een load balancer. Dit is nog belangrijker bij OSS, waar replica's geen state delen: budgetten en counters leven per pod, dus metrics per pod zijn het enige eerlijke beeld.

Wat Bifrost exposeert

De catalogus van metrics, gegroepeerd op basis van waarvoor je ze zou gebruiken:

De HTTP-metrics labelen path met het gematchte route template, niet met de ruwe URL, waardoor de cardinaliteit beperkt blijft. Eén ding om te onthouden over bifrost_cost_total: het is een kostprijs die Bifrost berekent op basis van zijn prijscatalogus en de usage-velden die providers terugsturen. Het is goed voor budgetten en kostentoewijzing, maar het is geen factuur, en onderhandelde kortingen of credits worden er niet in weergegeven.

De labels die het nuttig maken

De standaardlabels dragen dezelfde identiteitsstructuur die Bifrost gebruikt voor governance, wat ruwe counters omzet in antwoorden:

• provider, model en alias
• virtual_key_id / virtual_key_name, team_id / team_name, customer_id / customer_name. Deze zijn leeg wanneer je geen governance gebruikt.
• routing_engine_used, routing_rule_id / routing_rule_name, selected_key_id / selected_key_name en fallback_index, die samen verklaren waarom een request op een bepaalde plek terecht is gekomen.

Toewijzing per gebruiker is geen standaard metric-label. Je krijgt dit via logging headers (X-User-ID of een willekeurige x-bf-lh-* header), die in het request log terechtkomen, of via dimensions.

Aangepaste dimensions en de cardinaliteitsvalkuil

Elke request header die begint met x-bf-dim- wordt een dimension die tegelijkertijd naar het request log, de OTel-span en Prometheus als een aangepast label wordt geschreven (gedeelde observability-dimensions). Dat is de schoonste manier om verkeer te taggen per omgeving, feature of tenant zonder nieuwe virtual keys.

Het is ook de makkelijkste manier om Prometheus te laten crashen. Elke unieke waarde van een label creëert een nieuwe tijdreeks voor elke metric die dit label draagt. Een dimension zoals environment met drie waarden is prima. Een dimension zoals request_id, session_id of user_id creëert een reeks per waarde over tientallen metrics. Bewaar identifiers met een hoge cardinaliteit in logging headers (x-bf-lh-*), die alleen naar het request log gaan, en reserveer x-bf-dim-* voor waarden die je met een gerust hart in een dropdown-menu op een dashboard zou plaatsen.

PromQL het bewaren waard

Deze maken gebruik van de gedocumenteerde metric- en labelnamen. Controleer eerst de metric types met de /metrics output van jouw build; de TTFT-query gaat ervan uit dat de latency-metrics histogrammen zijn.‍

‍Alerting die je zelf moet meebrengen

De ingebouwde alerting-engine van Bifrost is alleen beschikbaar voor Enterprise, en evalueert budget- en rate-limit metrics (percentage gebruikt budget, uitgaven, request- en tokengebruik), niet het aantal fouten of latency (alerting). Voor betrouwbaarheidsalerts in beide tiers richt je Alertmanager op de bovenstaande metrics:

‍‍Bifrost levert geen Grafana-dashboard of alert-rule-pack in de documentatie die we hebben beoordeeld, dus het beheren hiervan komt volledig bij jouw team te liggen.

LLM-tracing met OpenTelemetry

De OTel-plugin inschakelen

Trace-export bevindt zich in de otel plugin, die deel uitmaakt van OSS (plugin-configuratie). Het staat standaard uit in de Helm chart; zodra je het toevoegt, staat trace-export standaard aan. De instellingen waarmee je te maken krijgt:

Aan de ontvangende kant ziet een minimale OpenTelemetry Collector die beide protocollen accepteert en doorstuurt naar je tracing backend er zo uit:

‍Houd een collector tussen Bifrost en elke SaaS-backend, zelfs als de backend rechtstreeks OTLP accepteert. Het geeft je één plek om te batching, attributen te filteren en van leverancier te wisselen zonder de gateway-configuratie aan te raken.

Een trace-indeling kiezen: OTel GenAI, OpenInference of Vercel

trace_type bepaalt hoe downstream-tools de spans van Bifrost interpreteren. Een globale gids voor het maken van een keuze:

• genai_extension volgt de OpenTelemetry GenAI semantische conventies (de gen_ai.* attributen, soms afgekort tot OTel GenAI). Kies dit voor algemene backends zoals Grafana Tempo, Honeycomb, Jaeger of Datadog via OTLP.
• open_inference volgt de OpenInference-conventies van Arize. Kies dit als je trace viewer is gebouwd rond OpenInference, zoals Arize Phoenix. Bifrost documenteert geen native Langfuse- of Arize-connectors, dus beschouw OTLP plus OpenInference daar als de meest waarschijnlijke route in plaats van een ondersteunde integratie.
• vercel komt overeen met de conventies van de Vercel AI SDK. Kies dit als de rest van je traces al afkomstig zijn van de Vercel AI SDK.

Welke je ook kiest, stuur één test-request en controleer de attribuutnamen in je backend voordat je er dashboards op bouwt.

Prompt-inhoud in je traces

Dit is de instelling die een security reviewer het meest waarschijnlijk zal verrassen. Bifrost's client-level disable_content_logging verwijdert prompts en responsen uit zijn eigen logopslag, maar dit is niet van toepassing op observability-connectors. OpenTelemetry, Datadog, BigQuery, Kafka en Pub/Sub hebben elk hun eigen disable_content_logging flag, en deze staat standaard op false (client-configuratie). Een team dat content-logging bij de client uitschakelt en de OTel-plugin toevoegt, exporteert standaard dus nog steeds volledige prompts naar de tracing backend.

Voor een setup met alleen metadata stel je de flag in op de client en op elke connector die je inschakelt. Opgehaalde request headers worden geëxporteerd ongeacht de content flags, dus controleer ook welke headers je verzamelt. Als je bepaalde inhoud nodig hebt voor debugging, is een attribute-dropping processor in je collector een tweede verdedigingslinie, maar stem deze af op de attribuutnamen die de door jou gekozen trace-indeling daadwerkelijk uitstoot.

Bifrost-spans koppelen aan je applicatie-traces

End-to-end W3C trace-context propagation is gedocumenteerd voor de native Datadog-plugin, die gebruikmaakt van dd-trace-go. Voor de generieke OTel-plugin vermeldt de documentatie niet of een inkomende traceparent header van de span van Bifrost een child maakt van de span van je applicatie. Test dit voordat je iemand een enkele waterfall belooft van frontend naar model. Als het niet koppelt, is de gedeelde x-bf-dim-* dimension je terugvaloptie om de twee te correleren.

Het request log: het vlak dat je al hebt

De logging-plugin is het enige vlak dat je niet hoeft in te stellen. Punten die het in de praktijk nuttig maken:

• GET /api/logs filtert op provider, model, status, tijdsbereik, latency, tokens en kosten, en ondersteunt full-text content_search. Een WebSocket-stream geeft je een live tail.
• Sinds v1.5.0 legt elke rij de geselecteerde sleutel, het aantal retries en een geordende attempt_trail vast, waarin elke poging, de sleutel, de reden van mislukking en of deze een sleutelrotatie heeft getriggerd worden getoond. Wanneer een provider haperingen vertoont, is dit sneller dan welk dashboard dan ook.
• De opslag is standaard SQLite en PostgreSQL voor productie. Retentie staat standaard op 365 dagen via log_retention_days, met een cleaner die elke 24 uur draait.
• Op v2.0.0 is het vastleggen van ruwe provider requests en responsen een schakelaar onder Observability, en dan Logs Settings, in het dashboard. We hebben dit ingeschakeld om precies te inspecteren wat Bifrost naar elke provider stuurde, en het is goed om te weten dat het bestaat voordat je het nodig hebt.

Er is geen op snelheid gebaseerde sampling voor logs. De dichtstbijzijnde knop, drop_excess_requests, vermindert de belasting wanneer queues vollopen; het is geen sampler. Bij een hoog volume moet je opslag plannen voor elke request, of content logging uitschakelen.

Valkuilen, in één lijst

• De client content-logging schakelaar geldt niet voor connectors. Stel dit per connector in.
• Het inschakelen van auth zorgt ervoor dat /metrics Basic auth vereist; totdat auth is ingeschakeld, is alles open.
• Scrapen via een load balancer verstoort de counters per pod. Scrape pods of gebruik de Push Gateway.
• x-bf-dim-* waarden worden Prometheus-labels. Houd ID's hierbuiten.
• De OTel-plugin staat standaard uit in Helm, ook al is deze gratis.
• Kostenmetrics worden berekend op basis van een prijscatalogus die elke 24 uur synchroniseert vanuit Maxim. In een air-gapped installatie moet je het prijsbestand zelf aanleveren.
• Native alerting is alleen voor Enterprise en omvat alleen uitgaven en rate-limits. Latency- en error-alerts moet je zelf bouwen.
• Als je logs offloadt naar S3 of GCS (Enterprise), verwijdert de retentie-cleaner die objecten niet. Stel een lifecycle-regel in voor de bucket.

Wat is OSS en wat is Enterprise

Als de vraag over Enterprise verder gaat dan observability, behandelt onze vergelijking van Bifrost Enterprise vs OSS identiteit, audit en clustering.

Waar de monitoring van Bifrost ophoudt

Bifrost vertelt je wat er is gebeurd. Het vertelt je niet of het antwoord goed was. Kwaliteitssignalen zoals evaluaties, drift en hallucinatie-checks bevinden zich in het afzonderlijke platform van Maxim, waar de gratis Maxim-plugin verkeer naar doorstuurt, of in tooling die je bouwt op basis van geëxporteerde logs. De gateway laat het ontwerpen van dashboards, alert-regels, het dimensioneren van de log-opslag en het log-beleid per team ook aan jou over. Content-logging is wereldwijd ingeschakeld of uitgeschakeld, per request of per connector; er is geen regel zoals “log nooit de prompts van het financiële team.”

Het TrueFoundry-alternatief

De TrueFoundry AI Gateway omvat dezelfde drie vlakken met minder instelwerk. Een paar verschillen die van belang zijn na het lezen van de bovenstaande valkuilen:

• Een dashboard dat je niet zelf hoeft te bouwen. Het metrics-dashboard omvat kosten, LLM- en MCP-calls, foutenanalyses, guardrail-resultaten, routing, caching en kostenbesparingen, en filtert op model, gebruiker, virtueel account en team (metrics dashboard).
• OTel-export vanuit de UI. Traces en metrics kunnen elk worden geëxporteerd naar elke OTLP-backend via HTTP of gRPC, met aangepaste headers en een optie voor delta temporality, geconfigureerd in de gateway-instellingen in plaats van in een configuratiebestand (OpenTelemetry-gegevens exporteren).
• Prometheus wanneer je de gateway zelf host. Een zelfgehoste gateway exposeert /metrics met model-, tenant- en gebruikerslabels, en je kiest welke request metadata-sleutels labels worden, waardoor de cardinaliteit onder jouw controle blijft (Prometheus en Grafana).
• Logging-regels op basis van wie en wat. Logging-configs matchen op gebruikers, teams, virtuele accounts, models of request metadata, beslissen of bodies worden gelogd volgens het principe dat weigeren wint, en redacteren patronen uit het opgeslagen exemplaar (logging-configuratie). Dat is de regel “log nooit de prompts van het financiële team” die Bifrost niet heeft.

Als je je tijd liever besteedt aan wat de metrics betekenen dan aan het aansluiten ervan, bekijk dan hoe de TrueFoundry AI Gateway omgaat met LLM-monitoring.

Gerelateerde artikelen

• Observability in een AI-gateway
• Wat is LLM-observability?
• Beste LLM-observabilitytools
• AI-agent observability: waarom deed hij dat?
• Bifrost-prijzen: OSS, Enterprise-kosten en wat teams moeten weten

Conclusie

Bifrost biedt gratis een goede basis voor LLM-monitoring: logs per request, Prometheus-metrics met governance-bewuste labels, en OpenTelemetry-traces in de conventie van jouw keuze. Het production-ready maken ligt bij jou. Scrape per pod, houd ID's buiten dimension-labels, stel de content flag in op elke connector en bouw de alerts en dashboards die niet worden meegeleverd. Als die lijst eruitziet als werk dat je liever niet zelf doet, boek dan een TrueFoundry-demo en vergelijk de twee setups naast elkaar.