Skip to main content

Overview

HoneyHive supports multiple tracer instances in a single application. Each instance maintains its own session context, configuration, and OTel TracerProvider. Instances do not share context. Projects are selected by the API key. Use a separate project-scoped API key when a tracer should write to a different HoneyHive project. Use metadata or session enrichment when traces should stay in the same project.

Use Cases

Environment-Based Tracing

Send each environment to the project scoped to its API key:

Multi-Tenant SaaS

Give each tenant its own tracer and session metadata. If tenants need project-level isolation, select a project-scoped API key for that tenant:

A/B Testing

Run different configurations side-by-side and compare them with session metadata:

Feature Isolation

Route different features to projects scoped by separate API keys:

Per-Request Initialization

For full isolation, initialize a tracer per request:

Thread Safety

HoneyHive uses Python’s contextvars for thread safety. When using thread pools, propagate context explicitly:
Copy the context for each executor.submit() call. Reusing a single context object across threads causes race conditions. See Multi-Threading for details.

Best Practices

  • Keep tracer instances in a central registry - create once, reuse many times
  • Use project-scoped API keys when a tracer should write to a different project
  • Store API keys in environment variables or a secret manager, never hard-code them
  • Use metadata to differentiate when possible, rather than creating additional tracers
  • 2-5 tracers per application is typical and performant

Performance


Production Deployment

Initialization patterns for production environments

Multi-Threaded Tracing

Context propagation across threads