observabilityopentelemetryPractitioner

OTel-Native by Design: Streamlining Observability Across Stacks

5 min read OpenTelemetry BlogOct 8, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

Observability is no longer a luxury; it's a necessity in modern software development. As applications grow more complex, the ability to monitor and understand their behavior becomes critical. OTel-native design addresses this by enabling products to export telemetry data—logs, traces, and metrics—directly to any observability stack, simplifying integration and enhancing visibility across your systems.

The mechanism is straightforward: configure an OTLP endpoint and push your telemetry data. You can choose to support one, two, or all three signals depending on what your product generates. Key configuration parameters include telemetry-endpoint, which defines where your telemetry data is sent, and telemetry-protocol, allowing you to select between gRPC or HTTP for data transport. For example, you might use a YAML configuration like this:

YAML

# MeshTrace policy
backends:
- type: OpenTelemetry
  openTelemetry:
      endpoint: otel-collector:4317

In production, remember that proper configuration is essential. You need to enable tracing for HTTP requests, databases, and other services to get a complete picture of your application's performance. The Profiles feature, currently in public alpha, will help you understand resource consumption during execution. Keep an eye on your logs' levels and ensure they are filtered appropriately to avoid noise in your observability data.

Key takeaways

→Configure an OTLP endpoint to export telemetry data.
→Use `telemetry-protocol` to choose between gRPC or HTTP for data transport.
→Enable tracing for HTTP requests, databases, and other services for comprehensive monitoring.
→Leverage the Profiles feature to analyze resource consumption during execution.

Why it matters

Implementing OTel-native design enhances your observability strategy, allowing for better performance monitoring and quicker issue resolution across diverse environments. This leads to improved application reliability and user satisfaction.

Code examples

YAML

# MeshTrace policy
backends:
- type: OpenTelemetry
  openTelemetry:
      endpoint: otel-collector:4317

YAML

1# MeshAccessLog policy
2backends:
3- type: OpenTelemetry
4  openTelemetry:
5      endpoint: otel-collector:4317
6  body:
7    kvlistValue:
8      values:
9      - key: mesh
10        value:
11          stringValue: '%KUMA_MESH%'
12      attributes:
13      - key: start_time
14        value:
15          stringValue: '%START_TIME%'

Bash

bin/kc.sh start --telemetry-endpoint=http://my-otel-endpoint:4317 --telemetry-protocol=grpc

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

DigitalOcean Serverless InferenceSponsor

OpenAI & Anthropic-compatible inference API — no GPU provisioning needed. 55+ models, pay-per-token with no minimums. VPC + zero data retention by default.

Try Serverless Inference →

OTel-Native by Design: Streamlining Observability Across Stacks

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Mastering Instrumentation Quality for Full-Stack Observability

Unlocking Performance: Pyroscope 2.0 for Continuous Profiling at Scale

Scaling Alloy: Mastering Your Central Telemetry Gateway