Grouping Process#
When a new error event occurs, Flashduty uses a three-step grouping strategy to group errors into issues, effectively reducing the number of errors that need to be processed. The grouping process is as follows:1.
Fingerprint Matching: Obtains the fingerprint of the error event and compares it with the fingerprints of existing issues.
2.
Automatic Merging: If the new event shares the same fingerprint with an existing issue, it is automatically assigned to that issue.
3.
Similarity Analysis: If no fingerprint match is found, machine learning models analyze error similarity, assigning the event to the most similar issue or creating a new issue if similarity is too low.
Default Fingerprinting#
Flashduty enables error grouping by default, without requiring additional configuration to start working. The Browser SDK automatically collects error data and performs grouping. Below are the basic settings for web environments:1.
Integrate Flashduty Browser SDKInclude the Flashduty Browser SDK in your HTML file: 2.
When initializing the SDK, specify the application ID and environment: 3.
When an error event doesn't carry a fingerprint, Flashduty automatically calculates a fingerprint based on the following error properties:service: The service where the error occurred.
env: The environment where the error occurred.
error.type: The type classification of the error.
error.message: The descriptive text of the error.
To improve grouping accuracy, Flashduty removes variable attributes from stack frames, such as version numbers, IDs, dates, and other dynamic parameters.
Custom Fingerprinting#
If default grouping doesn't meet your needs, you can take complete control of error grouping behavior by providing custom fingerprints. Custom fingerprints take precedence over default fingerprints.1.
Manually Add Custom FingerprintsWhen manually reporting errors, add custom fingerprints through addError: 2.
Dynamically set fingerprints through the beforeSend callback: Custom fingerprints must be string type.
Errors with the same fingerprint in the same service will be grouped into the same issue.
Errors from different services will be grouped into different issues even if they have the same fingerprint.
The beforeSend callback can also be used to filter out irrelevant errors (such as third-party script errors).
Web-Specific Considerations#
Upload sourcemap files to decode compressed stack traces, ensuring that error stacks in aggregated issues can be mapped to original source code.
Example: Use flashcat-cli to upload sourcemaps: Third-Party Script Errors:By default, Flashduty filters out errors from browser extensions or third-party scripts (such as those with network origin) to reduce noise.
You can further customize filtering rules through beforeSend: Viewing and Analyzing Grouping Results#
On the Flashduty platform, navigate to "Error Tracking" to view the list of aggregated issues. Each issue includes:Error messages and stack traces (if sourcemaps were uploaded, original source code locations will be displayed).
Metadata (such as browser type, version number).
Next Steps#
微信扫码交流