A DevOps team is deploying a business-critical microservice across a fleet of Compute Engine Linux virtual machines (VMs). The service writes application events and stack traces to /var/log/app/service.log. The team has the following observability and operational requirements: Standardize on the Google Cloud Ops Agent across all instances. Ingest logs from the custom log path /var/log/app/service.log. Concatenate multi-line language exception stack traces and parse JSON-formatted entries. Exclude non-essential DEBUG log entries before sending data to Cloud Logging to manage ingestion costs. How should the DevOps team configure /etc/google-cloud-ops-agent/config.yaml to achieve these objectives?

Define a files type receiver under logging.receivers, configure parse_multiline, parse_json, and exclude_logs processors under logging.processors, and combine them within a pipeline in logging.service.pipelines.: ### What the Ops Agent Logging Pipeline Architecture Is The **Ops Agent** uses an embedded **Fluent Bit** engine to provide high-throughput, unified log collection and processing on Compute Engine virtual machines. Its architecture is configured using a declarative YAML structure comprising **receivers** (log data sources), **processors** (log parsing, field modification, and filtering), and **service pipelines** (directional streams connecting receivers through processors to the Cloud Logging exporter). ### How It Meets the Requirements - **Custom Log Path Ingestion**: Defining a receiver of `type: files` under `logging.receivers` with the target path `/var/log/app/service.log` tells the Fluent Bit engine to tail and collect log entries from the custom application log file. - **Multi-line Exception Handling & JSON Parsing**: Chaining the `parse_multiline` and `parse_json` processors under `logging.processors` ensures multi-line stack traces (such as Java, Python, or Go exceptions) are properly concatenated into single log entries before payload JSON structures are parsed. - **Cost Control via Filtering**: Adding an `exclude_logs` processor allows the team to evaluate log statements against matching rules (e.g., matching `DEBUG` level) and discard them prior to egress, preventing unnecessary ingestion and storage charges in Cloud Logging. - **Sequential Pipeline Assembly**: Referencing the receiver and processors in order within `logging.service.pipelines` guarantees that raw file logs flow through multiline reconstruction, JSON field extraction, and exclusion filtering before export. ### Key Advantages and Capabilities - **Resource-Efficient Telemetry**: Leverages native Fluent Bit multi-core performance for lower memory footprint and CPU overhead. - **Declarative Pipeline Management**: All receivers, processors, and pipelines are defined in a single `/etc/google-cloud-ops-agent/config.yaml` file. - **Built-in Parsing Rules**: Provides out-of-the-box support for popular exception patterns and structured logging payloads. - **Granular Ingestion Control**: Prevents log bloat and reduces billing by discarding noisy debug traces locally on the VM. ### Why This Is Optimal This solution relies completely on standard, supported **Ops Agent logging mechanisms**. It consolidates log gathering and pre-ingestion filtering directly on the host without requiring custom sidecar daemons or external log forwarders.

Ops Agent Custom Logging Pipeline Configuration | Professional Cloud DevOps Engineer

Ops Agent Custom Logging Pipeline Configuration

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 DevOps team is deploying a business-critical microservice across a fleet of Compute Engine Linux virtual machines (VMs). The service writes application events and stack traces to /var/log/app/service.log.

The team has the following observability and operational requirements:

Standardize on the Google Cloud Ops Agent across all instances.
Ingest logs from the custom log path /var/log/app/service.log.
Concatenate multi-line language exception stack traces and parse JSON-formatted entries.
Exclude non-essential DEBUG log entries before sending data to Cloud Logging to manage ingestion costs.

How should the DevOps team configure /etc/google-cloud-ops-agent/config.yaml to achieve these objectives?

Define an otlp type receiver under combined.receivers and route log records through a logging pipeline in combined.service.pipelines to the embedded OpenTelemetry Collector.

Install the legacy Cloud Logging agent (google-fluentd) alongside the Ops Agent to process file logs and multiline traces while the Ops Agent collects host metrics.

Configure a prometheus receiver under the metrics block with metric_relabel_configs to drop debug statements and forward the parsed logs to Cloud Logging.

Define a files type receiver under logging.receivers, configure parse_multiline, parse_json, and exclude_logs processors under logging.processors, and combine them within a pipeline in logging.service.pipelines.

Professional Cloud DevOps Engineer

Ops Agent Custom Logging Pipeline Configuration

Related questions