Db audit log beta dedicated#22889
Conversation
|
Hi @ginkgoch. Thanks for your PR. I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Code Review
This pull request updates the TiDB Cloud Dedicated Database Audit Logging documentation to reflect its Public Preview status, introduces a legacy guide, and details new configuration steps for log rotation and redaction. Reviewer feedback focuses on correcting grammatical errors, ensuring terminology consistency for Azure storage, and aligning list formatting and capitalization with the style guide.
| > Currently, the database audit logging feature is only available upon request. To request this feature, click **?** in the lower-right corner of the [TiDB Cloud console](https://tidbcloud.com), and then click **Support Tickets** to go to the [Help Center](https://tidb.support.pingcap.com/servicedesk/customer/portals). Create a ticket, fill in "Apply for database audit logging" in the **Description** field, and then click **Submit**. | ||
| > Database audit logging is now in Public Preview for eligible clusters. | ||
| > | ||
| > * **Public Preview Eligibility**: * Version: TiDB v7.5.6+ or v8.5.2+. |
| 5. Click **Enable** to enable audit logging for the cluster. | ||
|
|
||
| TiDB Cloud is ready to write audit logs for the specified cluster to your Amazon S3 bucket. | ||
| 4. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigate to the next step for **Database Audit Logging Settings**. |
There was a problem hiding this comment.
The verb 'navigate' should be 'navigates' to agree with the singular subject 'dialog'.
| 4. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigate to the next step for **Database Audit Logging Settings**. | |
| 4. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigates to the next step for **Database Audit Logging Settings**. |
| 4. Click **Enable** to enable audit logging for the cluster. | ||
|
|
||
| TiDB Cloud is ready to write audit logs for the specified cluster to your GCS bucket. | ||
| 3. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigate to the next step for **Database Audit Logging Settings**. |
There was a problem hiding this comment.
The verb 'navigate' should be 'navigates' to agree with the singular subject 'dialog'.
| 3. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigate to the next step for **Database Audit Logging Settings**. | |
| 3. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigates to the next step for **Database Audit Logging Settings**. |
|
|
||
| - In the **Blob URL** field, enter the URL of the container where audit logs will be stored. | ||
| - In the **SAS Token** field, enter the SAS token for accessing the container. | ||
| 5. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigate to the next step for **Database Audit Logging Settings**. |
There was a problem hiding this comment.
In the Azure section, 'container' is the correct terminology instead of 'bucket'. Also, 'navigate' should be 'navigates'.
| 5. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the bucket. If the connection is successful, the dialog navigate to the next step for **Database Audit Logging Settings**. | |
| 5. Click **Test Connection and Save** to verify whether TiDB Cloud can access and write to the container. If the connection is successful, the dialog navigates to the next step for **Database Audit Logging Settings**. |
| 2. In the **Add Filter Rule** dialog, configure the following items: | ||
|
|
||
| You can add one audit rule at a time. Each rule specifies a user expression, database expression, table expression, and access type. You can add multiple audit rules to meet your auditing requirements. | ||
| - **Filter Name**: enter a name for the filter rule. |
|
|
||
| You can add one audit rule at a time. Each rule specifies a user expression, database expression, table expression, and access type. You can add multiple audit rules to meet your auditing requirements. | ||
| - **Filter Name**: enter a name for the filter rule. | ||
| - **SQL User**: enter the SQL user in the `<user>@<host>` format. The username and hostname can use `%` to match any value or `_` to match any single character. The `@` symbol and `<host>` are optional. |
There was a problem hiding this comment.
Start the description with a capital letter and use backticks for the SQL wildcards % and _ as per the style guide.
| - **SQL User**: enter the SQL user in the `<user>@<host>` format. The username and hostname can use `%` to match any value or `_` to match any single character. The `@` symbol and `<host>` are optional. | |
| - **SQL User**: Enter the SQL user in the `<user>@<host>` format. The username and hostname can use `%` to match any value or `_` to match any single character. The `@` symbol and `<host>` are optional. |
| You can add one audit rule at a time. Each rule specifies a user expression, database expression, table expression, and access type. You can add multiple audit rules to meet your auditing requirements. | ||
| - **Filter Name**: enter a name for the filter rule. | ||
| - **SQL User**: enter the SQL user in the `<user>@<host>` format. The username and hostname can use `%` to match any value or `_` to match any single character. The `@` symbol and `<host>` are optional. | ||
| - **Filter Events**: select the events to log. For the supported filter events, see [Audit Filter Events](#audit-filter-events). |
There was a problem hiding this comment.
Start the description with a capital letter for consistency.
| - **Filter Events**: select the events to log. For the supported filter events, see [Audit Filter Events](#audit-filter-events). | |
| - **Filter Events**: Select the events to log. For the supported filter events, see [Audit Filter Events](#audit-filter-events). |
|
|
||
| ## Audit logging limitations | ||
|
|
||
| {{{ .dedicated }}} does not guarantee the sequential order of audit logs, which means that you might have to review all log files find the most recent events. To sort the logs chronologically, you can use the `TIME` field in the audit logs. |
There was a problem hiding this comment.
Add the missing word 'to' for correct sentence structure.
| {{{ .dedicated }}} does not guarantee the sequential order of audit logs, which means that you might have to review all log files find the most recent events. To sort the logs chronologically, you can use the `TIME` field in the audit logs. | |
| {{{ .dedicated }}} does not guarantee the sequential order of audit logs, which means that you might have to review all log files to find the most recent events. To sort the logs chronologically, you can use the `TIME` field in the audit logs. |
|
|
||
| 5. Click **Test Connection** to verify whether TiDB Cloud can access and write to the container. | ||
|
|
||
| If it is successful, **The connection is successfully** is displayed. Otherwise, check your access configuration. |
There was a problem hiding this comment.
Grammar: 'successfully' is an adverb; 'successful' is the adjective needed here.
| If it is successful, **The connection is successfully** is displayed. Otherwise, check your access configuration. | |
| If it is successful, **The connection is successful** is displayed. Otherwise, check your access configuration. |
|
@jusong: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
First-time contributors' checklist
What is changed, added or deleted? (Required)
We are going to public preview audit log v2, so documents are update accordingly. V1 document is still keep for existing user for reference.
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions.
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?