Skip to content
AutoObserve
Design Partner

TELEMETRY EVIDENCE

OpenTelemetry Build the telemetry foundation for production investigations.

Keep your instrumentation. Keep your Collector. Send OpenTelemetry telemetry to AutoObserve and transform metrics, logs and traces into correlated production evidence for investigation, topology and AIDDE.

Signals
Metrics · Logs · Traces
Protocols
OTLP
Deployment
Collector
Status
GA
See the evidence received ↓View architecture →

OpenTelemetry Quick Start →

Your applications

  • Java
  • Go
  • Python
  • Node.js
  • .NET

  1. OpenTelemetry

  2. Existing Collector

  3. AutoObserve

  4. Production evidence

  5. Correlation → Investigation → AIDDE

WHY THIS INTEGRATION MATTERS

Instrument once. Keep telemetry portable.

OpenTelemetry is the evidence transport layer serious teams already standardise on — without locking instrumentation to a single vendor.

  • Open instrumentation

    Instrument once. Keep your applications portable.

  • Portable telemetry

    Change observability platforms. Not instrumentation.

  • Common semantics

    Shared resource attributes. Shared meaning.

  • Collector ecosystem

    Use the Collector architecture your team already trusts.

EVIDENCE RECEIVED

Metrics, logs, traces and resource attributes

OpenTelemetry delivers operational signals with shared semantics. AutoObserve treats them as production evidence — not disconnected telemetry streams.

  • Metrics
  • Logs
  • Traces
  • Resource attributes

  1. Telemetry

    Metrics, logs, traces and resources arrive via your existing pipeline.

  2. Evidence

    Signals normalise into inspectable production evidence classes.

  3. Context

    Shared service, environment and time window survive every transition.

  4. Relationships

    Evidence connects across dependencies, changes and runtime objects.

  5. Investigation

    Correlated evidence supports explainable hypotheses — not opaque scores.

  6. Decision

    Teams act with visible evidence — and known gaps — behind every conclusion.

IDENTITY & SEMANTIC CONVENTIONS

Correlation starts with identity.

Shared resource attributes are not metadata decoration. They are how metrics, logs and traces become the same production story.

ATTRIBUTE CHAIN

  1. Metric

    service.name

  2. Trace

    service.version

  3. Pod

    k8s.pod.name

  4. Namespace

    k8s.namespace.name

  5. Deployment

    k8s.deployment.name

  6. Canonical service

    checkout-api

CANONICAL SERVICE RESOLUTION

  • checkout
  • checkout-service
  • checkout-api
  • checkout-prod

checkout-api

AutoObserve resolved them.

IDENTITY QUALITY

Correlation confidence reduced when identity attributes are incomplete.

  • checkout-api

    GOOD
    • service.name
    • version
    • namespace
    • environment
    • workload
    • cluster

  • legacy-payment

    PARTIAL
    • service.name
    • environment
    • namespace
    • version

    Correlation confidence reduced.

Explore Topology →

HOW AUTOOBSERVE USES THIS EVIDENCE

Telemetry arrives as signals. AutoObserve builds production understanding from them.

AutoObserve does not stop at ingestion. It resolves identity, correlates signals, models runtime context and prepares evidence for investigation and AIDDE.

Provides

  1. Metrics
  2. Logs
  3. Traces
  4. Resources

AutoObserve creates

  1. Identity
  2. Correlation
  3. Runtime model
  4. Investigation
  5. AIDDE

OpenTelemetry is evidence. AutoObserve is understanding.

OpenTelemetry gives you telemetry, not understanding →

FIT INTO YOUR EXISTING ARCHITECTURE

Add AutoObserve without replacing your stack.

Keep your SDKs, Collector and existing backends. AutoObserve subscribes to the telemetry path you already operate.

Fork telemetry from the Collector you already run — alongside your current backend.

  1. Applications

  2. OpenTelemetry SDK

  3. Collector

  4. Export fork

    • Existing backend
    • AutoObserve

Already query Prometheus, Loki or Tempo directly? Multi-DSL can access those backends in parallel with OpenTelemetry ingestion.

Explore Multi-DSL →

QUICK START

Connect OpenTelemetry in four steps.

Minimal configuration to fork telemetry into AutoObserve. Full Collector and Kubernetes guides live in docs.

Configure exporter

Add an AutoObserve exporter to your Collector or SDK.

Minimal OpenTelemetry Collector exporter configuration
# 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]
Explore Observability →

TELEMETRY QUALITY

Evidence quality is part of the product.

AutoObserve surfaces missing or partial telemetry before it silently weakens investigation — aligned with explainable, uncertainty-aware automation.

checkout-api

  • Metrics

    GOOD

  • Logs

    GOOD

  • Traces

    PARTIAL

    Trace coverage incomplete on payment path.

  • Identity

    GOOD

  • Sampling

    31%

    Head-based sampling on ingress.

  • Collector

    Healthy

INVESTIGATION CONFIDENCE

Reduced

PARTIAL

Reason

Trace coverage incomplete.

Investigation confidence may be reduced when trace evidence is partial.

WHAT SUCCESS LOOKS LIKE

Telemetry connected. Context ready for investigation.

Success means production evidence is flowing with resolvable identity — not merely that an exporter is configured.

  • Services detected

    checkout-api and peer services appear in production context.

  • Runtime identity resolved

    service.name and deployment attributes resolve consistently.

  • Telemetry flowing

    Metrics and logs arrive; trace coverage gaps are visible.

  • Correlation active

    Signals connect in a shared investigation window.

REAL INCIDENT

One degradation. One evidence chain.

The same checkout-api fixture used across AutoObserve — metric, log, trace, deployment and identity connected in one production window.

  1. Metric

    14:31:00

    Checkout latency +184%

Walk through the evidence chain · 1/6

Evidence step 1 of 6

TROUBLESHOOTING

Common telemetry path failures

  • Problem

    Traces missing in AutoObserve

    Likely cause

    Trace pipeline not configured in the Collector export path.

    Resolution

    Add a traces pipeline to your Collector exporter configuration and reload the Collector.

    Verify

    Trace channel shows Receiving in the verification panel.

  • Problem

    Identity attributes incomplete

    Likely cause

    Resource attributes missing service.name or deployment.environment.

    Resolution

    Apply semantic conventions in SDK resource detection or Collector processors.

    Verify

    Identity quality cards move from PARTIAL to GOOD.

  • Problem

    No metrics arriving

    Likely cause

    Exporter endpoint unreachable or metrics pipeline omitted.

    Resolution

    Verify OTLP endpoint, TLS settings, and that metrics receivers are wired.

    Verify

    Metrics channel shows Receiving after a deploy window.

PRODUCTION INTELLIGENCE

How OpenTelemetry contributes to production understanding

Each signal class enables a distinct investigation capability inside AutoObserve.

EvidenceEnables
MetricsPerformance understanding
LogsOperational context
TracesRequest causality
Resource attributesIdentity
Kubernetes metadataRuntime topology
DeploymentsChange correlation

KEEP TELEMETRY OPEN

Keep your telemetry open. Add production intelligence.

Send OpenTelemetry to AutoObserve without re-instrumenting — and build operational understanding from the evidence you already collect.

OpenTelemetry Quick StartRead integration docsBecome a Design Partner