OpenTelemetry gives enterprises a vendor-neutral way to instrument, generate, collect and export telemetry. It does not automatically create observability. Teams still need service objectives, semantic conventions, correlation, collection architecture, data governance, cost controls and operating ownership. The design should help engineers answer why a user journey failed—not merely move more data into another backend.

Executive perspective

The decision behind OpenTelemetry observability architecture is not a narrow technology purchase. Leaders must connect customer or clinical outcome, architecture, security, operations, people and economics. A useful plan states what success means, which evidence is required, who accepts residual risk and when the chosen approach must be reconsidered.

Separate facts, assumptions and recommendations. Establish a baseline before delivery, attach measurable acceptance criteria to every stage and make benefits ownership explicit. This prevents a technically successful programme from failing because adoption, contracts, operating roles or data responsibilities were left unresolved.

Begin with user journeys and reliability questions

Identify the transactions whose failure matters: login, checkout, payment, data import or clinical workflow. Define service-level indicators and objectives from the user perspective. Instrumentation should answer known operational questions and support unknown-unknown investigation. Starting with every available signal creates cost before value.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Understand the signal model

Metrics summarise behaviour over time, traces follow requests across components, and logs record events. Profiles and events extend the picture. Use consistent resource and service attributes so signals can be correlated. No signal replaces the others: aggregate health, causal path and detailed event context serve different purposes.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Choose instrumentation approaches by workload

Use language SDKs for application control, automatic instrumentation for coverage and infrastructure receivers for platforms. Maintain manual spans around business operations that frameworks cannot infer. Avoid double instrumentation and unstable attributes. Treat instrumentation libraries as production dependencies with version and performance tests.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Design the Collector topology

Collectors can run as agents, gateways or layered pipelines. Agents capture local context and reduce application coupling; gateways centralise processing, policy and export. Size for peak volume and backpressure. Define behaviour when collectors or backends fail so telemetry problems do not take down customer workloads.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Standardise resource identity and semantic conventions

Set rules for service name, environment, version, region, tenant-safe identifiers and deployment metadata. Adopt stable semantic conventions and govern custom attributes. Inconsistent naming makes cross-signal queries unreliable. Version taxonomy changes and test dashboards and alerts before rollout.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Propagate context across boundaries

Carry trace context through HTTP, messaging, jobs and asynchronous workflows. Add trace and span identifiers to logs where appropriate. Be careful with baggage because it propagates and can create privacy or performance exposure. Verify context through gateways, queues and third-party integrations.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Apply sampling without losing critical evidence

Head sampling decides early and is predictable; tail sampling can retain errors or slow traces after observing outcomes but needs more infrastructure. Define policies by service, error, latency, customer tier and risk. Preserve high-impact transactions while controlling routine volume. Measure sampling bias.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Control cardinality, volume and cost

Unbounded user IDs, URLs, query text and random values can explode metric or trace dimensions. Establish attribute allowlists, limits, redaction and drop rules. Allocate telemetry cost by service and signal. Cost optimisation should preserve incident and compliance evidence, not simply discard expensive data.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Secure the telemetry pipeline

Telemetry can contain personal data, credentials, queries and internal topology. Encrypt transport, authenticate exporters, isolate collectors, rotate secrets and restrict backend access. Redact near the source where possible. Define retention, residency and deletion rules and threat-model telemetry as sensitive production data.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Build dashboards and alerts from service objectives

Use symptom-based alerts tied to user impact, supported by diagnostic views for saturation, dependency and release changes. Avoid alerting on every infrastructure fluctuation. Connect traces and logs from the alert context. Review false positives and missed incidents as product quality problems.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Migrate incrementally from legacy agents

Inventory current agents, fields, dashboards and compliance uses. Introduce OpenTelemetry for a representative journey, compare signal fidelity and cost, then expand by service group. Dual-run only as long as necessary. Preserve business-critical queries and remove obsolete collectors deliberately.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Create an observability operating model

Platform teams own standards, collector services and paved paths; product teams own useful instrumentation and service objectives; security and privacy own policy; FinOps tracks cost. Establish instrumentation reviews, schema change control and support. Observability is a shared product, not a central dumping ground.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Select an observability engineering partner

Look for SRE, platform, application instrumentation, security and cost skills. Ask candidates to trace one business journey across mixed technology, propose a collector topology and quantify volume. A strong partner will reduce noise and improve decisions rather than sell maximal ingestion.

Turn this principle into a named artefact: an architecture decision, evidence request, control, test, runbook, contract requirement or benefits measure. Assign one accountable owner and reviewers from the functions exposed to the result. Document normal operation, exceptions and escalation so the design can be operated rather than admired.

Evaluate alternatives across business value, implementation effort, recurring cost, security, reliability, reversibility and time-to-value. Where uncertainty is material, run a bounded exercise using representative data and failure conditions. Define the decision the exercise must unlock and the threshold for proceeding, changing approach or stopping.

Implementation scorecard

Track outcome, adoption, quality, reliability, security exceptions, change lead time, unit economics and realised benefit. Each measure needs a baseline, target, data source, cadence and accountable owner. Segment results by customer, workflow, market or risk tier so averages do not conceal concentrated failure.

Recommended engagement approach

Begin with a focused assessment of one representative domain. Project Supply can connect digital engineering, AI/data, ecommerce and cybersecurity work to create the fact base, target architecture, controls and executable roadmap required for OpenTelemetry observability architecture.