Release Notes
Announcements
Enabling Database Audit
Use Cases
First-time enabling audit feature forDistributed Cache: Applies to newly created Distributed Cache instances or existing instances that have not enabled the audit feature. First-time enabling the audit can immediately start recording all eligible commands, laying the foundation for compliance checks before business launch and subsequent O&M management.
Batch enabling the audit feature uniformly for multiple instances: When businesses are launched in batches, you can configure the same audit policy (such as write command audit and retention for 7 days) for all business-related instances at once, ensuring consistency in audit configuration and avoiding operational errors from configuring one by one.
Prerequisites
Condition Type | Specific requirements |
Instance Version | Redis versions 4.0, 5.0, 6.0, 7.0, Valkey 8.0. |
Network Environment | Distributed Cache instance is running, and network connection is normal. |
Region Availability | The region where the instance is located has enabled the audit feature (currently supported in all regions, but may be subject to region allowlist restrictions during the gradual rollout period). |
Operation Steps
1. Log in to the Tencent Cloud Distributed Cache console.
2. In the left sidebar, select Database Audit under the menu Distributed Cache (Redis OSS-Compatible).
3. On the Database Audit page, select the region where database audit needs to be enabled, set Audit Status to Disabled, and the page will display all database instances in that region with audit not enabled.
4. (Optional) The search box above the database instance list can be used to filter target instances by keywords: it supports searching based on Instance ID, Instance Name, Tag Key, and Tag.
5. You can enable the Database Audit service for single or multiple instances in the database instance list.
Batch enablement: On the database instance list, select one or more instances to enable audit for, then click Enable Database Audit above the list.
Single instance enablement: In the Operation column of the target instance, click Enable Database Audit.
6. On the Enable Database Audit page, configure audit rules and audit log retention policies.
Configuration Item | Configuration Parameter | Parameter Description |
Select Audit Instance | - | Select the instances that require database auditing again. |
Audit Rule Settings | Audit Mode | Write Command (default): Data modification commands covering write operations for all data structures such as strings, hashes, lists, sets, and sorted sets. Read Command: Data query commands covering read operations for all data structures and metadata query operations. All Commands: Audits the execution of all commands. |
| Degradation Policy | Set the P99 latency threshold for triggering Database Audit downgrade. Note: Database Audit consumes certain system resources during operation. After the downgrade policy is enabled, the system will continuously monitor the database's P99 latency. When the latency exceeds your configured threshold (such as during periods of high system pressure), the system will proactively trigger its self-protection mechanism. This mechanism will temporarily stop collecting and discard new audit log data, thereby releasing system resources to prioritize normal read/write requests for your core business. Once the database load decreases and latency returns to normal levels, audit data collection will automatically resume. The entire process requires no manual intervention. Default threshold: 500ms. Configurable range: 300-1000ms. |
Configure Audit | Log Retention Period | Range: 7-30 days. Default value: 7 days. Recommendation: Select an appropriate duration based on compliance requirements and cost budget. |
| Frequency Access Storage Period | High-frequency storage uses high-performance media with fast query speeds, suitable for recent audit logs requiring frequent search. Currently, the selection is limited to 7 days. |
| Infrequency Access Storage Period | When data storage exceeds the "High-frequency Storage Duration", it will be automatically transitioned to low-frequency storage. |
7. Confirm the configuration information, click OK to submit the enable audit request. The system will create an asynchronous workflow to configure the audit feature. On the audit instance page, all instances with audit enabled will be displayed.
FAQs
Q1: Does the audit service configuration support modification after it is enabled?
Supported. After activation, you can flexibly adjust audit types, audit log retention periods, downgrade policies, and other settings on demand. For specific operations, see Modify Audit Configuration.
Q2: Are there any limitations on batch operations?
Batch enabling/disabling of auditing supports selecting multiple instances at once, with currently no limitation on the number of instances.
When batch modifying audit rules, all instances use the same configuration. If different configurations are required, modify them separately.
It is recommended that the number of instances for a single batch operation does not exceed 50 to avoid operation timeout.
Q3: How to set the threshold for the degradation policy?
The default value for the degradation policy (P99 latency) is 500 ms, with flexible adjustment supported between 300 and 1000 ms. When the instance latency reaches this threshold, the system automatically suspends audit collection to ensure service availability. It is recommended that you configure this based on actual business scenarios:
Latency-sensitive services (such as flash sales and real-time transactions): It is recommended to lower the threshold (such as 300 ms). During sudden traffic surges, the system can offload audit overhead earlier to ensure lrapid/fast response for core business operations.
For regular business operations: It is recommended to keep the default 500 ms setting, which strikes a balance between "business performance" and "security auditing requirements" under normal workloads.
For compliance-critical/high-latency-tolerance services: If your business has extremely high requirements for security operation traceability and can tolerate a certain level of access latency, you may appropriately increase the threshold (such as 800 to 1000 ms) to maximize the integrity of audit logs.
Q4: After the "downgrade policy" is triggered and log collection is suspended, is manual reactivation of the audit required?
Not at all. The degradation policy is a fully automated self-protection mechanism. When the P99 latency of an instance exceeds your set threshold (such as 500 ms), the system will pause collection to protect core business operations. Once the peak business period passes and the database load decreases with latency dropping below this threshold, the system will automatically resume audit log collection. The entire process requires no manual intervention.
피드백