Observability should let a DevOps team connect a user-visible symptom to the application version, dependency, infrastructure state, and deployment that caused it. In AZ-400, that means instrumentation is part of delivery architecture: teams need traces, metrics, logs, exceptions, and release context that remain useful across environments and changes.
Microsoft’s current guidance positions OpenTelemetry as the open-source instrumentation standard for Azure Monitor Application Insights. The Azure Monitor OpenTelemetry Distro provides Microsoft-supported instrumentation and Azure integrations for common languages, while direct OTLP ingestion supports teams that want a more vendor-neutral OpenTelemetry pipeline. The broader Azure platform still uses Application Insights experiences and Azure Monitor storage, querying, alerting, and visualization.
OpenTelemetry standardizes how applications emit telemetry
OpenTelemetry defines APIs, SDKs, semantic conventions, collectors, and protocols for traces, metrics, and logs. Instrumenting an application with OpenTelemetry reduces dependence on a proprietary in-process telemetry API and makes it easier to route data to more than one observability backend when architecture requires it.
Standardization does not remove implementation choices. Establish semantic conventions for internal attributes such as tenant, product, region, build version, and deployment environment. Inconsistent naming across teams makes cross-service queries brittle and can multiply metric series when the same concept appears under several slightly different labels. Teams still choose automatic versus manual instrumentation, which libraries to enable, which attributes to record, how much data to sample, and where collectors run. Instrument only information that supports operations; high-cardinality labels and sensitive data can create cost, privacy, and performance problems.
Application Insights provides application-focused analysis
Application Insights is the application performance management experience within Azure Monitor. It connects requests, dependencies, exceptions, traces, availability, and user or service behavior so teams can troubleshoot distributed applications. OpenTelemetry can feed these experiences without forcing developers to use older vendor-specific instrumentation patterns.
Define cloud role names and service attributes consistently so distributed components appear as separate, understandable services. Include ownership metadata outside the raw span where operational tooling can use it, such as service catalog entries or deployment tags. During an incident, engineers should be able to move from a failing dependency to the responsible team without manual archaeology. If every microservice reports the same service name, traces become difficult to interpret and ownership disappears. Service identity in telemetry should align with deployment and incident ownership.
The Azure Monitor OpenTelemetry Distro is the supported Azure path
Microsoft recommends the Azure Monitor OpenTelemetry Distro for teams that want OpenTelemetry instrumentation while retaining rich Azure Monitor experiences. The distro packages common instrumentation and Azure-specific support for .NET, Java, Node.js, and Python scenarios, including automatic telemetry and Live Metrics where supported.
Use the distro when operational consistency and Microsoft support matter more than maintaining a fully vendor-neutral collector stack. Decide whether instrumentation is code-based, automatic, agent-based, or collector-based and document the tradeoff. Automatic instrumentation accelerates adoption, but manual spans may still be necessary for domain transactions that framework instrumentation cannot infer. Keep package versions controlled and review release notes because instrumentation changes can affect attribute names, sampling, or telemetry volume even when application code remains unchanged.
Direct OTLP ingestion supports vendor-neutral pipelines
Some organizations standardize on community OpenTelemetry SDKs and collectors across multiple clouds. Azure Monitor now supports OTLP ingestion paths that can preserve that architecture while sending telemetry to Azure Monitor. This can reduce duplicate instrumentation when the same service must report to several backends.
A collector becomes part of the reliability path. Size collectors for burst traffic, define buffering behavior, and isolate failure domains so one overloaded collector does not make an entire region invisible. If the architecture fans telemetry to several destinations, monitor each exporter independently because one blocked backend can affect the pipeline differently from another. Monitor collector queues, export failures, memory, dropped telemetry, and retry behavior. A healthy application can look invisible if the collector is failing, so observability infrastructure needs its own observability and alerting.
Distributed tracing depends on context propagation
A trace becomes useful when request context flows across HTTP calls, queues, background jobs, and service boundaries. Asynchronous systems need special care because a producer and consumer may be separated by seconds or hours. Preserve correlation identifiers across message headers or supported propagation mechanisms so delayed work can still be connected to the originating operation. Missing or rewritten trace context breaks one transaction into unrelated fragments. Validate propagation through frameworks, API gateways, messaging middleware, serverless functions, and third-party components that participate in the request path.
Add spans around business-relevant operations that automatic instrumentation cannot understand, but avoid creating a span for every trivial function. Add useful attributes such as operation type or dependency class while avoiding unbounded values such as raw user input, full URLs with IDs, or generated SQL text that can create excessive cardinality and privacy exposure. The trace should explain latency and dependency structure without generating so much data that engineers cannot identify the critical path.
Metrics and logs answer different operational questions
Metrics are efficient for trends, rates, latency distributions, saturation, and alert thresholds. Logs provide event-level detail and flexible context. Traces reconstruct distributed transactions. A mature observability design uses all three rather than trying to force one signal to answer every question. Use logs for detailed event context, metrics for efficient aggregation and alerting, and traces for causal path reconstruction. When teams understand these strengths, they collect less redundant data and can choose the cheapest signal that still answers the operational question.
Align telemetry with service objectives. Separate symptom alerts from diagnostic signals: an error-rate or latency SLO breach should wake an operator, while a noisy low-level log may be retained for investigation without paging anyone. Observability becomes actionable when each alert has an owner, severity, runbook, and clear reason to exist. Track request success, latency, queue depth, dependency errors, resource pressure, and business outcomes that indicate service health. Low-level platform metrics are useful, but users care about completed transactions, not whether CPU averaged forty percent.
Sampling controls cost and diagnostic fidelity
High-volume services can generate more trace data than is economical to retain. Sample normal successful traffic more aggressively than failures if the tooling and architecture allow it, and preserve representative traces for performance analysis. Review whether sampling decisions are made before or after error information becomes visible, because early decisions can accidentally discard the most interesting requests. Sampling reduces volume, but the strategy should preserve enough rare failures and slow transactions for diagnosis. Head-based sampling makes decisions early, while collector or backend approaches may use more context depending on the architecture.
Do not sample critical audit or security events merely because trace volume is high. Separate telemetry classes when their retention and completeness requirements differ. Review sampling after traffic growth because a percentage that worked at low volume can produce an unexpectedly large bill later.
Connect telemetry to deployments and release health
Observability is most useful when a team can see which version or deployment introduced a regression. Deployment annotations should be automated by the release pipeline rather than entered manually, and rollback or feature-flag events should be recorded with the same discipline. This creates a common timeline for application behavior and delivery changes. Add build version, environment, region, feature flag, and deployment annotations where appropriate. Compare new and previous versions during canary or ring releases so promotion decisions use evidence from the actual changed population.
Azure monitoring tools connect platform metrics, logs, alerts, and resource health with the application telemetry described here. DevOps operations should also correlate deployment events, incident records, and service ownership so an engineer can move from user symptom to the responsible component quickly.
Design telemetry governance before volume grows
Define retention, access, data classification, query cost, naming conventions, and redaction standards before every team invents its own telemetry. Apply least privilege to observability stores because traces and logs can reveal internal architecture, customer identifiers, secrets, and security events. Production telemetry is operational data with security value, not merely a debugging convenience. Define separate access for engineers, support staff, and security analysts when their data needs differ, and audit high-volume exports or broad queries against sensitive telemetry stores. Observability should increase visibility without creating a new unrestricted copy of production data. Periodically test telemetry access controls and retention jobs so governance remains effective as new services, regions, data sources, and teams are added over time. Query strings, headers, user IDs, exception messages, and custom attributes can contain secrets or personal data. Redact at collection when possible rather than depending on analysts to avoid sensitive fields later.
Review observability quality as part of service ownership. A production service should have useful traces, metrics, logs, alerts, and dashboards before it becomes critical. OpenTelemetry, Application Insights, and Azure Monitor form complementary layers: instrumentation standard, application analysis, and broader monitoring platform. Document which layer owns collection, transport, storage, alerting, and visualization so teams do not duplicate exporters or assume another platform is retaining a signal that was never routed there. Clear responsibility prevents observability gaps during migrations. The architecture should remain testable: intentionally generate known requests and failures after major instrumentation changes, then verify that traces, metrics, logs, correlations, and alerts still arrive with the expected service identity and deployment metadata.
Instrumentation should carry stable resource identity so traces, metrics, and logs can be joined across deployments and environments. Service name, version, environment, region, and correlation identifiers are more useful when standardized before every team invents its own labels. Combine that with deliberate sampling rules: preserve high-value errors and representative traces while controlling routine volume so cost reduction does not remove the evidence needed for incident diagnosis.