DX Operational Observability

In Part 1, we learned how to explore a transaction trace from entry point to attributes. Now, we’ll move from exploration to implementation. We’ll see how DX O2 maps OpenTelemetry span kinds to components, how correlation rules rebuild the full trace tree, what ingestion patterns keep your traces accurate, and finally, how DX O2 compares with Jaeger when visualizing the same data.

But knowing how to view traces is only half the story. The real challenge for DevOps and platform teams is making sure those traces are mapped correctly, correlated across services, and sampled in a way that preserves accuracy without overwhelming the system. This part solves that problem, showing you how DX O2 transforms raw OpenTelemetry spans into business-ready transaction views you can trust at scale.

Key Takeaways

• Map OpenTelemetry span kinds (client, server, producer, consumer) to DX O2 component types with clarity.

• Understand correlation rules and attribute mapping that rebuild the full transaction tree.

• Learn ingestion and sampling best practices, including a minimal OTel Collector config.

• See how the same trace looks in DX O2 Transaction Trace Viewer compared with Jaeger.

This guide is designed for DevOps engineers, SREs, platform teams, and developers implementing tracing in distributed architectures.

Mapping Span Kinds to DX O2 Component Types

Every span has a role. Client and server spans, producers and consumers, all of these map into recognizable DX O2 components. By mapping span kinds to internal and inbound, outbound services, DX O2 makes distributed flows instantly understandable. We’ll walk through an example: from raw span data to a visualized component in the DX O2 Transaction Trace Viewer.

This transformation generates clear and descriptive component names, directly conveying the business purpose of each operation.

Correlation and Attribute Mapping

Correlation is the magic that ties spans into a coherent trace. Using trace_id, span_id, and parent_span_id, DX O2 reconstructs the flow across services. Resource attributes like service.name set the stage, while span attributes like http.method or db.statement enrich the scene. Together, they form a trace tree you can navigate with clarity.

Here is the mapping:

Hierarchy is reconstructed using trace_id, parent-child IDs, and OTel resource/user attributes.

Resource vs. Span Attributes

Resource Attributes (service-level, shown on root components):

• service.name → Service identification

• service.version → Deployment version

• k8s.pod.name → Kubernetes pod information

• deployment.environment → Environment context

Span Attributes (operation-level, shown on individual components):

• http.request.method → HTTP operation type

• http.response.status_code → Response status

• db.statement → Database query details

• messaging.destination → Queue or topic names

• (and more based on trace opentelemetry semantic context std)

Example Transformation

Consider this OpenTelemetry HTTP client span (example below highlight important attributes, for actual span request, take a look at here: https://github.com/open-telemetry/opentelemetry-proto/blob/main/examples/trace.json) 

  "span_id": "abc123def456",
  "parent_span_id": "xyz789abc123", 
  "trace_id": "trace_001122334455",
  "span.kind": "CLIENT",
  "http.request.method": "POST",
  "http.url": "https://payment-api.internal/charge",
  "service.name": "checkout"

Becomes DX O2 component:

• Name: Backends | WebService at payment-api.internal

• Component ID: abc123def456

• Caller Component ID: xyz789abc123

• Attributes: http.request.method: POST, http.url: https://payment-api.internal/charge

• Resource Attributes: service.name: checkout

Ingestion & Sampling Best Practices

Accurate tracing starts with ingestion. A single Collector ensures trace completeness by preventing split pipelines. Tail-based sampling gives you accuracy where it matters, while head-based sampling can reduce noise in specific use cases.

Follow these best practices:

Use OpenTelemetry Collector

Multiple services send spans to a centralized collector before routing to DX O2.

Benefits:

• Ensures all correlated spans arrive together

• Simplifies configuration management

• Enables consistent processing policies

• Reduces network overhead

Enable Tail-Based Sampling

Captures complete correlated traces across services before exporting. According to the OpenTelemetry sampling documentation, tail sampling allows sophisticated decision-making based on the entire trace, enabling you to:

• Always sample traces containing errors

• Sample based on overall latency thresholds

• Apply different rates based on service characteristics

• Sample traces with specific attribute values

Pro Tip: For high-volume systems, you might combine both approaches - use head sampling to reduce initial volume, then tail sampling for sophisticated decisions.

DX O2 vs Jaeger: A Comparative View

The same trace can look very different depending on your viewer. In Jaeger, you see a raw timeline of spans. In DX O2, those spans are enriched and correlated into a connected transaction. Both reflect the same data, but the perspectives differ. Here’s a side-by-side view to illustrate the difference.

Let's examine the same e-commerce checkout flow in both UIs to understand their different approaches.

In Jaeger Trace View:

Jaeger is an open-source distributed tracing system that supports OpenTelemetry, providing  visualization and analysis of traces across microservices. For more details, refer to the OpenTelemetry documentation on exporting to Jaeger or the official Jaeger documentation.

• Hierarchical span tree shown in full

• Single root span for the distributed trace

• Requires expanding/collapsing to follow flow

Strengths: Complete view of all spans and timing relationships. Jaeger provides a detailed, comprehensive view of every span and their timing.

Weaknesses: Can become overwhelming with complex traces. With very complex microservice architectures and numerous spans, the full hierarchical view in Jaeger can indeed become overwhelming and difficult to navigate.

In DX O2 Transaction Viewer:

• Entry points (frontend spans) shown first in Trace List

• Component calls grouped separately for clarity

• Easier to identify which services participated

When you select a service from the Trace List, the Components view shows the operations within that service boundary. 

Look at arrows in the screenshot below:

Key Insight: Collapsing in Jaeger ≈ Components view in DX O2

This separation helps teams:

• Quickly find affected services

• Drill into per-service spans

• Navigate correlated traces using parent span links

Feature Comparison: DX O2 vs. Jaeger

Here are some services from the OpenTelemetry Community Demo. Let's take a look at the checkout service.

Within the checkout service, there are five major exit calls that occur during a single transaction:

1. Checkout Service

2. Payment Service

3. Shipping Service

4. Cart Service

5. Email Service

These exit calls are clearly visible in both:

• Jaeger UI Trace View: When you collapse the span tree, the child spans representing these services are displayed.

• DX O2 Transaction Trace Viewer: These exit calls appear in the Components Section, allowing you to drill down and view details of each service call.

Visual Reference:

• In Jaeger UI, you expand or collapse the tree to navigate between parent and child spans (as shown in image 1).

• In DX O2, the same exit calls can be viewed as separate components in the Components View (as shown in image 2).

Image 1: Jaeger UI showing collapsed tree of checkout service with its internal calls.

Observer numbers from 1 to 5 in both Image 1 and Image 2.

Image 2: DX O2 Transaction Trace Viewer showcasing checkout service with individual components (Checkout, Payment, Shipping, Cart, Email - internal calls) in Component View.

The same pattern is also visible for cart and email services as shown in the screenshots below.

Image 3: same reference for cart service, review both Jaeger UI and DX Transaction Trace Viewer UI.

(check 1, 2 numbers in Jaeger in first image and Component in second image)

Image 3: same reference for email service, review both Jaeger UI and DX Transaction Trace Viewer UI.

Note: You can observe the “sintra.render_template” entry shown once, observe count is 2 in Component View. 

DX O2 Transaction Trace Viewer:

• Analyzing business transaction flows

• Identifying performance bottlenecks at the service level

• Understanding cross-service dependencies

• Presenting trace data to non-technical stakeholders

• Managing complex microservices architectures

Conclusion

• DX O2 rebuilds transaction flows from raw spans into actionable insights.

• Mapping and correlation ensure every part of the transaction is connected.

• Collector design and sampling directly influence what you see.

• Compared to Jaeger, DX O2 emphasizes enriched, business-friendly transaction clarity.

Closing of Part 2

With mappings, correlation, and ingestion best practices in place, you’re ready to scale transaction tracing across complex systems. DX O2 Transaction Trace Viewer gives you more than just spans—it gives you the story behind them, making performance issues and bottlenecks easier to find and fix.

Your next step: deploy the sample OpenTelemetry Collector, run a demo application or real application workload, and ingest traces into DX O2. Then compare the same trace side-by-side in Jaeger and DX O2 Transaction Trace Viewer. Seeing the enriched, service-centric view in DX O2 will highlight how quickly you can move from raw spans to actionable insights.

If you miss Part 1, refer to this blog A Primer On Distributed Traces with DX Operational Observability: From Basics to Mastery Using Transaction Trace Viewer (Part 1)