An e-commerce checkout flow spans three microservices instrumented with OpenTelemetry: frontend-service, payment-service, and inventory-service. Users intermittently experience 504 Gateway Timeout errors during high-traffic flash sales. You examine Cloud Trace in the Google Cloud console and observe the following pattern on failing requests: The root span (frontend-service: /checkout) has a duration of 30,000 ms. Child span 1 (payment-service: /charge) executes concurrently and completes successfully in 250 ms. Child span 2 (inventory-service: /reserve) remains active for 29,750 ms before returning an HTTP 500 error status. You need to isolate the critical path bottleneck and determine the root cause of the failure using integrated Google Cloud Observability tooling. What should you do?

Identify child span 2 (`inventory-service: /reserve`) as the critical path bottleneck, and navigate to the Logs & Events tab within the Trace details panel to inspect correlated log entries for the failing span.: ### What this approach is In distributed tracing, the **critical path** represents the sequence of dependent operations that determines the minimum total duration of the end-to-end transaction. When parent spans wait on child operations, the slowest sequential child span directly dictates the total latency. Using Google Cloud Trace, developers can drill down directly from a specific span in the **Trace details** panel to correlated application logs via the **Logs & Events** tab. ### How it meets the requirements - **Identifies the critical path and latency outlier**: The trace timeline clearly illustrates that while `/charge` finishes in 250 ms, `/reserve` consumes 29,750 ms of the 30,000 ms root span before timing out and failing, pinpointing `inventory-service` as the blocking bottleneck. - **Correlates traces with logs**: By selecting the failing span in Cloud Trace and switching to the **Logs & Events** tab (or clicking **View Logs** to jump to Logs Explorer), the engineer immediately views structured application and proxy logs injected with matching `trace_id` and `span_id` contexts without manual querying. - **Diagnoses root-cause failure**: The correlated logs expose backend-specific exceptions, database lock timeouts, or internal errors within `inventory-service` that triggered the HTTP 500. ### Key advantages - **Direct contextual linkage**: Avoids searching through millions of log lines across services during peak traffic. - **Pinpoints latency contributors**: The Gantt chart visualizes concurrent vs. blocking operations. - **Rapid root-cause analysis**: Seamlessly bridges trace performance data with detailed error stack traces in Cloud Logging.

Analyze Distributed Trace Bottleneck Correlate Logs | Professional Cloud DevOps Engineer

Analyze Distributed Trace Bottleneck Correlate Logs

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An e-commerce checkout flow spans three microservices instrumented with OpenTelemetry: frontend-service, payment-service, and inventory-service. Users intermittently experience 504 Gateway Timeout errors during high-traffic flash sales.

You examine Cloud Trace in the Google Cloud console and observe the following pattern on failing requests:

The root span (frontend-service: /checkout) has a duration of 30,000 ms.
Child span 1 (payment-service: /charge) executes concurrently and completes successfully in 250 ms.
Child span 2 (inventory-service: /reserve) remains active for 29,750 ms before returning an HTTP 500 error status.

You need to isolate the critical path bottleneck and determine the root cause of the failure using integrated Google Cloud Observability tooling.

What should you do?

Identify child span 2 (inventory-service: /reserve) as the critical path bottleneck, and navigate to the Logs & Events tab within the Trace details panel to inspect correlated log entries for the failing span.

Navigate to the Logs Explorer and manually search all unindexed error logs across the entire cluster without trace context to locate database exceptions.

Focus troubleshooting exclusively on Istiod control plane logs to verify why Envoy sidecars failed to scale pod replicas.

Identify child span 1 (payment-service: /charge) as the critical path bottleneck because financial transactions must complete first, and query Prometheus metrics for database lock contention.

Professional Cloud DevOps Engineer

Analyze Distributed Trace Bottleneck Correlate Logs

Related questions