Traceloop Hub

repository·main·Indexed 42 days ago

https://github.com/traceloop/hub

An open-source LLM gateway written in Rust that centralizes control, observability, and tracing for LLM calls via a unified, OpenAI-compatible API. It supports two deployment modes: YAML Mode for static configurations and Database Mode for dynamic configuration via a PostgreSQL database and a REST Management API. Version 0.10.1.

Tokens
13.4K
Snippets
44
Records
52
Agent score
52%

What's inside Traceloop Hub

  1. Understand the Traceloop Hub architecture

    main

    Traceloop Hub acts as an intermediary between your Client Application and LLM Providers (like OpenAI). It supports two primary configuration modes: YAML Mode (for simple deployments) and Database Mode (which includes a Management API).

    Data flow follows this pattern:

    1. Client App sends requests to Traceloop Hub.
    2. Traceloop Hub routes requests to the LLM Provider.
    3. Traceloop Hub also handles/forwards data to Observability backends (such as OTel or Metrics).
  2. How YAML Mode works

    main

    YAML Mode is designed for simple deployments and development environments. It uses a static config.yaml file for configuration and has no external dependencies like a database.

    Key Characteristics:

    • Static configuration via config.yaml.
    • No management API.
    • Operates on a single port (3000).
    • Ideal for simple provider and model setups.
    providers:
      - key: openai
        type: openai
        api_key: sk-...
    
    models:
      - key: gpt-4
        type: gpt-4
        provider: openai
    
    pipelines:
      - name: chat
        type: Chat
        plugins:
          - ModelRouter:
              models: [gpt-4]
  3. How Database Mode works

    main

    Database Mode is intended for production environments that require dynamic configuration and hot reloading without service restarts.

    Key Characteristics:

    • Uses a PostgreSQL database for configuration storage.
    • Includes a REST Management API for dynamic updates.
    • Supports hot reloading and configuration polling.
    • Uses a SecretObject system for managing credentials.
    • Operates on dual ports: 3000 for the Gateway and 8080 for the Management API.
    ### Setup
    
    1. Set up a PostgreSQL database.
    2. Run migrations: `sqlx migrate run`.
    3. Set environment variables:
    
    ```bash
    HUB_MODE=database
    DATABASE_URL=postgresql://user:pass@host:5432/db
  4. Run Traceloop Hub in Daemon mode

    main

    Daemon mode runs the Traceloop Hub containers in the background. This is useful for persistent services where you do not want to see the logs directly in your terminal session.

    To start the service in the background: docker compose --env-file env.template up -d

    To stop and remove the containers: docker compose --env-file env.template down

    docker compose --env-file env.template up -d
    
    docker compose --env-file env.template down
  5. Setup Traceloop Hub using Docker Compose

    main

    To run Traceloop Hub locally using Docker Compose, follow these steps to prepare your environment:

    1. Copy the provided template file env.template to a new file named .env.
    2. Open .env and customize the credentials and connection strings to match your environment requirements.
    3. Use the --env-file env.template flag with Docker Compose commands to ensure the correct configuration is loaded.
    cp env.template .env
  6. Quick Start with Traceloop Hub

    main

    You can quickly get started with Traceloop Hub using either Docker or Cargo. Choose YAML Mode for simple, static deployments or Database Mode for dynamic configuration with a management API.

    ### Using Docker
    
    ```bash
    # YAML Mode (simple deployment)
    docker run -p 3000:3000 -v $(pwd)/config.yaml:/app/config.yaml traceloop/hub
    
    # Database Mode (with management API)
    docker run -p 3000:3000 -p 8080:8080 \
      -e HUB_MODE=database \
      -e DATABASE_URL=postgresql://user:pass@host:5432/db \
      traceloop/hub

    Using Cargo

    # Clone and build
    git clone https://github.com/traceloop/hub.git
    cd hub
    cargo build --release
    
    # YAML Mode
    ./target/release/hub
    
    # Database Mode  
    HUB_MODE=database DATABASE_URL=postgresql://user:pass@host:5432/db ./target/release/hub
  7. Fallback behavior when no configuration is available

    main

    If the Hub is running without an active configuration, it uses a fallback router created by create_no_config_router. This router explicitly listens for common LLM endpoints:

    • POST /chat/completions
    • POST /completions
    • POST /embeddings

    When these endpoints are called without a configuration, the Hub returns a 404 Not Found error.

  8. How secret resolution works in the Hub

    main

    The SecretResolver service is used to transform SecretObject definitions into actual string values (e.g., API keys or credentials). It supports three primary modes of resolution:

    1. Literal: Uses the provided string value directly. Note that if the encrypted flag is set to true, the system currently treats it as plaintext and logs a warning, as decryption is not yet implemented.
    2. Environment: Fetches the value from a system environment variable specified by variable_name. If the variable is not found, an error is returned.
    3. Kubernetes: Attempts to resolve a secret from a Kubernetes namespace using a secret_name and key. Note: Kubernetes secret resolution is currently not implemented and will return an error.

    When configuring providers or services, you can use these modes to avoid hardcoding sensitive information in configuration files.

    // Example of how the different SecretObject variants behave:
    
    // 1. Literal (Plaintext)
    let literal = SecretObject::Literal { value: "my-key".to_string(), encrypted: Some(false) };
    
    // 2. Environment Variable
    let env_var = SecretObject::Environment { variable_name: "API_KEY".to_string() };
    
    // 3. Kubernetes (Currently returns an error)
    let k8s = SecretObject::Kubernetes { 
        secret_name: "my-secret".to_string(), 
        key: "api-key".to_string(), 
        namespace: Some("default".to_string()) 
    };
  9. Configure SecretObject for API requests

    main

    When managing providers or configuring plugins (like Tracing), you can use the SecretObject abstraction to define how sensitive values like API keys are retrieved. This prevents hardcoding secrets in your configuration.

    Supported types:

    • literal: A direct string value. Use {"type": "literal", "value": "your-secret"}.
    • kubernetes: A reference to a Kubernetes secret. Use {"type": "kubernetes", "secret_name": "my-secret", "key": "api-key", "namespace": "my-namespace"}.
    • environment: A reference to an environment variable. Use {"type": "environment", "variable_name": "MY_ENV_VAR"}.
    {
      "type": "environment",
      "variable_name": "TRACING_API_KEY"
    }
  10. Understand the difference between LLM Gateway and Management API

    main

    When running Traceloop Hub, you may interact with one or two distinct server interfaces depending on your HUB_MODE:

    1. LLM Gateway: This server is always present. It handles the actual LLM requests, routing them through configured providers, models, and pipelines. It listens on the port defined by PORT (default 3000).

    2. Management API: This server is only available in database mode. It provides an interface for managing the gateway's configuration via the database. It listens on the port defined by MANAGEMENT_PORT (default 8080).

  11. Configure Traceloop Hub deployment modes

    main

    Traceloop Hub can be run in two distinct configuration modes, determined by the HUB_MODE environment variable. This choice dictates how the gateway retrieves its configuration (providers, models, and pipelines) and whether a management API is available.

    YAML Mode

    In this mode, the gateway loads configuration from a static file. This is suitable for simple deployments where configuration changes are managed via file updates and service restarts.

    • Trigger: Set HUB_MODE=yaml or leave it unset (default).
    • Configuration File: Controlled by the CONFIG_FILE_PATH environment variable. If not set, it defaults to config.yaml.

    Database Mode

    In this mode, the gateway fetches configuration from a PostgreSQL database and periodically polls for updates. This allows for dynamic, live configuration changes without restarting the gateway. It also enables a Management API server.

    • Trigger: Set HUB_MODE=database.
    • Database Connection: Requires the DATABASE_URL environment variable to be set.
    • Polling: The frequency of configuration updates is controlled by DB_POLL_INTERVAL_SECONDS (defaults to 30 seconds).
    # Example: Running in YAML mode with a custom config path
    export HUB_MODE=yaml
    export CONFIG_FILE_PATH=/path/to/my/config.yaml
    ./hub
    
    # Example: Running in Database mode
    export HUB_MODE=database
    export DATABASE_URL=postgres://user:pass@localhost:5432/dbname
    ./hub