This configuration is written based on FastGPT v4.17.0.
What this category of data looks like
Data for this category primarily comes from CDN consoles, DNS resolution records, user access logs, and monitoring alert systems. Update frequency is daily or after each configuration change. Daily associated documents include domain access forms, cache rules, refresh and preheating records, and fault analysis reports. Data fields include request timestamp, node identifier, cache status code, traffic value (unit: MB), request path, and more. Data is stored categorized by node, time, and operation type. No additional aggregated statistical fields are included.
What constraints do these characteristics impose on the conversation logs and audits workflow
Multiple data sources require audit logs to integrate console operations, DNS changes, access logs, and alert data. This avoids audit blind spots from single data sources. The update rhythm of data on a daily or change-triggered basis requires log collection to support change-triggered or scheduled pulls. This ensures configuration adjustment operations can be traced. Multiple associated document types require logs to be bound to unique identifiers of corresponding resources. This enables subsequent traceability. Fields contain multi-dimensional information. The detail parameter must fully record all relevant fields to avoid missing key information.
How to set the configuration
| Configuration Item | Recommended Practice | Rationale |
|---|---|---|
chatId | Bind to the unique identifier of the current CDN node | Ensure each audit log is associated with the corresponding distribution node, avoiding cross-node log confusion |
responseChatItemId | Associate with the cache rule version number | Bind audit logs to specific configuration versions to facilitate rollback traceability |
detail | Include request time, node IP, cache status code, traffic value (unit: MB) | Cover core audit fields in CDN scenarios to meet security review requirements |
| Log storage period | 180–365 days | Meet industry general compliance storage period requirements and support security review needs |
| Log sync trigger | Triggered by configuration changes + daily full sync | Balance real-time operation traceability and historical data completion |
Three common misconfigurations
- Workflow conversations display a failure, but the model backend receives response logs. The cause is incorrect configuration of
chatIdbinding to the CDN node identifier. This leads to incorrect log association, and the workflow cannot match the corresponding context. - The
detailfield in conversation logs is empty. The cause is that full field collection configuration is not enabled. Only basic conversation text is stored, and core business fields in CDN scenarios are not included. - Application conversation exception errors are not recorded. The cause is that exception log trigger rules are not configured. Only logs of normal interactions are recorded, and audit requirements for exception scenarios are not covered.
How to confirm the configuration is complete
- Enter the FastGPT log management page. Locate the conversation logs of the corresponding CDN node, and check whether
chatIdmatches the node identifier. - Trigger a cache rule change operation. Check whether the log contains the version number associated with
responseChatItemId. - View the
detailfield of a single log. Confirm whether it includes core business fields such as request time and node IP. - Trigger an exception operation, such as an incorrect cache refresh request. Check whether the corresponding exception audit log is generated.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.