ApsaraDB for MongoDB:Enable audit logs

Use cases

Prerequisites

• Your instance is a replica set instance or a sharded cluster instance. The audit log feature does not support standalone instances.

• Log Service is enabled. For instructions, see Getting Started.

• If you enable audit logs as a RAM user, you must grant the following permissions to the RAM user:

  • AliyunLogFullAccess: This is a system policy. For instructions on how to grant this permission, see Grant permissions to a RAM user.

  • dds:CheckServiceLinkedRole: This is a custom policy. You must first create this policy in the Resource Access Management (RAM) console and then grant it to the RAM user. To create a custom policy by using the script editor, see Create custom policies. For instructions on how to grant the permission, see Grant permissions to a RAM user.

    The following script is for the dds:CheckServiceLinkedRole policy.

    {
    	"Version": "1",
    	"Statement": [
    		{
    			"Effect": "Allow",
    			"Action": "dds:CheckServiceLinkedRole",
    			"Resource": "*"
    		}
    	]
    }

• If you use a RAM user to access audit logs, you must grant the AliyunLogFullAccess or AliyunLogReadOnlyAccess permission to the RAM user. For instructions on how to grant these permissions, see Grant permissions to a RAM user.

Usage notes

• After you enable the audit log feature, the system records audit information for write operations. This can add performance overhead and cause latency jitter on your ApsaraDB for MongoDB instance. For instances that run MongoDB 6.0 or later, the performance overhead can be 15% to 20%. For instances that run an earlier version, the performance overhead may be higher. For more information, see Audit log performance analysis.

  Note

  If your application performs a high volume of write operations on your ApsaraDB for MongoDB instance, we recommend enabling this feature only for troubleshooting or security audits to prevent performance degradation.

• After you enable the audit log feature, only the admin and slow operation types are selected by default. To change the audited operation types, see Modify operation types for audit logs.

• The log retention period setting applies to all ApsaraDB for MongoDB instances in the current region. All other settings apply only to the current instance.

• If you have enabled the free trial edition of the audit log feature and require a longer retention period or more storage space, you can upgrade to the official edition. For instructions, see Upgrade to the official edition.

Billing

The official edition of the audit log feature is billed on a pay-as-you-go basis based on the storage usage and retention period of audit logs. The following tables show the prices in different regions.

You can use the following methods to reduce your audit log costs.

Procedure

1. Log on to the ApsaraDB for MongoDB console.

2. In the left-side navigation pane, click Replica Set Instances or Sharded Cluster Instances based on your instance type.

3. In the upper-left corner of the page, select the resource group and region where the instance is located.

4. Click the ID of the instance, or click Manage in the Actions column for the instance.

5. In the left-side navigation pane, choose Data Security > Audit Logs.

6. On the Latest Audit Logs page, set the Log Retention Period.

   • You can set the retention period from 1 to 365 days. The default value is 30 days.

   • Confirm that the selected retention period is suitable for all instances in the region before you proceed.

7. Click Activate.

   Note

   When you enable the audit log feature, ApsaraDB for MongoDB is automatically granted the AliyunServiceRoleForMongoDB service-linked role. This role allows ApsaraDB for MongoDB to access logs from Log Service.

8. In the Activate dialog box, read the message and click Confirm.

What to do next

API reference

Related documentation

• Query audit logs

• Download audit logs

• Disable the audit log feature

• Audit log performance analysis