Overview
HoneyHive supports multiple tracer instances in a single application. Each instance maintains its own session context, configuration, and OTelTracerProvider. 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’scontextvars for thread safety. When using thread pools, propagate context explicitly:
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
| Metric | Impact |
|---|---|
| Memory | ~100KB per tracer instance |
| Network | Batched, async export per tracer |
| Span Processing | Each tracer has its own processor |
Related
Production Deployment
Initialization patterns for production environments
Multi-Threaded Tracing
Context propagation across threads

