This page describes how to use Extended Events (XEvents) on your instances.
Cloud SQL supports using XEvents for monitoring, identifying, and troubleshooting the performance of your database. To do this, you create XEvent sessions and read XEvent output files. You can read the XEvent output files either on the instance or by downloading the XEvent files from a Cloud Storage bucket.
Before you begin
If you want to upload your XEvent files to a Cloud Storage bucket, then create a bucket in your Google Cloud account.
Best practices
- To avoid transferring large files across regions, we recommend that you do one of the following:
- Create multi-regional Cloud Storage buckets
- Set up the destination Cloud Storage bucket in the same region as the instance
- Before using XEvents, enable automatic storage increases. XEvent output files, depending on their total size and retention intervals, might need significant disk space.
- To avoid retaining too many XEvent files for a long time, set up a data retention policy for your Cloud Storage bucket.
- If you create an XEvent session by using the SSMS UI, but some boxes for input values don't appear, then resize the Create XEvent Session window.
How to create XEvent sessions
XEvents is enabled on your instances automatically.
Use the CREATE EVENT SESSION
command to define new XEvent sessions. You also can use the user interface of
SQL Server Management Studio (SSMS) to create XEvent sessions.
Cloud SQL enforces the following parameters for all XEvent sessions:
Parameter | Description | Allowed values |
FILENAME
|
Specifies the filename and path for storing XEvents Session data. | Any path that starts with /var/opt/mssql/xevents/
|
MAX_FILE_SIZE
|
Specifies the maximum size of each output file before a new file is created. | A minimum of 10 MB
A maximum of 1 GB |
MAX_MEMORY
|
Specifies the maximum amount of memory to allocate to the session for event buffering. | A minimum of 4 MB
A maximum of 8 MB |
MAX_DISPATCH_LATENCY
|
Specifies the maximum time (in seconds) that events can remain in the event dispatch queue before being sent to the target. | A minimum of 1 sec
A maximum of 30 sec |
MAX_EVENT_SIZE
|
Sets the maximum size of each event, in bytes. | A minimum of 4 MB
A maximum of 8 MB |
XEvent session configuration parameters
You can configure XEvent sessions by using the following parameters as custom flags:
Parameter | Description |
cloud sql xe bucket name
|
Specify the Cloud Storage bucket to which you want to upload the XEvent session output. If this isn't specified, then Cloud SQL doesn't upload the XEvent session output data to Cloud Storage. |
cloud sql xe output total disk size (mb)
|
Specify the amount of disk space to be reserved for the output of all XEvent sessions. If this isn't specified, then Cloud SQL uses a default disk space of 512 MB. If the XEvent output files use disk space more than the value of
cloud sql xe output total disk size (mb) , then Cloud SQL removes these files from the disk.
|
cloud sql xe file retention (mins)
|
Specify the retention time on the instance in minutes for files generated by the file targets of XEvent sessions. If this isn't specified, then Cloud SQL uses a default value of 7 days. |
cloud sql xe upload interval (mins)
|
Specify the upload interval for XEvent files being uploaded to Cloud Storage. If this isn't specified, then Cloud SQL uses a default value of 10 minutes. |
For more information about setting these flags, see Configure database flags.
How to read XEvent session output files
You can read XEvent session output files from either a Cloud SQL instance or a Cloud Storage bucket.
Read XEvent output files from an instance
To retrieve the data from an XEvent file that an XEvent session creates, use the sys.fn_xe_file_target_read_file
function.
Here's an example:
SELECT * FROM sys.fn_xe_file_target_read_file('/var/opt/mssql/xevents/filename*, NULL, NULL, NULL);
Read XEvent output files from a bucket
To read XEvent output files from a Cloud Storage bucket, download the files from the bucket to a SQL Server instance. You can download from one of the following instances:
- A Compute Engine Windows instance
- A Compute Engine Linux instance
- Another type of instance that runs SQL Server
Then, transfer the XEvent output files from the bucket to a location accessible to
that instance, such as its local disk. Next, to return information from the XEvent
output file, run the sys.fn_xe_file_target_read_file
function with an account that has the
VIEW SERVER STATE
permission on the server. For more information about permissions, see
Permissions.
Monitor XEvent sessions
You can monitor XEvent session-related activities through the xevents.log
file for the following operations:
- The XEvent output files removed from the disk, which were not uploaded to Cloud Storage and were occupying disk space higher than the value associated with
cloud sql xe output total disk size (mb)
. - The XEvent output files removed from the disk, which were not uploaded to Cloud Storage and are older than the value associated with
cloud sql xe file retention
.
Considerations for read replicas
This section contains information about XEvent sessions for new and existing read replicas.
For new read replicas
- All XEvent session configuration parameters that are passed through database flags on the original instance are available on the newly created read replica.
- All XEvent sessions present on the original instance when the read replicas are created are available on the read replica. Note that XEvent sessions on the read replica need to be started manually, unless they're configured to start automatically. For more information, see How to create XEvent sessions.
- If you clone a primary instance, then any database flags that appear on the primary instance are propagated to the cloned instance. Also, you must grant permissions to the service account of the cloned instance to access the Cloud Storage bucket again.
For existing read replicas
- XEvent session configuration parameters passed through database flags to the original instance aren't propagated to read replicas.
- XEvent sessions created on the original instance aren't propagated to read replicas.