# Service Monitoring Fundamentals with Cloud Monitoring

> Chapter 9 of the Courseiva GOOGLE-PCDOE curriculum — https://courseiva.com//learn/google-pcdoe/monitoring-with-cloud-monitoring

**Official objective:** 2.1 — Configure Cloud Monitoring dashboards, alerting policies, and uptime checks for applications and infrastructure.

## Introduction

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.

## The Hotel Front Desk Manager Analogy

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.

## Core explanation

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.

## Real-world context

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.

## Exam focus

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.

## Step by step

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.

## Comparisons

### Uptime Check vs Alerting Policy

**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) vs Ops Agent Metrics

**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 vs Log-Based Metric

**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 vs Metrics Explorer

**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

## Common misconceptions

- **Misconception:** Cloud Monitoring only monitors Google Cloud services, not on-premises servers or other clouds. **Reality:** 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.)
- **Misconception:** If a metric is not visible in Cloud Monitoring, it means the resource is unhealthy. **Reality:** 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.)
- **Misconception:** Uptime checks can monitor any service, including internal databases behind a firewall. **Reality:** 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.)
- **Misconception:** Alerting on a high CPU utilisation value means you must fix the server immediately. **Reality:** 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.)
- **Misconception:** You can create one alerting policy for all teams with the same notification settings. **Reality:** 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.)
- **Misconception:** Log-based metrics are the same as regular system metrics. **Reality:** 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.)

## Key takeaways

- 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.

## FAQ

**What is the difference between an alert and an incident in Cloud Monitoring?**

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.

**Can Cloud Monitoring monitor on-premises servers?**

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.

**How often do uptime checks run?**

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.

**Do I need to install an agent for every VM in Compute Engine?**

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).

**What are log-based metrics used for?**

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.

**How do I share a dashboard with my team?**

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.

---

Interactive version with quiz and diagrams: https://courseiva.com//learn/google-pcdoe/monitoring-with-cloud-monitoring