OpenTelemetry

When should I use this?

• You already run OpenTelemetry and want AutoObserve to consume metrics, logs, and traces.
• You need vendor-neutral ingestion with consistent resource identity across signals.
• You are evaluating AutoObserve alongside an existing observability backend.

Requirements

• OpenTelemetry Collector or SDK export path you can modifyRequired
• AUTOOBSERVE_OTLP_ENDPOINT and API credentialsRequired
• Aligned service.name, service.version, and Kubernetes attributesRequired
• Existing Prometheus, Grafana, or Jaeger backend (optional coexistence)Optional

Steps

1. Add the AutoObserve exporter

Add an AutoObserve exporter to your OpenTelemetry Collector (or SDK export path):

# Add to your OpenTelemetry Collector exporters:
exporters:
  otlp/autoobserve:
    endpoint: ${AUTOOBSERVE_OTLP_ENDPOINT}
    headers:
      authorization: ${AUTOOBSERVE_API_KEY}

service:
  pipelines:
    traces:
      exporters: [otlp/autoobserve]
    metrics:
      exporters: [otlp/autoobserve]
    logs:
      exporters: [otlp/autoobserve]

Store endpoint and credentials in environment variables or your secret manager — do not commit API keys to source control.

Use the Quick Start stepper for the interactive verification checklist.

2. Keep your collector topology

Keep your existing Collector / Gateway deployment. AutoObserve is designed to subscribe to the pipelines you already operate.

Fork export from the Collector you already run:

Applications → OpenTelemetry SDK → Collector
                                    ├─ Existing backend (Prometheus / Loki / Tempo / …)
                                    └─ AutoObserve

You do not need to remove your current observability backend to evaluate AutoObserve. See Architecture on the OpenTelemetry page for Kubernetes and greenfield paths.

3. Align resource identity

Correlation starts with consistent identity — align these across metrics, logs, and traces:

Incomplete identity reduces correlation confidence. See Identity on the OpenTelemetry page for the canonical service model and GOOD vs PARTIAL examples.

4. Verify signals and open a service

1. Restart or reload the Collector pipeline after applying the exporter.
2. Confirm metrics, logs, and traces arrive with expected resource attributes.
3. Open a known service — for example checkout-api — in Observability.

Product overview: How telemetry becomes production evidence — architecture, identity, quality, and quick start on the marketing page.

Engineering paper: OpenTelemetry gives you telemetry, not understanding — why standardizing collection is not the same as production understanding.

Did it work?

• Collector connected to AutoObserve
• Metrics receiving
• Logs receiving
• Traces receiving (all pipelines configured)
• Known service visible in Observability

Troubleshooting