Exam domain 3.4 asks you to implement monitoring, logging, and observability using Google Cloud's tools. This matters because without these three capabilities, your application is a black box - you have no idea if it is healthy, fast, or even running at all. For the PCD exam, understanding how Cloud Monitoring, Cloud Logging, and Cloud Trace work together separates candidates who pass from those who guess.
Jump to a section
A simple way to picture Monitoring, Logging, and Observability
Your house has a central security panel mounted on the wall in the hallway. This panel is the single place where all information about your home's safety is collected and displayed.
When you arm the system at night, the panel shows green icons for every locked door and closed window - this is monitoring, a real-time status check of each component's health. If a window is left open, that icon turns red and the panel beeps immediately. You see the problem the moment it happens.
Beneath the panel, hidden in a basement server rack, a separate device logs every single sensor event for years. Every door open, every motion detection, every alarm test, every time you entered the wrong code. This is logging - a permanent, searchable record of everything that has ever happened, even if the house is quiet now.
Observability is the hardest piece. It is the ability, weeks later, to answer not just 'did a window open?' but 'why did the alarm trigger at 2am last Tuesday when all sensors showed green?' You trace the sequence of events - the dog triggered the motion sensor, the delay timer started, the disarm code was entered 30 seconds late but still accepted because of a firmware bug. Observability lets you ask unplanned questions about your system's behaviour, connecting scattered logs and metrics to find root causes.
Monitoring, logging, and observability are the three pillars of understanding what your software is doing in production. Let us break each one down from the ground up.
Monitoring is the practice of collecting and displaying metrics - numbers that describe the state of your system at a given moment. A metric is a measurement: how many requests arrive per second, how much memory your application is using, what percentage of your CPU is busy. Monitoring tools typically show these numbers on dashboards with charts and alert you if something goes outside an expected range. For example, you might set a monitoring alert that triggers an email to your team if the average response time exceeds 500 milliseconds for five consecutive minutes. The key idea with monitoring is that you are watching known, expected indicators. You decide in advance what matters - CPU, memory, latency - and you watch those specific numbers.
Logging is the practice of recording events as they happen. A log is a timestamped message that says something occurred. Your application might log 'User login successful' or 'Database connection failed - retrying in 5 seconds'. Logs contain details that metrics do not: the exact error message, the user ID involved, the stack trace. Think of logs as a diary. While monitoring tells you 'the server is running at 90% CPU', logs tell you 'at 14:32:15, user 12345 tried to upload a file and the disk filled up'. In Google Cloud, Cloud Logging collects, stores, and lets you search through all your logs from one central place.
Observability is the newest and most complete concept. It is not a tool but a property of your system. A system is observable if you can understand its internal state by looking at its outputs - metrics, logs, and traces - without having to add new instrumentation or restart it. The classic test is: can you answer a question you did not anticipate? For instance, 'Why did the checkout page load slowly for customers in Europe yesterday at 3pm?' If your system is observable, you can look at traces (records of a single request's journey through all services), correlate them with logs and metrics, and find the answer without deploying new code. Observability relies on three data types working together: metrics for trends, logs for details, and traces for request flow.
Now replace these concepts with Google Cloud's specific tools:
Cloud Monitoring (formerly Stackdriver Monitoring): collects metrics from your Google Cloud resources and applications. It supports custom metrics (numbers you define) and built-in metrics (pre-defined for Google services like Compute Engine or Cloud Run). You create dashboards and alerting policies.
Cloud Logging (formerly Stackdriver Logging): ingests, stores, and enables search of log entries. It can forward logs to other destinations like BigQuery for analysis or Pub/Sub for real-time processing. Log-based metrics let you turn log messages into quantifiable metrics.
Cloud Trace: captures latency data from your applications. It shows how long each part of a request takes, including calls to databases, external APIs, and internal services. This is critical for finding performance bottlenecks.
These three tools are deeply integrated. For example, you can see a metric spike in Cloud Monitoring, click through to view related logs in Cloud Logging, and then open a trace to see which specific service call slowed down that request. Google Cloud calls this unified observability.
Why did these tools replace older approaches? Before cloud observability, teams used separate, siloed tools. One tool for server metrics (like CPU), another for application logs (like error messages), and another for performance traces. Teams spent hours copying data between systems. Google Cloud's approach puts everything in one ecosystem, reducing 'time to triage' - the time between noticing a problem and finding its root cause.
Instrument your application
Add code to your application to emit metrics, logs, and traces. For a Python Flask app on Cloud Run, you import the OpenTelemetry SDK and configure it to send metrics to Cloud Monitoring, logs to Cloud Logging, and traces to Cloud Trace. Without instrumentation, these tools capture nothing.
Define key metrics
Decide which numerical indicators matter for your service: request count, latency percentiles (p50, p95, p99), error rate, CPU utilisation, memory usage. These become the basis for dashboards and alerting policies. In Cloud Monitoring, you create custom metrics for application-specific values like 'cart abandon rate'.
Create a dashboard in Cloud Monitoring
Build a visual display that shows your key metrics in one place. You add widgets like line charts for latency over time, a gauge for current CPU, and a table showing error rates by endpoint. This dashboard becomes your team's first view when something goes wrong.
Set up alerting policies
Configure conditions that trigger notifications. For example, 'if error rate exceeds 5% for 5 minutes, send email and Slack message'. You can also create log-based alerts: 'if a log message contains CRITICAL, page the on-call engineer'. Each alert has a severity level and escalation path.
Configure log export and retention
Set up log sinks to route specific log types to other services. For example, send all audit logs to BigQuery for compliance querying, send error logs to Pub/Sub for real-time processing, and store all logs for 1 year in Cloud Storage for long-term archival. Set retention policies on each log bucket.
Test observability with a simulated failure
Simulate a slow database query or a memory spike to see if your monitoring alerts fire, logs capture the event, and traces show the slow call. This step validates that your instrumentation is working correctly. Many teams skip this and only discover broken monitoring during a real incident.
Imagine you are a site reliability engineer at an e-commerce company called ShopFast. Your team runs a shopping cart service on Google Kubernetes Engine (GKE). One Tuesday afternoon, you start getting reports from customer support that users cannot complete purchases. You open Cloud Monitoring.
Step 1: you look at the dashboard for your shopping cart service. The 'request latency' metric shows a sharp spike starting at 13:45 UTC. The 99th percentile latency jumped from 200ms to 4 seconds. You see a red alert for a new alerting policy you created last week: 'High checkout latency' triggered at 13:47.
Step 2: you click the alert. Cloud Monitoring shows a link to related logs. You open Cloud Logging and filter to the time range 13:45-13:55 and the resource 'gke-shopping-cart'. You see hundreds of log entries with the message 'Timeout connecting to payment gateway after 3000ms'.
Step 3: you know the payment gateway is an external third-party service. To understand the full picture, you open Cloud Trace. You search for traces from the same time period and look at a sample request that failed. The trace shows the cart service called the payment gateway, waited 3 seconds, then threw a timeout error. But interestingly, the trace also shows a call to the product inventory service that took 2.5 seconds - normally 0.5 seconds.
Step 4: you now have a hypothesis: the payment gateway timeout is the surface issue, but the inventory slowdown might have increased request volume to the payment gateway by delaying other parts of the checkout flow. You check the inventory service metrics in Cloud Monitoring. Its CPU is at 95%. You look at its recent deployment history and see a new version was released at 13:30 - 15 minutes before the problem started.
Step 5: you roll back the inventory service to its previous version. Within minutes, latency drops back to normal. You later confirm through log analysis that a memory leak in the new code caused the inventory service to degrade, which backpressured the entire checkout process. The payment gateway timeout was a symptom, not the cause.
What did an IT professional actually do here? They used monitoring to detect the anomaly, logging to identify the error messages, and tracing to trace the request flow across multiple services. Without traces, you might have blamed the payment gateway and wasted hours. In a real production environment, observability tools are used daily for:
The PCD exam tests your ability to configure Google Cloud's observability tools correctly, not your ability to architect a full observability strategy. The questions are practical and scenario-based. Here is what you need to know.
First, the exam loves testing default behaviours. A common question asks: 'You need to retain logs for 30 days for audit compliance. Which service does this?' The answer is Cloud Logging with a log bucket retention policy. But many candidates confuse Cloud Logging with Cloud Monitoring. Know that Cloud Logging stores logs. Cloud Monitoring stores metrics and alerts. They are separate services that share a single console but have different storage backends.
Second, alerting policies are a major topic. You must understand the difference between metric-based alerts and log-based alerts. A metric-based alert fires when a numerical value (like CPU utilisation) crosses a threshold. A log-based alert fires when a specific log message pattern appears (like 'ERROR: database connection failed'). The exam will give you a scenario and ask which type of alert to create.
Third, you must know how to export logs. Cloud Logging can route logs to BigQuery, Pub/Sub, or Cloud Storage for long-term retention or analysis. The exam tests the export sink configuration: you create a sink that filters logs and sends them to a destination. Remember that log sinks are flexible and can exclude certain logs to save costs.
Fourth, Cloud Trace is frequently tested as the tool for analysing latency across microservices. The exam expects you to know that Trace works by sampling requests - it does not trace every request by default. You can adjust the sampling rate. A typical question: 'Your users report slow checkout. Which tool shows the time spent in each microservice?' The answer is Cloud Trace.
Fifth, custom metrics are a high-yield topic. You create custom metrics using the Cloud Monitoring API or through OpenTelemetry. The exam tests that custom metrics are billable and require explicit creation. Pre-built metrics (like 'cpu/utilization') come free and require no setup.
Key concepts to memorise:
Monitoring gives you real-time numerical health checks on known indicators; logging gives you detailed records of every event; observability lets you answer unplanned questions by combining metrics, logs, and traces.
Cloud Monitoring, Cloud Logging, and Cloud Trace are three separate Google Cloud services that integrate deeply to provide unified observability.
Logs are stored in log buckets with configurable retention periods (default is 30 days); to store logs longer, you must create a custom log bucket and incur storage costs.
Cloud Trace does not trace every request by default; it uses sampling and requires your application to be instrumented with the trace client library or OpenTelemetry.
Alerting policies in Cloud Monitoring can be metric-based (threshold on a numeric value) or log-based (triggered by a log message pattern) - each suited for different scenarios.
Export sinks in Cloud Logging allow you to route logs to BigQuery for analytics, Pub/Sub for real-time streaming, or Cloud Storage for archival, based on inclusion or exclusion filters.
These come up on the exam all the time. Here's how to tell them apart.
Cloud Monitoring
Collects numeric metrics (CPU, latency, request count)
Stores data in time-series format
Used for dashboards and alerts on thresholds
Cloud Logging
Collects event records with messages and timestamps
Stores data in log entries (searchable text)
Used for debugging and compliance audits
Metric-based Alert
Triggers when a numeric value crosses a threshold
Monitors metrics like CPU or error rate
Alerts are latency-based (e.g., fails after 5 minutes)
Log-based Alert
Triggers when a log message pattern appears
Monitors specific text strings in logs
Alerts can be near real-time on log entry
Cloud Trace
Shows request flow across microservices
Captures latency per span (each service call)
Uses sampling; not every request traced
Cloud Logging
Shows individual event records
Captures error messages and stack traces
Every log entry is stored (if not excluded)
Log Sink
A routing configuration that exports logs
Can filter logs and send to external destinations
Defines where logs go (BigQuery, Pub/Sub, GCS)
Log Bucket
A storage location for logs within Cloud Logging
Has a retention period (default 30 days)
Logs are stored here unless exported via a sink
Mistake
Monitoring and logging are the same thing - they both just watch your server.
Correct
Monitoring collects numerical metrics over time (like CPU usage) and alerts on thresholds. Logging records discrete events with timestamps and messages. They serve different purposes and are stored in different systems within Google Cloud.
The words are used interchangeably in casual conversation. In Google Cloud, they are distinct products with different UIs and billing models.
Mistake
Cloud Logging stores all logs forever for free.
Correct
Cloud Logging has a retention period. The _Default log bucket retains logs for 30 days. You can create custom log buckets with longer retention (up to 3650 days) but storage costs apply. Logs are not stored for free indefinitely.
Many assume cloud services have unlimited free storage. Google Cloud sets clear retention limits and charges for extended storage, which is a common exam trick.
Mistake
If Cloud Monitoring shows no alerts, your application is healthy.
Correct
Monitoring only checks what you told it to check. If you did not create an alert for a specific condition (like memory leak or slow database query), monitoring will not detect it. Observability is broader - it helps you find unknown unknowns.
People believe monitoring is a total health check. In reality, you must proactively define what 'healthy' means. An unmonitored metric can cause an outage without triggering any alert.
Mistake
Cloud Trace automatically traces every request in your application with no configuration.
Correct
Cloud Trace only works if your application code explicitly adds trace instrumentation, typically via OpenTelemetry or Google's client libraries. It also samples requests by default - you must configure sampling rate. Out of the box, no traces are captured.
Newcomers expect full auto-instrumentation. In fact, traces require code changes and configuration. The exam tests this explicitly.
Mistake
Logs are only useful after an outage to find the cause.
Correct
Logs are also used proactively for compliance audits, security investigations, capacity planning, and creating log-based metrics that feed into monitoring dashboards. They are not just a postmortem tool.
Many think of logs as a last resort. In mature observability practices, logs are ingested continuously and analysed in real time for anomaly detection.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud Monitoring collects numeric metrics over time (like CPU usage or request latency) and shows them on dashboards with alerts. Cloud Logging stores individual event records with timestamps and messages (like 'error connecting to database'). They are separate services that work together.
The default log bucket, called _Default, retains logs for 30 days. If you need logs for longer, you must create a custom log bucket with a longer retention period, which can be up to 3650 days (10 years) but incurs storage costs.
No. Cloud Trace only traces requests if your application code is instrumented with a trace client library or OpenTelemetry. By default, it samples only a fraction of requests (the sampling rate is configurable). You must explicitly add instrumentation.
A log-based metric is a numeric metric created from log entries. For example, you can count all log messages that contain '404 Not Found' and chart that count over time. This lets you turn log data into metrics that appear in Cloud Monitoring dashboards.
Yes. You create a log sink in Cloud Logging that exports logs to BigQuery, Pub/Sub, or Cloud Storage. The sink includes a filter to select which logs to export, and you can exclude certain logs to save costs.
A metric-based alert triggers when a numeric metric crosses a threshold, like CPU exceeding 80%. A log-based alert triggers when a specific pattern appears in log entries, like a certain error message. Use metric alerts for performance thresholds; use log alerts for specific error conditions.
For Google Cloud services like Compute Engine, monitoring and logging agents are available (the Ops Agent) or you can use OpenTelemetry. For application-level instrumentation, you install the appropriate client library (Python, Java, Go, etc.) and configure it to send data to Cloud Monitoring and Cloud Logging.
You've finished Monitoring, Logging, and Observability. Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?