Sign inTry Free

Data Plane Audit Logs

On this page

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 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)

  • New Relic

  • Splunk

Configure Audit Log Forwarding

Contact SingleStore 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 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 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 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:

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:

  • Log rotated: Indicates that a new file was required because rotation conditions were met.

  • Log opened on MemSQL startup: Indicates that a new file was created because the node was either started or restarted.

version

Specifies current audit logging format version.

action

Describes the audit logging state associated with the new file. It can have the following values:

  • Log level initiated at <auditlog-level>: Indicates that audit logging was first enabled at a given level and then the log file was opened.

  • Log level changed to <auditlog-level>: Indicates that logging was already enabled, but the audit logging level was changed.

  • Logging at level <auditlog-level>: Indicates that the system was restarted or the log was rotated, but the audit log level remained the same.

For example:

{
    "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 the SingleStore Helios workspace in the <host>:<port> format.

nodetype

Specifies the type of node. It can have one of the following values:

  • agg: For aggregators.

  • leaf: For leaf nodes.

type

Specifies the login or logout event type. It can have the following values:

  • USER_LOGIN: For login attempts.

  • USER_LOGOUT: For logout event.

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 the workspace. 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:

  • SUCCESS: For a successful login.

  • FAILURE: reason: For a failed login attempt. Optionally, includes a reason that specifies why the login attempt failed.

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:

{
  "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:

  • SUCCESS: Indicates successful execution of the query.

  • FAILURE:<error_code>: Indicates query failure and includes the error returned by the SingleStore engine.

records_affected

Specifies the number of affected or returned records recorded at completion time.

For example:

{
  "id": 123456,
  "record_type": "C",
  "status": "SUCCESS",
  "records_affected": 42
}

Schema for General Entries

Queries are logged as general entries in the following format:

{
    "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 the SingleStore 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.

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.

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In