Cloud Monitoring in Google Cloud: The Dashboard, Alarm Bell and Health Check for Everything You Run
A beginner-friendly guide to how Cloud Monitoring collects metrics, draws dashboards, raises smart alerts, tracks service-level goals and helps teams find and fix problems before customers notice.
Imagine you are the captain of a huge ship crossing an ocean at night. You cannot see inside the engine room, the fuel tanks or the cargo holds with your own eyes. Instead, you rely on gauges: engine temperature, fuel level, speed, water pressure and a panel of warning lights that flash red when something goes wrong. A good captain also knows which gauges matter, which warnings are urgent and which can wait until morning. Cloud Monitoring gives you exactly this panel of gauges and warning lights for your applications and infrastructure in Google Cloud, so you always know how your systems are feeling, even when you are asleep.
1First, Why Do We Need Monitoring?
A few simple ideas before we meet the service.
Software breaks, quietly and loudly
Every system eventually has problems. A server runs out of memory. A database slows down. A new release contains a bug. A network link becomes congested. Some failures are dramatic, and the whole website goes down. Others are sneaky: pages load a little slower each day until customers give up and leave without ever complaining. If nobody is watching, the first sign of trouble is often an angry customer or a lost sale.
What monitoring means
Monitoring is the practice of continuously measuring how your systems behave, storing those measurements, showing them in a useful way and alerting people when something looks wrong. It answers two big questions: “Is everything working right now?” and “Is it getting better or worse over time?”
Monitoring, logging and tracing: three friends
People often talk about three kinds of signals. Metrics are numbers measured over time, such as requests per second or memory used. Logs are detailed written records of events, such as an error message with a timestamp. Traces follow a single request as it travels through many services, showing where time is spent. Together they form observability, the ability to understand what is happening inside a system by looking at what it reports. Cloud Monitoring focuses mainly on metrics and alerting, and works closely with logging and tracing tools.
Metrics are a patient’s vital signs, such as temperature and heart rate. Logs are the doctor’s detailed notes about what happened and when. Traces are a map showing where a patient went through the hospital and how long each stop took. A good doctor uses all three, starting with vital signs to know when to look closer.
2So, What Is Cloud Monitoring?
Google Cloud’s managed service for collecting, viewing and acting on metrics.
Cloud Monitoring is a fully managed service that gathers metrics from Google Cloud services, your own applications, virtual machines, containers and even other clouds and on-premises systems. It stores those metrics, lets you chart and explore them, builds dashboards, checks the availability of your websites and services, defines service-level goals, and sends alerts when something needs attention. You do not run any monitoring servers, databases or storage. Google operates the entire backend.
Cloud Monitoring is part of a family of tools sometimes called Google Cloud Observability, which also includes Cloud Logging, Cloud Trace, Error Reporting and Profiler. Together they cover the main pillars of observing a running system.
Most Google Cloud services start sending useful metrics automatically, with no setup. You turn on charts and alerts rather than installing and tuning a monitoring system.
Cloud Monitoring is like a building’s central security and facilities control room. Sensors are already installed in every room by the building’s owner. You walk in, look at the screens, set up which alarms should ring and who should be called.
3Core Building Blocks You Must Know
A short dictionary of Cloud Monitoring words.
Metric
A measurement collected over time, such as processor use, request count or response time.
Time Series
The series of values of one metric for one specific resource, recorded at regular intervals, which is what a chart draws as a line.
Monitored Resource
The thing being measured, such as a virtual machine, a container, a database or a load balancer.
Label
Extra tags on a metric, such as region or service name, that let you filter and group the data.
Dashboard
A page of charts and numbers arranged to show the health of a system at a glance.
Alerting Policy
A rule that says when to raise an alert and whom to notify, based on conditions about your metrics.
Notification Channel
Where alerts are sent, such as email, a chat tool, a paging service, a messaging topic or a webhook.
Metrics Scope
The set of projects whose metrics you can view together from one place, useful for large organizations.
4Where Metrics Come From
Four main sources feed Cloud Monitoring.
Google Cloud system metrics
Services such as virtual machines, load balancers, databases, messaging and storage report their own metrics automatically, such as processor use, request counts and latency. These are available without any setup and are generally free to view.
Agent-collected metrics
A virtual machine’s inner workings, such as memory use and disk space, are not visible from outside. The Ops Agent, a small program you install on the machine, collects those detailed metrics and also forwards logs. It can also gather metrics from popular software running on the machine, such as web servers and databases.
Custom and application metrics
Your own code can report business and application measurements, such as orders placed per minute or items in a processing queue. Open standards for telemetry make this possible without locking your code to one vendor.
Prometheus metrics
Prometheus is a very popular open-source metrics system, especially in container platforms. Google Cloud Managed Service for Prometheus collects and stores Prometheus-style metrics at scale without you running Prometheus servers, and you can query them with the Prometheus query language.
Log-based metrics
You can create metrics from your logs, for example counting how many times a particular error message appears, so that log events can drive charts and alerts.
flowchart LR
GCS[Google Cloud services] --> CM[Cloud Monitoring]
VM[VMs with Ops Agent] --> CM
APP[Your applications - custom metrics] --> CM
K8S[Kubernetes - Prometheus metrics] --> CM
LOGS[Cloud Logging - log-based metrics] --> CM
OTHER[Other clouds and on-premises] --> CM
CM --> DASH[Dashboards]
CM --> ALERT[Alerting policies]
CM --> SLO[Service-level objectives]
Think of a hospital. Some vital signs come from machines already built into the bed. Others need a nurse with a special clip, like the agent on a machine. And the patient’s own diary of how they feel is like a custom application metric. All of it ends up on one chart at the nurse’s station.
5Exploring Metrics and Building Dashboards
Turning raw numbers into pictures people can read.
Metrics Explorer
Metrics Explorer is the place to ask questions interactively. You pick a metric, choose which resources to include, filter by labels, group the results and choose how to combine the data, for example by averaging across machines or adding up requests across a region. You can look at the last hour or the last month, and switch chart types. It is the best tool for investigating a problem or experimenting before you build a permanent dashboard.
Dashboards
A dashboard collects charts, numbers and text into one page. Cloud Monitoring provides ready-made dashboards for many Google Cloud services, which appear automatically when you use those services, and you can build custom dashboards for your own applications. Good dashboards answer the question “is this healthy?” within seconds, then let you dig deeper if it is not.
Querying data
Beyond point-and-click, Cloud Monitoring supports query languages for advanced analysis. The Prometheus query language, PromQL, can be used on metrics, which is convenient for teams already familiar with it. A native Monitoring Query Language has also been available. Language support evolves, so check the current documentation to see which is recommended for new work.
Decide who the dashboard is for
An on-call engineer needs different views than a manager. Pick one audience per dashboard.
Start with health summaries
Put key numbers, such as error rate and latency, at the top, where eyes land first.
Add detail below
Include charts for components, such as database, queue and cache, to help locate where trouble starts.
Use filters and consistent time ranges
Let viewers pick an environment or region, and keep all charts aligned on the same time window.
Review and prune
Remove charts nobody looks at. A short, clear dashboard beats a crowded one.
Show what users feel, such as slow responses and failed requests, before what machines feel, such as processor use. A machine can look busy while customers are perfectly happy, and the reverse can also be true.
6What Should You Measure? The Four Golden Signals
When you do not know where to start, start here.
Site reliability engineers, including those at Google, recommend four signals that describe the health of almost any user-facing service. If you can only watch four things, watch these.
Latency
How long requests take. Track the slowest few percent as well as the average, because slow outliers are what unhappy users feel.
Traffic
How much demand the system is receiving, such as requests per second. Sudden changes can mean growth, campaigns or attacks.
Errors
The rate of failed requests, whether obvious failures or wrong answers. Rising errors are an early warning of trouble.
Saturation
How full the system is, such as memory, disk or queue length. As saturation nears the limit, performance suffers.
Think of a restaurant. Latency is how long a guest waits for food. Traffic is how many guests walk in. Errors are wrong or missing dishes. Saturation is how full the kitchen and tables are. A manager who watches those four things knows exactly when the evening is going badly.
| Golden Signal | Example Metric | Typical Question It Answers |
|---|---|---|
| Latency | Response time at the 95th or 99th percentile | Are users waiting too long? |
| Traffic | Requests per second | How busy are we, and is that unusual? |
| Errors | Share of requests that fail | Are we failing users? |
| Saturation | Memory, disk or queue fullness | How close are we to running out of room? |
7Alerting: Getting the Right Person at the Right Time
An alert is a message that says “a human should look at this.”
An alerting policy has three parts: one or more conditions that describe what bad looks like, notification channels that say whom to tell, and optional documentation that tells the responder what the alert means and what to do first. When a condition is met, an incident opens, and when the condition clears, the incident closes. Incidents are tracked so you can see what happened and when.
Types of conditions
Threshold
The most common type. Alert when a metric stays above or below a value for a set time, such as error rate above a limit for five minutes. The waiting period prevents false alarms from brief blips.
Absence
Alert when data stops arriving, which can mean a service or an agent has stopped working. Silence can be the loudest sign of trouble.
Rate of change
Alert when a metric is rising or falling unusually fast, even before it reaches a fixed limit, such as disk space filling much faster than normal.
Forecast
Predict that a metric will cross a limit within a certain time and alert early, for example warning that a disk will be full in a day, so you can act before it becomes an emergency.
Uptime check and log-based conditions
Alert when an uptime check fails from several locations, or when a certain log message appears too often.
Where alerts go
Email and Mobile
Simple and good for lower-urgency notices, or for people who need to be informed.
Chat Tools
Post alerts into team channels so everyone sees and discusses them together.
Paging Services
Wake the on-call person with calls or push notifications, with escalation if they do not respond.
Messaging Topics and Webhooks
Send alerts to other systems, which can automatically open tickets, run repair scripts or notify other tools.
flowchart TD
M[Metric data arrives] --> C{Condition met for the set duration?}
C -->|No| OK[No alert]
C -->|Yes| I[Incident opens]
I --> N[Notification sent to channels]
N --> R[Responder reads the alert documentation]
R --> F[Investigate using dashboards, logs and traces]
F --> X[Fix the cause]
X --> CL[Condition clears, incident closes]
Alerting on every small wobble. When people receive too many alerts, they stop reading them, a problem called alert fatigue. Every alert that wakes someone should be urgent, real and actionable. Everything else belongs on a dashboard or in a daily report.
8Writing Alerts That People Love
Good alerts are short, clear and useful at three in the morning.
Alert on symptoms, not only causes
Users feel slow pages and errors. Alert on those first. High processor use is only interesting if it leads to a symptom.
Pick sensible thresholds and durations
Base them on observed normal behavior, and require the condition to last long enough to avoid brief false alarms.
Include helpful documentation
Add a short explanation, links to dashboards and logs, and the first steps to try, so the responder is never starting from zero.
Choose severity and the right channel
Page for urgent customer-impacting problems, post to chat for medium ones, and email for informational items.
Review alerts regularly
After each incident ask: did the alert fire at the right time, was it clear, was it needed? Tune or delete accordingly.
A good smoke alarm sounds when there is real smoke, not every time you make toast. If it screams all the time, people take out the battery, and then it fails when you need it most. Alerts must earn the trust of the people who receive them.
Use snoozing and maintenance windows to silence alerts during planned work, so people do not learn to ignore the noise, and remember to review snoozed policies afterwards.
9Uptime Checks and Synthetic Monitoring
Checking your service from the outside, like a customer would.
Metrics reported from inside a system can be perfectly healthy while customers cannot reach it, for example if a network route is broken. Uptime checks solve this by probing your service from multiple locations around the world at regular intervals, over the web, and recording whether it responded correctly and how fast. You can check public web addresses, private resources through special configuration, and look for specific content in the response. When several locations report failures, an alert can fire.
Synthetic monitoring goes a step further. A synthetic monitor runs a scripted test that behaves like a user, for example loading a page and clicking through a key journey, on a schedule, and reports success or failure with timings. It catches problems in whole workflows rather than just whether a single address responds. Features in this area evolve, so check current documentation for supported options.
sequenceDiagram
participant P1 as Probe in Region A
participant P2 as Probe in Region B
participant P3 as Probe in Region C
participant S as Your Service
participant CM as Cloud Monitoring
P1->>S: Request on a schedule
P2->>S: Request on a schedule
P3->>S: Request on a schedule
S-->>P1: Response and timing
S-->>P2: No response
S-->>P3: No response
P1->>CM: Report result
P2->>CM: Report failure
P3->>CM: Report failure
CM->>CM: Failures from multiple locations, open incident and notify
An uptime check is like a mystery shopper who visits your store at different times and from different directions, and reports whether the door opened, the lights were on and the cashier responded. Staff inside the store might all believe everything is fine, but the shopper sees what customers see.
10Service Monitoring: SLIs, SLOs and Error Budgets
A way to talk about reliability in terms customers and executives understand.
Saying “the system should be fast and reliable” is vague. Service-level thinking makes it measurable. A service-level indicator, or SLI, is a carefully chosen measurement of good service, such as the percentage of requests answered successfully, or the percentage answered within 300 milliseconds. A service-level objective, or SLO, is a target for that indicator over a period, such as “99.9 percent of requests succeed over thirty days.”
The gap between perfect and your target is the error budget. If your target is 99.9 percent, you have 0.1 percent of requests that are allowed to fail. This turns reliability into a shared, honest budget. While the budget is healthy, teams can release new features boldly. As it is used up, teams slow down and focus on stability. Cloud Monitoring lets you define services, set SLOs, track error budget consumption on dashboards and alert on burn rate, which means how fast the budget is being used.
SLI
The measurement, such as the share of requests that succeed quickly.
SLO
The target for the measurement over a time window, agreed by the team.
Error Budget
The amount of unreliability you can afford while still meeting the SLO.
Burn Rate
How quickly you are spending the budget. A high burn rate means you will run out soon and need to act.
An error budget is like a monthly spending allowance. If you spend it slowly, you can afford treats, meaning new features. If you burn through half of it in the first week, you know you must tighten up, meaning fix reliability, before the month ends.
Alerting on how fast the budget is burning catches serious problems quickly and ignores tiny blips that do not threaten the target. It produces fewer, more meaningful alerts than simple thresholds on raw numbers.
11Monitoring Containers, Kubernetes and Serverless
Modern applications change shape constantly, and monitoring must keep up.
In container platforms such as Google Kubernetes Engine, machines and containers appear and disappear all the time. Cloud Monitoring understands these environments: it collects metrics about clusters, nodes, pods and containers, and provides ready-made dashboards that show health at each level. Managed Prometheus supports the open-source ecosystem of metrics that Kubernetes applications commonly expose, so teams can use familiar tools and queries.
For serverless services such as Cloud Run and Cloud Functions, system metrics such as request counts, latencies, instance counts and error rates are collected automatically, and you can add custom metrics from your code. For databases, messaging and storage services, each provides its own set of metrics, from query latency to message backlog, available in the same place.
Cluster and node health
Watch capacity, restarts and scheduling problems, so you notice trouble before applications are affected.
Application-level metrics
Request rates, errors and latency per service, so you can see which microservice is struggling.
Autoscaling behavior
Track how many instances exist and how busy they are, to confirm that scaling reacts well and to spot cost surprises.
Dependencies
Monitor databases, queues and external services your application depends on, since failures there often show up as errors in your own service.
12Working With Logging, Tracing and Error Reporting
Metrics tell you something is wrong. The other tools tell you why.
A healthy investigation moves smoothly between tools. An alert fires from a metric. You open the dashboard to see which part is affected. You jump to the logs from that time window to read error messages. You open a trace to see which step of a request was slow. You check Error Reporting to see grouped exceptions and how often each occurs. You use the profiler, if needed, to see which code consumed the most processor time. Because these tools share context such as time range and resource, moving between them is quick.
flowchart TD
A[Alert: error rate high] --> B[Dashboard: which service and region?]
B --> C[Logs: what do error messages say?]
C --> D[Trace: which step of the request is slow?]
D --> E[Error Reporting: which exception is most common?]
E --> F[Profiler: which code uses the most resources?]
F --> G[Fix, deploy and watch metrics recover]
A detective story: the alarm tells you a crime occurred, the dashboard tells you which building, the logs are witness statements, the trace is the security camera footage following the suspect, and the profiler is the forensic report on exactly what was touched.
Include links to the relevant dashboard and a pre-filtered log view in the documentation of each alert. Saving even two minutes of searching on every incident adds up to hours over a year.
13Organizing Monitoring Across Many Projects
Large organizations often have dozens or hundreds of projects.
Google Cloud organizes resources into projects, and each project has its own metrics. A metrics scope is a way to view the metrics of several projects together from one chosen project, called the scoping project. This lets a central team build dashboards and alerts that cover many projects, while individual teams still manage their own. Some organizations choose one monitoring project per environment, such as production, and attach all related projects to it.
| Approach | How It Works | Good For |
|---|---|---|
| One scope per project | Each project monitors only itself | Small teams and simple setups |
| Central monitoring project | One project’s scope includes many projects | Platform teams needing a unified view |
| One scope per environment | Separate monitoring projects for production and non-production | Keeping production alerts clean and access tightly controlled |
Whatever structure you choose, use consistent names and labels for services, environments and teams, so that dashboards and alerts can be filtered and reused easily. Consistent labels are also the key to attributing monitoring costs and ownership.
14Security and Access Control
Monitoring data can reveal a lot about your systems, so protect it.
Access to Cloud Monitoring is controlled through Google Cloud’s identity and access management. There are roles for people who only need to view dashboards, for those who create and edit alerting policies and dashboards, and for administrators. Give people the lowest role that lets them do their job. Be especially careful with who can change or delete alerting policies and notification channels, since silent changes to alerting could hide a real problem.
Notification channels can carry sensitive information, so use trusted destinations and avoid putting secrets or personal data in alert text or metric labels. Custom metric labels should never contain customer identifiers or confidential values. Audit logs record who changed monitoring configuration, supporting reviews and investigations.
flowchart TD
A[Least-privilege roles for viewers, editors, admins] --> B[Restrict who can change alerting and channels]
B --> C[No secrets or personal data in metric labels or alert text]
C --> D[Trusted notification destinations]
D --> E[Audit logs for configuration changes]
E --> F[Regular access reviews]
Putting user identifiers, email addresses or other personal data into metric labels. Labels are widely visible and create huge numbers of separate time series. Keep labels about the system, not the people using it.
15Understanding Costs
Many metrics are free, but some usage is billed.
Metrics from Google Cloud services are generally available at no charge, while charges apply to other kinds of ingestion, such as custom metrics, agent-collected metrics from third-party software, external and Prometheus metrics, and some related features. Pricing is usually based on the volume of data ingested, and related services, such as logging and tracing, have their own charges. Rates and free allowances change, so always check Google Cloud’s pricing page and calculator.
Beware of high cardinality
Cardinality means the number of distinct label combinations. Adding a label with many possible values, such as a user or request identifier, creates millions of separate time series and can inflate costs and slow queries. Keep labels to a small set of meaningful values.
Collect what you will use
Do not turn on every possible metric from every agent by default. Choose the ones that feed dashboards and alerts.
Tune collection frequency
A metric sampled every few seconds costs more than one sampled every minute. Use the longer interval where fine detail is not needed.
Watch log-based metrics and related services
Heavy logging can add up, so apply filters and exclusions, and check how much each source contributes to the bill.
Monitor your monitoring cost
Review usage reports regularly and set budgets or alerts so that a sudden jump in metric volume is noticed quickly.
16Advantages and Trade-offs
A balanced view.
Advantages
- Fully managed with no monitoring infrastructure to run, scale or patch.
- Google Cloud service metrics and ready-made dashboards work with almost no setup.
- Supports custom metrics, agent metrics and managed Prometheus for open-source compatibility.
- Flexible alerting, including threshold, absence, rate-of-change and forecast conditions.
- Built-in service-level objectives, error budgets and burn-rate alerting.
- Works smoothly with logging, tracing, error reporting and incident tools.
Disadvantages / Trade-offs
- Costs can grow quickly with custom metrics, high cardinality and heavy ingestion.
- Alerting needs careful design, or teams drown in noise.
- Best fit is Google Cloud; other environments need agents and extra configuration.
- Query language options and features evolve, so documentation must be checked.
- Dashboards and alerts left unmaintained decay and mislead people.
17Best Practices and Anti-Patterns
Habits of teams who sleep well at night.
Best practices at a glance
Start with the four golden signals
Measure latency, traffic, errors and saturation for every user-facing service before adding anything else.
Define SLOs and alert on burn rate
Agree on reliability targets with the business, and alert on how fast you are spending the error budget.
Make every alert actionable
Each alert should mean something is wrong, should be urgent enough for its channel and should include documentation and links.
Check from the outside
Add uptime and synthetic checks so you see what customers see, not only what servers report.
Keep labels small and meaningful
Avoid high-cardinality labels, and use consistent names for services, environments and teams.
Manage monitoring as code and review it often
Keep dashboards and alerting policies in version control, review them after incidents, and delete what nobody uses.
Anti-patterns to avoid
Problem
Creating an alert for every metric that could possibly go wrong.
Why It’s Harmful
People receive constant notifications, learn to ignore them and miss the one that matters.
Correct Approach
Alert on user-impacting symptoms and error-budget burn, and keep other signals on dashboards.
Problem
Alerts with no description, no owner and no next step.
Why It’s Harmful
The responder wastes precious minutes figuring out what the alert means, delaying the fix.
Correct Approach
Add clear documentation, links to dashboards and logs, severity and an owning team to every alerting policy.
Problem
Adding labels such as user identifiers or request identifiers to custom metrics.
Why It’s Harmful
It creates an explosion of time series, raises costs, slows queries and may expose personal data.
Correct Approach
Use labels with a small number of values, and put per-request detail in logs and traces instead.
Problem
Monitoring only from inside the system, with no external checks.
Why It’s Harmful
Everything may look healthy internally while customers cannot reach the service because of a network, DNS or certificate problem.
Correct Approach
Add uptime checks and synthetic monitors from several locations and alert on agreeing failures.
18Frequently Asked Questions
Not to see metrics from Google Cloud services, which arrive automatically. To see detailed information inside virtual machines, such as memory and disk use, install the Ops Agent. For your own application’s metrics, add instrumentation to your code.
Monitoring focuses on numeric measurements over time and alerting. Logging stores detailed records of individual events. They complement each other, and you can even create metrics from logs.
Yes. Agents, open standards for telemetry and Prometheus-style collection can bring in metrics from other clouds and on-premises systems, though charges and setup effort differ from Google Cloud’s built-in metrics.
It is a rule that defines conditions on your metrics or logs, who should be notified and what documentation to include. When the conditions are met, an incident opens and notifications are sent.
Alert on symptoms that affect users, use sensible durations to avoid brief blips, use burn-rate alerts for SLOs, route low-urgency items to dashboards or email, and review alerts after every incident.
An SLI is a measurement of service quality. An SLO is a target for that measurement over time. The error budget is the amount of failure allowed while still meeting the target.
Yes. Google Cloud Managed Service for Prometheus collects and stores Prometheus-style metrics, and you can query them with the Prometheus query language, without running your own Prometheus servers.
Retention depends on the metric type and may change over time, with detail reduced for older data. Check the current documentation for retention periods, and export metrics elsewhere if you need longer history.
It means a metric has labels with very many distinct values, creating a huge number of separate time series. This increases cost, slows queries and can hit limits. Keep labels few and meaningful.
Use a metrics scope. Choose a scoping project and add other projects to its scope, so dashboards and alerts in that project can cover all of them.
19Summary and Key Takeaways
Cloud Monitoring is the control room for everything you run on Google Cloud and beyond. It collects metrics automatically from Google Cloud services, from agents, from your own code and from Prometheus-style sources, then turns them into dashboards, alerts, uptime checks and service-level objectives. The tool is only as good as the thinking behind it: watch the four golden signals, alert on symptoms that users feel and on error-budget burn, make every alert actionable, check your services from the outside, keep labels small, and protect both your data and your configuration. Combine it with logs, traces and error reporting, and your team will find and fix problems faster, often before customers ever notice.
Key Takeaways
- Managed observability — Cloud Monitoring collects, stores, charts and alerts on metrics with no monitoring servers to run, and Google Cloud services report metrics automatically.
- Many sources, one place — system metrics, Ops Agent data, custom application metrics, log-based metrics and managed Prometheus all feed the same dashboards and alerts.
- Watch the four golden signals — latency, traffic, errors and saturation describe the health of almost any service.
- Alerts must be actionable — alert on user-impacting symptoms, include documentation and links, and avoid noise that causes alert fatigue.
- SLOs make reliability measurable — error budgets and burn-rate alerts balance new features against stability in a way the whole organization understands.
- Check from the outside — uptime checks and synthetic monitors reveal what customers experience, even when internal metrics look fine.
- Control cost and access — keep label cardinality low, collect only useful metrics, use least-privilege roles, and keep personal data out of labels and alerts.