# Data Plane Audit Logs SingleStore logs database activities and writes the generated logs to an external location. You can forward Data Plane audit logs and access them through third-party audit tools such as Amazon CloudWatch, Datadog, and others. Contact [SingleStore Support](https://singlestore.com/support) to set up audit log forwarding with a supported third-party tool. ## Forwarding Data Plane Audit Logs > **⚠️ Warning**: Including customer credentials or other sensitive or confidential information through Zendesk or email puts both you, our customer, and SingleStore at risk, as the subject credentials may be exposed to unauthorized parties.Please use a secure secrets management solution when sharing credentials via any means with SingleStore or any other third party. SingleStore Helios supports forwarding Data Plane audit logs to the following third-party tools/integrations: * Amazon CloudWatch * Amazon S3 * Azure Blob * Azure Log Analytics * Datadog * Google Cloud Logging (via [Stackdriver](https://docs.fluentbit.io/manual/data-pipeline/outputs/stackdriver)) * New Relic * Splunk ## Configure Audit Log Forwarding Contact [SingleStore Support](https://singlestore.com/support) and provide the requested information to configure audit log forwarding, including the audit logging level. ## Requirements Here are the requirements for some common supported third-party integrations: ## Amazon CloudWatch * Your AWS access key ID and secret access key. * `log_group_name`: The name of the CloudWatch Log Group to send records to. * `log_stream_name`: The name of the CloudWatch Log Stream to send records to. * `region`: The AWS region. Refer to [Amazon CloudWatch](https://docs.fluentbit.io/manual/pipeline/outputs/cloudwatch) for more information. ## Amazon S3 * Your AWS access key ID and secret access key. * `bucket`: The name of your S3 bucket. * `region`: The AWS region of your S3 bucket. Refer to [Amazon S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3) for more information. ## Datadog * `apikey`: Your Datadog API key. * Host: The Datadog server to send logs to. * TLS: Enable/disable end-to-end security communications protocol. Refer to [Datadog](https://docs.fluentbit.io/manual/pipeline/outputs/datadog) for more information. ## Access Data Plane Audit Logs You can view the Data Plane audit logs once they are configured and forwarded to the specified third-party tool. Here's a sample audit log from a log group configured in Amazon CloudWatch: ![](https://images.contentstack.io/v3/assets/bltac01ee6daa3a1e14/blt61f21fa5acbbbe2d/6a57ad3a6d9e2e6bcb32860e/image1-KtA2VY.png) ## Audit Log Formats Data Plane audit logs are parsed and represented as JSON-formatted records in third-party tools. Each forwarded audit log record follows a schema specific to its audit log type. The following sections describe the corresponding record schema for each audit log type. ## First Line Schema The first line of a log file has a unique schema that describes the event or action that resulted in the creation of a new log file. It has the following schema: | **Field** | **Description** | | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id` | Represents the unique identifier for the log entry within the scope of a single log file. This value is always`0`for the first line in a log file. | | `time` | Specifies the local system time when the file was opened or rotated, using the same timestamp formatting as other audit log records. | | `origin` | Describes the reason or event that caused the creation of the log file. It can have the following values: | | `version` | Specifies current audit logging format version. | | `action` | Describes the audit logging state associated with the new file. It can have the following values: | For example: ```json { "id": "0", "time": "2026-06-21 18:49:25.888", "origin": "Log opened on MemSQL startup", "version": "Format version 4", "action": "Logging at level ADMIN-ONLY-INCLUDING-PARSE-FAILS" } ``` ## Login and Logout Schema Each login attempt and logout event is logged using the following schema: > **📝 Note**: The logout event log schema does not contain the `authtype` and `status` fields. | **Field** | **Description** | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id` | Represents the unique identifier for the log entry within the scope of a single log file. | | `time` | Specifies the node’s local system time when an operation was executed. | | `timezone` | Specifies the local time zone when the event was logged. | | `endpoint` | Specifies the hostname or IP address of theSingleStore Heliosworkspacein the`:`format. | | `nodetype` | Specifies the type of node. It can have one of the following values: | | `type` | Specifies the login or logout event type. It can have the following values: | | `threadid` | Specifies the ID of the thread that is running the statement. | | `username` | Specifies the username of the user performing the login or logout. | | `remotehost` | Specifies the hostname or IP address that the client is using to connect to theworkspace. This value is detected by the server and not reported by the client. | | `usergrant` | Specifies the`'username'@'hostname'`specification from the`GRANT`that defines the user being authenticated or logged out. | | `authtype`(Login attempts only) | Specifies the authentication method for the user, for example,`password`,`PAM`,`Kerberos`, etc. | | `status`(Login attempts only) | Indicates the success or failure of the login attempt. It can have the following values: | | `tlscipher` | Specifies the TLS encryption algorithm used during the session. | | `appname` | Specifies the client application name retrieved from the session's`program_name`attribute, if set. | | `osuser` | Specifies the client OS user retrieved from the session's`_os_user`attribute, if set. | For example: ```json { "id": "363750385", "time": "2026-08-11 18:53:18.150,UTC", "endpoint": "c770dd909a9c:3306", "nodetype": "agg", "type": "USER_LOGIN", "threadid": "100000", "username": "pac", "remotehost": "192.168.0.1", "usergrant": "pac@%", "authtype": "mysql_native_password", "status": "SUCCESS", "tlscipher": "ECDHE-RSA-AES256-GCM-SHA384", "appname": "mysql", "osuser": "osuser" } ``` ## Completion Record Schema for Query Execution Completion records capture the final outcome of a query after execution. They are emitted as a separate record, associated with the original query record by `id`. Completion records have the following schema: | Field | Description | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id` | Specifies the audit-log record ID of the original query record, used to correlate the command completion log to the original query. | | `record_type` | A record-type marker which indicates a query record. Its value is always`C`for a completion record. | | `status` | Specifies the final status of the query. It can have the following values: | | `records_affected` | Specifies the number of affected or returned records recorded at completion time. | For example: ```JSON { "id": 123456, "record_type": "C", "status": "SUCCESS", "records_affected": 42 } ``` ## Schema for General Entries Queries are logged as general entries in the following format: ```json { "id": "28151", "endpoint": "node-37775b0a-6feb-4b61-98a7-master-0:3306", "nodetype": "agg", "aggregatorid": "1", "threadid": "99996", "username": "root", "database": "[unknown]", "queryhash": "3505599087362974304", "query": "GRANT CREATE LINK\\,DROP LINK\\,SHOW LINK ON *.* TO 'admin'" } ``` | **Field** | **Description** | | -------------- | ------------------------------------------------------------------------------------------------------ | | `id` | Represents the unique identifier for the log entry within the scope of a single log file. | | `endpoint` | Specifies the hostname or IP address of theSingleStore Heliosworkspace. | | `nodetype` | Specifies the type of node. It can have one of the following values:`agg`(aggregator) and`leaf`(leaf). | | `aggregatorid` | Specifies the ID of the aggregator that is running the query. | | `threadid` | Specifies the ID of the thread that is running the query. | | `username` | Specifies the username that is running the query. | | `database` | Specifies the database name. | | `queryhash` | Specifies the unique hash of the query signature or the query text. | | `query` | Specifies the query signature or the query text. | ## Audit Logging Levels There are 11 logging levels that are organized into the following categories, each with increasing levels of verbosity: * Log only valid statements and queries: * `LOGINS-ONLY` * `ADMIN-ONLY` * `WRITES-ONLY` * `ALL-QUERIES` * `ALL-QUERIES-PLAINTEXT` * `ALL-RESULTS` * Log valid and invalid statements and queries: * `ADMIN-ONLY-INCLUDING-PARSE-FAILS` (default) * `WRITES-ONLY-INCLUDING-PARSE-FAILS` * `ALL-QUERIES-INCLUDING-PARSE-FAILS` * `ALL-QUERIES-PLAINTEXT-INCLUDING-PARSE-FAILS` * `ALL-RESULTS-INCLUDING-PARSE-FAILS` A valid statement or query is one that can be successfully parsed by SingleStore. Invalid statements or queries include those with misspellings or improper syntax. > **⚠️ Warning**: User credentials and PII information contained in all valid statements and queries is obfuscated in audit logs. When invalid statements cannot be parsed, the literal query text is included in the log entry. This text may contain sensitive information. For example, if a user attempts to connect to the database with an invalid statement that contains their username and password, these values will be logged in plain text. You can optionally filter logs for the root user only and exclude the audit of information schema queries. To change the current audit logging level contact [SingleStore Support](https://support.singlestore.com/). ## LOGINS-ONLY The `LOGINS-ONLY` level logs the successful and failed login attempts into the database. These login activities coexist with audit data from existing levels, but the information about logins follows a different format than database activities. The `LOGINS-ONLY` level does not include the `PARSE-FAILS` option for logins, because this option is reserved for queries. The `LOGINS-ONLY` level is the lowest level of the audit log, i.e. every other audit level is inclusive of the login information. ## ADMIN-ONLY and ADMIN-ONLY-INCLUDING-PARSE-FAILS The `ADMIN-ONLY` level is inclusive of the `LOGINS-ONLY` level logs, and it also logs DDL operations such as `CREATE`, `DROP`, `ALTER`, etc. Additionally, if a query contains passwords (such as `SET PASSWORD`), the password’s value will be omitted from the log. The `ADMIN-ONLY-INCLUDING-PARSE-FAILS` level is inclusive of `ADMIN-ONLY` but also logs invalid statements that fail to parse. These invalid statements may include sensitive information that would normally be obfuscated in a log entry. ## WRITES-ONLY and WRITES-ONLY-INCLUDING-PARSE-FAILS The `WRITES-ONLY` level is inclusive of `ADMIN-ONLY` but also logs DML operations such as `INSERT`, `DELETE`, `UPDATE`, with one exception: `SELECT` queries are not logged. The `WRITES-ONLY-INCLUDING-PARSE-FAILS` level is inclusive of `WRITES-ONLY` but also logs invalid statements that fail to parse. These invalid statements may include sensitive information that would normally be obfuscated in a log entry. ## ALL-QUERIES and ALL-QUERIES-INCLUDING-PARSE-FAILS The `ALL-QUERIES` level is inclusive of `WRITES-ONLY` but also logs read operations such as `SELECT` statements. The `ALL-QUERIES-INCLUDING-PARSE-FAILS` level is inclusive of `ALL-QUERIES` but also logs invalid statements that fail to parse. These invalid statements may include sensitive information that would normally be obfuscated in a log entry. ## ALL-QUERIES-PLAINTEXT and ALL-QUERIES-PLAINTEXT-INCLUDING-PARSE-FAILS The `ALL-QUERIES-PLAINTEXT` level is inclusive of `ALL-QUERIES` but also logs the entire literal query, not just the parameterized version without literal strings and numbers. The `ALL-QUERIES-PLAINTEXT-INCLUDING-PARSE-FAILS` level is inclusive of `ALL-QUERIES-PLAINTEXT` but also logs invalid statements that fail to parse. These invalid statements may include sensitive information that would normally be obfuscated in a log entry. ## ALL-RESULTS and ALL-RESULTS-INCLUDING-PARSE-FAILS The `ALL-RESULTS` level is inclusive of `ALL-QUERIES-PLAINTEXT` but also logs the database’s responses. This is the most verbose logging level available, and accordingly it produces a large number of log entries. When this level is selected, the entry ID for a query is shared with the results entries. The `ALL-RESULTS-INCLUDING-PARSE-FAILS` level is inclusive of `ALL-RESULTS` but also logs invalid statements that fail to parse. These invalid statements may include sensitive information that would normally be obfuscated in a log entry. *** Modified at: July 3, 2026 Source: [/cloud/security/audit-logging/data-plane-audit-logs/](https://docs.singlestore.com/cloud/security/audit-logging/data-plane-audit-logs/) (An index of the documentation is available at /llms.txt)