How do I connect HoneyHive to our existing OpenTelemetry Collector pipeline?

Most teams already have an OpenTelemetry Collector pipeline in place before they add HoneyHive. You don’t need to rebuild that stack. Because HoneyHive is OpenTelemetry-native and speaks OTLP directly, connecting it usually comes down to adding a new exporter and, optionally, a pipeline dedicated to AI traces.

Quick Answer: Point your existing OpenTelemetry Collector to HoneyHive’s OTLP endpoint as an additional exporter, then route the traces (and spans) you care about into that exporter. You can do this with a few lines of configuration while keeping your current telemetry pipeline intact.

Frequently Asked Questions

How does HoneyHive work with an existing OpenTelemetry Collector pipeline?

Short Answer: HoneyHive plugs into your current OpenTelemetry Collector as an OTLP-compatible backend, so you add it as another exporter and send relevant AI traces there.

Expanded Explanation:
HoneyHive is built on OpenTelemetry primitives, not a proprietary SDK. If you’re already collecting traces and spans through an OpenTelemetry Collector, you can keep that architecture and simply extend it. You configure a new otlp exporter that points to HoneyHive’s ingestion endpoint and wire an existing or new pipeline to use that exporter. From there, HoneyHive ingests OTLP traces, reconstructs agent runs into graph and timeline views, and lets you layer online evals, alerts, and annotation workflows on top.

This means you don’t have to “fork” your observability stack just to get AI observability and evaluation. Collector stays the central routing layer; HoneyHive becomes the AI-native observability and evaluation surface that understands prompts, model calls, tools, and RAG spans.

Key Takeaways:

• HoneyHive accepts OTLP traces directly, so it slots into your existing OpenTelemetry Collector.
• You typically just add a new OTLP exporter and route AI/LLM spans to HoneyHive while keeping your current backends.

---

What are the exact steps to connect HoneyHive to our OpenTelemetry Collector?

Short Answer: Add HoneyHive as an OTLP exporter in your Collector config, wire it into a traces pipeline, then verify that AI spans are flowing into HoneyHive.

Expanded Explanation:
At a high level, you (1) define a new OTLP exporter that points to HoneyHive, (2) add that exporter to the traces pipeline that carries your AI/LLM traffic, and (3) restart the Collector and validate traces in HoneyHive. You can either mirror traces to HoneyHive alongside your existing backend (e.g., Jaeger, Tempo, X-Ray) or create a dedicated “ai-traces” pipeline if you want more control around sampling and filtering.

On the application side, you keep instrumenting with OpenTelemetry as before—either via HoneyHive’s OpenTelemetry-native SDKs or any other OTLP-compatible instrumentation. The Collector remains the single ingestion point; HoneyHive becomes one of the exporters that receives those traces.

Steps:

1. Get your HoneyHive OTLP endpoint and auth

   • In HoneyHive, grab the OTLP ingestion URL and any required headers or tokens (e.g., x-api-key or similar).
   • Decide whether you’re sending over gRPC (otlp) or HTTP/JSON (otlphttp).

2. Add HoneyHive as an exporter in your Collector config
   Example (YAML, HTTP exporter):

   exporters:
     otlp/honeyhive:
       endpoint: https://ingest.honeyhive.ai/otlp/v1/traces
       auth:
         authenticator: bearer/honeyhive
   

   And an authenticator:

   extensions:
     bearer/honeyhive:
       scheme: "Bearer"
       token: "${HONEYHIVE_API_KEY}"
   

3. Attach the exporter to a traces pipeline and restart

   service:
     pipelines:
       traces/ai:
         receivers: [otlp]
         processors: [batch]
         exporters: [otlp/honeyhive, otlp/your-existing-backend]
   

   Restart the Collector, then use HoneyHive’s Traces and Playground views to confirm spans are arriving and stitched correctly.

---

What’s the difference between using HoneyHive’s SDKs and only using the Collector?

Short Answer: The Collector handles transport of OTLP traces; HoneyHive’s SDKs add AI-specific instrumentation and auto-instrumentation for popular agent frameworks on top of standard OpenTelemetry.

Expanded Explanation:
If you only use the OpenTelemetry Collector, HoneyHive will still ingest any OTLP-compatible spans you send. You’ll see traces, spans, and attributes like you do in any OpenTelemetry backend. However, HoneyHive’s Python and Typescript SDKs are OpenTelemetry-native and tuned for AI workloads: they auto-instrument popular LLM libraries and agent frameworks, standardize span schemas for prompts, model calls, tools, and RAG steps, and make it easy to attach eval metadata and user feedback directly at the span level.

In practice, most teams keep their existing Collector and add HoneyHive’s SDKs inside their AI services. The SDKs generate rich AI spans and attributes; the Collector then routes those spans into HoneyHive (and any other backend) without you having to write custom span plumbing.

Comparison Snapshot:

• Collector-only:
  • Standard OTLP transport.
  • Works with any OpenTelemetry instrumentation you already have.
  • You may need to manually standardize span names/attributes for AI semantics.
• Collector + HoneyHive SDKs:
  • AI-aware span structure (prompts, tool calls, RAG, agents).
  • Auto-instrumentation for common LLM libraries and frameworks.
  • Built-in hooks for evaluations, annotations, and production-to-dataset workflows.
• Best for:
  • Collector-only when you want minimal changes and already have rich OTLP spans.
  • Collector + HoneyHive SDKs when you want full agent observability, online evals, and standardized telemetry with minimal manual work.

---

What do I need to implement before HoneyHive starts receiving traces?

Short Answer: You need a reachable HoneyHive OTLP endpoint, credentials, and an updated Collector configuration that exports AI traces to HoneyHive.

Expanded Explanation:
From a deployment perspective, HoneyHive is just another OTLP backend. Your OpenTelemetry Collector must be able to reach HoneyHive’s ingestion endpoint (respecting your network and firewall policies), and you must configure authentication according to your HoneyHive account (API keys, headers, or tokens). On the application side, your services need to emit traces that reach the Collector—either via HoneyHive’s OpenTelemetry-native SDKs or any OpenTelemetry library you already use.

Once those pieces are in place, HoneyHive will start reconstructing traces into agent runs. You can then layer Monitors, Alerts, and Evaluators on top of those traces, and turn failing runs into datasets and CI regression tests.

What You Need:

• Network + Auth:
  • HoneyHive OTLP endpoint accessible from your Collector (SaaS or self-hosted HoneyHive).
  • API key or token wired into the Collector config (environment variables recommended).
• Instrumentation + Routing:
  • OpenTelemetry traces emitted from your AI services (via HoneyHive SDKs or existing OTEL instrumentation).
  • Collector pipelines that receive those traces and export them to otlp/honeyhive.

---

How does connecting HoneyHive to our Collector help us operationally?

Short Answer: It lets you reuse your existing telemetry pipeline while adding AI-specific observability, evaluation, and governance on top of the same OTLP traces.

Expanded Explanation:
By plugging HoneyHive into your OpenTelemetry Collector, you standardize around one telemetry path and avoid siloed AI observability. Traces for your agents, tools, and RAG calls flow through the same Collector you use for the rest of your stack, but HoneyHive adds the AI-native layer: graph views for agent runs, online evals on live traffic, annotation queues for domain-expert review, and automated drift detection and alerts on model behavior.

The bigger impact is closed-loop reliability. When a production span fails (unsafe output, hallucination, tool misuse, latency spike), you can see the full trace, route it into a dataset directly from HoneyHive, run experiments on alternative prompts/models, and then enforce regression checks in CI. All of this is driven by the same OTLP traces you’re already generating.

Why It Matters:

• Operational consistency:
  • Keep one OpenTelemetry Collector pipeline; add HoneyHive as the AI observability and evaluation surface.
  • Avoid bespoke agents-only pipelines or custom integrations for every framework.
• Higher reliability in production:
  • Catch silent failures, quality drift, and tool misuse through alerts and online evals on live OTLP traces.
  • Turn real production failures into repeatable test cases and CI checks using HoneyHive’s datasets and experiments.

---

Quick Recap

You don’t have to redesign your observability stack to get AI observability and evaluation. Because HoneyHive is OpenTelemetry-native, you connect it to your existing OpenTelemetry Collector by adding a new OTLP exporter and routing AI traces there. For richer AI semantics, combine that with HoneyHive’s OpenTelemetry-based SDKs to auto-instrument LLMs and agents. The result is end-to-end tracing, online/offline evals, and governance on top of the same OTLP pipeline you’re already running.

Next Step

Get Started