# 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. ## 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/6a354935dd7075d44cc8f5bd/image1-NNVSWe.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 can have one of the following schema: ## Schema for First Line The first line of a log file describes the reason/action that resulted in the creation of a new log file: ```json { "id": "0", "time": "2022-06-21 18:49:25.888", "origin": "Log opened on MemSQL startup", "version": "Format version 2", "action": "Logging at level ADMIN-ONLY-INCLUDING-PARSE-FAILS" } ``` | **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 timestamp when the action/event occurred. | | `origin` | Specifies the reason/event that resulted in the creation of the log file. | | `version` | Specifies the log format version. | | `action` | Specifies the reason/event that opened or rotated the log file. | ## Schema for Login Attempt Logs Each login attempt is logged in the following format: ```json { "id": "28179", "endpoint": "node-37775b0a-6feb-4b61-98a7-master-0:3306", "nodetype": "agg", "threadid": "99996", "username": "root", "remotehost": "localhost", "usergrant": "root@%", "authtype": "password", "status": "SUCCESS" } ``` | **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). | | `threadid` | Specifies the ID of the thread that is running the statement. | | `username` | Specifies the username that is trying to log in. | | `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` | The`'username'@'hostname'`specification that defines the user for whom authentication is being attempted. | | `authtype` | Specifies the authentication method for the user, for example`password`,`PAM`,`Kerberos`, etc. | | `status` | Indicates the`SUCCESS`or`FAILURE`of the login query. | ## 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: January 12, 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)