Skip to main content

Overview

Bifrost provides built-in telemetry and monitoring capabilities through Prometheus metrics collection. The telemetry system tracks both HTTP-level performance metrics and upstream provider interactions, giving you complete visibility into your AI gateway’s performance and usage patterns. Key Features:
  • Prometheus Integration - Native metrics collection at /metrics endpoint
  • Comprehensive Tracking - Success/error rates, token usage, costs, and cache performance
  • Custom Labels - Configurable dimensions for detailed analysis
  • Dynamic Headers - Runtime label injection via x-bf-dim-* headers
  • Cost Monitoring - Real-time tracking of AI provider costs in USD
  • Cache Analytics - Direct and semantic cache hit tracking
  • Async Collection - Zero-latency impact on request processing
  • Multi-Level Tracking - HTTP transport + upstream provider metrics
The telemetry plugin operates asynchronously to ensure metrics collection doesn’t impact request latency or connection performance.

Default Metrics

HTTP Transport Metrics

These metrics track all incoming HTTP requests to Bifrost: Labels:
  • path: HTTP endpoint path
  • method: HTTP verb (e.g., GET, POST, PUT, DELETE)
  • status: HTTP status code
  • custom labels: Custom labels configured in the Bifrost configuration

Upstream Provider Metrics

These metrics track requests forwarded to AI providers: Base Labels:
  • provider: AI provider name (e.g., openai, anthropic, azure)
  • model: Model name (e.g., gpt-4o-mini, claude-3-sonnet)
  • alias: Alias resolved to this model (empty if none)
  • method: Request type (chat, text, embedding, speech, transcription)
  • virtual_key_id: Virtual key ID
  • virtual_key_name: Virtual key name
  • routing_engine_used: Comma-separated routing engines used (routing-rule, governance, loadbalancing, model-catalog, core). core is emitted when the Bifrost orchestrator itself makes a routing decision — i.e. a fallback transition or a retry transition.
  • routing_rule_id: Routing rule ID that matched the request
  • routing_rule_name: Routing rule name that matched the request
  • selected_key_id: ID of the key that successfully served the request (empty string "" on final errors)
  • selected_key_name: Name of the key that successfully served the request (empty string "" on final errors)
  • fallback_index: Fallback index (0 for first attempt, 1 for second attempt, etc.)
  • team_id / team_name: Team identifiers (empty when governance is not used)
  • customer_id / customer_name: Customer identifiers (empty when governance is not used)
  • custom labels: Custom labels configured in the Bifrost configuration

Streaming Metrics

These metrics capture latency characteristics specific to streaming responses:

Monitoring Examples

Success Rate Monitoring

Track the success rate of requests to different providers:

Token Usage Analysis

Monitor token consumption across different models:

Cost Tracking

Monitor spending across providers and models:

Cache Performance

Track cache effectiveness:

Error Rate Analysis

Monitor error patterns:

Configuration

Configure custom Prometheus labels to add dimensions for filtering and analysis:
Prometheus Labels
  1. Navigate to Configuration
    • Open Bifrost UI at http://localhost:8080
    • Go to Config tab
  2. Prometheus Labels

Dynamic Label Injection

Add custom label values at runtime using x-bf-dim-* headers:
Header Format:
  • Prefix: x-bf-dim-
  • Label name: Any string after the prefix, except reserved metric labels like path and method
  • Value: String value for the label
These runtime dimensions are also forwarded to the other observability backends. The same x-bf-dim-* values appear in internal logs, OpenTelemetry span attributes, and Maxim tags.
Legacy x-bf-prom-* headers still work for Prometheus-only behavior, but they are deprecated. When both prefixes provide the same label, x-bf-dim-* wins.

Infrastructure Setup

Development & Testing

For local development and testing, use the provided Docker Compose setup:
Development Only: The provided Docker Compose setup is for testing purposes only. Do not use in production without proper security, scaling, and persistence configuration.
You can use the Prometheus scraping endpoint to create your own Grafana dashboards. Given below are few examples created using the Docker Compose setup. Grafana Dashboard

Production Deployment

For production environments:
  1. Deploy Prometheus with proper persistence, retention, and security
  2. Configure scraping to target your Bifrost instances at /metrics
  3. Set up Grafana with authentication and dashboards
  4. Configure alerts based on your SLA requirements
Prometheus Scrape Configuration:
If you have Bifrost authentication enabled (auth_config), you must include basic_auth in the scrape config with your admin_username and admin_password. See the Prometheus docs for details.

Production Alerting Examples

Configure alerts for critical scenarios using the new metrics: High Error Rate Alert:
High Cost Alert:
Cache Performance Alert:

Next Steps