If you cannot read your own system's logs, a production outage becomes a guessing game that can last hours. Centralised logging and analysis with Cloud Logging gives you a single, searchable, permanent record of everything your applications do, so you can find the root cause of a failure in minutes instead of digging through dozens of scattered files. For the PCDOE exam, you need to know how to route logs to the right storage, create metrics that trigger alerts, and use the Logs Explorer to investigate incidents — these are the hands-on skills Google tests directly.
Jump to a section
A simple way to picture Centralized Logging and Analysis with Cloud Logging
3,742 packages leave a busy warehouse every day. Each package has a handwritten shipping label. If a package goes missing, you must search through 3,742 paper labels spread across 12 different desks to find it. This is what system logging looks like without centralisation.
Now imagine every single label is instantly photocopied and sent to one master logbook in the supervisor's office. The logbook is sorted by date, and the supervisor can flip to any page and find every label from the past year. If a customer calls about a missing delivery, the supervisor searches the logbook by the tracking number and finds the entry in seconds. That logbook is your centralised logging system. The shipping labels are your log entries.
In a warehouse, you also want to know if too many packages get damaged on a certain conveyor belt. So you set up a rule: every time the damage stamp is used on a label, the supervisor adds a tally mark to a whiteboard near that belt. After ten tally marks, the whiteboard triggers a red light that tells a manager to inspect the belt. The tally rule is a log-based metric, and the red light is an alert. Cloud Logging lets you build this same system for your software, but instead of a master logbook, you use a digital tool called Logs Explorer, and instead of tally marks, you write metric filters that count specific events automatically.
At its simplest, a log is a timestamped record of an event. When you run software, every action — a user logging in, a server starting up, a database query failing — can generate a log entry. Think of logs as a diary: they tell you what happened, when it happened, and often why.
Before centralised logging, each server or application wrote its own log to a local text file on its own hard drive. If you had 100 servers, you had to log in to each one separately, open the file, and read it. Searching for a specific error across 100 servers meant 100 manual logins. This was slow and nearly impossible during an outage when every second counted.
Cloud Logging solves this by collecting all log entries from all your Google Cloud resources — Compute Engine virtual machines, Google Kubernetes Engine clusters, Cloud Functions, App Engine applications, and more — into one central place. You do not log in to each machine. Instead, every resource sends its logs to Cloud Logging's central storage, called the Logs Bucket.
Here is how the flow works:
Log generation: A resource generates a log entry. For example, a Cloud Run service logs a line saying 'Request processed successfully'.
Log ingestion: Cloud Logging automatically receives this log entry. Google's agents, like the Cloud Logging agent that runs on Compute Engine VMs, collect logs and forward them. You do not need to do anything for most managed services; they send logs automatically.
Log storage: The log entry lands in a logs bucket. By default, logs are stored in the _Default logs bucket, which keeps them for 30 days. You can create custom logs buckets with different retention policies, like 365 days for compliance.
Log viewing and searching: You use a tool called Logs Explorer to search across all logs. It works like a Google search bar but for log entries. You can filter by resource type, severity, timestamp, or any text in the log message. Type 'error' and you see all error entries.
Log routing with sinks: This is where the power comes in. A log sink is a rule that says 'send all logs that match a filter to a specific destination'. Destinations include Cloud Storage for long-term archive, BigQuery for analytics, or Pub/Sub for real-time processing. For example, you could create a sink that sends all logs with severity 'ERROR' or 'CRITICAL' to a Pub/Sub topic, which triggers a Cloud Function to page an on-call engineer.
Log-based metrics: A log-based metric is a counter that increases every time a log entry matches a particular pattern. For instance, you can create a metric that counts every time a log entry contains the phrase 'disk full'. Then you set an alert on that metric: if the count goes above 5 in five minutes, send an email to the operations team. This is how you turn static log data into proactive alerts.
Why does this exist? In modern distributed systems, a single user request might travel through five different microservices running on 20 different containers. Without centralised logging, you would have to piece together the trail manually. With Cloud Logging, you can query across all services and see the complete timeline of that one request.
Logs are categorised by severity levels: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY. These help you filter for the most important events quickly.
Logs also have a structured format called a log entry. Each entry includes a log name, resource type, timestamp, severity, and the log message itself. Many services also include labels or structured payloads with key-value pairs, making them easy to search programmatically.
You also have the concept of excluded logs. If your service generates millions of DEBUG logs that you never read, you can create an exclusion filter to drop them before they are stored. This saves storage costs and reduces noise.
For the PCDOE exam, centralised logging is how you prove your system is observable. Without it, you are blind. With it, you can answer the three most important questions when something breaks: what failed, when did it fail, and which component caused it.
Identify the log source and enable logging
First, determine which Google Cloud resources produce the logs you need. For managed services like Cloud Run or App Engine, logging is enabled by default. For Compute Engine VMs, you must install the Ops Agent. This step is the foundation because without log ingestion, nothing else works. On the exam, questions about 'missing logs' usually test that you forgot to install the agent on a VM.
Open Logs Explorer and write a query
Go to the Cloud Logging menu in the Google Cloud Console and open Logs Explorer. Write a query using filters like 'resource.type="k8s_container"' and 'severity>=ERROR' to narrow down your search. This is how you investigate incidents. The exam tests your ability to choose the correct query syntax to find a specific error in a multi-service architecture.
Create a log sink to route logs to a destination
Navigate to Log Router in the Cloud Console and click 'Create sink'. Give it a name, write a filter (for example, 'severity=CRITICAL'), and choose a destination like a Cloud Storage bucket or a Pub/Sub topic. This step is critical for compliance and real-time alerting. The exam tests that you know the four valid destinations and that a sink does not delete original logs.
Define a log-based metric and alert
In the Logs Explorer, select 'Actions' and 'Create metric'. Write a filter that matches the log pattern you care about, such as 'textPayload:"disk full"'. Choose the metric type 'Counter' and save. Then create an alert policy in Cloud Monitoring that triggers when this metric exceeds a threshold. This step turns static log data into automated responses. The exam tests that the metric is evaluated on ingestion, not on stored data.
Set a log exclusion to reduce costs
If your service generates excessive DEBUG or INFO logs that you never use, go to Log Router and create an exclusion. Write a filter that matches those logs, and choose to exclude them from ingestion. This saves storage costs and reduces noise in Logs Explorer. The exam tests that exclusions drop logs before they are stored, and that they are different from sinks.
Analyse logs over time with exported data
If you exported logs to BigQuery using a sink, you can run SQL queries to find trends — for example, 'average error count per hour over the last week'. In Logs Explorer, you can also use histogram charts to see log volume over time. This step is how you move from reactive firefighting to proactive capacity planning. The exam tests your understanding of when to use BigQuery vs Logs Explorer for long-term analysis.
A real IT professional at a mid-sized e-commerce company uses Cloud Logging every day to keep the checkout system running. Let us walk through a typical Tuesday morning.
At 9:15 AM, a customer support manager reports that users are complaining about slow payment processing. As the DevOps engineer, you open Cloud Logging's Logs Explorer. You type a query filtering by resource type 'cloud_run_revision' and include the text 'payment'. You also set the time range to the last two hours. In seconds, the Logs Explorer returns 847 log entries. You sort by severity and notice 23 ERROR-level logs from a service called 'payment-authoriser'.
You click on one ERROR log. It shows a stack trace pointing to a 'timeout waiting for connection from pool'. The log message includes a trace ID. You copy that trace ID and paste it into Cloud Trace — another Google Cloud tool — to see the full request journey. You discover that a database connection pool was exhausted because a batch job that runs at 9 AM is holding connections open too long.
Now you need to ensure this does not happen again. You decide to create a log-based metric. You write a filter that matches any log entry containing 'timeout waiting for connection from pool' with severity ERROR. You name it 'payment_connection_timeout_count'. You then create an alert policy that triggers an email and a SMS notification to the on-call engineer if the metric value exceeds 5 in any 5-minute window.
Next, you set up a log sink for compliance. The company's security policy requires retaining all audit logs for one year. You create a sink that routes all logs from the 'audit' log bucket to a Cloud Storage bucket named 'audit-logs-2024'. You configure the destination bucket with lifecycle rules to move logs to archive storage after 90 days, and delete them after 365 days.
You also set up a second sink for the security team. This sink sends all logs with severity CRITICAL or ALERT to a Pub/Sub topic. The security team's SIEM (Security Information and Event Management) system subscribes to that topic and ingests the logs for threat detection.
Finally, you set up a dashboard in Cloud Monitoring that shows the count of log entries by severity, the top error messages from the last hour, and the status of your log-based metric. This dashboard lives on a screen in the office so everyone can see system health at a glance.
At the end of the week, you run a BigQuery query on the exported logs to find the average latency of payment requests over the last month. This helps the product team decide where to invest in performance improvements.
Every step here — searching logs, creating metrics, routing to storage and alerts — is exactly what the PCDOE exam tests. You are not just reading logs; you are building a system that makes logs useful automatically.
The PCDOE exam tests your ability to design and implement a centralised logging strategy using Cloud Logging. Expect scenario-based multiple-choice questions where you must choose the correct tool or configuration. Here are the specific concepts they test and the traps they set.
Log sinks: The exam loves log sinks. You will see questions like 'A company needs to store application logs for 7 years for compliance. Which two steps should they take?' The correct answer is always: create a log sink that routes logs to a Cloud Storage bucket, and configure a lifecycle rule on the bucket to transition objects to Archive storage. The trap is that beginners choose a logs bucket retention policy, but logs buckets have a maximum retention of 3650 days (10 years) — that is covered, but the exam wants you to choose a sink to a different destination for long-term storage, not rely on the default logs bucket alone.
Log-based metrics: You will see questions where you must write a filter expression. For example: 'Create a metric that counts logs containing the word 'timeout' from any resource in the production project.' The correct filter uses a regular expression like: severity>=ERROR AND textPayload=~"timeout". The trap is forgetting to include the severity filter, which would count DEBUG logs too and cause false positives.
Logs Explorer queries: The exam presents a scenario with a broken service and asks you to choose the correct query to find the root cause. They test your knowledge of filters like resource.type, severity, timestamp, and textPayload. A common trap is using 'AND' incorrectly — you must know that filters are case-sensitive for field names.
Exclusions vs sinks: This is a major point of confusion. An exclusion drops logs before storage to save cost. A sink copies logs to another destination. The exam will ask: 'Your team wants to stop storing DEBUG logs to reduce costs. What should you do?' The answer is create a log exclusion, not a sink. The trap is choosing a sink because it sounds like 'sink them away' — but a sink copies logs, it does not delete them.
Logs bucket destinations: They test that you can only send logs to specific destinations: Cloud Storage, BigQuery, Pub/Sub, or another project's logs bucket. They will offer a trap like 'send logs to a Cloud SQL database' which is not supported.
Retention periods: The _Default logs bucket retains logs for 30 days. You can change this if you create a custom logs bucket, with retention from 1 day to 3650 days. The exam tests that you cannot reduce retention below 1 day.
IAM permissions: They test that to view logs you need the Logs Viewer role (roles/logging.viewer). To create sinks you need Logs Configuration Writer (roles/logging.configWriter). A common trap is assuming any project viewer can create sinks — they cannot.
Key definitions to memorise:
Log sink: A rule that routes matching log entries to a destination.
Log-based metric: A counter or distribution derived from log entries matching a filter.
Logs Explorer: The UI for searching and analysing logs.
Logs bucket: A storage container for logs within Cloud Logging.
Log exclusion: A filter that prevents certain log entries from being ingested or stored.
The exam also tests 'aggregated sinks' — sinks that collect logs from multiple projects into a single destination, often used in a centralised logging project. They ask: 'Your company has 50 projects. You want to store all audit logs in one BigQuery dataset. What do you create?' Answer: an aggregated sink at the organisation level that routes logs from all projects to a BigQuery dataset in a central project.
A log sink copies log entries to Cloud Storage, BigQuery, Pub/Sub, or another project's logs bucket; it does not delete the original logs.
A log-based metric counts log entries matching a filter at ingestion time and is the foundation for proactive alerting.
Logs Explorer is the central search tool for querying logs using filters on resource type, severity, timestamp, and text payload.
By default, logs are stored in the _Default logs bucket with a 30-day retention, but you can create custom logs buckets with retention up to 3650 days.
Compute Engine VMs require the Ops Agent to send system logs to Cloud Logging; managed services like Cloud Run send logs automatically.
Log exclusions drop matching logs before storage to reduce costs and noise, while log sinks copy matching logs to another destination.
These come up on the exam all the time. Here's how to tell them apart.
Log Sink
Copies matching logs to a destination such as Cloud Storage, BigQuery, or Pub/Sub
Original logs remain in the logs bucket and are still searchable
Used for long-term archiving, analytics, or real-time streaming to third parties
Log Exclusion
Drops matching logs before they are stored in the logs bucket
Original logs are permanently lost and cannot be searched
Used to reduce storage costs by eliminating noisy or unnecessary logs
Logs Explorer
Best for real-time troubleshooting and investigating specific incidents
Queries use a simple filter language similar to a search engine
Limited to logs stored in Cloud Logging (up to 3650 days retention)
BigQuery Log Analysis
Best for long-term trend analysis and running complex SQL aggregations
Queries use standard SQL for advanced joins and window functions
Requires logs to be exported via a log sink to a BigQuery dataset
Default Logs Bucket
Created automatically for every Google Cloud project
Retention is fixed at 30 days and cannot be changed
Cannot be deleted or moved
Custom Logs Bucket
Created manually by the user for specific retention or organisational needs
Retention can be set from 1 day to 3650 days
Can be deleted or reassigned to different logs sinks
Mistake
A log sink deletes logs from the original location after routing them to a destination.
Correct
A log sink copies logs to a destination; the original logs remain in the logs bucket unless you also create an exclusion.
The word 'sink' sounds like it drains or removes water, leading people to think it removes logs. In reality, it is a copy operation.
Mistake
Log-based metrics can only be created from logs that are stored in a logs bucket.
Correct
Log-based metrics are evaluated on log entries as they are ingested, before they are stored. They work even if logs are later excluded or have short retention.
People assume metrics come from stored data because other metrics are derived from stored time-series data. Log-based metrics are a special case that works at ingestion time.
Mistake
Cloud Logging automatically captures all logs from every Google Cloud resource without any configuration.
Correct
Cloud Logging captures logs from managed services automatically, but Compute Engine VMs require you to install the Cloud Logging agent or use the Ops Agent to collect system logs.
Beginners think 'fully managed' means everything is automatic. For VMs, you must explicitly install an agent because Google cannot read your VM's internal system logs without permission.
Mistake
If you set a log exclusion, the logs are still available to search in Logs Explorer for a short time.
Correct
A log exclusion prevents logs from being ingested at all — they are dropped before they ever reach the logs bucket, so they never appear in Logs Explorer.
Users expect a 'soft delete' or 'trash can' behaviour because other Google Cloud services often have recovery features. Log exclusion is a hard drop.
Mistake
Logs Explorer can show live tailing of logs without any configuration.
Correct
Logs Explorer has a 'Live tail' mode, but it only shows logs from the last few minutes and requires the streaming API to be enabled on the logs bucket.
The name 'Live tail' sounds like a real-time stream that never ends. In reality, it streams for a limited window and can be paused. Beginners expect infinite scrolling.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A log sink copies matching logs to another destination like Cloud Storage or BigQuery, and the original logs remain. A log exclusion drops matching logs before they are stored, so they never appear in Logs Explorer.
By default, logs go to the _Default logs bucket, which has a 30-day retention. You can create custom logs buckets with retention from 1 day up to 3650 days (10 years).
Yes, you need to install the Cloud Ops Agent on the VM. Managed services like Cloud Run or App Engine send logs automatically, but VMs require the agent because Google cannot access your VM's internal system logs otherwise.
Yes, you can use a log sink with a Pub/Sub destination, and then have your third-party tool subscribe to that Pub/Sub topic to ingest the logs. You cannot send logs directly from Cloud Logging to a third-party API without Pub/Sub.
Live tail shows log entries in real-time as they are ingested into Cloud Logging, but only for the last few minutes. It is useful for debugging a live issue rather than searching historical logs.
First, create a log-based metric with a filter that matches the error message (for example, 'textPayload:404'). Then create an alert policy in Cloud Monitoring that triggers when the metric count exceeds a threshold you define, such as 10 occurrences in 5 minutes.
You've finished Centralized Logging and Analysis with Cloud Logging. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?