Service monitoring fundamentals with Cloud Monitoring: every application or website you use depends on underlying services that must stay healthy. For the PCDOE exam, you need to know how to set up dashboards, alerts, and uptime checks so you can catch problems before customers do — and prove your system is reliable.
Jump to a section
A simple way to picture Service Monitoring Fundamentals with Cloud Monitoring
A Hotel Front Desk Manager is responsible for ensuring every guest has a smooth stay. Their job is to watch the hotel's key systems continuously, respond to issues quickly, and make sure the hotel keeps running.
Throughout the day, the manager checks a dashboard on their tablet. This dashboard shows the current occupancy rate, the number of housekeeping requests, and the wait time for the elevator. If the elevator wait time suddenly spikes above five minutes, that is a problem. The manager has set up an alert in their system: when the wait time breaches that threshold, they receive a notification. This is like a Cloud Monitoring alerting policy.
Every morning, the manager runs an uptime check on the hotel's booking website to make sure guests can book rooms online. If the site is down, the manager gets an alert and can fix the problem before guests complain. This is exactly how an IT professional uses uptime checks to verify a web application is accessible.
The manager also creates custom dashboards for different teams. The housekeeping team sees a dashboard showing how many rooms are dirty and how long they have been waiting. The maintenance team sees a dashboard for elevator and air conditioning performance. Each dashboard shows the metrics that matter most to that team. In Cloud Monitoring, you can create custom dashboards for different stakeholders.
Finally, the manager reviews weekly reports to spot trends: are elevator waits getting worse every Friday? This proactive analysis helps the manager hire more staff or fix the elevator before it breaks. This is the fundamental purpose of service monitoring: to see the health of your systems, get alerted when something goes wrong, and use data to improve your service over time.
Cloud Monitoring is Google Cloud's tool for observing the health and performance of your applications, infrastructure, and services. Think of it as a central command centre that collects data from across your cloud environment and presents it in a way that helps you answer questions like: "Is my website still loading quickly?" or "Is my database running out of storage?"
The core concept is a metric. A metric is a measured value captured over time. Common metrics include CPU utilisation (how busy your virtual machine's processor is), memory usage (how much RAM is being used), request latency (how long it takes your app to respond to a user), and error count (how many requests failed). Metrics are the raw data points you monitor.
To collect these metrics, Cloud Monitoring uses agents and APIs. A monitoring agent is a small piece of software you install on a virtual machine. It collects system-level metrics like CPU and disk usage and sends them to Cloud Monitoring. For Google Cloud services like Cloud SQL (a managed database) or Compute Engine (virtual machines), metrics are automatically collected without any agent needed — no additional configuration necessary.
Dashboards are visual displays that organise your metrics into charts and graphs. A dashboard might show a line chart of CPU utilisation over the last hour, or a bar chart of error counts by region. You can create custom dashboards to show exactly the metrics your team needs. For example, a developer might want a dashboard showing request latency and error rates for their microservice, while a system administrator wants a dashboard showing disk space and memory usage across all virtual machines.
Alerting policies are rules you define to notify you when a metric crosses a threshold that indicates a problem. An alerting policy includes:
A condition: for example, "if the average CPU utilisation exceeds 80% for 5 minutes"
A notification channel: where to send the alert — email, SMS, Slack, PagerDuty, or others
A duration: how long the condition must persist before triggering, which prevents false alarms from brief spikes
When the condition is met, Cloud Monitoring fires an incident — a record of the alert. You can then investigate and resolve the issue.
Uptime checks are automated tests that verify your application is reachable from the internet. They simulate a user visiting your website or API endpoint from multiple locations around the world. If the check fails (e.g., the server returns an error or doesn't respond), you get alerted. Uptime checks help you detect outages before your customers do.
Cloud Monitoring also supports alerting based on logs through log-based metrics. Logs are records of events happening in your system — like a user logging in or an error message. You can create a metric from specific log entries and then alert on that metric. For example, you could create a log-based metric that counts every occurrence of the word "ERROR" in your application logs, then alert if that count exceeds 10 in an hour.
Why does this matter? Before cloud monitoring existed, IT teams would manually check servers or wait for users to report problems. This was slow and unreliable. Modern monitoring gives you real-time visibility, automated alerting, and historical data to analyse trends. For the PCDOE exam, you must understand how to configure these three core building blocks: dashboards, alerting policies, and uptime checks.
Common services you monitor in Google Cloud include:
Compute Engine virtual machines: CPU, memory, disk, network
Cloud SQL databases: connections, queries, storage
App Engine applications: request latency, error rates, instance count
Kubernetes Engine clusters: pod cpu, node memory, container restarts
Cloud Storage buckets: object count, total size, request rates
For each service, you can use pre-built dashboards or create custom ones. You can also use the Metrics Explorer tool to browse all available metrics and build charts on the fly.
Create a Custom Dashboard
Navigate to Cloud Monitoring in the Google Cloud Console. Click 'Dashboards' then 'Create Dashboard'. Give it a name like 'ShopFast App Overview'. This is your central view for the application's health.
Add a Chart to the Dashboard
Click 'Add Chart'. Choose a metric, for example 'CPU utilisation' for your Compute Engine instance. Select the chart type (e.g., line chart). Set the aggregation (e.g., average over 5 minutes). This gives you a visual representation of CPU usage over time.
Configure an Alerting Policy
Go to 'Alerting' and click 'Create Policy'. Name it 'High CPU Alert'. Add a condition: select metric 'CPU utilisation', set condition 'is above' 80%, duration '5 minutes'. This ensures you only get alerted when the CPU stays high long enough to be a problem.
Set a Notification Channel
Under 'Notifications', click 'Add Notification Channel'. Choose 'Email' and enter your address. You can also add Slack, SMS, or PagerDuty. Save the policy. Now when the alert fires, you will receive an email.
Create an Uptime Check
Go to 'Uptime Checks' and click 'Create Uptime Check'. Enter your website URL (e.g., https://www.shopfast.com). Choose a check interval (e.g., every 1 minute). Select locations: 'London', 'New York', 'Tokyo'. Save the check. Cloud Monitoring will now test your site from those locations every minute.
Test and Tune Alerts
Simulate a high-load condition (e.g., by running a CPU-intensive script) and verify the alert fires within the expected time. If you get too many false alarms, increase the duration or threshold. This iterative process ensures your alerts are meaningful.
An IT professional at a company called 'ShopFast', an e-commerce platform, uses Cloud Monitoring to keep the application running smoothly. Here is what their day looks like.
First, they set up a custom dashboard that shows key business and technical metrics. The dashboard has several charts: one showing the number of active users on the site, one showing the average page load time, one showing the number of successful checkouts per minute, and one showing the CPU utilisation of the database server. This dashboard is pinned as their default view so they can instantly see the health of the entire service.
Next, they create alerting policies for critical conditions. For example:
If the page load time rises above 3 seconds for more than 2 minutes, they get an email and a Slack message
If the checkout success rate drops below 95%, a high-priority alert goes to PagerDuty on-call engineers
If the database server's CPU utilisation exceeds 80% for 5 minutes, an alert is sent to the database administrator
If the site's uptime check from three different locations all fail simultaneously, a critical incident is created
They also configure uptime checks for the main website (www.shopfast.com) and the API endpoint (api.shopfast.com/health). The uptime check pings the site every minute from four global locations: London, Tokyo, New York, and Sydney. If any location fails, they get a warning alert. If three out of four locations fail, they receive a critical alert.
After these are configured, the professional tests the setup. They simulate a high-load scenario by sending extra traffic to the database. The CPU metric increases, and after 5 minutes of sustained high CPU, they receive the alert on their phone. They then investigate the cause by looking at the dashboard and logs.
Over time, they refine the alerting policies. Initially, they had an alert for CPU utilisation over 70% for 1 minute, but that triggered too often during normal traffic spikes. They changed the duration to 5 minutes and the threshold to 80%. This reduced false alarms and made the alerts more meaningful.
They also use Cloud Monitoring to create weekly reports for the management team. They export dashboard snapshots showing the site's uptime (99.9% over the last month), average response time (200ms), and peak concurrent users. This data helps the team plan capacity upgrades.
Finally, they integrate Cloud Monitoring with other tools. They set up notifications to go to a Google Chat room where the whole engineering team can see alerts. They also use the Cloud Monitoring API to automatically scale resources up when certain metrics hit thresholds (though this is more advanced and part of autoscaling).
The key takeaway: the IT professional does not just set it and forget it. They actively tune thresholds, review dashboards, and respond to alerts. This ensures the service remains reliable and customers have a good experience.
The PCDOE exam tests your ability to configure Cloud Monitoring dashboards, alerting policies, and uptime checks. Here is exactly what you need to know.
Multiple-choice questions will present a scenario and ask you to choose the correct configuration. Common scenario types include: - "A development team wants to see real-time CPU and memory usage for their Compute Engine instances. What should they create?" Answer: A custom dashboard. - "An operator wants to receive an email when the error rate exceeds 5% for 10 minutes. What should they configure?" Answer: An alerting policy with a condition, a notification channel, and a duration. - "A company needs to verify their public website is accessible from around the world. Which feature should they use?" Answer: Uptime checks.
Key concepts you must memorise:
Metrics: CPU utilisation, memory usage, disk I/O, network traffic, request count, error count, latency
Alerting policy components: condition (metric threshold), notification channel (email, SMS, Slack, PagerDuty, webhook), duration (how long the condition must persist)
Incident states: open, acknowledged, closed
Uptime check parameters: target hostname/URL, protocol (HTTP, HTTPS, TCP), check interval (1, 5, 10, 15 minutes), locations (choose specific regions), timeouts
Log-based metrics: created from log entries using filters; used for alerting on specific events
Dashboards: custom dashboards with charts (line, bar, stacked bar, heatmap) that can be arranged in a grid
Metrics Explorer: tool to explore all available metrics and build ad-hoc charts
Traps the exam sets:
Confusing alerting policies with uptime checks. An uptime check tests availability from the outside; an alerting policy monitors internal metrics. They serve different purposes.
Forgetting the duration parameter. Without a duration, even a 1-second spike triggers an alert, causing noise.
Trying to use uptime checks for non-public resources. Uptime checks only work for resources reachable from the internet. For internal resources (like a VM without a public IP), you must use Cloud Monitoring's built-in metrics or a monitoring agent.
Selecting the wrong notification channel. The question will specify how the team wants to be notified. Make sure you match the channel to the requirement.
Misunderstanding log-based metrics. They are not real-time metrics from the system; they are derived from log entries. You must filter log entries first, then create a metric from that filter.
Exam question patterns: - "You need to alert when a metric exceeds a value for a sustained period. Which parameter is most important?" Duration. - "Which tool lets you view metrics from multiple Google Cloud services in one place?" Custom dashboard. - "You want to be notified when your website is down from the Asia region. What should you configure?" An uptime check with a location in Asia.
For the PCDOE exam, you should be able to describe the steps to create an alerting policy using the gcloud command-line tool or the Cloud Console. The exam may ask you to identify the correct command or console path.
Finally, know that alerting policies can use multiple conditions combined with AND/OR logic. For example: alert if CPU > 80% AND memory > 90%. This reduces false positives.
Memorise the default metric types: for Compute Engine, the key metrics are cpu/utilization, memory/usage (if agent installed), disk/read_bytes_count, disk/write_bytes_count, network/received_bytes_count, network/sent_bytes_count.
Cloud Monitoring uses metrics (CPU, memory, latency) to show the health and performance of your cloud resources.
Dashboards are visual collections of charts that let you see multiple metrics at a glance for different teams or services.
Alerting policies contain a condition (metric threshold), a duration (how long the condition lasts), and a notification channel (email, SMS, Slack) to trigger an alert.
Uptime checks test your public-facing application from multiple global locations to verify it is reachable and responding correctly.
Log-based metrics let you create alerting rules based on events found in your log files, such as counting every 'ERROR' entry.
Always set a duration on alerting policies to avoid false alarms from brief metric spikes.
Custom dashboards can be shared across teams and pinned to the Cloud Monitoring homepage for quick access.
These come up on the exam all the time. Here's how to tell them apart.
Uptime Check
Tests external reachability from multiple global locations
Measures whether the application is up or down from the internet
No metric threshold — just success/failure per check
Alerting Policy
Monitors internal metrics like CPU, memory, or error rates
Triggers when a metric crosses a defined threshold for a duration
Uses conditions, durations, and notification channels
Default Metrics (Compute Engine)
Sent automatically without any installation
Include CPU utilisation, disk I/O, network traffic
Do not include memory usage or process-level data
Ops Agent Metrics
Requires installing the Ops Agent on the VM
Includes memory usage, disk usage, and custom application metrics
Provides more detailed health information for troubleshooting
Metric
Measured value from a resource (e.g., CPU %) at set intervals
Real-time or near real-time data
Can trigger alerts directly based on thresholds
Log-Based Metric
Derived from counting or aggregating log entries
Updated when logs are processed (some delay)
Useful for alerting on specific events (e.g., error count)
Custom Dashboard
Persistent collection of charts saved for repeated viewing
Shared with teams and pinned for quick access
Ideal for ongoing monitoring and operations
Metrics Explorer
Ad-hoc tool to explore available metrics and build temporary charts
Not saved by default; used for one-time investigation
Good for debugging and exploring new metrics
Mistake
Cloud Monitoring only monitors Google Cloud services, not on-premises servers or other clouds.
Correct
Cloud Monitoring can collect metrics from on-premises servers, other cloud providers (AWS, Azure), and hybrid environments using the Monitoring agent, API, or OpenTelemetry.
People assume a cloud-specific tool only monitors that cloud, but Google designed Cloud Monitoring to be a central observability hub for any environment.
Mistake
If a metric is not visible in Cloud Monitoring, it means the resource is unhealthy.
Correct
A missing metric often indicates the monitoring agent is not installed, the metric is not supported, or the resource is not configured to export metrics.
Beginners jump to conclusions about health instead of verifying the data pipeline. The absence of data does not mean a problem — it means a configuration gap.
Mistake
Uptime checks can monitor any service, including internal databases behind a firewall.
Correct
Uptime checks are external, internet-facing tests. They cannot reach private IP addresses or resources behind a VPN or firewall without additional setup (like a proxy).
Because uptime checks simulate public users, people wrongly assume they can test any resource. Internal resources require agent-based metrics.
Mistake
Alerting on a high CPU utilisation value means you must fix the server immediately.
Correct
A high CPU alert is a signal to investigate, not a mandate to act. The server might be processing a legitimate batch job or handling normal traffic spikes. The alert triggers investigation, not automatic action.
Newcomers think all alerts are emergencies. In reality, many alerts are informational and require context before acting.
Mistake
You can create one alerting policy for all teams with the same notification settings.
Correct
Best practice is to create separate alerting policies per team or service with different notification channels and severity levels. Developers get Slack messages; operations get PagerDuty pages.
Beginners aim for simplicity but ignoring role-based alerting leads to alert fatigue and missed critical messages.
Mistake
Log-based metrics are the same as regular system metrics.
Correct
Log-based metrics are derived from log entries, not from the system directly. They measure events in logs, not system-level utilisation. They are slower to update and more useful for business-level events (e.g., error counts).
The name 'metric' makes people think they are the same, but they are fundamentally different in source and latency.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An alert is the notification you receive when a condition is met. An incident is the record of that alert in Cloud Monitoring, which has a lifecycle (open, acknowledged, closed) and can be tracked.
Yes. You can install the Cloud Monitoring agent on an on-premises server, and it will send metrics to Cloud Monitoring. You can also use the OpenTelemetry Collector for more advanced scenarios.
You can configure uptime checks to run every 1, 5, 10, or 15 minutes. The shorter the interval, the faster you detect outages, but it generates more cost.
No. Compute Engine automatically sends basic metrics (CPU, disk, network) without any agent. For memory usage and more detailed metrics, you need the Cloud Monitoring agent (or Ops Agent).
They are used to count specific events in logs, like errors or user sign-ups. You can then create alerts based on those counts. For example, alert if more than 10 'CRITICAL' errors appear in an hour.
In the Cloud Console, you can share the dashboard link. If the team members have appropriate IAM permissions (roles like 'Monitoring Viewer'), they can view the same dashboard.
You've finished Service Monitoring Fundamentals with Cloud Monitoring. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?