Sign inTry Free

Data Plane Audit Logs

On this page

SingleStore logs all 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 third-party tools. Here's a list of some common supported third-party tools/integrations:

  • Amazon CloudWatch

  • Amazon S3

  • Azure Blob

  • Azure Log Analytics

  • Datadog

  • Kafka

  • Loki

  • New Relic

  • Slack

  • Splunk

Refer to Outputs for a list of all the supported integrations.

Configure Audit Log Forwarding

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

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

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

{
    "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: August 25, 2025

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