OpenTelemetry for Technology & SaaS

A SaaS platform team adopts OpenTelemetry across thirty product teams and instrumentation coverage climbs quickly. Then a cross-service investigation reveals the problem: one team names the customer identifier attribute one way, another another, a third puts it in a span event rather than an attribute, and two teams have included a high-cardinality field that is quietly costing more than the rest of the telemetry combined. Every team instrumented correctly according to the guidance they read. There was no enforced convention, so the traces exist and cannot be joined.

Instrumentation without enforced semantic conventions produces telemetry that is present and unjoinable.

OpenTelemetry for SaaS means adopting a vendor-neutral instrumentation standard with semantic conventions enforced at collection, sampling strategy set centrally, and cardinality controlled, so telemetry from thirty teams composes into something answerable.

Why “Context” Is Becoming the New Cloud Infrastructure Layer

Understand how context infrastructure is reshaping retrieval and intelligent systems.

Download Whitepaper

However, most adoptions measure instrumentation coverage, which rises quickly while the attribute naming drift that makes cross-service investigation possible goes unmanaged.

If you are a VP of Engineering or Head of Infrastructure at a SaaS company, the intent of this article is:

Define why semantic conventions must be enforced not documented
Show how cardinality quietly dominates telemetry cost
Lay out how sampling strategy belongs centrally

To do that, let's start with the basics.

What Is OpenTelemetry for SaaS? The Basic Definition

At a high level, OpenTelemetry is a vendor-neutral standard for generating and collecting traces, metrics, and logs, with a collector layer that processes and exports to backends. The portability is genuine and it is not the main benefit in a multi-team estate. The main benefit is that thirty teams can produce telemetry that composes, provided semantic conventions are enforced so the same concept carries the same attribute name everywhere. Without that, you have adopted a standard for the wire format and not for the meaning, which is the half that determines whether a cross-service investigation is possible.

To compare:

OpenTelemetry without enforced conventions is thirty teams writing in the same alphabet and different languages. The transport works, the storage works, and joining a request path across four services requires someone to translate each hop. The standard solved the encoding problem, which was never the one blocking the investigation.

Why Does OpenTelemetry Matter for SaaS?

Issues that it addresses or resolves:

Telemetry from many teams that cannot be joined
Attribute naming drifting per team
Cardinality quietly dominating telemetry cost

Resolved Issues by OpenTelemetry Done Well

Conventions enforced so traces compose across services
Sampling strategy set centrally rather than per team
Cardinality controlled before it dominates the bill

Core Components of OpenTelemetry Adoption in SaaS

Semantic conventions defined and enforced at collection
Sampling strategy set centrally with tail-based options
Cardinality limits applied in the collector
Collector configuration owned centrally
Vendor portability preserved deliberately

Modern OpenTelemetry Tooling for SaaS

Collector deployments with processing pipelines
Attribute normalisation and validation at collection
Tail-based sampling for trace completeness
Cardinality limiting and attribute dropping
Per-team telemetry volume and cost attribution

These tools make thirty teams' telemetry composable. Attribute normalisation at collection is what corrects drift without requiring thirty teams to change code simultaneously.

Other Core Issues They Will Solve

Cross-service investigation possible without translation
Telemetry cost attributable per team
Backend changes without re-instrumenting

In Summary: OpenTelemetry for SaaS delivers composable telemetry across many teams when semantic conventions are enforced at collection and cardinality is controlled centrally.

Importance of OpenTelemetry for SaaS in 2026

Multi-team estates generate telemetry faster than they standardise it. Four reasons explain why this matters now.

1. Cross-service investigation is the point.

A trace that stops at a service boundary because the next hop named things differently does not help.

2. Convention drift is invisible until needed.

Every team's instrumentation looks correct in isolation, and the incompatibility appears during an incident.

3. Cardinality dominates cost quietly.

One high-cardinality attribute in one service can exceed the cost of everything else.

4. The collector is the enforcement point.

Correcting drift in thirty codebases is slow; correcting it at collection is a configuration change.

Traditional vs. Modern SaaS Telemetry

Per-team instrumentation choices vs. enforced semantic conventions
Sampling per service vs. strategy set centrally
Cardinality unmanaged vs. limited at collection
Vendor-specific agents vs. portable instrumentation

In summary: A modern SaaS approach enforces conventions and cardinality limits at the collector, which is the only point that can correct thirty teams at once.

Details About the Core Components of OpenTelemetry Adoption in SaaS: What Are You Designing?

Let's go through each component.

1. Convention Layer

The same name everywhere.

Convention decisions:

Semantic conventions defined for shared concepts
Enforcement at collection rather than in documentation
Drift detected and normalised

2. Sampling Layer

Centrally decided.

Sampling decisions:

Strategy set centrally, not per service
Tail-based sampling where trace completeness matters
Rates reviewed against investigation needs

3. Cardinality Layer

Controlling the cost driver.

Cardinality decisions:

Limits applied in the collector
High-cardinality attributes identified and dropped
Cost attributed per team

4. Collector Layer

The enforcement point.

Collector decisions:

Configuration owned centrally
Processing pipelines normalising attributes
Changes deployable without team involvement

5. Portability Layer

Keeping the option.

Portability decisions:

Vendor-specific features used deliberately
Export configuration separable from instrumentation
Backend change cost understood

Benefits Gained from OpenTelemetry in SaaS

Traces that join across service boundaries
Telemetry cost attributable and controllable
Backend changes without re-instrumenting thirty services

How It All Works Together

The SaaS platform team defines semantic conventions for the concepts that appear across services, customer identifier, tenant, request identifier, operation name, and enforces them at collection rather than publishing guidance and hoping. That enforcement point matters enormously: correcting attribute naming drift across thirty codebases requires thirty teams to prioritise a change, while normalising at the collector is a configuration deployment. Sampling strategy is set centrally with tail-based sampling where trace completeness matters, because per-service sampling produces traces with gaps that make cross-service investigation unreliable. Cardinality limits are applied in the collector with high-cardinality attributes identified and dropped, since a single such attribute in one service can exceed the telemetry cost of everything else and nobody notices until the bill. Cost is attributed per team so the conversation is specific. And export configuration is kept separable from instrumentation so vendor portability remains real rather than theoretical.

Common Misconception

We adopted OpenTelemetry, so our telemetry is standardised.

You standardised the wire format and the SDK, which is the easy and less consequential half. What determines whether a trace can be followed across four services is whether all four named the same concept identically, and nothing in the standard enforces that by itself. Semantic conventions exist and are frequently treated as guidance, so thirty teams each make locally reasonable choices and the incompatibility surfaces during an incident when someone tries to join a request path. The adoption was real. The standardisation that mattered was never enforced, and enforcing it at the collector is considerably faster than asking thirty teams to change code.

Key Takeaway: The standard covers the wire format. Whether traces join depends on conventions, which need enforcing at collection.

Real-World OpenTelemetry for SaaS in Action

Let's take a look at how it operates with a real-world example.

We worked with a SaaS platform team whose traces existed and could not be joined across services, with these constraints:

Enforce semantic conventions at collection
Set sampling strategy centrally
Control cardinality before it dominates cost

Step 1: Define the Conventions

For shared concepts.

Conventions defined for cross-service concepts
Documented and published
Drift identified in current telemetry

Step 2: Enforce at Collection

Not in documentation.

Attribute normalisation in the collector
Validation rejecting or correcting drift
Changes deployable centrally

Step 3: Set Sampling Centrally

With tail-based where needed.

Strategy owned centrally
Tail-based sampling for completeness
Rates reviewed against needs

Step 4: Control Cardinality

Before the bill.

Limits applied in the collector
High-cardinality attributes dropped
Cost attributed per team

Step 5: Preserve Portability

Deliberately.

Export configuration separable
Vendor features used knowingly
Backend change cost understood

Where It Works Well

Multi-team estates needing cross-service investigation
Collector deployments able to normalise attributes
Programmes controlling cardinality centrally

Where It Does Not Work Well

Conventions published as guidance without enforcement
Sampling decided per service
Cardinality unmanaged until it appears on the bill

Key Takeaway: Enforce conventions at the collector, set sampling centrally, and limit cardinality before it dominates cost.

Common Pitfalls

i) Conventions as guidance

Thirty teams each make locally reasonable naming choices and traces stop joining at boundaries. Enforce and normalise at collection instead.

Cross-service investigation requires translation per hop
The incompatibility surfaces during an incident
Every team instrumented correctly

ii) Cardinality unmanaged

One high-cardinality attribute in one service can exceed everything else in cost. Limit at the collector and attribute cost per team.

iii) Sampling per service

Independent sampling decisions produce traces with gaps, which makes cross-service paths unreliable. Set strategy centrally with tail-based sampling where completeness matters.

iv) Vendor coupling through instrumentation

Using vendor-specific features in instrumentation rather than in export configuration removes the portability you adopted the standard for.

Takeaway from these lessons: The collector is the only place you can correct thirty teams at once, which makes it the enforcement point.

OpenTelemetry Best Practices for SaaS: What High-Performing Teams Do Differently

1. Enforce conventions at the collector

Normalise attribute naming centrally rather than asking thirty teams to change code, because one is a deployment and the other is a quarter.

2. Set sampling strategy centrally

Use tail-based sampling where trace completeness matters, since per-service decisions produce gaps that break cross-service investigation.

3. Limit cardinality and attribute cost

Control it in the collector and report cost per team, because a single attribute can dominate the bill invisibly.

4. Keep export configuration separable

Preserve real portability by keeping vendor-specific choices out of instrumentation.

5. Detect drift continuously

Monitor for attributes that do not match conventions, since new services introduce drift constantly.

Logiciel's value add is helping SaaS platform teams enforce semantic conventions and cardinality control at the collector, so telemetry from thirty teams composes into something answerable.

Takeaway for High-Performing Teams: Enforce at the collector, sample centrally, limit cardinality, keep export separable, detect drift.

Signals You Are Doing OpenTelemetry Well in SaaS

How do you know it is working? Not by instrumentation coverage, but by whether a trace crosses four services. These are the signals that separate composable telemetry from present telemetry.

Traces join. A request path can be followed across service boundaries.

Conventions are enforced. Attribute naming is normalised at collection.

Cardinality is controlled. No single attribute dominates cost.

Sampling is central. Trace completeness is a deliberate decision.

Cost is attributed. Telemetry spend is visible per team.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. OpenTelemetry adoption depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake.

AIOps consumes the telemetry for correlation and depends on its consistency. AI-assisted SRE assembles context from it. The service catalog supplies ownership for attribution. FinOps guardrails supply the cost discipline. Naming these adjacencies upfront keeps the work scoped and helps leadership see the collector as the enforcement point.

The common mistake is treating each adjacency as someone else's problem. The convention enforcement is your problem. The cardinality control is your problem. The sampling strategy is your problem. Pretend otherwise and you will have complete instrumentation and unjoinable traces. Own the adjacencies you depend on, partner with the teams that hold them, and share the conventions.

Conclusion

Adopting OpenTelemetry standardises the wire format and the SDK, which is the straightforward half. Whether a trace can be followed across four services depends on all four naming the same concept identically, and semantic conventions treated as published guidance produce thirty locally reasonable choices that do not compose. Enforce conventions at the collector, because that is the only point where thirty teams can be corrected with a configuration deployment rather than a quarter of coordinated code changes. Set sampling strategy centrally with tail-based sampling where completeness matters, limit cardinality before it dominates the bill invisibly, attribute cost per team, and keep export configuration separable so portability stays real.

Key Takeaways:

The standard covers wire format; conventions determine whether traces join
The collector is the only point that can correct thirty teams at once
A single high-cardinality attribute can exceed all other telemetry cost

Adopting OpenTelemetry well requires central enforcement. When done correctly, it produces:

Traces that join across service boundaries
Telemetry cost attributable and controllable per team

The AI Product Playbook: Launch Faster, Scale Smarter, Fund with Confidence

Launch faster, scale smarter, and approach funding with greater confidence.