Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
A service-level indicator (SLI) is a measurement of how well a service performs from the user's point of view. A service-level objective (SLO) is the target value for that SLI over a compliance period, and the error budget starts at 1 minus the SLO and shrinks as performance misses the goal. In Google Cloud, Cloud Monitoring (opens in a new tab) collects infrastructure performance metrics that become the basis for SLIs, and you can create up to 500 SLOs for each service in Cloud Monitoring.
Google Cloud groups services to help you pick the right metrics for SLIs. Request-response services wait for explicitly requested work to complete, data storage and retrieval services store or return data in response to a request, and data-processing services process customer data and return a result or continual feed. Because each group exposes different Cloud Monitoring metrics through automatic integration with Cloud Monitoring and Cloud Logging, the first step in defining an SLI is matching the database or service to its group and its available metrics.
Availability and latency SLIs are ratios built from request-count and response-latency metrics. An availability SLI is the ratio of successful responses to all responses, such as HTTP 2xx responses divided by all HTTP responses per minute. A latency SLI is the ratio of calls below a latency threshold to all calls, such as the share of 2xx responses faster than 300 ms.
These ratios turn raw counts into a measure of good service that can be tracked over time. For known service types such as Cloud Service Mesh, Istio on Google Kubernetes Engine, and App Engine, useful SLIs are already identified from request-count and response-latency metrics. For other services you can define a custom service type and select its performance metrics as the SLI source.
Request-based SLIs measure good service by counting atomic units of work. A request-based SLI counts events such as the number of successful HTTP requests, successful object reads, or database queries that meet a goodness rule. This approach works well when each request matters equally and total volume is high enough to form a stable ratio.
Windows-based SLIs measure good service by counting time periods where performance meets a goodness criterion. A windows-based SLI divides time into small windows and counts how many windows had, for example, response latency below a threshold or error rate below a limit. Choose windows-based SLIs when low traffic, bursty workloads, or long operations make per-request ratios noisy.
Database SLIs build on the four golden signals that describe application health from the user's perspective. The four golden signals provide a complete starting set for selecting latency, availability, and throughput indicators that tie to business requirements:
Latency for database queries often depends on how much data is retrieved and can vary with application workload, so thresholds should reflect realistic query patterns. Saturation and traffic help explain why latency or availability degrades, because a database constrained on memory, CPU, or storage throughput will show slower inserts, updates, deletes, and reads before it shows outright failures.
Data storage and retrieval SLIs focus on availability and latency for services that store and provide data as a response to a request. The three Google Cloud service groups use different metrics as SLI sources:
| Service group | What the service does | Example services |
|---|---|---|
| Request-response services | Customer asks for work and waits for completion | Cloud Endpoints, Cloud Run, Cloud Run functions, App Engine, Google Kubernetes Engine |
| Data storage and retrieval services | Service stores or provides data as the response | Cloud Storage, Bigtable, Spanner, Datastore |
| Data-processing services | Service processes customer data and returns a result or feed | Dataflow, Managed Service for Apache Spark |
For data services, a request-based availability SLI uses a TimeSeriesRatio structure that sets good requests divided by total requests, with filters on metric labels defining good and valid. A request-based latency SLI uses a DistributionCut structure that counts the share of operations below a latency threshold. You choose the filters from available labels to match business needs, such as a single bucket, table, method, or response code.
Cloud Storage (opens in a new tab) is a worldwide object store where availability SLIs come from the gcs_bucket monitored-resource type and the storage.googleapis.com/api/request_count metric type. The method label isolates an operation such as ReadObject for a specific bucket_name, and the response_code label isolates good requests such as OK, so the total filter counts all reads while the good filter counts only reads with OK. Cloud Storage does not provide a latency metric, so if read or write latency matters, instrument the client to collect it and use logs-based metrics, Prometheus, or OpenCensus as the SLI source.
Bigtable (opens in a new tab) is a fully managed NoSQL database for large analytical and operational workloads with high read-and-write throughput at low latency. Bigtable writes metric data to Cloud Monitoring using the bigtable_table monitored-resource type with server/request_count for total requests and server/error_count for failed requests. An availability SLI for Bigtable therefore compares successful operations derived from those counters to total operations, while a latency SLI tracks the share of operations under the chosen threshold for the workload's data size.
Exam tip: Cloud Storage supports an availability SLI from api/request_count with response_code="OK", but it exposes no latency metric — collect latency on the client when latency matters.
Configuring SLOs and alerting policies in Cloud Monitoring (opens in a new tab) is the process of turning database performance metrics into measurable reliability targets and automated warnings. A service-level indicator (SLI) measures performance, a service-level objective (SLO) states the desired performance over time, and an alerting policy watches the error budget implied by the SLO. When the budget is consumed too fast, the policy notifies operators before a Service Level Agreement (SLA) breach occurs.
A service-level indicator (SLI) in Cloud Monitoring is a measurement of how well a service performs, derived from collected metrics. Cloud Monitoring automatically identifies request-count and response-latency metrics for known service types such as Cloud Service Mesh, Istio on Google Kubernetes Engine, and App Engine, and you can define a custom service type with its own metrics for databases. An availability SLI is the ratio of successful responses to all responses, while a latency SLI is the ratio of calls below a latency threshold to all calls.
Google Cloud services expose Monitoring metrics that can be used as SLIs, including data storage and retrieval services such as Cloud Storage, Bigtable, Spanner, and Datastore. Request-response services such as Cloud Run, App Engine, and Google Kubernetes Engine and data-processing services such as Dataflow provide additional metrics for applications that span multiple database technologies. The SLI data flows from the underlying metric into the service monitoring system, which then evaluates it against the SLO.
| SLI Type | What Is Counted | Example |
|---|---|---|
| Request-based SLI | Atomic units of service | Number of successful HTTP requests divided by total requests |
| Windows-based SLI | Time periods where goodness criterion is met | Number of windows with latency below threshold divided by total windows |
A service-level objective (SLO) in Cloud Monitoring is a target value for an SLI measured over a compliance period. The SLO defines what qualifies as good service and is built from three parts:
You can create up to 500 SLOs for each service in Cloud Monitoring. SLOs are typically described as a number of nines, such as 99% or 99.9%, and the highest value you can set is 99.9%. A useful SLO targets less than 100% because the gap between 100% and the goal creates the error budget for risk-taking and change.
An error budget in Cloud Monitoring is the allowed amount of poor performance implied by the SLO, starting at 1 minus the SLO. The budget declines as actual performance misses the goal and triggers an SLO violation when the budget drops below 0. For example, a 95% availability SLO over a calendar week allows 5% failures, while a 75% availability SLO over a rolling 3-day period allows 25% failures within the moving window.
The compliance period controls how the budget moves over time. A calendar period resets at the start of each WEEK or other calendar unit, while a rolling period continuously drops old data points and adds new ones. The remaining budget can rise when a request-based SLO on a calendar period sees increased activity so the extrapolated total traffic grows, and when a period of poor compliance rolls out of a rolling window and is replaced by compliant present time. At any point, a budget at or above 0 means a compliant rolling window, and a budget below 0 means a non-compliant window.
An alerting policy for error budgets in Cloud Monitoring is a rule that watches SLO time series and sends notifications through configured notification channels when burn rate is too high. Changes in SLO compliance can signal the onset of failures, so the policy monitors the SLI-to-SLO comparison to give warning before a problem cascades. SLO data is stored as time series retrieved with a time-series selector in the timeSeries.list filter, and the same selector is used to configure burn-rate alerting programmatically.
The monitoring flow runs from metric collection to operator action:
Teams use the predefined Cloud SQL monitoring dashboard and Query Insights dashboard to find expensive queries and capacity issues. They also create custom dashboards and metrics-based policies such as an alert when available disk space falls below 20%.
Exam tip: Only Cloud SQL instances configured for high availability with at least one dedicated CPU are covered by the SLA; shared-core and single-zone instances are not covered.
Database SLA coverage for Cloud SQL excludes outages caused by factors outside of Google's reasonable control, including user-controlled misconfigurations. If an instance becomes unhealthy while out of compliance with operational limits, the downtime does not count against the Cloud SQL SLA. You are responsible for monitoring the instance to ensure it is properly sized for its load.
Excluded configurations fall into general requirements, database flag values, and resource constraints. General requirements mean overload from workload or long recovery time removes coverage. Risky flag settings such as autovacuum and max_wal_size can compromise stability or durability. Resource constraints that remove coverage are:
Analyzing performance trends and compliance means comparing historical service-level indicator (SLI) measurements against service-level objective (SLO) targets over time. An SLI is a measurement of performance, an SLO is a statement of desired performance for that SLI over a compliance period, and the error budget starts at 1 minus the SLO and declines as performance misses the goal. This analysis shows whether a database is meeting its contractual service-level agreement (SLA), reveals gradual degradation before users are affected, and provides the evidence needed to explain why an SLO was missed.
Cloud Monitoring (opens in a new tab) is the Google Cloud service that collects, stores, and visualizes infrastructure and application metrics for databases and the resources they use. Cloud SQL uses built-in memory agents to collect query telemetry with low performance impact, and that telemetry flows into Cloud Monitoring where it can be viewed in the predefined Cloud SQL monitoring dashboard, the instance Overview page, and the Query Insights dashboard. Teams can also create custom dashboards tailored to workload indicators, compare metrics across selected instances, and set alert policies for timely notification. Collected over weeks under different load conditions, this telemetry establishes a baseline that makes abnormal latency, saturation, or error rates visible as trends.
Monitor the four golden signals for database applications to cover both performance and capacity:
SLO compliance is the comparison of an SLI value to its performance goal during a defined compliance period. An SLO is built from an SLI, a performance goal, and a compliance period such as a rolling 30-day period or a calendar week, and Cloud Monitoring supports up to 500 SLOs for each service. Common database-related examples include 99.9% of API calls must return a successful response, 95th percentile inference latency must be below 300 ms, and latency can exceed 300 ms in only 5 percent of requests over a rolling 30-day period. Because a useful SLO targets less than 100%, the small allowed miss rate becomes the error budget that the team can spend on changes, releases, or unexpected load.
Standard SLIs for request-driven services are derived as ratios from request-count and response-latency metrics. An availability SLI is the ratio of successful responses to all responses, while a latency SLI is the ratio of calls below a latency threshold to all calls. When compliance drops, the error budget burns faster, and changes in SLO compliance can signal the onset of failures before they cascade. Alerting on error-budget burn rate therefore gives earlier warning than alerting on a single outage.
Request-based and windows-based SLOs are two ways to define what counts as good service for compliance and trend analysis. Request-based SLOs count atomic units of service, while windows-based SLOs count time periods during which service meets a goodness criterion.
| SLO type | What is counted | Good-service example |
|---|---|---|
| Request-based SLI | Individual successful requests out of all requests | Number of successful HTTP requests divided by total requests |
| Windows-based SLI | Time windows where performance meets a threshold | Number of windows with response latency below a threshold divided by total windows |
Exam tip: A request-based SLO fails when too many requests are bad, while a windows-based SLO fails when too many time windows are bad, even if total request counts look similar.
Root cause analysis of an SLO miss correlates the SLI trend with logs, traces, and code-level profiles to find which layer caused the miss. Cloud Logging (opens in a new tab) collects detailed logs from applications and database infrastructure, and those logs provide the event and error context around the time the SLI degraded. Cloud Trace collects latency data and shows how requests propagate across distributed microservices and inference pipelines, so teams can compare latency distributions over time and pinpoint which hop introduced delay. Cloud Profiler identifies performance bottlenecks inside application function blocks, which helps explain whether high latency came from inefficient code, constrained CPU or memory, or distant writer and reader locations adding network latency.
Application context strengthens this analysis when SQL statements carry tags from the application. Sqlcommenter, an OpenTelemetry library, instruments object-relational mappers (ORMs) to augment SQL statements with tags and propagate trace context to the database. With those tags, database performance can be correlated back to specific application code, which makes it easier to separate an application issue from an underlying cloud infrastructure issue and to fix the true cause of repeated budget burn.
storage.googleapis.com/api/request_count for availability SLIs but exposes no latency metric, so client-side instrumentation is required for latency SLIs.Last updated