System Event Audit Messages in Self-Managed Deployments

uuid

A document that contains a message identifier.

The UUID identifies a client connection. Use the UUID to track audit events connected to that client.

The value of the $type field is BSON type 04 which indicates that the $binary field contains a UUID.

local

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.

A document that contains the ip address and the port number of the incoming connection associated with the event.

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.

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 and Amazon Web Services Identity and Access Management (AWS-IAM) (see authMechanism).

authCheck

{
  command: <name>,
  ns: <database>.<collection>,
  args: <command object>
}

By default, the auditing system logs only the authorization failures. To enable the system to log authorization successes, use the auditAuthorizationSuccess parameter.

Enabling 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.

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 command.

createCollection

{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}

Logged when a:

• Collection is created.

• View 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 definition for the view.

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 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 audit event.

• Logged for a createCollection event if the collection has an index.

The audit message contains result code 276 for createIndex audit events with IndexBuildState set to IndexBuildAborted. The audit message contains result code 0 for 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 or admin.system.roles collections.

dropCollection

{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}

Logged when a:

• Collection is dropped.

• View 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 definition for the view.

In addition, starting in MongoDB 5.0, a dropCollection audit event is logged when a dropDatabase event occurs.

If the collection or view does not exist, the audit message shows the return code as result: 26.

{
  user: <user name>,
  db: <database>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

The customData field is optional.

getClusterParameter

setClusterParameter

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

{
  user: <user name>,
  db: <database>,
  passwordChanged: <boolean>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

The customData field is optional.

{
  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. For a list of actions, see Privilege Actions for Self-Managed Deployments.

{
  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. For a list of actions, see Privilege Actions for Self-Managed Deployments.

{
  role: <role name>,
  db: <database>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

For details on the resource document, see Resource Document on Self-Managed Deployments. For a list of actions, see Privilege Actions for Self-Managed Deployments.

{
  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. For a list of actions, see Privilege Actions for Self-Managed Deployments.

{
  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.

{
  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.

{ }

Indicates commencement of database shutdown.

{ msg: <custom message string> }

See logApplicationMessage.

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

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