OpenTelemetry with Dynamics 365 integrations

Observability for Dynamics 365 integrations spans many systems — plug-ins, Azure Functions, Service Bus, external APIs. Each has its own logging story; collecting consistent telemetry across all is hard. OpenTelemetry is the open-standard answer: vendor-neutral instrumentation that exports to many backends. For multi-system Dynamics architectures, OpenTelemetry simplifies observability.

What OpenTelemetry is.

• Open standard for instrumentation.
• CNCF project.
• Supports logs, metrics, traces.
• Vendor-neutral instrumentation.
• Many language libraries.
• Export to many backends (App Insights, Datadog, Jaeger, etc.).

The headline value: instrument once, export anywhere.

Why it matters.

• No vendor lock-in. Change observability backend without rewriting instrumentation.
• Consistency. Same patterns across languages and services.
• Distributed tracing standard. W3C Trace Context for cross-service correlation.
• Modern. Active development; growing adoption.

For new instrumentation, OpenTelemetry is the recommended choice.

Three signal types.

• Traces — request flow across services.
• Metrics — quantitative aggregated data.
• Logs — discrete events.

OpenTelemetry covers all three; many older tools focus on one.

Instrumentation libraries.

• .NET — OpenTelemetry SDK for C#.
• Java — well-supported.
• Python, Node.js, Go, Ruby — all supported.
• Auto-instrumentation — many libraries instrumented automatically.

For .NET (typical Dynamics environment), OpenTelemetry SDK provides comprehensive support.

Distributed tracing.

• Trace — full end-to-end request.
• Span — single operation within trace.
• Trace ID — links all spans in a trace.
• Parent-child relationships between spans.

A trace visualises as a Gantt-like chart: which service did what when.

W3C Trace Context. Standard format:

• HTTP header traceparent carries context.
• All services that understand it propagate.
• Cross-service correlation just works.

Without standard format, each service uses its own; correlation hard.

Span attributes. Per span:

• Service name.
• Operation name.
• Duration.
• Status (OK / Error).
• Attributes (key-value, e.g., HTTP status, customer ID).

Attributes enable filtering and analysis.

OpenTelemetry Collector.

• Receives data from instrumented apps.
• Processes (filtering, sampling, transformation).
• Exports to backends.

Decouples app from backend; switch backends without app change.

Exporters.

• Azure Monitor / Application Insights — most common for Microsoft stack.
• Jaeger — open-source tracing.
• Zipkin — older open-source.
• Datadog, New Relic, Splunk — commercial.

Same instrumentation; export to one or many.

Instrumentation in Dynamics plug-ins.

• Plug-in code emits spans for major operations.
• Spans correlated to incoming context.
• Exported to App Insights or other.

Plug-in tracing becomes part of broader distributed trace.

Instrumentation in Azure Functions.

• Built-in OpenTelemetry support increasing.
• Auto-instrumentation for HTTP, Service Bus, etc.
• Custom spans for business operations.

Function-level traces tied to broader trace context.

Sampling.

• Always sample — full visibility; expensive.
• Probabilistic — sample N% of traces.
• Tail sampling — sample based on outcome (sample all errors).

Sampling balances visibility and cost.

Custom metrics.

var meter = new Meter("MyService");
var counter = meter.CreateCounter<long>("orders_processed");
counter.Add(1, new KeyValuePair<string, object?>("status", "success"));

Counters, gauges, histograms; emitted to backend.

Semantic conventions. OpenTelemetry defines standards:

• HTTP attributes — method, URL, status.
• Database attributes — system, statement.
• Messaging attributes — destination, operation.

Consistent attribute names enable cross-service analysis.

Migration from existing observability.

• Application Insights SDK — Microsoft-specific; replace with OpenTelemetry + AppInsights exporter.
• Custom logging — gradually replace.

Coexistence possible; full migration over time.

Performance overhead.

• Modest; well-designed for production.
• Sampling reduces cost.
• Don't instrument hot loops.

Production-ready performance.

Trace context in messaging.

• Service Bus messages carry trace context in properties.
• Event Grid similarly.
• Consumers continue the trace.

Async patterns preserve correlation.

Trace context in Dataverse.

• Plug-in receives operation; what's the trace context?
• Custom header passed via HTTP integrations.
• For Dynamics-internal events, requires plug-in pattern.

Capturing context across Dataverse plug-in boundary is the integration point.

Visualisation.

• App Insights end-to-end transaction details — trace flame graph.
• Jaeger UI — open-source.
• Custom dashboards — tailored.

Visualisation reveals system behaviour patterns.

Use cases.

• Performance investigation — where did time go in a slow request?
• Error correlation — find related errors across services.
• Dependency mapping — what calls what.
• Capacity planning — bottleneck identification.

Common pitfalls.

• Over-instrumentation. Performance degraded; cost explodes.
• Under-instrumentation. Gaps in visibility.
• No context propagation. Traces broken; can't follow request.
• Sensitive data in attributes. Compliance issue.
• Sampling too aggressive. Important traces missed.
• Single backend lock-in. Defeats OpenTelemetry's purpose.

Best practices.

• Start with auto-instrumentation for common libraries.
• Add custom spans for business operations.
• Use semantic conventions.
• Configure sampling for cost / visibility balance.
• Propagate context through messaging.
• Document trace topology.

Strategic positioning. OpenTelemetry is the modern observability standard. Dynamics 365 integrations using OpenTelemetry get vendor-neutral instrumentation that exports to current and future backends. The investment is modest — replace existing libraries with OpenTelemetry, configure exporters — and pays back in flexibility and depth of visibility.

For architects:

• Default to OpenTelemetry for new code.
• Migrate existing instrumentation gradually.
• Standardise span / metric naming.
• Build dashboards on the foundation.

For organisations on App Insights, OpenTelemetry coexists seamlessly. For others or those wanting vendor flexibility, OpenTelemetry is the path. Either way, it's the direction the observability industry is moving; aligning early reduces future migration burden.