# Audit Log File Format

> **⚠️ Warning**: As of the time of this publication, audit logging features are made available and licensed only as part of the SingleStore Enterprise edition.

Audit logs are written to the directory specified by the `auditlogsdir` variable. See [Configure Audit Logging](https://docs.singlestore.com/db/v9.1/security/audit-logging/configuring-audit-logging.md) for details on how to set this variable.

Each node in a cluster will create its own files in the destination directory using the following naming convention:

```
auditlog_<hostname>-<port>_<year>-<month>-<day>_<hour>-<minute>-<second>.log

```

For example, consider the following log file name:

```
auditlog_myVmbox-3306_2016-08-30_06-38-46.log

```

If a log file’s rotation size is very small, an auto-incrementing integer may be appended to the end of the log file. For example:

```
auditlog_myVmbox-3306_2016-08-30_06-38-46_1.log
auditlog_myVmbox-3306_2016-08-30_06-38-46_2.log
auditlog_myVmbox-3306_2016-08-30_06-38-46_3.log

```

Data within the log file is written in comma-separated values (CSV) format. Log files are updated immediately as queries are executed; they are not cached locally and then eventually written to the destination directory.

The `auditlog_disk_sync` engine variable controls whether the audit is written to disk synchronously. This can be set to ON/OFF to specify synchronous/asynchronous writes to disk. Note that if it is set to ON (synchronous writes), there can be an impact to performance as log entries must be flushed to disk before the query executes.

## Log Entry File Schemas

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:

```CSV
<id>,<time>,INFO: <origin>. <version>. <action>
```

| **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:<ul> <li><strong>Log rotated</strong>: Indicates that a new file was required because rotation conditions were met. When a log is rotated, either the <code>auditlog_rotation_size</code> or the <code>auditlog_rotation_time</code> engine variable's conditions are met.</li> <li><strong>Log opened on MemSQL startup</strong>: Indicates that a new file was created because the node was either started or restarted.</li> </ul>                                                                                |
| `version` | Specifies current audit logging format version.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| `action`  | Describes the audit logging state associated with the new file. It can have the following values:<ul> <li><strong>Log level initiated at &#x3C;auditlog-level></strong>: Indicates that audit logging was first enabled at a given level and then the log file was opened.</li> <li><strong>Log level changed to &#x3C;auditlog-level></strong>: Indicates that logging was already enabled, but the audit logging level was changed.</li> <li><strong>Logging at level &#x3C;auditlog-level></strong>: Indicates that the system was restarted or the log was rotated, but the audit log level remained the same.</li> </ul> |

For example:

```CSV
0,2026-06-21 18:49:25.888,INFO: Log opened on MemSQL startup. Format version 4. 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.

```CSV
<id>,<time>,<timezone>,<endpoint>,<nodetype:agg|leaf>,<type:USER_LOGIN|USER_LOGOUT>,<threadid>,<username>,<remotehost>,<usergrant:grant_user@grant_host>,<authtype>,<status:SUCCESS|FAILURE: reason>,<tlscipher>,<appname>,<osuser>
```

| **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 theSingleStoreclusterin the`<host>:<port>`format.                                                                                                                                                                                                               |
| `nodetype`                      | Specifies the type of node. It can have one of the following values:<ul> <li><code>agg</code>: For aggregators.</li> <li><code>leaf</code>: For leaf nodes.</li> </ul>                                                                                                                                  |
| `type`                          | Specifies the login or logout event type. It can have the following values:<ul> <li><code>USER_LOGIN</code>: For login attempts.</li> <li><code>USER_LOGOUT</code>: For logout event.</li> </ul>                                                                                                        |
| `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 thecluster. 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:<ul> <li><code>SUCCESS</code>: For a successful login.</li> <li><code>FAILURE: reason</code>: For a failed login attempt. Optionally, includes a reason that specifies why the login attempt failed.</li> </ul> |
| `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:

```CSV
363750385,2026-08-11 18:53:18.150,UTC,c770dd909a9c:3306,agg,USER_LOGIN,100000,s2user,192.168.0.1,s2user@%,mysql_native_password,SUCCESS,ECDHE-RSA-AES256-GCM-SHA384,mysql,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:

```CSV
<id>,<record_type>,<completion_status:SUCCESS|FAILURE:error_code>,<records_affected>
```

| 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:<ul> <li><code>SUCCESS</code>: Indicates successful execution of the query.</li> <li><code>FAILURE:&#x3C;error_code></code>: Indicates query failure and includes the error returned by the SingleStore engine.</li> </ul> |
| `records_affected` | Specifies the number of affected or returned records recorded at completion time.                                                                                                                                                                                                                    |

For example:

```CSV
123456,C,SUCCESS,42
```

## Schema for ALL-RESULTS Database Responses

If your node is configured to use the `ALL-RESULTS` logging mode, the database’s responses are logged uniquely from other entries. Consider the following example result entry for the `SHOW VARIABLES LIKE '%master_aggregator%'` query:

```CSV
237,R,master aggregator

```

The log entry above demonstrates the following schema:

```CSV
<parent-query-log-entry-id>,R,<data>

```

Query results share the same entry ID as the query itself. In the example above, the log entry for the query also has an `<entry-id>` value of `237`. The comma-separated `R` denotes that the log entry only contains query result data. Lastly, the returned data is included as the last value in the entry.

## General Log Entry Schema

All entries in a log file adhere to a predefined schema. To help understand the log file schema, consider the following example entry for the statement `UPDATE t SET a = 0 WHERE a = 1`:

```CSV
237,2016-08-25 11:29:09,PDT,localhost:3306,agg,1,99999,root,db,temp_1_14_16,9959767090931131257,UPDATE t SET a = 0 WHERE a = 1

```

The log entry above demonstrates the following schema:

```CSV
<log-entry-id>,<timestamp>,<time-zone>,<hostname>:<port>,<node-type>,<aggregator-id>,<thread-id>,<username>,<database-name>,<correlation-id>,<query-hash>,<query>

```

Therefore, each of the 12 values can be mapped in the following way:

| Example Value                    | Definition       |
| -------------------------------- | ---------------- |
| `237`                            | `log-entry-id`   |
| `2016-08-25 11:29:09.875`        | `timestamp`      |
| `PDT`                            | `time-zone`      |
| `localhost:3306`                 | `hostname:port`  |
| `agg`                            | `node-type`      |
| `1`                              | `aggregator-id`  |
| `99999`                          | `thread-id`      |
| `root`                           | `username`       |
| `db`                             | `database-name`  |
| `temp_1_14_16`                   | `correlation-id` |
| `9959767090931131257`            | `query-hash`     |
| `UPDATE t SET a = 0 WHERE a = 1` | `query`          |

## log-entry-id

The first value is `log-entry-id`, which represents the entry’s unique identifier within the scope of a single log file. Every new file always starts with an entry that has an ID of `0`, incrementing by one afterwards. A `log-entry-id` is a 64-bit unsigned integer value.

The entry ID for any given operation is unique to the node, regardless of how a query is processed across the cluster. For example, imagine a three node cluster with a master aggregator and two leaves. When the master aggregator receives a distributed query and executes it on both leaf nodes, each leaf’s entry ID for the operation may be completely different.

If your database is configured to use the `ALL-RESULTS` logging mode, the results will appear as additional log entries with the same `<log-entry-id>` as the parent. For more information, see [Schema for ALL-RESULTS Database Responses](https://docs.singlestore.com/db/v9.1/security/audit-logging/audit-log-file-format.md).

## timestamp

The second value is `timestamp`, which specifies the node’s local system time when an operation was executed. The timestamp is printed in `%Y-%m-%d %H:%M:%S.%f` format.

## time-zone

The third value is `time-zone`, which specifies the local time zone when an operation was executed. The time zone is printed as an initialism, such as `GMT` (Greenwich Mean Time).

## hostname:port

The fourth value is `hostname:port`, which specifies the node’s hostname and port. The hostname is the same the database’s `hostname` global variable. Together, these values represent the identifier for a node.

## node-type

The fifth value is `node-type`, which specifies whether the node is an aggregator (`agg`) or a leaf (`leaf`).

## aggregator-id

The sixth value is `aggregator-id`, which specifies the ID of the aggregator that issued any given query. An `aggregator-id` is a 64-bit unsigned integer value.

An `aggregator-id` may contain an invalid value of `18446744073709551615` if the aggregator has not yet been given an ID.

In a cluster with multiple aggregators, the ID of the master aggregator never changes, but the ID of a child aggregator may change. For example, if a child aggregator temporarily loses network connectivity and then reconnects, it may acquire a new aggregator ID. The child aggregators that remained connected might also have their aggregator IDs altered during the event.

When correlating a master aggregator’s query with its resulting downstream leaf node queries, you can use the combination of an entry’s `correlation-id` and `aggregator-id` values as a unique identifier. For example, if a query is executed against a cluster with one master aggregator and one leaf node, the query will be logged in the master aggregator’s log file and the leaf node’s log file. To quickly correlate entries for the same query across large log files, use the combination of the `correlation-id` and `aggregator-id` as a key.

## thread-id

The seventh value is `thread-id`, which specifies the ID of the node’s thread that is executing the query. A `thread-id` is a 32-bit integer value.

## username

The eight value is `username`, which specifies the username of the authenticated user who is executing the query.

## database-name

The ninth value is `database-name`, which specifies the name of the database that is being queried.

This value may appear as `[unknown]` in a log entry under a few conditions:

* If the query is not related to a specific database (e.g. `SHOW VARIABLES`).
* If the user does not specify `USE <database-name>` before executing their query. However, in this case the query does contain the database, such as `SELECT * from <db-name>.t`.

## correlation-id

The tenth value is `correlation-id`, which specifies an identifier for the current query. Multiple successive log entries can reference the same correlation-id, especially when a query requires data from more than one leaf partition.

When correlating a master aggregator’s query with its resulting downstream leaf node queries, you can use the combination of an entry’s `correlation-id` and `aggregator-id` values as a unique identifier. For example, if a query is executed against a cluster with one master aggregator and one leaf node, the query will be logged in the master aggregator’s log file and the leaf node’s log file. To quickly correlate entries for the same query across large log files, use the combination of the `correlation-id` and `aggregator-id` as a key.

Under some circumstances, a `correlation-id` value may not appear in the log entry. This value is usually missing when a DDL operation is executed.

## query-hash

The 11th value is `query-hash`, which specifies a unique hash of either the query signature or the query text. The `query-hash` is a 64-bit unsigned integer value.

The full query text will only be hashed if the node’s logging level is set to `ALL-QUERIES-PLAINTEXT` or `ALL-QUERIES-PLAINTEXT-INCLUDING-PARSE-FAILS`. Otherwise, just the query signature will be hashed.

## query

The 12th value is the `query`, which specifies either the query signature or the query text.

The full query text will only be written to the log if the node’s logging level is set to `ALL-QUERIES-PLAINTEXT` or `ALL-QUERIES-PLAINTEXT-INCLUDING-PARSE-FAILS`. Otherwise, just query signature will be hashed.

The `USING` clause of queries is not captured as part of audit logging and can be viewed via [SHOW PROCESSLIST](https://docs.singlestore.com/db/v9.1/reference/sql-reference/show-commands/show-processlist.md) where applicable.

***

Modified at: July 3, 2026

Source: [/db/v9.1/security/audit-logging/audit-log-file-format/](https://docs.singlestore.com/db/v9.1/security/audit-logging/audit-log-file-format/)

(An index of the documentation is available at /llms.txt)