Optimize Observability Structured Logging Sampling Strategy

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.

A team of DevOps engineers is redesigning the observability architecture for a distributed microservices application running on Google Cloud. The application currently produces hundreds of gigabytes of unstructured string logs per day, experiences high Cloud Trace ingestion costs due to un-sampled tracing, and struggles with query latency during production incident investigations.

Which strategy should the team implement to optimize observability telemetry for efficient troubleshooting while balancing operational costs?

Standardize on single-line text logs mapped to generic severity levels at ingestion, disable trace context propagation to minimize HTTP header overhead, and rely exclusively on uptime checks for diagnosing failures.

Set microservice log levels to DEBUG globally, route all raw application logs to an external storage bucket via log router sinks, and map severity levels using log message string matching.

Configure aggressive head-based sampling at a fixed 0.01% rate across all microservices, output raw syslog text strings to avoid JSON serialization overhead, and add user IDs as custom metric labels.

Emit structured JSON payloads with recognized severity levels and trace context identifiers, implement tail-based or adaptive trace sampling to preserve error transactions, and keep high-cardinality attributes in structured log payloads rather than metric labels.

Professional Cloud DevOps Engineer

Optimize Observability Structured Logging Sampling Strategy

Related questions