Professional Cloud Database Engineer

Define and Select Service Level Indicators (SLIs)

Service Level Indicators (SLIs) are the specific numbers you use to measure how well your database is performing. They are the foundation for setting performance goals. The most important SLIs for databases usually track three things: Availability (is the database up and responding?), Latency (how fast does it respond?), and Throughput (how much work can it handle?). Choosing the right SLIs makes sure you are measuring what truly matters for your business.

Different Google Cloud database services have their own key metrics to watch. For Cloud SQL, you might monitor CPU utilization and disk space. For Spanner, transaction latency is critical, while for Bigtable, you would track cluster load. These specific signals help you spot problems like running out of resources before they cause an outage.

Google Cloud provides tools like Cloud Monitoring and Cloud Logging to automatically collect these metrics. You can also use Prometheus to gather custom metrics from your applications. This automated data collection helps you establish a normal performance baseline. Effective SLIs also feed into an error budget, which is the small amount of poor performance you can tolerate. If your SLIs show the error budget is being used up too fast, your team knows to focus on stability instead of new features.

Configure SLOs and Alerting Policies

Service Level Objectives (SLOs) are the specific, numerical targets you set for your SLIs over a period of time, like aiming for 99.9% availability over a month. An error budget is directly calculated from your SLO; it is the small amount of failure you are allowed (e.g., 0.1% downtime for a 99.9% SLO). Managing this budget lets teams balance launching new features with keeping the system stable. If the budget runs out, work should shift to improving reliability.

You need to set up alerting policies in Cloud Monitoring to warn you when you are burning through your error budget too quickly. These policies use a lookback period to calculate the current burn rate. You connect these alerts to notification channels like email, Slack, or PagerDuty so the right people get notified about potential problems.

It's important to know that a database's official Service Level Agreement (SLA) from Google often has specific rules. For example, single-zone Cloud SQL instances or machines with shared cores might not be covered by the uptime guarantee. To stay eligible for SLA coverage, you must monitor for critical resource limits. Key constraints to watch include CPU overload, storage running full (if auto-increase is off), and high memory usage, as these can all cause performance issues that break your SLOs.

Analyze Performance Trends and Compliance

To prevent problems, you must regularly analyze historical performance data. Using Cloud Monitoring dashboards, you can identify trends, like a gradual increase in latency, which allows for proactive database tuning and capacity planning before your SLOs are missed. Tools like Cloud Logging and Cloud Trace provide the detailed logs and request traces needed to understand system behavior.

When a SLO miss does occur, you perform a root cause analysis to understand why. This involves examining the related metrics and logs to find the underlying fault. Tracking the burn rate of your error budget during this analysis helps you decide if you need to halt changes and focus entirely on restoring stability.

Validating SLA compliance requires generating reports from your monitoring data to prove you met the contracted service levels. For services like Cloud SQL, compliance often depends on proper configuration, such as using the High Availability option and ensuring resources like CPU, memory, and storage are adequately provisioned and not consistently maxed out. Monitoring these resource constraints is essential for both performance and contractual adherence.