An e-commerce platform running a distributed microservices application on Google Kubernetes Engine with Cloud Service Mesh experiences cascading service timeouts and intermittent HTTP 503 errors across several dependent services. As a DevOps engineer, you need to use Google Cloud's Logs Explorer diagnostic tools to: Pinpoint the exact timeframe where the anomalous spike in ERROR severity entries occurred relative to normal traffic. Quickly identify the specific service emitting the majority of errors without manually composing query language filters. Isolate and correlate the full end-to-end request lifecycle across all upstream and downstream microservices for an individual failed transaction. Which workflow within Logs Explorer should you execute to diagnose and trace this failure?

Inspect the Logs Histogram to identify the ERROR severity spike and drag over the time window to filter the range; use the Field Explorer to view the distribution of resource.labels.container_name and filter on the failing container; then select a failed log entry and filter by its trace field to view the correlated end-to-end request flow.: ### What this solution is This workflow leverages the core diagnostic and analytical tools built natively into Google Cloud **Logs Explorer**: the **Logs Histogram**, the **Log fields (Field Explorer)** pane, and **Distributed Tracing correlation** using the `trace` context field. ### How it meets the diagnostic requirements - **Pinpointing anomalous timeframes**: The **Logs Histogram** visualizes log entry volume over time broken down by log severity levels (e.g., `DEFAULT`, `INFO`, `WARNING`, `ERROR`, `CRITICAL`). Selecting or dragging across a specific bar or timeline segment zooms into that precise interval, automatically constraining the query time boundary. - **Identifying the failing service without writing manual queries**: The **Field Explorer** lists all indexed and parsed fields from the fetched log results, such as `resource.labels.container_name` or `jsonPayload` attributes, alongside counts and percentage distributions. Clicking on a high-error container name automatically appends the exact filter to the query editor. - **Correlating distributed microservice requests**: Cloud Service Mesh and Google Cloud client libraries automatically propagate and inject W3C trace contexts into log entries as `logging.googleapis.com/trace`. Expanding a failed log entry and filtering by its `trace` field displays all chronologically ordered logs generated by every microservice participating in that specific transaction. ### Key advantages and capabilities - **Visual anomaly detection**: The severity breakdown in the histogram allows immediate differentiation between traffic spikes and true error surges. - **Rapid root-cause isolation**: The Field Explorer eliminates syntax guesswork when navigating deeply nested JSON payloads or resource labels. - **Contextual cross-service correlation**: Trace-based correlation bridges logs across disparate containers, pods, and namespaces seamlessly. ### Why this is optimal This approach uses the integrated visual and indexing capabilities of the Logs Explorer interface directly, minimizing time to resolution (MTTR) during active incident troubleshooting.

Logs Explorer Histogram Field Explorer Trace Correlation | Professional Cloud DevOps Engineer

Logs Explorer Histogram Field Explorer Trace Correlation

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 platform running a distributed microservices application on Google Kubernetes Engine with Cloud Service Mesh experiences cascading service timeouts and intermittent HTTP 503 errors across several dependent services.

As a DevOps engineer, you need to use Google Cloud's Logs Explorer diagnostic tools to:

Pinpoint the exact timeframe where the anomalous spike in ERROR severity entries occurred relative to normal traffic.
Quickly identify the specific service emitting the majority of errors without manually composing query language filters.
Isolate and correlate the full end-to-end request lifecycle across all upstream and downstream microservices for an individual failed transaction.

Which workflow within Logs Explorer should you execute to diagnose and trace this failure?

Inspect the Logs Histogram to identify the ERROR severity spike and drag over the time window to filter the range; use the Field Explorer to view the distribution of resource.labels.container_name and filter on the failing container; then select a failed log entry and filter by its trace field to view the correlated end-to-end request flow.

Use the Log Scope selector to restrict logs to the Kubernetes cluster level; inspect the Log Search Summary pane to summarize payload strings; then use the spanId field to link all upstream and downstream service logs.

Navigate to Cloud Monitoring Metrics Explorer to chart log-based metric error counts; navigate to Error Reporting to group stack traces; then copy the Error Group ID into Logs Explorer to view all interrelated logs.

Configure a Log Router sink to export all logs to BigQuery; execute a SQL query grouping by severity and container name to isolate the error window; then query all logs sharing the same insertId across datasets.

Professional Cloud DevOps Engineer

Logs Explorer Histogram Field Explorer Trace Correlation

Related questions