> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# mongo Schema Audit Messages

In the `mongo` schema, recorded log messages have this syntax:

```none
{
  atype: <string>,
  ts : { $date: <timestamp> },
  uuid : { $binary: <string>, $type: <string> },
  local: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },
  remote: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },
  directRemote: { ip: <string>, port: <int> || unix: <string> },   // Added in MongoDB 9.0 *(also available in 8.3.9 and 8.0.33)*
  intermediates: [   // Added in MongoDB 8.1
     {
        // IP address and port for mongos or load balancer
        ip: <string>,
        port: <int>
     }, {
        //  IP address and port for mongos or load balancer
        ip: <string>,
        port: <int>
     }
  ],
  users : [ { user: <string>, db: <string> }, ... ],
  roles: [ { role: <string>, db: <string> }, ... ],
  param: <document>,
  result: <int>
}
```

The following table describes the fields in the `mongo` schema.

| Field | Type | Description |
| --- | --- | --- |
| `atype` | string | Action type. See [Audit Event Actions, Details, and Results.](https://www.mongodb.com/docs/manual/reference/audit-message/mongo.md#std-label-audit-action-details-results) |
| `ts` | document | Document that contains the date and UTC time of the event, in ISO 8601 format. |
| `uuid` | document | A document that contains a message identifier. The UUID (Universally unique identifier) identifies a client connection. Use the UUID to track audit events connected to that client. The value of the `$type` field is [BSON type](https://www.mongodb.com/docs/manual/reference/bson-types.md#std-label-bson-types) `04` which indicates that the `$binary` field contains a UUID. **New in version 5.0** |
| `local` | document | A document that contains the `ip` address and the `port` number of the running instance. Starting in MongoDB 5.0, can alternatively be a document with one of these fields: `isSystemUser` that indicates whether the user who caused the event was a system user. Logged for self-referential jobs initiated by a background process that runs on the same server instance.; `unix` that contains the MongoDB socket file path if the client connects through a Unix domain socket. Starting in MongoDB 5.0, the `local` field is deprecated. Use the `localEndpoint` field in the [clientMetadata](https://www.mongodb.com/docs/manual/reference/audit-message/mongo.md#std-label-audit-message-clientMetadata) audit message instead. **Changed in version 5.0** |
| `intermediates` | array of documents | Starting in MongoDB 8.1, if a client application connects to `mongos` through a load balancer, the origin client computer and load balancer IP addresses and ports are included in the audit log. You can use the log to match an audit event with the origin client computer. Starting in MongoDB 8.1, `mongos` parses the proxy protocol header and stores the origin client computer IP address and port in the `remote` field. Also, if a load balancer is used, the `intermediates` document stores the load balancer IP address and port. In MongoDB versions earlier than 8.1, the load balancer IP address and port are stored in the `remote` field and the origin client computer IP address and port are omitted. Each array element in `intermediates` is a document with `ip` and `port` fields, which are either the IP address and port of a load balancer or `mongos` that the origin client computer request passes through. If the origin client computer request passes through a load balancer: Starting in MongoDB 8.1, the `remote` field stores the client computer IP address and port that are read from the proxy protocol header. The `intermediates` document contains the load balancer IP address and port.; In MongoDB versions earlier than 8.1, the `remote` field stores the load balancer IP address and port. The `intermediates` document isn't in the audit log. If the audit event occurs on a shard: Starting in MongoDB 8.1, the `remote` field stores the client computer IP address and port. The address and port are read from the proxy protocol header or, if the client computer connects to `mongos`, the address and port are read from the origin client computer connection. The `intermediates` document stores the `mongos` IP address and port. If a load balancer is used, the `intermediates` document also stores the load balancer IP address and port.; In MongoDB versions earlier than 8.1, the `remote` field stores the `mongos` IP address and port. The `intermediates` document isn't in the audit log. **New in version 8.1** |
| `remote` | document | A document that stores the `ip` address and the `port` number of the incoming connection associated with the event. Starting in MongoDB 8.1, `mongos` parses the proxy protocol header and stores the origin client computer IP address and port in the `remote` field. Also, if a load balancer is used, the `intermediates` document stores the load balancer IP address and port. In MongoDB versions earlier than 8.1, the load balancer IP address and port are stored in the `remote` field and the origin client computer IP address and port are omitted. Starting in MongoDB 5.0, can alternatively be a document with one of these fields: `isSystemUser` that indicates whether the user who caused the event was a system user. Logged for self-referential jobs initiated by a background process that runs on the same server instance.; `unix` that contains the MongoDB socket file path if the client connects through a Unix domain socket. The `directRemote` field records the host that opens the connection when a load balancer or reverse proxy asserts the client address. **Changed in version 8.1** |
| `directRemote` | document | A document that stores the `ip` address and the `port` number of the host that connects directly to the instance. If the client connects through a Unix domain socket, the document stores a `unix` field instead of the `ip` and `port` fields. This address identifies the host that opens the connection, even when a load balancer or reverse proxy asserts a different client address. MongoDB accepts proxy protocol connections on a specific port. Any host that can reach that port can assert an arbitrary client address. To keep the recorded address trustworthy, restrict access to that port to the load balancer or reverse proxy. For audit events recorded by a shard, the reported address depends on how the shard receives the request: If a `mongos` instance routes the request, the address repeats the client address that `mongos` forwards.; If the request comes directly from `mongos`, the address records the `mongos` instance. **New in version 9.0** (*Also available starting in 8.3.9, 8.0.33*) |
| `users` | array | Array of user identification documents. Because MongoDB allows a session to log in with different user per database, this array can have more than one user. Each document contains a `user` field for the username and a `db` field for the authentication database for that user. |
| `roles` | array | Array of documents that specify the [roles](https://www.mongodb.com/docs/manual/core/authorization.md) granted to the user. Each document contains a `role` field for the name of the role and a `db` field for the database associated with the role. |
| `param` | document | Specific details for the event. See [Audit Event Actions, Details, and Results.](https://www.mongodb.com/docs/manual/reference/audit-message/mongo.md#std-label-audit-action-details-results) |
| `result` | integer | Error code. See [Audit Event Actions, Details, and Results.](https://www.mongodb.com/docs/manual/reference/audit-message/mongo.md#std-label-audit-action-details-results) |

## Audit Event Actions, Details, and Results

The following table lists for each `atype` or action type, the associated `param` details and the `result` values, if any.

| `atype` | `param` | `result` |
| --- | --- | --- |
| `authenticate` | `{
  user: <user name>,
  db: <database>,
  mechanism: <mechanism>
}` Starting in MongoDB 5.0, `authenticate`: Is logged for incomplete authentication attempts.; Includes the principle name and identifier in `mechanism` for external authentication mechanisms such as [X.509](https://www.mongodb.com/docs/manual/core/security-x.509.md#std-label-security-auth-x509) and Amazon Web Services Identity and Access Management (AWS-IAM) (see [`authMechanism`](https://www.mongodb.com/docs/manual/reference/connection-string-options.md#mongodb-urioption-urioption.authMechanism)). **Changed in version 5.0** | `0` - Success`18` - Authentication Failed`334` - Mechanism Unavailable`337` - Authentication Abandoned |
| `authCheck` | `{
  command: <name>,
  ns: <database>.<collection>,
  args: <command object>
}` Logs authorization checks for user attempts to read from or write to the database. `ns` field is optional.`args` field may be redacted. By default, the auditing system logs only the authorization failures. To enable the system to log authorization successes, use the [`auditAuthorizationSuccess`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.auditAuthorizationSuccess) parameter. Enabling [`auditAuthorizationSuccess`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.auditAuthorizationSuccess) degrades performance more than logging only the authorization failures. Starting in MongoDB 5.0, `authCheck` is not logged for actions that are generated internally. **Changed in version 5.0** | `0` - Success`13` - Unauthorized to perform the operation. |
| `clientMetadata` | `{
   localEndpoint : {
      ip : <IP address of running instance>,
      port : <port of running instance>
   } || {
      unix : <MongoDB socket file path if connecting through
              a Unix domain socket>
   },
   clientMetadata : {
      driver : {
         name : <client driver name>,
         version : <client driver version>
      },
      os : {
         type : <client operating system type>,
         name : <client operating system name>,
         architecture : <client operating system architecture>,
         version : <client operating system version>
      },
      platform : <client platform name>,
      application : {
         name : <client application name>
      }
   }
}` Contains the client metadata. Logged when the client runs the [`hello`](https://www.mongodb.com/docs/manual/reference/command/hello.md#mongodb-dbcommand-dbcmd.hello) command. For more details, see [Client Data.](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-client-data) **New in version 5.0** | `0` - Success |
| [`createCollection`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createCollection) | `{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}` Logged when a: Collection is created.; [View](https://www.mongodb.com/docs/manual/core/views.md#std-label-views-landing-page) is created, with the view name logged in the `ns` field. Starting in MongoDB 5.0, this additional information is logged for a view: `viewOn` field with the database and collection for the view.; `pipeline` field with the [aggregation pipeline](https://www.mongodb.com/docs/manual/core/aggregation-pipeline.md#std-label-aggregation-pipeline) definition for the view. **Changed in version 5.0** | `0` - Success |
| `createDatabase` | `{ ns: <database> }` | `0` - Success |
| [`createIndex`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createIndex) | `{
  ns: <database>.<collection>,
  indexName: <index name>,
  indexSpec: <index specification>,
  indexBuildState: <index build state>
}` Possible values for `indexBuildState` are: `IndexBuildStarted`; `IndexBuildSucceeded`; `IndexBuildAborted` Starting in MongoDB 5.0, [`createIndex`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createIndex) audit events are: Logged at the start and end of index creation, and includes a message indicating if the index was successfully created or not.; Attributed to the originating user for the action that caused the [`createIndex`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createIndex) audit event.; Logged for a [`createCollection`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createCollection) event if the collection has an index. **Changed in version 5.0** | `0` - Success`276` - Index build aborted. The audit message contains result code `276` for [`createIndex`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createIndex) audit events with `IndexBuildState` set to `IndexBuildAborted`. The audit message contains result code `0` for [`createIndex`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createIndex) audit events with `IndexBuildState` set to `IndexBuildStarted` or `IndexBuildSucceeded`. |
| `directAuthMutation` | `{
   document: {
      <collection modifications>
   },
   ns: <database>.<collection>,
   operation: <database operation>
}` Logged when a database operation directly modifies the contents of the [`admin.system.users`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data-admin.system.users) or [`admin.system.roles`](https://www.mongodb.com/docs/manual/reference/system-collections.md#mongodb-data-admin.system.roles) collections. **New in version 5.0** | `0` - Success |
| `renameCollection` | `{
  old: <database>.<collection>,
  new: <database>.<collection>
}` | `0` - Success |
| [`dropCollection`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-dropCollection) | `{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}` Logged when a: Collection is dropped.; [View](https://www.mongodb.com/docs/manual/core/views.md#std-label-views-landing-page) is dropped, with the view name logged in the `ns` field. Starting in MongoDB 5.0, this additional information is logged for a view: `viewOn` field with the database and collection for the view.; `pipeline` field with the [aggregation pipeline](https://www.mongodb.com/docs/manual/core/aggregation-pipeline.md#std-label-aggregation-pipeline) definition for the view. In addition, starting in MongoDB 5.0, a [`dropCollection`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-dropCollection) audit event is logged when a [`dropDatabase`](https://www.mongodb.com/docs/manual/reference/change-events/dropdatabase.md#mongodb-data-dropDatabase) event occurs. **Changed in version 5.0** | `0` - Success`26` - `NamespaceNotFound` If the collection or view does not exist, the audit message shows the return code as `result: 26`. |
| [`dropDatabase`](https://www.mongodb.com/docs/manual/reference/change-events/dropdatabase.md#mongodb-data-dropDatabase) | `{ ns: <database> }` | `0` - Success |
| [`dropIndex`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-dropIndex) | `{
  ns: <database>.<collection>,
  indexName: <index name>
}` | `0` - Success |
| [`createUser`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createUser) | `{
  user: <user name>,
  db: <database>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}` The `customData` field is optional. | `0` - Success |
| [`dropUser`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-dropUser) | `{
  user: <user name>,
  db: <database>
}` | `0` - Success |
| `dropAllUsersFromDatabase` | `{ db: <database> }` | `0` - Success |
| `getClusterParameter` | `{
    requestedClusterServerParameters: <parameters>
}` | `0` - Success |
| `setClusterParameter` | `{
    originalClusterServerParameter: <original parameter value>,
    updatedClusterServerParameter": <new parameter value>
}` | `0` - Success |
| `updateCachedClusterServerParameter` | `{
    originalClusterServerParameter: <original parameter value>,
    updatedClusterServerParameter": <new parameter value>
}` Logged when a parameter is changed because of: Propagation of a `setClusterParameter` command; Replication event such as rollback; A refresh of new cluster parameter values from the config server on `mongos` | `0` - Success |
| `updateUser` | `{
  user: <user name>,
  db: <database>,
  passwordChanged: <boolean>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}` The `customData` field is optional. | `0` - Success |
| `grantRolesToUser` | `{
  user: <user name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}` | `0` - Success |
| `revokeRolesFromUser` | `{
  user: <user name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}` | `0` - Success |
| [`createRole`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-createRole) | `{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ],
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}` The `roles` and the `privileges` fields are optional. For details on the resource document, see [Resource Document on Self-Managed Deployments](https://www.mongodb.com/docs/manual/reference/resource-document.md#std-label-resource-document). For a list of actions, see [Privilege Actions.](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#std-label-security-user-actions) | `0` - Success |
| `updateRole` | `{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ],
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}` The `roles` and the `privileges` fields are optional. For details on the resource document, see [Resource Document on Self-Managed Deployments](https://www.mongodb.com/docs/manual/reference/resource-document.md#std-label-resource-document). For a list of actions, see [Privilege Actions.](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#std-label-security-user-actions) | `0` - Success |
| [`dropRole`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-dropRole) | `{
  role: <role name>,
  db: <database>
}` | `0` - Success |
| `dropAllRolesFromDatabase` | `{ db: <database> }` | `0` - Success |
| `grantRolesToRole` | `{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}` | `0` - Success |
| `revokeRolesFromRole` | `{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}` | `0` - Success |
| `grantPrivilegesToRole` | `{
  role: <role name>,
  db: <database>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}` For details on the resource document, see [Resource Document on Self-Managed Deployments](https://www.mongodb.com/docs/manual/reference/resource-document.md#std-label-resource-document). For a list of actions, see [Privilege Actions.](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#std-label-security-user-actions) | `0` - Success |
| `revokePrivilegesFromRole` | `{
  role: <role name>,
  db: <database name>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}` For details on the resource document, see [Resource Document on Self-Managed Deployments](https://www.mongodb.com/docs/manual/reference/resource-document.md#std-label-resource-document). For a list of actions, see [Privilege Actions.](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#std-label-security-user-actions) | `0` - Success |
| `replSetReconfig` | `{
  old: {
   _id: <replicaSetName>,
   version: <number>,
   ...
   members: [ ... ],
   settings: { ... }
  },
  new: {
   _id: <replicaSetName>,
   version: <number>,
   ...
   members: [ ... ],
   settings: { ... }
  }
}` For details on the replica set configuration document, see [Self-Managed Replica Set Configuration.](https://www.mongodb.com/docs/manual/reference/replica-configuration.md) | `0` - Success |
| [`enableSharding`](https://www.mongodb.com/docs/manual/reference/built-in-roles.md#mongodb-authrole-enableSharding) | `{ ns: <database> }` | `0` - Success |
| `shardCollection` | `{
  ns: <database>.<collection>,
  key: <shard key pattern>,
  options: { unique: <boolean> }
}` | `0` - Success |
| [`addShard`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-addShard) | `{
  shard: <shard name>,
  connectionString: <hostname>:<port>,
}` When a shard is a replica set, the `connectionString` includes the replica set name and can include other members of the replica set. | `0` - Success |
| [`refineCollectionShardKey`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-refineCollectionShardKey) | `{
  ns: <database>.<collection>,
  key: <shard key pattern>
}` | `0` - Success |
| [`removeShard`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-removeShard) | `{ shard: <shard name> }` | `0` - Success |
| [`shutdown`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-shutdown) | `{ }` Indicates commencement of database shutdown. | `0` - Success |
| [`applicationMessage`](https://www.mongodb.com/docs/manual/reference/privilege-actions.md#mongodb-authaction-applicationMessage) | `{ msg: <custom message string> }` See [`logApplicationMessage`.](https://www.mongodb.com/docs/manual/reference/command/logapplicationmessage.md#mongodb-dbcommand-dbcmd.logApplicationMessage) | `0` - Success |
| `logout` | `{
  reason: <string>,
  initialUsers: [ <document>, ... ],
  updatedUsers: [ <document>, ... ],
}` `reason` will be either:"Explicit logout from <database>"; "Implicit logout due to client connection closure" `initialUsers` is an array of documents containing users authenticated on the current client prior to logout. `updatedUsers` is an array of documents containing users expected to be authenticated on the current client after the logout event. Each document in `initialUsers` and `updatedUsers` contains:`user`: the username; `db`: the database `user` is authenticated to **New in version 5.0** | `0` - Success |
| `startup` | `{
    startupOptions: <document>,
    initialClusterServerParameter: <array of documents>
}` `startupOptions` contains all of the options that the node has after startup; `initialClusterServerParameters` contains the initial values of the cluster server parameters that the node has at the end of startup:after they have been loaded from storage (for `mongod`); after they have been refreshed from the config server (for `mongos`). **New in version 5.0** **Changed in version 6.1** | `0` - Success |