Error List¶
Click "Error Center" in the left navigation bar to display the error list by default. All error data in the list comes from the delivery rules you have configured.
Error Delivery Logic¶
Error Center uses an intelligent aggregation mechanism to manage error data uniformly. The system only processes error data that can generate a unique identifier (issue_id). This identifier is generated by combining the error fingerprint and service context to ensure continuous tracking of the same error.
Error Aggregation Mechanism¶
The system achieves intelligent error aggregation through the following steps:
1. Error Fingerprint Generation
The system generates a unique fingerprint identifier (fingerprint) for each error:
- APM:
Error type (error_type) + Error message (error_message) + Error stack (error_stack) - RUM:
Error type (error_type) + Error message (error_message) + Error stack (error_stack) - Logs (with
error_stack):Error type (error_type) + Error message (error_message) + Error stack (error_stack) - Logs (without
error_stack):Error type (error_type) + Error message (error_message)
Error fingerprint generation is premised on data completeness. APM, RUM, and Logs data must contain fields for the above paths to generate a fingerprint; if fields are missing, that piece of data is skipped.
Note
- Before calculation, the system performs standardization processing, automatically identifying and filtering variable content (such as timestamps, user IDs, etc.) in the error message (
error_message) to ensure consistent fingerprints for logical errors of the same type. - Stack information (
error_stack) undergoes optimization processing, retaining only key business call lines. - The system strictly verifies field completeness; data missing necessary fields will be excluded.
2. Error Issue Identification
Based on the error fingerprint, the system combines the context in which the error occurred to generate a unique issue identifier (issue_id), used to track and manage this issue within the Error Center. The specific generation logic is as follows:
- APM errors:
Service (service) + Fingerprint (fingerprint) - RUM errors:
Application name (app_name) + Fingerprint (fingerprint) - Log errors:
Service (service) + Fingerprint (fingerprint)
When the system first generates a new issue_id for a particular error combination, it automatically records the first occurrence time of this issue in the workbench and begins full lifecycle status tracking and aggregation analysis for it.
Error Data Storage¶
Error data is stored in an independent namespace, isolated from the original data, and is retained for 90 days by default (❗️Customization is not currently supported). The upper limit for new error issues per workspace per day is 10,000.
The Error Center list displays aggregation results by issue_id, including errors from "All" sources and in "All" statuses. You can switch to view:
-
Error sources:
- Logs
- APM
- RUM
-
Error statuses:
- Triage
- Assigned
- Working
- Resolved
- Ignored
Special Scenarios for Status Changes
When an error issue that is already in the "Resolved" state encounters the same error again, the system will automatically reset its status from "Resolved" to (Triage) and restart the entire handling process (including automatically notifying the responsible person).
If an error is in the (Ignored) state, then even if the same error occurs again, it will not be reopened but will remain in the (Ignored) state.
You can also filter and search using the application name (app_name), service (service), source (resource), version (version), or environment (env) to locate specific errors.
List Display¶
On the list page, each error entry clearly displays the most recently occurred error type and description, the associated application or service, the current error handler, the last trigger time, and the cumulative count. The right side of the data provides a recent occurrence trend chart for that error, visually presenting the temporal distribution pattern of the error.
