This page describes how to monitor a Cloud SQL instance.
Cloud SQL offers two ways to monitor an instance:
- In the Google Cloud console
- In Cloud Monitoring
Compare metrics from multiple instances
- Go to the Cloud SQL Instances page in the Google Cloud console.
- From the SQL instances overview page, select up to 5 instances you want to compare by checking the checkbox to the left of the instance name.
- In the Info Panel on the right, select the Monitoring tab.
Select the metric you want to compare from the metric dropdown.
You can see the exact data for a specific time by hovering over the graph.
Cloud SQL instance monitoring in the console
Cloud SQL provides some performance monitoring in the INFO PANEL on the SQL instances overview page, and also in the instance details page for a selected instance. A drop-down menu in those charts presents the following options:
- CPU utilization
- Storage usage
- Memory usage
- Read/write operations
- Active connections
- Ingress/Egress bytes
Additionally, a read replica offers the option
In the Google Cloud console, go to the Cloud SQL Instances page.
- To open the Overview page of an instance, click the instance name.
The metrics chart is prominent on the top of the page.
The usage charts can help you respond proactively as your application needs change. From these metrics, you can gain insight into issues of throughput and latency as well as instance usage costs.
|Storage usage (GB)||
You can use the storage usage metric to help you understand your storage costs. For more information about storage usage charges, see Storage and Networking Pricing.
Point-in-time recovery (PITR) uses write-ahead log (WAL) archiving. These logs update regularly, and use storage space. Write-ahead logs are automatically deleted with their associated automatic backup, which generally happens after about 7 days.
If the size of your write-ahead logs are causing an issue for your instance, you can increase your storage size, but the write-ahead log size increase in disk usage might be temporary. To avoid unexpected storage issues, we recommend enabling automatic storage increases when using PITR.
To delete the logs and recover storage, you can disable point-in-time recovery. Note, however, that decreasing the storage used does not shrink the size of the storage provisioned for the instance.
Temp data is included in the storage usage metric. Temp data is removed as part of maintenance and is allowed to increase beyond user-defined capacity limits to avoid a disk full event, at no charge to the user.
A newly created database uses about 100 MB for system tables and files.
You can use this metric to monitor whether your instance has sufficient CPU for your application's needs. If this value is running too high, you can increase the size of your machine type to give your instance more CPU capability.
The amount of memory being used by your instance.
The Number of Reads metric is the number of read operations served from disk that do not come from cache. You can use this metric to help you understand whether your instance is correctly sized for your environment. If needed, you can move to a larger machine type to serve more requests from cache and reduce latency.
The Number of Writes metric is the number of write operations to disk. Write activity is generated even if your application is not active, because Cloud SQL instances write to a system table approximately every second (except for replicas).
|Active connections||Number of open connections to the Cloud SQL instance.|
|Ingress/Egress bytes (bytes/sec)||The amount of network traffic coming into or leaving the instance.|
The number of transactions that have been committed or rolled back on the
instance. These values correspond to the
|Instance state||The state of your instance is indicated by the status icon, next to the
instance name. You can also monitor the
Figure 1 points out the different parts of a usage chart.
Callout 1: The metric data displayed in the chart.
Callout 2: The time range for which to view the metric data.
Callout 3: The value of the metric at the cursor.
Callout 4: The data cursor. Use the cursor to find the value of a metric at a specific time.
Cloud Monitoring includes a default Cloud SQL monitoring dashboard, which includes the most commonly used metrics. You can use this dashboard to monitor the general health of your primary and replica instances. You can also create your own custom dashboards to display data that is of interest to you.
Cloud Monitoring also includes many other metrics on its Metrics Explorer page:
In the Google Cloud console, go to the Monitoring page.
For Resource Type select Cloud SQL Database.
You can also create an alert for when a metric exceeds a given value. See more information on how to use Cloud Monitoring.
Set a Monitoring alert for memory usage
You can set an alert in Monitoring to send notifications when the memory usage metric exceeds 80%.
To create an alert for the memory usage metric:
In the Google Cloud console, select Monitoring, or use the following button:
Select Alerting > Create Policy.
Add a condition for the memory usage threshold:
- Click Add Condition.
- In the Resource section, select the Cloud SQL Database resource type.
- For the Metric, select "Memory Usage".
- In the Configuration section, choose Any time the series violates.
- Set Condition to Is above.
- Set Threshold to
0.8, which represents 80% of your system memory.
- Optionally, use the Filter field to set an alert for a single instance ID. If you choose not to filter to a specific instance, the alert will send a notification any time a Cloud SQL instance in your project has memory usage exceeding 80%.
- Click the Add button.
Click the Next button.
Click Who should be notified?
Fill in the notification form.
Click the Next button.
Click What are the steps to fix the issue?
Add a name for the alert and any additional message you want to include in the notification.
Click the Save button.
The configured notification recipients are notified anytime the memory usage exceeds 80%.