Reading mapFrom the signal to an operational decision
  1. 01Understand
  2. 02Prioritize
  3. 03Acting

OpenTelemetry became the open standard for generating and moving telemetry, but installing an agent does not create observability on its own. An implementation without conventions, filters or budget can produce unsearchable spans and an invoice that grows with each request.

This guide summarizes how to carry OpenTelemetry for production with a controllable architecture.

What OpenTelemetry Solves

OpenTelemetry —OTel — offers APIs, SDKs, instrumentation, protocol and Collector to work with traces, metrics and logs. It is neutral to the backend: it can export to Grafana, Datadog, Dynatrace, New Relic, Jaeger, Prometheus or other destinations.

It does not store telemetry or replace the analysis experience. Its function is to decouple the way applications produce data from where they are consulted.

In May 2026 OpenTelemetry reached the level Graduated CNCF. CNCF’s annual 2025 survey reported 49% use in production and 26% of organizations evaluating it, a sign of standardization relevant to architectural decisions.

Recommended architecture

Aplicaciones → OTLP → Collector gateway → backend(s)
                    ↳ filtros
                    ↳ redacción
                    ↳ muestreo
                    ↳ enriquecimiento

SDKs generate telemetry and send it via OTLP. The Collector receives, processes and exports. In large environments, an agent collector can be combined near the workload with centralized gateways.

Step 1: define the use case

Before I was instrumental, I chose a specific question:

  • Why does the checkout exceed your SLO?
  • What dependency generates intermittent errors?
  • What version introduced a regression?
  • What transactions fail only in one region?

The use case determines the services, attributes and sampling level. “Capturing everything to see it later” is not a strategy.

Step 2: normalize resources

Each signal must consistently identify:

  • service.name
  • service.namespace
  • service.version
  • deployment.environment.name
  • region, cluster or tenant where applicable
  • owner of the service by means of an attribute or associated catalogue

If production appears as prod, production y prdconsultations, costs and alerts are fragmented.

Step 3: combine auto and manual instrumentation

Self-instrumentation covers frameworks, HTTP, databases and known libraries with little code change. It is ideal for discovering the initial topology.

Manual instrumentation adds business meaning: type of operation, result of an order or stage of a process. You must avoid personal data, secrets and identifiers with unlimited cardinality.

Step 4: Propagating context

Propagation transports trace_id y span_id Without it, each service creates an isolated trace and misses the route.

It also allows you to correlate logs with the active trace. Validation must include HTTP, messaging, asynchronous jobs and internal protocols; cuts usually appear in uninstrued libraries or gateways.

Step 5: Design the Collector

The Collector can:

  • Receive OTLP and existing formats.
  • Add infrastructure attributes.
  • Remove sensitive fields.
  • Limit memory and process batches.
  • Filter valueless telemetry.
  • Apply sampling.
  • Send to one or more backends.

It should be monitored as a critical component. Full tails, rejections, restarts or export errors can create blind spots even if the application works.

Collector's Deployment Patterns

The pattern agent runs a Collector near each host or workload. It makes it easy to collect local logs and metadata, and distributes load. gateway Centralize credentials, processing and export. Many companies combine both.

To choose, evaluate network limits, isolation, volume, and fault domain. A single gateway simplifies governance, but can concentrate capacity and risk. Multiple gateways need balancing, consistent configuration, and a queue strategy.

The configuration should be modified, tested with synthetic telemetry and progressively deployed. I measured reception, export, rejected data, memory usage and tail length. If the Collector changes attributes or removes signals, that behavior must have tests like an API.

Step 6: Control Cardinality

An attribute with almost unique values — request ID, unparametrized URL, timestamp or mail — multiplies series and queries. Routes must be normalized: /clientes/{id} in place of /clientes/728491.

It will separate useful attributes to search for fields that only generate volume. Cardinality should be reviewed before and after each new instrumentation.

Step 7: define sampling

Saving all traces can be valid in low volume, but rarely scale. There are two approaches:

  • Head sampling: decides at the beginning; it is simple and cheap, but still does not know the result.
  • Tail sampling: decides at the end; may retain errors, high latency or critical services, but requires more memory and operation.

A combined policy can retain 100% of errors and critical transactions while taking a representative sample of healthy traffic.

Step 8: validate quality, not just arrival

The test must check:

  • Continuity of traces between services.
  • Stable and understandable names.
  • Correct versions and environments.
  • Correlating logs.
  • Absence of secrets and personal data.
  • Loss, latency and retrying of the pipeline.
  • Daily volume and cost projection.

Seeing spans on a dashboard does not confirm that they are useful during an incident.

Adoption strategy

  1. A critical flow and three to five services.
  2. Conventions and Collector as code.
  3. Failure and load tests.
  4. Telemetry budget by equipment.
  5. Reusable templates for new services.
  6. Monthly review of quality and cost.

The target is an internal platform that makes it easy to do the right thing, not a collection of different configurations.

I also defined an exception process. A service may need special attributes or retention, but it must justify it, estimate volume and set revision date. Without that mechanism, conventions are quietly broken and the common pipeline is no longer reliable.

Next step

CTL implements OpenTelemetry in Argentina and Latin America, from concept testing to multi-backend business pipelines. Set up a technical meeting.

Frequently Asked Questions

OTLP encrypts the data?

OTLP can be transported via gRPC or HTTP with TLS. Authentication, rotation of credentials, segmentation and network policies must also be defined.

Does OpenTelemetry reduce the lock-in seller?

It reduces instrumentation and transport coupling, but does not eliminate dependency on queries, dashboards, retention and backend proprietary functions.

Is it appropriate to migrate all telemetry at the same time?

No. It is important to start with a measurable flow, compare data and cost, document conventions and progressively expand.

Verifiable sources