Skip to main content
Keep your existing OTel pipeline (Honeycomb, Datadog, Grafana Tempo, Jaeger) and add Trodo alongside. The Trodo SDK doesn’t own the OTel tracer — it registers its own exporter. Any other exporter you’ve set up keeps working.
import { NodeTracerProvider } from '@opentelemetry/sdk-trace-node';
import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import trodo from 'trodo-node';

// 1. Your existing OTel setup — unchanged.
const provider = new NodeTracerProvider();
provider.addSpanProcessor(
  new BatchSpanProcessor(
    new OTLPTraceExporter({ url: 'https://api.honeycomb.io/v1/traces' }),
  ),
);
provider.register();

// 2. Trodo attaches its own exporter to the same provider.
trodo.init({ siteId: process.env.TRODO_SITE_ID });

// 3. Instrument as normal. Every span goes to both exporters.
await trodo.wrapAgent('support-bot', async () => {
  // ...
});

What each backend sees

  • Your OTel collector — standard spans with gen_ai.* semantic-convention attributes. Your existing dashboards keep working.
  • Trodo — the same spans, grouped into runs, with the Trodo-specific rollups (tokens, cost, feedback, clusters).
Both use the same trace_id / span_id, so you can cross-reference a run in Trodo against a trace in your OTel backend.

Disable Trodo’s built-in exporter

If you’d rather pipe everything through your existing OTLP collector and let it forward to Trodo, set exporter: 'none':
trodo.init({ siteId: process.env.TRODO_SITE_ID, exporter: 'none' });
Then point your OTLP exporter at https://sdkapi.trodo.ai/otlp/v1/traces with header X-Trodo-Site-Id: <your-site-id>.

See also