OpenTelemetry backend — OTel-first, not OTel-bolt-on

TL;DR. Sutrace is a native OpenTelemetry backend. OTLP is the primary protocol, not a translation layer wedged in front of a proprietary store. You ship traces, metrics, and logs over gRPC or HTTP/protobuf, we land them in ClickHouse, and you query in seconds. No vendor agent, no re-tagging at ingest, no SDK lock-in. Cardinality is monitored per service and shown in dollars before the bill, not after. EU residency is the default (Frankfurt, europe-west3). If your team has standardised on the OpenTelemetry Collector and you don't want a backend that treats OTLP as a second-class input, this is the page for you. The rest is detail.

This page covers what "OTel-first" actually means in implementation, the pipeline you'll end up running, what we don't do, and the FAQ that comes up on every demo call.

What "OTel-first" means in practice

Most observability vendors accept OTLP. Fewer are built around it. The difference shows up in five places:

1. Ingest path. OTLP gRPC and HTTP/protobuf are the primary endpoints. There's no "Sutrace agent" you have to install. If you're already running an OpenTelemetry Collector, you point its otlp exporter at our endpoint and you're done. If you're not, the same OTel Collector binary is what we recommend, configured with our example pipeline.
2. Tag fidelity. We don't rename your resource attributes at ingest. service.name stays service.name. deployment.environment stays deployment.environment. Datadog historically rewrote these into its own tag namespace; some commercial backends still do. We don't, because the moment you re-tag, you've broken portability — your queries no longer survive a vendor switch.
3. Storage shape. Traces, metrics, and logs land in ClickHouse, in tables that match the OTel data model. The schema is the official OTel ClickHouse exporter schema. If you ever decide to leave us, you can replay your data into your own ClickHouse cluster with the same schema and the same exporter. The lock-in is zero by design.
4. Cardinality budget. Cardinality is enforced at the collector layer using transform and filter processors plus our sample_limit defaults. The UI shows series counts per metric, per service, in real time. We covered the architecture in cardinality cost attribution before the bill arrives.
5. No SDK lock-in. Use the upstream OTel SDKs in your language. We don't ship a "better" SDK because the upstream ones are good enough and switching SDKs is the most painful migration there is.

The pipeline you'll run

# otel-collector-config.yaml — what most teams end up with
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 8192
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert
  # Cardinality control — drop high-cardinality labels at the edge
  transform/cardinality:
    metric_statements:
      - context: datapoint
        statements:
          - delete_key(attributes, "user_id")
          - delete_key(attributes, "request_id")

exporters:
  otlp/sutrace:
    endpoint: ingest.sutrace.io:4317
    headers:
      api-key: ${env:SUTRACE_API_KEY}
    compression: zstd

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, resource]
      exporters: [otlp/sutrace]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, transform/cardinality, batch, resource]
      exporters: [otlp/sutrace]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch, resource]
      exporters: [otlp/sutrace]

Three things to note. First, memory_limiter goes before everything else so an upstream burst can't OOM your collector. Second, the transform/cardinality processor is where you defend the metrics pipeline from user_id-style label sprawl — see the cardinality explainer for the math on why this matters. Third, compression: zstd on the exporter cuts egress by 60–80% versus gzip, which on a busy node is real money.

Why a native OTel backend matters

Grafana's 2025 OpenTelemetry report found OTel-related GitHub PRs growing 40% YoY, with the Python SDK alone reaching 21M downloads/month — a 445% YoY jump. Dynatrace's OTel trends piece puts logs adoption at the same inflection point traces hit two years earlier. The protocol war is over. The backend war isn't.

When OTel won, the question shifted from "which agent should I run?" to "which backend respects my OTel data?" Some legacy backends accept OTLP but immediately translate it into a proprietary internal model, and the moment they do, you've inherited a translation tax — query semantics that don't match the OTel semantic conventions, tag names that drift, and a portability story that exists only on the marketing site. Native means the storage shape is the OTel shape, end-to-end.

ClickHouse's roundup of OTel-compatible platforms is the cleanest survey of who's actually OTel-native today. The list is shorter than vendors would like it to be.

What we don't do

We don't ship a proprietary agent. We don't re-tag your resource attributes. We don't bill on cardinality (we budget and warn instead). We don't accept StatsD as a primary protocol — if you have a StatsD-only legacy system, run a sidecar that converts it to OTLP, and we'll point you at the StatsD receiver in OTel Collector. And we don't pretend OpenMetrics scraping is a complete solution — scraping has scale issues, and once you're past the small-cluster phase, push (OTLP) is structurally better.

Where Sutrace fits in the OTel landscape

Three categories of OTel-friendly backends exist today:

1. Hyperscale incumbents — Datadog, New Relic, Dynatrace. Accept OTel, often translate it. Pricing scales with cardinality.
2. OTel-native startups — SigNoz, Uptrace, ClickStack, HyperDX. Open-source first, varying quality of managed offerings.
3. Vendor-neutral storage stacks — Grafana Mimir/Tempo/Loki, the LGTM stack. Composable, powerful, operationally heavy.

Sutrace sits in category 2 with three differences. First, we add hardware (PLC/SCADA) and AI-agent (LLM cost/latency) signals natively. Second, we ship cardinality cost attribution as a primary feature rather than an afterthought. Third, EU residency is the default, not a paid SKU. The protocol-war pillar post goes deeper on the categorisation.

Cost attribution before ingest — the part most backends skip

Cardinality is the dominant cost driver in commercial observability. ClickHouse's year-in-review named it explicitly. The fix isn't "use fewer tags" — it's to show engineers the cost at the moment they make the choice, not 30 days later when the invoice arrives.

In Sutrace, every metric's page shows the active series count, the projected monthly delta when a new label is added, and the cap at which the collector will rate-limit. There's no separate cost dashboard because cost is metric-level data. If a deploy adds a label that 10x's the cardinality, the on-call team gets a notification before the data hits storage, with a one-click revert that drops the label at the collector.

FAQ

1. Do I need to replace my existing OTel Collector? No. Point your existing collector's otlp exporter at ingest.sutrace.io:4317 and you're done. We recommend our example processor stack but don't require it.

2. What about Prometheus scrape configs? Two options. Either run prometheusreceiver inside your collector and have it scrape your existing targets, then forward over OTLP — this is the migration path most teams take. Or keep Prometheus as the scraper and use remote_write to push into our Prometheus-compatible endpoint. Native push (option 1) is structurally better; we explain why in the Prometheus-at-scale post.

3. Will my Grafana dashboards work? Yes. We expose Prometheus query API and OTel-compatible trace/log query APIs. Point Grafana at our endpoint and your existing PromQL dashboards work unchanged. LogQL-style queries are translated to our log query DSL.

4. EU residency — is data ever leaked outside the region? No. Storage is europe-west3 (Frankfurt). Backups stay in-region. Support staff access is logged and region-restricted. The pricing page lists the residency commitments per plan tier.

5. Can I self-host? Not today. Our stack is OTel Collector + ClickHouse + a thin gateway. If you want full self-host, SigNoz and Uptrace are the open-source options to look at — we recommend them honestly when self-host is a hard requirement. Our wedge is managed-with-EU-residency and cost attribution.

6. What's the migration path from Datadog? Run the OTel Collector in parallel for two weeks shipping to both Datadog and Sutrace. Validate dashboards, validate alerts, then flip. The full playbook is in migrating from Datadog to OTel — the week-one checklist.

Closing

OTel adoption is universal. The work that's left isn't on the protocol; it's on the backend. If you've standardised on OTLP and you want a backend that respects the choice — keeps tag names, keeps schemas, keeps the door open to leave — point a collector at us and run a two-week parallel-write evaluation. The free tier is enough to validate.

If your team is still on a proprietary-agent backend and you're considering the move, the Datadog comparison, the Grafana Cloud comparison, and the SigNoz comparison are the three pages to read next.