From 78fbd138133c41e6b5a147b0dcd43ebf5a0c80d5 Mon Sep 17 00:00:00 2001 From: ysyneu Date: Tue, 17 Mar 2026 19:54:10 +0800 Subject: [PATCH 1/2] docs: comprehensive coverage audit fixes across all modules MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Coverage audit scanned 9 source repos against all doc modules, identified 29 findings (1 high, 15 medium, 13 low) and fixed 25 of them. Key changes: - Add Telegram and Zoom notification channel docs (new pages) - Fix flapping detection default (was "off", actually enabled) - Fix rate limit contradiction (200qps → 100qps) - Document pipeline processing order (Enrich → Pipeline → Route) - Document recovery events bypassing pipeline - Add AI Summary feature docs with model selection - Add Explorer saved views docs for RUM - Add missing IM platforms (Slack, Teams) in escalation rules - Document configurable snooze presets - Add OIDC scopes required-field warning - Expand monitors dashboard FAQ and engine API key docs - Add mobile app device binding docs Co-Authored-By: Claude Opus 4.6 --- docs.json | 8 +- en/monitors/engine/engine.mdx | 7 ++ en/monitors/faq/faq.mdx | 17 ++-- en/on-call/channel/create-edit.mdx | 4 + en/on-call/channel/escalation-rule.mdx | 2 +- en/on-call/channel/noise-reduction.mdx | 19 ++++- .../configuration/personal-settings.mdx | 31 ++++++- .../incident/handle-update-incident.mdx | 6 +- en/on-call/incident/search-view-incident.mdx | 20 ++++- en/on-call/incident/what-is-incident.mdx | 2 +- .../alert-integration/alert-pipelines.mdx | 24 +++++- .../alert-integration/routing-rules.mdx | 20 ++++- .../integration/instant-messaging/slack.mdx | 10 +++ .../instant-messaging/telegram.mdx | 70 ++++++++++++++++ .../integration/instant-messaging/zoom.mdx | 84 +++++++++++++++++++ .../integration/webhooks/custom-actions.mdx | 3 +- en/platform/configure-sso.mdx | 15 ++++ en/rum/error-tracking/error-viewing.mdx | 27 +++++- en/rum/error-tracking/issue-alerts.mdx | 13 ++- en/rum/explorer/overview.mdx | 35 ++++++++ en/rum/quickstart/app-management.mdx | 9 ++ zh/monitors/engine/engine.mdx | 7 ++ zh/monitors/faq/faq.mdx | 17 ++-- zh/on-call/channel/create-edit.mdx | 4 + zh/on-call/channel/escalation-rule.mdx | 2 +- zh/on-call/channel/noise-reduction.mdx | 19 ++++- .../configuration/personal-settings.mdx | 31 ++++++- .../incident/handle-update-incident.mdx | 6 +- zh/on-call/incident/search-view-incident.mdx | 20 ++++- zh/on-call/incident/what-is-incident.mdx | 2 +- .../alert-integration/alert-pipelines.mdx | 22 ++++- .../alert-integration/routing-rules.mdx | 20 ++++- .../integration/instant-messaging/slack.mdx | 10 +++ .../instant-messaging/telegram.mdx | 70 ++++++++++++++++ .../integration/instant-messaging/zoom.mdx | 84 +++++++++++++++++++ .../integration/webhooks/custom-actions.mdx | 3 +- zh/platform/configure-sso.mdx | 17 +++- zh/rum/error-tracking/error-viewing.mdx | 27 +++++- zh/rum/error-tracking/issue-alerts.mdx | 31 ++++--- zh/rum/explorer/overview.mdx | 35 ++++++++ zh/rum/quickstart/app-management.mdx | 9 ++ 41 files changed, 789 insertions(+), 73 deletions(-) create mode 100644 en/on-call/integration/instant-messaging/telegram.mdx create mode 100644 en/on-call/integration/instant-messaging/zoom.mdx create mode 100644 zh/on-call/integration/instant-messaging/telegram.mdx create mode 100644 zh/on-call/integration/instant-messaging/zoom.mdx diff --git a/docs.json b/docs.json index c2626b0..673cabf 100644 --- a/docs.json +++ b/docs.json @@ -218,7 +218,9 @@ "zh/on-call/integration/instant-messaging/wecom", "zh/on-call/integration/instant-messaging/dingtalk", "zh/on-call/integration/instant-messaging/slack", - "zh/on-call/integration/instant-messaging/microsoft-teams" + "zh/on-call/integration/instant-messaging/microsoft-teams", + "zh/on-call/integration/instant-messaging/telegram", + "zh/on-call/integration/instant-messaging/zoom" ] }, { @@ -622,7 +624,9 @@ "en/on-call/integration/instant-messaging/wecom", "en/on-call/integration/instant-messaging/dingtalk", "en/on-call/integration/instant-messaging/slack", - "en/on-call/integration/instant-messaging/microsoft-teams" + "en/on-call/integration/instant-messaging/microsoft-teams", + "en/on-call/integration/instant-messaging/telegram", + "en/on-call/integration/instant-messaging/zoom" ] }, { diff --git a/en/monitors/engine/engine.mdx b/en/monitors/engine/engine.mdx index 9e4c742..62a9f36 100644 --- a/en/monitors/engine/engine.mdx +++ b/en/monitors/engine/engine.mdx @@ -75,6 +75,13 @@ API Keys are used for authentication between the alert engine and the SaaS. You | **Rename** | Click the Key name to edit and rename it | | **Delete** | Delete unused API Keys; requires the API Key delete permission | +The management panel also displays the current status of each API Key: + +| Status | Description | +|--------|-------------| +| **Enabled** (green icon) | The API Key is active; engine instances can use it to communicate with the SaaS | +| **Disabled** (yellow icon) | The API Key has been disabled; engine instances using it will be unable to communicate with the SaaS | + After deleting an API Key, all engine instances using that Key will be unable to communicate with the SaaS. Ensure you have switched related engines to another valid API Key before deletion. diff --git a/en/monitors/faq/faq.mdx b/en/monitors/faq/faq.mdx index f387a80..60e1554 100644 --- a/en/monitors/faq/faq.mdx +++ b/en/monitors/faq/faq.mdx @@ -23,11 +23,18 @@ On the alert rules list page, there is a **Debug Log Switch** that you can enabl **Menu Entry**: Overview -The overview page provides a global view of alert rules, including: - -- **Rule Statistics**: Displays the total number of alert rules and the distribution across statuses -- **Channel Distribution**: Shows the number of associated alert rules per channel -- **Problem List**: Displays currently triggered alert events, helping you quickly identify active issues +The overview page provides a global view of alert rules, consisting of the following cards: + +| Card | Description | +|------|-------------| +| **Alert rule total trend** | An area chart showing how the total number of alert rules changes over time. The x-axis represents dates and the y-axis represents rule count, helping you track overall growth or reduction trends | +| **Alert rules by channel** | A pie chart showing the distribution of alert rules across channels. The top 10 channels are displayed by default; the remainder are aggregated as "Others." You can click to expand and view all details | +| **Triggered rules by top-level group** | Shows the health status of alert rules by top-level group. Each group displays as a card with a "normal/total" ratio and progress bar. Green indicates all normal; red indicates rules currently triggered. Click a card to jump to that group's rule list | +| **System event list** | Displays system events generated by the alert engine (such as engine disconnection, configuration anomalies, etc.), with pagination and delete support, helping you promptly discover and address infrastructure-level issues | + + +The overview page checks whether you have installed an alert engine. If not, a prompt guides you to the alert engine page to complete installation. + diff --git a/en/on-call/channel/create-edit.mdx b/en/on-call/channel/create-edit.mdx index 532f54f..f03f749 100644 --- a/en/on-call/channel/create-edit.mdx +++ b/en/on-call/channel/create-edit.mdx @@ -51,6 +51,9 @@ Proper planning can significantly improve operational efficiency. - **Auto-close after incident trigger**: Timer starts from when the incident is first triggered, suitable for alerts without automatic recovery - **Auto-close after alerts stop merging**: Timer starts from the last alert merge, suitable for scenarios with alert grouping enabled + + Enabled by default. When enabled, incidents automatically close when all associated alerts recover. When disabled, alert recovery does not auto-close the incident — you need to close it manually or rely on the auto-close timeout policy. + When enabled, incident lists and notification content will include an "Outlier Incident" indicator for quick identification. [Learn more](/en/on-call/incident/outlier-incidents) @@ -128,6 +131,7 @@ Go to Channel Details → **Basic Settings** to modify: - Channel name, description - Management team - Auto-close timeout policy +- Close with alerts toggle ### Disabling and Deleting diff --git a/en/on-call/channel/escalation-rule.mdx b/en/on-call/channel/escalation-rule.mdx index dbdc813..4e68831 100644 --- a/en/on-call/channel/escalation-rule.mdx +++ b/en/on-call/channel/escalation-rule.mdx @@ -69,7 +69,7 @@ Determines how users are reached. Send to instant messaging groups, with support for @ mentioning relevant personnel. - - **IM App Groups**: Supports Feishu/Lark, Dingtalk, WeCom groups, requires completing [IM Integration](/en/on-call/integration/instant-messaging/lark) first + - **IM App Groups**: Supports Feishu/Lark, Dingtalk, WeCom, Slack, and Microsoft Teams groups, requires completing [IM Integration](/en/on-call/integration/instant-messaging/lark) first - **Group Bots**: Supports Feishu/Lark, Dingtalk, WeCom, Telegram, Zoom, and other Webhook bots. Telegram requires configuring a Webhook notification address and Chat IDs, Zoom requires configuring a Webhook address and Verify Token, and supports enabling @ mention functionality. See [Notification Channel Configuration](/en/on-call/configuration/notifications) diff --git a/en/on-call/channel/noise-reduction.mdx b/en/on-call/channel/noise-reduction.mdx index 90e6299..3e4b804 100644 --- a/en/on-call/channel/noise-reduction.mdx +++ b/en/on-call/channel/noise-reduction.mdx @@ -100,6 +100,7 @@ Flashduty On-call provides two grouping modes: | Configuration | Description | | :------- | :----------------------------------- | | **Grouping Window** | Only group alerts within the time window, alerts outside the window trigger new incidents | +| **Window Type** | **Tumbling** (default): Fixed timer starts from incident creation, stops grouping when the window duration is reached. **Sliding**: Timer resets each time a new alert merges in, the window recalculates from the last merge | | **Alert Storm Warning** | When merged alert count reaches the configured threshold, the system records an alert storm event in the incident timeline and triggers a warning notification, prompting urgent handling | | **Strict Grouping** | When enabled, empty label values are treated as different; when disabled, empty values are treated as the same (not supported for intelligent grouping) | @@ -178,10 +179,22 @@ Go to Channel Details → Noise Reduction → **Flapping Detection**: | Option | Behavior | | :-------- | :--------------- | -| **Off** | Don't detect flapping status (default) | +| **Off** | Don't detect flapping status | | **Alert Only** | Mark flapping status, continue notifications per policy | | **Alert Then Silence** | Mark flapping status, no more notifications after first alert | + + Flapping detection is enabled by default for new channels (Alert Only mode). + + +### Configurable Parameters + +| Parameter | Description | Default | Range | +| :--- | :--- | :--- | :--- | +| **State changes** (max_changes) | Number of alert state changes within the observation window to trigger flapping detection | 4 | 2–100 | +| **Observation window** (in_mins) | Time window for counting state changes | 60 minutes | 1–1440 minutes | +| **Mute duration** (mute_mins) | Duration to mute notifications after flapping is detected (only applies in "Alert Then Silence" mode) | 120 minutes | 0–1440 minutes | + "Same incident" refers to incidents with the same Alert Key, typically using the alert ID pushed from the upstream system as a unique identifier. @@ -314,8 +327,8 @@ When a new alert meets conditions, and there's an **active incident** (not close Up to 5000, mainly to ensure console rendering performance. Due to backend concurrent processing, actual count may slightly exceed this limit. - - **Rule-based Grouping**: No limit, maximum grouping window is 24 hours. After 24 hours from alert trigger, new events create new incidents - - **Intelligent Grouping**: No limit, maximum grouping window is 30 days. After 30 days from alert trigger, new events create new incidents + - **Rule-based Grouping**: No limit, default maximum grouping window is 24 hours. After 24 hours from alert trigger, new events create new incidents + - **Intelligent Grouping**: No limit, default maximum grouping window is 24 hours, with certain subscription plans supporting extension up to 30 days. After exceeding the window, new events create new incidents diff --git a/en/on-call/configuration/personal-settings.mdx b/en/on-call/configuration/personal-settings.mdx index edb8b62..09a217d 100644 --- a/en/on-call/configuration/personal-settings.mdx +++ b/en/on-call/configuration/personal-settings.mdx @@ -73,12 +73,39 @@ APP Keys are used for API request authentication. --- +### Download the app + | Platform | Download Method | | --- | --- | | **iOS** | Search "Flashduty" in App Store | -| **Android** | Download from major app stores (Harmony OS not currently supported) | +| **Android** | Available on major app stores including Xiaomi, Huawei, Honor, OPPO, and vivo — search "Flashduty" to download (Harmony OS not currently supported) | + +If your phone brand is not listed above, you can click **Download here** on the APP management page to get an installation package QR code. Scan it with your phone to download. + +### Device binding + +After installing the app, you need to bind your mobile device to your Flashduty account to receive push notifications. + + + +Navigate to **Personal Center → Flashduty APP**. + + +The page displays a QR code. Open the Flashduty APP, tap the "Scan to Login" button, and scan the QR code on the page to complete device binding. + + + +Once bound, the page displays a list of linked devices, including device name, OS version, and device identifier. To unbind a device, hover over the device card and click the **Unbind** button. + + +- Binding a device does not automatically enable notifications — the actual notification method depends on your escalation rule settings +- After unbinding a device, it will no longer receive push notifications +- The QR code has an expiration time; the page automatically refreshes to generate a new QR code when it expires + + +### Push notifications -After downloading, select a login method to complete account linking. We recommend enabling system notification permissions and allowing urgent incident notifications in Do Not Disturb mode. +The Flashduty APP supports free push notifications for alerts, ensuring critical alerts reach you instantly. You can acknowledge, resolve, and escalate alerts anytime, anywhere from your mobile device. We recommend enabling system notification permissions and allowing urgent incident notifications in Do Not Disturb mode to avoid missing important alerts. ## FAQ diff --git a/en/on-call/incident/handle-update-incident.mdx b/en/on-call/incident/handle-update-incident.mdx index 12ce208..a9446e4 100644 --- a/en/on-call/incident/handle-update-incident.mdx +++ b/en/on-call/incident/handle-update-incident.mdx @@ -95,7 +95,11 @@ You can view each person's assignment time and acknowledgment time in the consol ## Snooze -After acknowledging an incident, responders may need time to investigate and handle it. **Snooze** can temporarily stop the incident from escalating per the expected escalation rule. After acknowledging, you can set a snooze duration such as 2 hours, 4 hours, 12 hours, or a custom expiration time within 24 hours. +After acknowledging an incident, responders may need time to investigate and handle it. **Snooze** can temporarily stop the incident from escalating per the expected escalation rule. After acknowledging, you can choose from preset durations (default: 2 hours, 4 hours, 12 hours) or set a custom expiration time within 24 hours. + + +Account administrators can customize the 3 snooze preset durations in **Account Settings** (in minutes, each value must be greater than 0 and no more than 24 hours). Changes take effect for all members. + If you've snoozed and the snooze time has passed but you still haven't resolved the incident, the system automatically reverts the incident to **Triggered** status and re-initiates assignment notifications. diff --git a/en/on-call/incident/search-view-incident.mdx b/en/on-call/incident/search-view-incident.mdx index 28905c9..f4ff21b 100644 --- a/en/on-call/incident/search-view-incident.mdx +++ b/en/on-call/incident/search-view-incident.mdx @@ -78,7 +78,7 @@ Incident details is the main entry point for investigating incidents, displaying | :---: | :--- | :--- | | 1 | Key Information | Incident title, severity, processing progress, ID number | | 2 | Action Area | Various high-frequency action buttons; more actions include custom actions and low-frequency buttons; War Room creation requires enabling [War Room](/en/on-call/advanced/war-room) in IM integration | -| 3 | Details | Incident description, label info; AI Summary can quickly extract incident details and output in three dimensions: event overview, impact scope, and actionable measures; labels support drag-to-sort and JSON view display | +| 3 | Details | Incident description, label info, and AI Summary (see below for details); labels support drag-to-sort and JSON view display | | 4 | Associated Alerts | All [grouped](/en/on-call/channel/noise-reduction) alerts associated with the incident, supports filtering by progress and view switching | | 5 | Comprehensive Info | Shows incident attributes, processing status, [images](https://developer.flashcat.cloud/api-344943718), and responder info | | 6 | Custom Fields | Custom field configuration area | @@ -104,10 +104,28 @@ The change event list displays the following information: You can adjust the query scope through the filter at the top, including time range and change source. Expand any row to view a timeline visualization of that change event, allowing comparison with the incident trigger time. +### AI Summary + +The incident details page supports one-click AI summary generation to help you quickly understand the full picture of an incident. Click the **AI Summary** button in the details area, and the system will automatically generate a structured summary based on the incident's associated alerts (up to 20), including: + +- **Summary**: A one-sentence description of what happened +- **Impacts**: Key affected resources such as services, systems, environments, and instances +- **Actions**: Immediately actionable investigation and remediation steps (up to 3) + +You can choose from different AI models (default is DeepSeek V3) and regenerate as needed. The generated summary supports real-time streaming output and can be saved as the incident description. + + +AI Summary is only available for incidents automatically triggered by alerts. Manually created incidents do not support this feature. + + ### Images When alerts associated with the incident include image information reported via API, the incident details right panel displays an **Images** section. You can click image thumbnails to preview them, and hover to view the Alt description and source links. +### Linked External Tickets + +If you have configured ticket integrations such as Jira, ServiceNow, or ServiceDesk Plus, the comprehensive info area in the incident details right panel displays linked external ticket information. You can click directly to navigate to the corresponding external ticket system and view details. + ## FAQ diff --git a/en/on-call/incident/what-is-incident.mdx b/en/on-call/incident/what-is-incident.mdx index 4841d6a..b0ecb50 100644 --- a/en/on-call/incident/what-is-incident.mdx +++ b/en/on-call/incident/what-is-incident.mdx @@ -123,7 +123,7 @@ Flashduty On-call supports dedicated and shared integration modes: Flashduty On-call provides a custom event standard, allowing you to report alerts via standard protocol, suitable for any non-integrated monitoring system. For details, read [Custom Alert Events](https://developer.flashcat.cloud/api-110655782). -To ensure system stability, Flashduty On-call has a **200qps** rate limit for API reporting. Exceeding this limit will reject reports. +To ensure system stability, Flashduty On-call enforces rate limits per integration (**100 requests/second**, **1000 requests/minute**). Exceeding these limits returns a `429` status code — please wait and retry. See [Integrate Data - Rate Limits](/en/on-call/channel/integrate-data#rate-limits) for details. diff --git a/en/on-call/integration/alert-integration/alert-pipelines.mdx b/en/on-call/integration/alert-integration/alert-pipelines.mdx index f1b5bb5..d70ebd7 100644 --- a/en/on-call/integration/alert-integration/alert-pipelines.mdx +++ b/en/on-call/integration/alert-integration/alert-pipelines.mdx @@ -16,9 +16,25 @@ description: "Cleanse, format, and preprocess data at the alert ingestion source */} +## Processing Order + +After an alert event enters Flashduty, it passes through three stages in sequence: + +| Stage | Description | +| :--- | :--- | +| **① Label Enhancement (Enrich)** | Dynamically generate or modify alert labels, such as querying CMDB via API to supplement business information | +| **② Alert Processing (Pipeline)** | Cleanse, transform, and filter alert data (the feature described in this document) | +| **③ Route Distribution (Route)** | Distribute events to corresponding channels based on alert attributes | + +Since label enhancement runs before Pipeline, Pipeline match conditions **can reference labels added or modified during the enrichment stage**. + + +Recovery events (event_status is Ok) bypass the alert processing Pipeline entirely and go directly into the alert merge flow. Therefore, discard, inhibition, rewrite, and other rules configured in Pipeline do not apply to recovery events. + + ## How It Works -Pipeline sits between **Alert Ingestion** and **Route Distribution**. Its execution logic is as follows: +Pipeline sits between **Label Enhancement** and **Route Distribution**. Its execution logic is as follows: 1. **Chain Processing**: You can configure multiple processing rules that execute sequentially **from top to bottom** 2. **Input/Output**: The result of a previous rule (e.g., modified title) can serve as input for the next rule @@ -85,12 +101,14 @@ Discard directly before data storage, leaving no records. This is similar to "Ex ### Alert Inhibition -Pipeline's inhibition feature is **exactly the same** as channel inhibition rules, both supporting dependency-based inhibition based on source incident, target incident, and correlation conditions. +Pipeline's inhibition feature is similar to channel inhibit rules, both supporting dependency-based inhibition based on source alert, target alert, and correlation conditions. Note that Pipeline inhibition only matches source alerts **within the same integration**, while channel inhibition matches across all alerts in the channel. | Comparison | Pipeline Inhibition | Channel Inhibition | | :--- | :--- | :--- | | Effective Layer | Integration layer | Channel layer | -| Use Case | **Global** inhibition logic, like inhibiting all alerts from a datacenter after network outage | Inhibition rules for specific channels | +| Match Scope | Only matches active alerts within the same integration | Matches all active alerts within the channel | +| Use Case | **Global** inhibition logic, like inhibiting all alerts from a datacenter after network outage | Inhibit rules for specific channels | +| Plan Requirement | Requires Standard plan or above | Requires Standard plan or above | When an entire datacenter loses network, all alerts from that datacenter (regardless of business line) should be inhibited. Configuring one rule at the integration layer is much more efficient than configuring separately in dozens of channels. diff --git a/en/on-call/integration/alert-integration/routing-rules.mdx b/en/on-call/integration/alert-integration/routing-rules.mdx index 4174f7e..85e61c2 100644 --- a/en/on-call/integration/alert-integration/routing-rules.mdx +++ b/en/on-call/integration/alert-integration/routing-rules.mdx @@ -46,9 +46,9 @@ When using name mapping mode, if corresponding channel doesn't exist, delivers t | Feature | Description | | :--- | :--- | -| Adjust Order | Use up/down arrows or drag rules to adjust match priority by channel | -| Insert Rule | Quickly insert new rules before/after specified rule | -| Filter Rules | Filter all rules delivering to a channel by that channel | +| Adjust Order | Use up/down arrows or drag rules to adjust match priority; also supports grouping and sorting by channel for easier management of large rule sets | +| Insert Rule | Quickly insert new rules before or after a specified rule without manually dragging to adjust position | +| Filter Rules | Filter by channel to quickly locate all rules delivering to a specific channel, ideal for scenarios with many rules | | Edit History | View historical configuration versions, compare differences, and quickly restore (see details below) | ### Edit History @@ -119,6 +119,20 @@ Before using name mapping mode, ensure channel names exactly match label values, +## Subscribe Rules + +In addition to routing rules, the system also supports **subscribe rules**. Subscribe rules run after routing rules and are used to additionally deliver alerts to interested channels without affecting the original routing logic. + +| Comparison | Routing Rules | Subscribe Rules | +| :--- | :--- | :--- | +| Configuration Location | Integration Details → Routing tab | Channel → Subscribe Settings | +| Execution Order | Runs first | Runs after | +| Purpose | Determine which channels alerts are delivered to | Additionally deliver matching alerts to the current channel | + + +Channels matched by routing rules and subscribe rules are automatically deduplicated — the same alert will not generate duplicate incidents in the same channel. + + ## FAQ diff --git a/en/on-call/integration/instant-messaging/slack.mdx b/en/on-call/integration/instant-messaging/slack.mdx index 9674c23..609b9e6 100644 --- a/en/on-call/integration/instant-messaging/slack.mdx +++ b/en/on-call/integration/instant-messaging/slack.mdx @@ -31,6 +31,16 @@ After completing the previous steps, in the Flashduty On-call integration config Only one IM integration can have War Room enabled at a time. If you've already enabled War Room in another IM integration (such as Dingtalk, Feishu/Lark, or WeCom), you need to disable it there first before enabling it in the current Slack integration. +### Permission verification and re-authorization + +When enabling War Room, the system automatically verifies whether the current Slack app has all the permissions required for War Room. If missing permissions are detected, a warning message appears on the page with a **Re-authorize** link. + +Click the **Re-authorize** link to be redirected to the Slack authorization page, which requests the additional permissions needed for War Room functionality (including channel management, message read/write, user info reading, etc.). After completing authorization, the page automatically returns to Flashduty, and you can then enable War Room normally. + + +If your Slack integration was authorized before the War Room feature was released, you will typically need to re-authorize on first use to add the new permissions. Re-authorization does not affect your existing integration configuration or user associations. + + ## 3. Linked Users In the **Linked Users** tab of the integration detail page, you can view the linking status between team members and Slack accounts, and quickly complete batch linking. diff --git a/en/on-call/integration/instant-messaging/telegram.mdx b/en/on-call/integration/instant-messaging/telegram.mdx new file mode 100644 index 0000000..5f65beb --- /dev/null +++ b/en/on-call/integration/instant-messaging/telegram.mdx @@ -0,0 +1,70 @@ +--- +title: "Telegram bot" +description: "Configure a Telegram bot to push alert notifications to Telegram group chats" +keywords: ["Telegram", "instant messaging", "alert notification", "bot", "group chat notification"] +--- + +Telegram bot is a group chat notification channel. You can configure a Telegram bot in a channel's escalation rule to push incident notifications to specified Telegram group chats. + +## Prerequisites + +Before configuring, you need to create a Telegram Bot and obtain the following information: + +1. **Bot Token / Webhook URL**: The Token obtained after creating a Bot via [BotFather](https://t.me/BotFather), or an accessible Telegram service proxy address. +2. **Chat ID**: The Chat ID of the group where you want to receive notifications. You can obtain the group Chat ID by adding the Bot to the group and using the Telegram API. + + +Telegram services may not be directly accessible in some regions. Ensure the Webhook URL you use is accessible in your current network environment. + + +## Configuration steps + +Add a Telegram bot notification channel in a channel's escalation rule: + + + +Go to Channel Details → Escalation Rule → Select or create a level → Under notification methods, select **Group Chat Notification** → **Telegram**. + + + +Enter the Bot Token or an accessible Telegram service proxy address. + +If you have previously configured a bot of the same type, the system displays historical records in the dropdown for quick selection. + + + +Enter the Chat IDs of the groups that should receive notifications. Multiple Chat IDs are supported. Press Enter after each ID to confirm, and the system displays them as tags. + + + +You can set an alias for this bot to help you remember and distinguish different notification channels. + + + +Expand **Advanced Settings** to configure severity filtering: + +| Setting | Description | +| :--- | :--- | +| **Severity filter** | Select which alert severity levels trigger notifications. Incidents with unselected severity levels will not be pushed to this Telegram group | + + + +After completing the configuration, save the escalation rule to apply changes. + + + +## FAQ + + + +Check whether the Webhook URL is accessible in your current network environment. Telegram services may be restricted in some regions. Consider using a reliable proxy service address. + + + +After adding the Bot to the target group, you can call the Telegram Bot API `getUpdates` method to obtain the group Chat ID. You can also use tools like [@userinfobot](https://t.me/userinfobot). + + + +Yes. Enter multiple Chat IDs in the Chat IDs field to push notifications to multiple groups at the same time. + + diff --git a/en/on-call/integration/instant-messaging/zoom.mdx b/en/on-call/integration/instant-messaging/zoom.mdx new file mode 100644 index 0000000..65bd574 --- /dev/null +++ b/en/on-call/integration/instant-messaging/zoom.mdx @@ -0,0 +1,84 @@ +--- +title: "Zoom bot" +description: "Configure a Zoom bot to push alert notifications to Zoom" +keywords: ["Zoom", "instant messaging", "alert notification", "bot", "group chat notification"] +--- + +Zoom bot is a group chat notification channel. You can configure a Zoom bot in a channel's escalation rule to push incident notifications to Zoom, with support for @ mentioning relevant responders. + +## Prerequisites + +Before configuring, you need to create a Chatbot application in the [Zoom Marketplace](https://marketplace.zoom.us/) and obtain the following information: + +1. **Webhook URL or Token**: The Webhook URL or Token of the Zoom Chatbot. +2. **Verify Token**: The Verify Token used to authenticate request origins. + +## Configuration steps + +Add a Zoom bot notification channel in a channel's escalation rule: + + + +Go to Channel Details → Escalation Rule → Select or create a level → Under notification methods, select **Group Chat Notification** → **Zoom**. + + + +Enter the Zoom Chatbot's Webhook URL or Token. + +If you have previously configured a bot of the same type, the system displays historical records in the dropdown for quick selection. Upon selection, the system automatically fills in the associated Verify Token. + + + +Enter the Zoom Chatbot's Verify Token, used to verify request authenticity. + + + +You can set an alias for this bot to help you remember and distinguish different notification channels. + + + +Expand **Advanced Settings** to configure the following: + +**@ Mentions** + +| Setting | Description | +| :--- | :--- | +| **Enable @ mentions** | When enabled, the system uses data from the user mapping table to @ mention corresponding responders | +| **User mapping table** | Required when @ mentions are enabled. Select a pre-created user mapping table to map Flashduty users to Zoom users. You can also click the **Quick Create Mapping Table** link to create one | + + +The user mapping table defines the correspondence between Flashduty users and Zoom users. You can create and maintain mapping tables on the **Mapping Table Management** page. + + +**Notification event types** + +Select which event types trigger Zoom notification pushes. All are selected by default. You can choose specific event types as needed (such as triggered, acknowledged, closed, etc.). + +**Severity filter** + +Select which alert severity levels trigger notifications. Incidents with unselected severity levels will not be pushed to Zoom. + + + +After completing the configuration, save the escalation rule to apply changes. + + + +## FAQ + + + +Verify the following: +- The **@ mentions** toggle is enabled +- A **user mapping table** is correctly selected +- The user mappings in the table are correct and complete + + + +You can find the Verify Token on your Chatbot application's configuration page in the Zoom Marketplace. This token is used to verify the authenticity of Webhook requests. + + + +Go to Platform Management → Mapping Table Management to create a Zoom-type user mapping table. You can also click the **Quick Create Mapping Table** link when configuring the Zoom bot to navigate directly to the creation page. + + diff --git a/en/on-call/integration/webhooks/custom-actions.mdx b/en/on-call/integration/webhooks/custom-actions.mdx index be23835..584b9c7 100644 --- a/en/on-call/integration/webhooks/custom-actions.mdx +++ b/en/on-call/integration/webhooks/custom-actions.mdx @@ -7,7 +7,8 @@ Configure incident custom actions, allowing you to quickly call external interfa 3. Configure Action Name—this name will appear as a button in incident details 4. Configure Channels—you can configure multiple, but each channel can have at most **5** Custom Actions 5. Configure Endpoint and custom Headers -6. Save to complete +6. If the target service uses a self-signed certificate or a certificate issued by an internal CA, you can enable the **Skip TLS Verification** option so the system will not validate the server certificate +7. Save to complete Each channel can have a maximum of 5 custom actions. If a channel has reached this limit, it cannot be selected when adding a new custom action. diff --git a/en/platform/configure-sso.mdx b/en/platform/configure-sso.mdx index ca2fd49..e165063 100644 --- a/en/platform/configure-sso.mdx +++ b/en/platform/configure-sso.mdx @@ -38,6 +38,10 @@ Flashduty supports Single Sign-On (SSO) via SAML2.0, OIDC, CAS, and LDAP (privat | Scopes | Specifies the information and functionality permissions the request can access, with support for customization. Defaults to `openid`, `profile`, `email`, `phone`; you can add custom scopes as tags | | Flashduty Service Provider Info | **Redirect URL**: Identity provider callback address
**Supported Signing Algorithms**: RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512 (HS256 not supported) | + +Scopes is a required field. The default values `openid`, `profile`, `email`, `phone` are the base permissions needed for OIDC to function properly. Removing these defaults may cause single sign-on to fail or prevent correct retrieval of user information. If you need to add custom scopes, add them while keeping the defaults intact. + + ## Configuring CAS Protocol --- @@ -127,6 +131,17 @@ The login domain is an important identifier for your account, used to locate the After configuring the login domain, members can initiate single sign-on directly through the `{domain}.sso.flashcat.cloud` address without manually selecting an identity provider. +You can modify the account domain on the **Platform Management → Basic Information** page. The domain must be 5–40 characters long and can only contain letters, numbers, or `-`, and cannot start or end with `-`. + + +After changing the domain, it will apply to the following scenarios: + +- **SSO single sign-on configuration**: All configured SSO login domains will change accordingly. Members will need to use the new domain to initiate single sign-on +- **Email integration push addresses**: The email integration receiving address format is `prefix@{domain}.{email-suffix}`. The address changes when the domain changes, so update related configurations promptly + +Before modifying, ensure you have checked your email integration configuration and notified your organization. The modification may require multi-factor authentication (MFA) verification. If you encounter any issues, contact technical support promptly. + + - It is recommended to use your company's English name as the login domain for easy memorization - Once set, changing the login domain will immediately invalidate the old domain; members using the old domain will need to update their login address diff --git a/en/rum/error-tracking/error-viewing.mdx b/en/rum/error-tracking/error-viewing.mdx index 5349478..e31dfd2 100644 --- a/en/rum/error-tracking/error-viewing.mdx +++ b/en/rum/error-tracking/error-viewing.mdx @@ -112,10 +112,31 @@ When hovering over an error cause classification, the system will use AI capabil The system uses a two-layer analysis mechanism to classify errors: -1. **Pattern Matching**: The rule engine first analyzes the error type and error message. For example, HTTP 4xx/5xx status codes are classified as API request failures, `TypeError` containing "Cannot read property of undefined" is classified as illegal object access, and errors containing "timeout" or "connection" are classified as network errors. -2. **AI Inference**: When pattern matching cannot determine the classification, the system invokes an AI model that analyzes the error message, stack trace, and platform type (browser, Android, iOS, Flutter, React Native, etc.) to provide an intelligent classification along with a brief explanation of the cause. +**Layer 1: Pattern Matching** -AI inference results are displayed as hover tooltips on the Issue card, showing the inferred error category and a specific cause explanation. +The rule engine checks error types and messages in priority order; the first matching rule determines the classification: + +| Check Order | Match Condition | Classification | +|-------------|-----------------|----------------| +| 1 | Error message contains "Unexpected token ... is not valid JSON" | Invalid Parameter | +| 2 | Associated resource HTTP status code is 4xx or 5xx | API Request Failed | +| 3 | Error type contains "Network" or "AbortError" | Network Error | +| 4 | Error type contains "Syntax", "Reference", "Range", "URI", or "Eval" | Code Error | +| 5 | Error type is TypeError and message matches null access patterns (e.g., "Cannot read property of undefined") | Illegal Object Access | +| 6 | Error message matches invalid argument patterns (e.g., "invalid argument", "unexpected token") | Invalid Parameter | +| 7 | Error message contains "API ERROR:" or license-related errors | API Request Failed | +| 8 | Error message contains network connection keywords (e.g., "timeout", "connection", "dns") | Network Error | +| 9 | None of the above matched | Unknown Error | + +**Layer 2: AI Inference** + +When pattern matching results in "Unknown Error", the system invokes an AI model for deeper analysis. The AI model evaluates the following information: + +- **Error Message**: The error description text +- **Stack Trace**: The complete call stack +- **Platform Type**: Browser/JavaScript, Android/Kotlin/Java, iOS/Swift/Objective-C, Flutter/Dart, React Native, Unity/C#, etc. + +The AI outputs an error classification and a brief cause explanation (up to 100 words). Inference results are displayed as hover tooltips on the Issue card, helping you quickly understand the root cause of the error. ## Regression diff --git a/en/rum/error-tracking/issue-alerts.mdx b/en/rum/error-tracking/issue-alerts.mdx index 612813d..f4ae369 100644 --- a/en/rum/error-tracking/issue-alerts.mdx +++ b/en/rum/error-tracking/issue-alerts.mdx @@ -98,7 +98,7 @@ Each grading rule consists of the following elements: | **Match Conditions** | Filter conditions based on Error attributes; multiple conditions within a rule use AND logic | | **Alert Level** | Priority assigned on match: P0 (Critical) / P1 (Warning) / P2 (Info) | -Rules are matched in priority order; the first match takes effect. +Rules are evaluated from top to bottom in priority order; **the first matching rule takes effect immediately**, and subsequent rules are not checked. You can drag and drop rules to adjust their priority order. #### Supported Match Fields @@ -106,17 +106,16 @@ Rules are matched in priority order; the first match takes effect. |-------|-------------|---------| | User ID (`error.usr_id`) | User identifier that reported the error | `vip_001` | | User Email (`error.usr_email`) | User email address | `*@vip.com` | +| Page URL (`error.view_url`) | Full page URL where the error occurred | Contains `/payment` | +| Page Path (`error.view_url_path`) | Path portion of the page URL | `/checkout/confirm` | | Error Type (`error.error_type`) | Error type classification | `TypeError`, `SyntaxError` | | Error Message (`error.error_message`) | Error description text | Contains `Cannot read property` | -| Error Stack (`error.error_stack`) | Stack trace information | Contains `undefined` | -| Page URL (`error.view_url`) | Page URL where the error occurred | Contains `/payment` | | Environment (`error.env`) | Environment where the error occurred | `production`, `staging` | -| Version (`error.version`) | Application version number | `1.0.0` | | Service (`error.service`) | Service the error belongs to | `payment` | -| Browser (`error.browser_name`) | Browser name | `Chrome` | +| Device Type (`error.device_type`) | User device type | `mobile`, `desktop` | +| OS Name (`error.os_name`) | User operating system name | `Windows`, `iOS` | +| Browser (`error.browser_name`) | Browser name | `Chrome`, `Safari` | | Is Crash (`error.is_crash`) | Whether it's a crash error | `true` | -| Fingerprint (`error.fingerprint`) | Fingerprint information | `06375381216fe431` | -| Custom Fields (`context`) | Custom attributes reported via context, supports 3 levels of nesting | `context.user.level` | Match operators support "contains" and "not contains". diff --git a/en/rum/explorer/overview.mdx b/en/rum/explorer/overview.mdx index 1e3773f..ae56be2 100644 --- a/en/rum/explorer/overview.mdx +++ b/en/rum/explorer/overview.mdx @@ -75,6 +75,41 @@ Flashduty RUM **Explorer** is a powerful data analysis tool designed to help dev +## Saved Views + +The saved views feature allows you to save your current query state as a reusable view for quickly switching between different analysis scenarios. Each account can create up to **20** saved views, and views are only visible to you. + +### What a View Saves + +Each saved view contains the following information: + +| Saved Item | Description | +|------------|-------------| +| **Time Range** | The currently selected time filter | +| **Query Type** | The currently selected event type (e.g., Sessions, Views, Actions, Errors, etc.) | +| **Query Statement** | The DQL filter conditions in the search bar | +| **Custom Columns** | The column configuration of the data table | + +### View Operations + + + + Click the view menu at the top of the Explorer, select "Save as New View", enter a view name, and confirm. View names must be unique. + + + Click the view menu and select the target view from the list. After switching, the Explorer automatically restores the saved time range, query type, query statement, and column configuration. + + + In the view list, click the action menu on the right side of the target view and select "Edit View" to modify the view name. If you have modified the current view's query conditions, you can also use "Save Changes" to update the view with the latest state. + + + Select "Delete View" from the view list or action menu and confirm. After deleting the currently active view, the Explorer automatically switches back to the default view. + + + Select "Switch to Default View" from the action menu to clear all filter conditions and restore the Explorer to its initial state. + + + ## Next Steps diff --git a/en/rum/quickstart/app-management.mdx b/en/rum/quickstart/app-management.mdx index 52aceca..9fa93af 100644 --- a/en/rum/quickstart/app-management.mdx +++ b/en/rum/quickstart/app-management.mdx @@ -128,6 +128,15 @@ The redirect link must start with `http://` or `https://`. +### Link Open Mode + +Tracing redirect links support two open modes: + +| Open Mode | Description | +|-----------|-------------| +| **Popup** (`popup`) | Opens the trace details in a popup within the current page, without leaving the RUM Explorer. This is the default mode | +| **New Tab** (`tab`) | Opens the trace details in a new browser tab, suitable for scenarios that require more viewing space | + Once configured, you can jump directly from resource details to the corresponding backend trace record via the Trace ID, quickly troubleshooting frontend-backend correlation issues. ## Privacy Settings diff --git a/zh/monitors/engine/engine.mdx b/zh/monitors/engine/engine.mdx index 29b8217..0927e84 100644 --- a/zh/monitors/engine/engine.mdx +++ b/zh/monitors/engine/engine.mdx @@ -75,6 +75,13 @@ API Key 用于告警引擎与 SaaS 端的身份认证。你可以在引擎安装 | **重命名** | 点击 Key 名称即可编辑修改 | | **删除** | 删除不再使用的 API Key，需要具备 API Key 删除权限 | +管理面板中还会展示每个 API Key 的当前状态： + +| 状态 | 说明 | +|------|------| +| **启用中**（绿色图标） | API Key 正常工作，引擎实例可以使用该 Key 与 SaaS 端通信 | +| **禁用中**（黄色图标） | API Key 已被禁用，使用该 Key 的引擎实例将无法与 SaaS 端通信 | + 删除 API Key 后，使用该 Key 的所有引擎实例将无法与 SaaS 端通信。请确保在删除前已将相关引擎切换到其他有效的 API Key。 diff --git a/zh/monitors/faq/faq.mdx b/zh/monitors/faq/faq.mdx index 8532b9c..587992f 100644 --- a/zh/monitors/faq/faq.mdx +++ b/zh/monitors/faq/faq.mdx @@ -24,11 +24,18 @@ keywords: ["常见问题", "FAQ", "调试日志", "故障排查", "monitedge"] **菜单入口**：概览 -概览页面提供告警规则的全局视图，包括： - -- **规则统计**：展示告警规则的总数及各状态的分布情况 -- **协作空间分布**：按协作空间展示关联的告警规则数量 -- **问题列表**：展示当前处于触发状态的告警事件，帮助你快速定位活跃问题 +概览页面提供告警规则的全局视图，由以下卡片组成： + +| 卡片名称 | 说明 | +|----------|------| +| **告警规则总量历史趋势图** | 面积图展示告警规则总数随时间的变化趋势，横轴为日期，纵轴为规则数量，帮助您掌握规则增长或缩减的整体走势 | +| **各协作空间告警规则数量对比** | 饼图展示各协作空间关联的告警规则数量分布。默认显示 Top 10 的协作空间，超出部分汇总为"其他"，可点击展开查看全部详情 | +| **所有顶层分组告警规则触发数量统计** | 按顶层分组展示告警规则的健康度，每个分组显示为一张卡片，包含"正常/总数"比例和进度条。绿色表示全部正常，红色部分表示有触发中的规则。点击卡片可跳转到对应分组的规则列表 | +| **系统事件列表** | 展示告警引擎产生的系统事件（如引擎失联、配置异常等），支持分页浏览和删除操作，帮助您及时发现并处理基础设施层面的问题 | + + +概览页面顶部会检查您是否已安装告警引擎。如果尚未安装，系统会显示引导提示，引导您前往告警引擎页面完成安装。 + diff --git a/zh/on-call/channel/create-edit.mdx b/zh/on-call/channel/create-edit.mdx index c2f923b..158aba5 100644 --- a/zh/on-call/channel/create-edit.mdx +++ b/zh/on-call/channel/create-edit.mdx @@ -52,6 +52,9 @@ keywords: ["协作空间", "创建管理", "业务隔离", "团队协作", "告 - **故障触发后自动关闭**：从故障首次触发开始计时，适合未自动恢复的告警 - **停止合入新告警后自动关闭**：从最后一次合入新告警开始计时，适合开启聚合降噪的场景 + + 默认开启。当该选项开启时，故障关联的所有告警恢复后，故障将自动关闭；当该选项关闭时，告警恢复不会自动关闭故障，您需要手动关闭或依赖超时自动关闭策略。 + 开启后，故障列表及通知内容中将带有"新奇故障"标识，便于快速识别。[了解更多](/zh/on-call/incident/outlier-incidents) @@ -129,6 +132,7 @@ keywords: ["协作空间", "创建管理", "业务隔离", "团队协作", "告 - 空间名称、描述 - 管理团队 - 超时自动关闭策略 +- 跟随告警关闭开关 ### 禁用与删除 diff --git a/zh/on-call/channel/escalation-rule.mdx b/zh/on-call/channel/escalation-rule.mdx index 95e38f7..72ff587 100644 --- a/zh/on-call/channel/escalation-rule.mdx +++ b/zh/on-call/channel/escalation-rule.mdx @@ -70,7 +70,7 @@ src="https://download.flashcat.cloud/flashduty/video/escalate-rule.mp4" 发送到即时通讯软件的群组中，支持 @ 提到相关人员。 - - **IM 应用群**：支持飞书、钉钉、企业微信群，需先完成 [IM 集成](/zh/on-call/integration/instant-messaging/lark) + - **IM 应用群**：支持飞书、钉钉、企业微信、Slack、Microsoft Teams 群，需先完成 [IM 集成](/zh/on-call/integration/instant-messaging/lark) - **群机器人**：支持飞书、钉钉、企业微信、Telegram、Zoom 等 Webhook 机器人。其中 Telegram 需要配置 Webhook 通知地址和群聊 ID（Chat Ids），Zoom 需要配置 Webhook 地址和 Verify Token，并支持开启 @ 提醒功能。详见 [通知渠道配置](/zh/on-call/configuration/notifications) diff --git a/zh/on-call/channel/noise-reduction.mdx b/zh/on-call/channel/noise-reduction.mdx index 58bf938..f03877f 100644 --- a/zh/on-call/channel/noise-reduction.mdx +++ b/zh/on-call/channel/noise-reduction.mdx @@ -101,6 +101,7 @@ Flashduty On-call 提供两种聚合模式： | 配置项 | 说明 | | :------- | :----------------------------------- | | **聚合窗口** | 仅聚合时间窗口内的告警，超出窗口的告警将触发新故障 | +| **窗口类型** | **滚动窗口**（默认）：从故障创建时开始固定计时，到达窗口时长后停止聚合；**滑动窗口**：每次有新告警合入时重置计时，窗口从最后一次合入开始重新计算 | | **风暴预警** | 当合入告警数达到设定阈值时，系统在故障时间线中记录告警风暴事件并触发预警通知，提醒你加急处理 | | **严格聚合** | 开启时，空值标签视为不同项；关闭时，空值标签视为相同项（智能聚合不支持） | @@ -179,10 +180,22 @@ Flashduty On-call 提供两种聚合模式： | 选项 | 行为 | | :-------- | :--------------- | -| **关闭** | 不检测抖动状态（默认） | +| **关闭** | 不检测抖动状态 | | **仅提醒** | 标记抖动状态，继续按策略通知 | | **提醒后静默** | 标记抖动状态，首次提醒后不再通知 | + + 新建协作空间默认开启抖动检测（仅提醒模式）。 + + +### 可配置参数 + +| 参数 | 说明 | 默认值 | 取值范围 | +| :--- | :--- | :--- | :--- | +| **状态变化次数** (max_changes) | 在观测窗口内，告警状态变化达到该次数即判定为抖动 | 4 次 | 2–100 | +| **观测窗口** (in_mins) | 统计状态变化的时间窗口 | 60 分钟 | 1–1440 分钟 | +| **静默时长** (mute_mins) | 判定为抖动后，静默通知的持续时间（仅"提醒后静默"模式生效） | 120 分钟 | 0–1440 分钟 | + "相同故障"指具有相同 Alert Key 的故障，通常使用上游系统推送的告警 ID 作为唯一标识。 @@ -315,8 +328,8 @@ src="https://download.flashcat.cloud/flashduty/video/inhibit.mp4" 上限为 5000 条，主要为了保证控制台渲染性能。由于后台并发处理，实际可能略超此限制。 - - **规则聚合**：无上限，聚合窗口最大为 24 小时。告警触发 24 小时后不再合入新事件，新事件将产生新故障 - - **智能聚合**：无上限，聚合窗口最大为 30 天。告警触发 30 天后不再合入新事件，新事件将产生新故障 + - **规则聚合**：无上限，聚合窗口默认最大为 24 小时。告警触发 24 小时后不再合入新事件，新事件将产生新故障 + - **智能聚合**：无上限，聚合窗口默认最大为 24 小时，部分订阅计划支持扩展至 30 天。告警超出窗口后不再合入新事件，新事件将产生新故障 diff --git a/zh/on-call/configuration/personal-settings.mdx b/zh/on-call/configuration/personal-settings.mdx index db1aa01..2948dbd 100644 --- a/zh/on-call/configuration/personal-settings.mdx +++ b/zh/on-call/configuration/personal-settings.mdx @@ -74,12 +74,39 @@ APP Key 用于 API 请求认证。 --- +### 下载应用 + | 平台 | 下载方式 | | --- | --- | | **iOS** | App Store 搜索"Flashduty" | -| **Android** | 各主流应用市场下载（暂不支持鸿蒙） | +| **Android** | 已上架小米、华为、荣耀、OPPO、vivo 等主流应用市场，搜索"Flashduty"即可下载（暂不支持鸿蒙） | + +如果您使用的手机品牌不在以上列表中，可以在 APP 管理页面点击**点此下载**获取安装包二维码，使用手机扫描即可下载。 + +### 设备关联 + +下载安装后，您需要将移动设备与 Flashduty 账号关联，以接收推送通知。 + + + +前往 **个人中心 → Flashduty APP** 页面。 + + +页面会显示一个二维码。打开 Flashduty APP，点击「扫码登录」按钮，扫描页面上的二维码即可完成设备关联。 + + + +关联成功后，页面会展示已关联的设备列表，包括设备名称、操作系统版本和设备标识。如需解除关联，将鼠标悬停在设备卡片上，点击**解除关联**按钮即可。 + + +- 关联设备不等同于开启通知，故障的具体通知方式取决于您的分派策略设置 +- 解除设备关联后，该设备将无法接收推送消息 +- 二维码具有时效性，过期后页面会自动刷新生成新的二维码 + + +### 推送通知 -下载后选择登录方式完成账号关联。建议开启系统通知权限，并在勿扰模式中放行紧急故障通知。 +Flashduty APP 支持免费推送告警通知，确保关键告警能即时触达。您可以在移动端随时随地认领、解决和升级告警。建议开启系统通知权限，并在勿扰模式中放行紧急故障通知，以免错过重要告警。 ## 常见问题 diff --git a/zh/on-call/incident/handle-update-incident.mdx b/zh/on-call/incident/handle-update-incident.mdx index a9e5350..aea04b5 100644 --- a/zh/on-call/incident/handle-update-incident.mdx +++ b/zh/on-call/incident/handle-update-incident.mdx @@ -96,7 +96,11 @@ Flashduty On-call 推送的语音告警，在语音播报结束时，会提醒 ## 暂缓处理 -故障的处理人，在认领故障之后，可能需要一些时间来调查和处理故障，**暂缓** 操作可以暂时停止故障按照预期的分派策略进行升级。您可以在认领故障之后，设定一个暂缓时间，比如 2 小时、4 小时、12 小时，或设定一个 24 小时以内的自定义到期时间。 +故障的处理人，在认领故障之后，可能需要一些时间来调查和处理故障，**暂缓** 操作可以暂时停止故障按照预期的分派策略进行升级。您可以在认领故障之后，从预设时长中选择（默认为 2 小时、4 小时、12 小时），或设定一个 24 小时以内的自定义到期时间。 + + +账户管理员可以在 **账户设置** 中自定义 3 个暂缓预设时长（单位为分钟，每个值须大于 0 且不超过 24 小时），调整后对所有成员生效。 + 如果您已经操作了暂缓，并且暂缓时间已过，且您仍然没有完成故障的处理，这时系统会自动将故障回退为 **待处理** 状态，并重新发起分派通知。 diff --git a/zh/on-call/incident/search-view-incident.mdx b/zh/on-call/incident/search-view-incident.mdx index 92ccc63..f7d1cbc 100644 --- a/zh/on-call/incident/search-view-incident.mdx +++ b/zh/on-call/incident/search-view-incident.mdx @@ -79,7 +79,7 @@ Flashduty On-call 提供各种维度的筛选能力，并给您足够多的灵 | :---: | :--- | :--- | | 1 | 关键信息 | 故障的标题、严重程度、处理进度、ID 编号 | | 2 | 操作区域 | 各类高频操作按钮，在更多操作中，包含了自定义操作和低频操作按钮，其中创建作战室需要在 IM 集成中开启[作战室](/zh/on-call/advanced/war-room) | -| 3 | 详细信息 | 故障的描述、标签信息，其中 AI 总结可以快速提炼故障详情，并以事件概况、影响范围、可行措施三个维度进行输出，标签内容支持拖拽排序和以 JSON 视图展示 | +| 3 | 详细信息 | 故障的描述、标签信息和 AI 总结（详见下方说明），标签内容支持拖拽排序和以 JSON 视图展示 | | 4 | 关联告警 | 故障所关联的所有被[聚合](/zh/on-call/channel/noise-reduction)的告警，支持按处理进度筛选，以及支持视图切换 | | 5 | 综合信息 | 展示该故障的属性、处理状态、[图片](https://developer.flashcat.cloud/api-344943718)以及处理人员信息 | | 6 | 自定义字段 | 自定义字段配置区域 | @@ -105,10 +105,28 @@ Flashduty On-call 提供各种维度的筛选能力，并给您足够多的灵 你可以通过顶部的筛选条件调整变更事件的查询范围，包括时间范围和变更来源。展开任意一行，可查看该变更事件的时间线可视化，与故障触发时间进行对比分析。 +### AI 总结 + +故障详情页支持一键生成 AI 总结，帮助您快速理解故障全貌。点击详细信息区域的 **AI 总结** 按钮，系统将基于故障关联的告警内容（最多 20 条），自动生成结构化摘要，包括： + +- **概述**：一句话描述发生了什么 +- **影响**：受影响的关键资源，如服务、系统、环境、实例等 +- **建议**：即时可执行的排查和修复操作（最多 3 条） + +您可以选择不同的 AI 模型（默认为 DeepSeek V3），并支持重新生成。生成的摘要可以实时流式输出，也可以保存为故障描述。 + + +AI 总结仅适用于由告警自动触发的故障，手动创建的故障不支持此功能。 + + ### 图片 当故障关联的告警通过 API 上报了图片信息时，故障详情右侧面板将展示 **图片** 区域。你可以点击图片缩略图进行预览，悬浮可查看图片的 Alt 描述和来源链接。 +### 关联外部工单 + +如果您配置了 Jira、ServiceNow 或 ServiceDesk Plus 等工单集成，故障详情右侧面板的综合信息区域将展示关联的外部工单信息。您可以直接点击跳转到对应的外部工单系统查看详情。 + ## 常见问题 diff --git a/zh/on-call/incident/what-is-incident.mdx b/zh/on-call/incident/what-is-incident.mdx index a680711..1dc6e80 100644 --- a/zh/on-call/incident/what-is-incident.mdx +++ b/zh/on-call/incident/what-is-incident.mdx @@ -124,7 +124,7 @@ Flashduty On-call 支持专属集成和共享集成模式： Flashduty On-call 提供了一个自定义事件标准，允许您通过标准协议上报告警，适用于任何未适配的监控系统。详细文档请阅读[自定义告警事件](https://developer.flashcat.cloud/api-110655782)。 -为了保证整个系统的稳定，Flashduty On-call 目前对于 API 上报有 **200qps** 的频率限制，超出限制之后将会拒绝上报。 +为了保证整个系统的稳定，Flashduty On-call 对每个集成的 API 上报实施频率限制（**100 次/秒**、**1000 次/分钟**），超出限制将返回 `429` 状态码，请等待后重试。详见[接入告警 - 频率限制](/zh/on-call/channel/integrate-data#频率限制)。 diff --git a/zh/on-call/integration/alert-integration/alert-pipelines.mdx b/zh/on-call/integration/alert-integration/alert-pipelines.mdx index de85f90..d58567b 100644 --- a/zh/on-call/integration/alert-integration/alert-pipelines.mdx +++ b/zh/on-call/integration/alert-integration/alert-pipelines.mdx @@ -17,9 +17,25 @@ keywords: ["告警处理", "数据清洗", "格式化", "预处理", "Pipeline"] */} +## 处理顺序 + +告警事件进入 Flashduty 后，依次经过三个阶段： + +| 阶段 | 说明 | +| :--- | :--- | +| **① 标签增强（Enrich）** | 动态生成或修改告警标签，如通过 API 查询 CMDB 补充业务信息 | +| **② 告警处理（Pipeline）** | 清洗、转换、过滤告警数据（即本文档描述的功能） | +| **③ 路由分发（Route）** | 根据告警属性将事件分发到对应的协作空间 | + +由于标签增强在 Pipeline 之前执行，Pipeline 的匹配条件**可以引用增强阶段新增或修改的标签**。 + + +恢复事件（event_status 为 Ok）不经过告警处理 Pipeline，直接进入告警合并流程。因此，Pipeline 中配置的丢弃、抑制、重写等规则不会对恢复事件生效。 + + ## 工作原理 -Pipeline 位于 **告警接入** 和 **路由分发** 之间。它的执行逻辑如下： +Pipeline 位于 **标签增强** 和 **路由分发** 之间。它的执行逻辑如下： 1. **链式处理**：您可以配置多个处理规则，系统按照**从上到下**的顺序依次执行 2. **输入输出**：上一个规则处理后的结果（如修改了标题），可以作为下一个规则的输入 @@ -86,12 +102,14 @@ Flashduty On-call 已经为标准集成内置了等级映射（例如将 Zabbix ### 告警抑制 -Pipeline 中的抑制功能与协作空间的抑制规则**完全一致**，都支持基于源故障、目标故障和关联条件的依赖抑制。 +Pipeline 中的抑制功能与协作空间的抑制规则类似，都支持基于源告警、目标告警和关联条件的依赖抑制。需要注意的是，Pipeline 抑制仅在**同一集成**的告警范围内匹配源告警，而协作空间抑制则在整个空间的告警范围内匹配。 | 对比项 | Pipeline 抑制 | 协作空间抑制 | | :--- | :--- | :--- | | 生效层级 | 集成层 | 空间层 | +| 匹配范围 | 仅匹配同一集成内的活跃告警 | 匹配同一协作空间内的所有活跃告警 | | 适用场景 | **全局性**的抑制逻辑，如机房断网后抑制该机房所有告警 | 特定协作空间的抑制规则 | +| 版本要求 | 需要标准版（Standard）及以上 | 需要标准版（Standard）及以上 | 当整个机房断网时，该机房下的所有告警（无论属于哪个业务线）都应该被抑制。此时在集成层配置一条规则，比在几十个协作空间里分别配置要高效得多。 diff --git a/zh/on-call/integration/alert-integration/routing-rules.mdx b/zh/on-call/integration/alert-integration/routing-rules.mdx index 68aa33f..cce712f 100644 --- a/zh/on-call/integration/alert-integration/routing-rules.mdx +++ b/zh/on-call/integration/alert-integration/routing-rules.mdx @@ -47,9 +47,9 @@ keywords: ["路由规则", "告警路由", "分发策略", "协作空间", "分 | 功能 | 说明 | | :--- | :--- | -| 调整顺序 | 使用上下箭头或拖动规则以及按协作空间调整匹配优先级 | -| 插入规则 | 在指定规则前后快速插入新规则 | -| 筛选规则 | 可以按协作空间筛选出投递到该空间的所有规则 | +| 调整顺序 | 使用上下箭头或拖动规则调整匹配优先级；也支持按协作空间分组排序，便于管理大量规则 | +| 插入规则 | 在指定规则的前方或后方快速插入新规则，无需手动拖动调整位置 | +| 筛选规则 | 按协作空间筛选，快速定位投递到某个空间的所有规则，适合规则数量较多的场景 | | 编辑历史 | 查看历史配置版本，对比差异并快速恢复（详见下方说明） | ### 编辑历史 @@ -120,6 +120,20 @@ keywords: ["路由规则", "告警路由", "分发策略", "协作空间", "分 +## 订阅规则 + +除了路由规则外，系统还支持**订阅规则**。订阅规则在路由规则之后执行，用于将告警额外投递到感兴趣的协作空间，而不影响原有的路由逻辑。 + +| 对比项 | 路由规则 | 订阅规则 | +| :--- | :--- | :--- | +| 配置位置 | 集成详情 → 路由页签 | 协作空间 → 订阅设置 | +| 执行顺序 | 先执行 | 后执行 | +| 作用 | 决定告警投递到哪些协作空间 | 将符合条件的告警额外投递到当前空间 | + + +路由规则和订阅规则匹配到的协作空间会自动去重——同一条告警不会在同一个空间中重复生成故障。 + + ## 常见问题 diff --git a/zh/on-call/integration/instant-messaging/slack.mdx b/zh/on-call/integration/instant-messaging/slack.mdx index 85cfa7d..7bbd2c7 100644 --- a/zh/on-call/integration/instant-messaging/slack.mdx +++ b/zh/on-call/integration/instant-messaging/slack.mdx @@ -32,6 +32,16 @@ keywords: ["Slack", "即时消息", "告警通知", "IM集成", "协作工具"] 同一时间仅支持在一个 IM 集成中开启作战室功能。如果你已在其他 IM 集成（如钉钉、飞书、企业微信）中启用了作战室，需要先在该集成中关闭后，才能在当前 Slack 集成中开启。 +### 权限验证与重新授权 + +开启作战室时，系统会自动验证当前 Slack 应用是否具备作战室所需的全部权限。如果检测到缺少必要权限，页面会显示一条警告提示，并提供 **重新授权** 链接。 + +点击 **重新授权** 链接后，系统会跳转到 Slack 授权页面，请求作战室功能所需的额外权限（包括频道管理、消息读写、用户信息读取等）。完成授权后，页面会自动返回 Flashduty，此时即可正常开启作战室。 + + +如果您的 Slack 集成是在作战室功能上线之前完成授权的，首次开启时通常需要重新授权以补充新增权限。重新授权不会影响已有的集成配置和用户关联。 + + ## 三、关联用户 在集成详情页的 **关联用户** 页签中，你可以查看团队成员与 Slack 账号的关联状态，并快速完成批量关联。 diff --git a/zh/on-call/integration/instant-messaging/telegram.mdx b/zh/on-call/integration/instant-messaging/telegram.mdx new file mode 100644 index 0000000..0085dac --- /dev/null +++ b/zh/on-call/integration/instant-messaging/telegram.mdx @@ -0,0 +1,70 @@ +--- +title: "Telegram 机器人" +description: "通过配置 Telegram 机器人，您可以将告警通知推送到 Telegram 群聊中" +keywords: ["Telegram", "即时消息", "告警通知", "机器人", "群聊通知"] +--- + +Telegram 机器人是一种群聊通知渠道，您可以在协作空间的分派策略中配置 Telegram 机器人，将故障通知推送到指定的 Telegram 群聊中。 + +## 前提条件 + +在配置之前，您需要先创建一个 Telegram Bot 并获取以下信息： + +1. **Bot Token / Webhook 通知地址**：通过 [BotFather](https://t.me/BotFather) 创建 Bot 后获取的 Token，或一个可在国内访问的 Telegram 服务代理地址。 +2. **Chat ID**：您希望接收通知的群聊 ID。您可以通过将 Bot 添加到群聊后，使用 Telegram API 获取群聊的 Chat ID。 + + +Telegram 服务在国内可能无法直接访问，请确保您使用的 Webhook 通知地址在当前网络环境下可以正常访问。 + + +## 配置步骤 + +在协作空间的分派策略中添加 Telegram 机器人通知渠道： + + + +前往 协作空间详情 → 分派策略 → 选择或新建一个环节 → 在通知方式中选择 **群聊通知** → **Telegram**。 + + + +输入 Bot Token 或国内可访问的 Telegram 服务代理地址。 + +如果您之前已配置过同类型的机器人，系统会在下拉列表中显示历史记录供您快速选择。 + + + +输入需要接收通知的群聊 ID，支持配置多个 Chat ID。输入每个 ID 后按回车确认，系统将以标签形式展示。 + + + +您可以为该机器人设置一个别名，方便记忆和区分不同的通知渠道。 + + + +展开 **高级配置**，您可以按告警严重程度过滤通知： + +| 配置项 | 说明 | +| :--- | :--- | +| **严重程度过滤** | 选择需要推送通知的告警严重程度。未选中的严重程度对应的故障将不会推送到该 Telegram 群聊 | + + + +完成配置后，保存分派策略即可生效。 + + + +## 常见问题 + + + +请检查 Webhook 通知地址在当前网络环境下是否可以正常访问。Telegram 服务在国内可能存在访问限制，建议使用可靠的代理服务地址。 + + + +将 Bot 添加到目标群聊后，您可以通过调用 Telegram Bot API 的 `getUpdates` 方法获取群聊 Chat ID。也可以使用 [@userinfobot](https://t.me/userinfobot) 等工具获取。 + + + +可以。在 Chat IDs 字段中输入多个群聊 ID 即可同时向多个群聊推送通知。 + + diff --git a/zh/on-call/integration/instant-messaging/zoom.mdx b/zh/on-call/integration/instant-messaging/zoom.mdx new file mode 100644 index 0000000..f3a7917 --- /dev/null +++ b/zh/on-call/integration/instant-messaging/zoom.mdx @@ -0,0 +1,84 @@ +--- +title: "Zoom 机器人" +description: "通过配置 Zoom 机器人，您可以将告警通知推送到 Zoom 中" +keywords: ["Zoom", "即时消息", "告警通知", "机器人", "群聊通知"] +--- + +Zoom 机器人是一种群聊通知渠道，您可以在协作空间的分派策略中配置 Zoom 机器人，将故障通知推送到 Zoom 中，并支持 @ 提醒相关处理人员。 + +## 前提条件 + +在配置之前，您需要先在 [Zoom Marketplace](https://marketplace.zoom.us/) 创建一个 Chatbot 应用并获取以下信息： + +1. **Webhook 地址或 Token**：Zoom Chatbot 的 Webhook URL 或 Token。 +2. **Verify Token**：用于验证请求来源的 Verify Token。 + +## 配置步骤 + +在协作空间的分派策略中添加 Zoom 机器人通知渠道： + + + +前往 协作空间详情 → 分派策略 → 选择或新建一个环节 → 在通知方式中选择 **群聊通知** → **Zoom**。 + + + +输入 Zoom Chatbot 的 Webhook 通知地址或 Token。 + +如果您之前已配置过同类型的机器人，系统会在下拉列表中显示历史记录供您快速选择。选择后，系统会自动填入关联的 Verify Token。 + + + +输入 Zoom Chatbot 的 Verify Token，用于验证请求合法性。 + + + +您可以为该机器人设置一个别名，方便记忆和区分不同的通知渠道。 + + + +展开 **高级配置**，您可以进行以下设置： + +**@ 提醒** + +| 配置项 | 说明 | +| :--- | :--- | +| **开启 @ 提醒** | 开启后，系统通过用户信息映射表中的数据 @ 提醒对应的处理人员 | +| **用户信息映射表** | 当开启 @ 提醒时为必填项。选择一个已创建的用户信息映射表，用于将 Flashduty 用户映射到 Zoom 用户。您也可以点击 **快速创建映射表** 链接快速创建 | + + +用户信息映射表定义了 Flashduty 用户与 Zoom 用户之间的对应关系。您可以在 **映射表管理** 页面创建和维护映射表。 + + +**触发通知事件类型** + +选择哪些事件类型会触发 Zoom 通知推送。默认全选，您可以按需选择特定事件类型（如触发、认领、关闭等）。 + +**严重程度过滤** + +选择需要推送通知的告警严重程度。未选中的严重程度对应的故障将不会推送到 Zoom。 + + + +完成配置后，保存分派策略即可生效。 + + + +## 常见问题 + + + +请确认以下事项： +- 已开启 **@ 提醒** 开关 +- 已正确选择 **用户信息映射表** +- 映射表中的用户映射关系正确且完整 + + + +在 Zoom Marketplace 的 Chatbot 应用配置页面中，您可以找到应用的 Verify Token。该 Token 用于验证 Webhook 请求的合法性。 + + + +前往 平台管理 → 映射表管理，创建 Zoom 类型的用户信息映射表。您也可以在配置 Zoom 机器人时，点击 **快速创建映射表** 链接直接跳转创建。 + + diff --git a/zh/on-call/integration/webhooks/custom-actions.mdx b/zh/on-call/integration/webhooks/custom-actions.mdx index 65a9e07..b283776 100644 --- a/zh/on-call/integration/webhooks/custom-actions.mdx +++ b/zh/on-call/integration/webhooks/custom-actions.mdx @@ -13,7 +13,8 @@ keywords: ["自定义操作", "Webhook", "故障自愈", "外部接口", "自动 3. 配置 操作名称，此名称将以按钮的形式体现在故障详情中 4. 配置 协作空间，可以配置多个，但每个协作空间至多添加 **5** 个自定义操作 5. 配置 Endpoint、自定义 Headers -6. 保存，完成 +6. 如果目标服务使用自签名证书或内部 CA 签发的证书，可以开启 **跳过 TLS 验证** 选项，系统将不校验服务端证书的合法性 +7. 保存，完成 每个协作空间最多关联 5 个自定义操作。如果某个协作空间已达到上限，在添加新的自定义操作时将无法选择该空间。 diff --git a/zh/platform/configure-sso.mdx b/zh/platform/configure-sso.mdx index a0746a8..fc054c4 100644 --- a/zh/platform/configure-sso.mdx +++ b/zh/platform/configure-sso.mdx @@ -39,6 +39,10 @@ Flashduty 支持 SAML2.0、OIDC、CAS 和 LDAP（仅私有化版本）协议的 | Scopes | 指定请求可访问的信息和功能权限，支持自定义。默认值为 `openid`、`profile`、`email`、`phone`，支持以标签形式添加自定义 Scope | | Flashduty 服务提供商信息 | **Redirect URL**：身份提供商回调地址
**支持签名算法**：RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512（不支持 HS256） | + +Scopes 为必填字段。默认值 `openid`、`profile`、`email`、`phone` 是 OIDC 协议正常工作所需的基础权限。删除这些默认值可能导致单点登录失败或无法正确获取用户信息。如需添加自定义 Scope，建议在保留默认值的基础上追加。 + + ## 配置 CAS 协议 --- @@ -124,10 +128,21 @@ LDAP 单点登录仅**私有化版本**支持。 --- -登录域名是识别你的主体账号的重要依据，用于单点登录时定位到正确的 SSO 配置。每个主体的登录域名全局唯一。 +登录域名是识别您的主体账号的重要依据，用于单点登录时定位到正确的 SSO 配置。每个主体的登录域名全局唯一。 配置登录域名后，成员可以通过 `{域名}.sso.flashcat.cloud` 地址直接发起单点登录，无需手动选择身份提供商。 +您可以在 **平台管理 → 基本信息** 页面修改主体账号的域名。修改域名时请注意，域名只能使用 5–40 位字母、数字或 `-`，且不能以 `-` 开头或结尾。 + + +修改域名后，该域名将应用于以下场景： + +- **SSO 单点登录配置**：所有已配置的 SSO 登录域名会随之变更，成员需要使用新域名发起单点登录 +- **邮件集成推送的邮箱地址**：邮件集成的接收地址格式为 `prefix@{域名}.{邮箱后缀}`，域名变更后地址也会随之变化，请及时更新相关配置 + +修改前请确认已检查邮件集成配置，并在组织内进行了通报。修改操作可能需要通过多因素认证（MFA）验证。如在使用过程中遇到任何问题，请及时联系技术支持。 + + - 建议使用公司英文名称作为登录域名，便于记忆 - 登录域名一旦设置，变更后原域名将立即失效，使用旧域名的成员需要更新登录地址 diff --git a/zh/rum/error-tracking/error-viewing.mdx b/zh/rum/error-tracking/error-viewing.mdx index b907ba2..b584c2f 100644 --- a/zh/rum/error-tracking/error-viewing.mdx +++ b/zh/rum/error-tracking/error-viewing.mdx @@ -113,10 +113,31 @@ Flashcat 在每次创建 Issue 时会为其添加错误发生可能产生的错 系统采用两层分析机制对错误进行分类： -1. **模式匹配**：首先通过规则引擎分析错误类型和错误消息。例如，HTTP 4xx/5xx 状态码归类为 API 请求失败，`TypeError` 中包含 "Cannot read property of undefined" 归类为非法对象访问，包含 "timeout" 或 "connection" 的错误归类为网络错误。 -2. **AI 推断**：当模式匹配无法确定分类时，系统会调用 AI 模型，结合错误消息、堆栈信息和平台类型（浏览器、Android、iOS、Flutter、React Native 等）进行智能分析，并返回错误分类和简要的原因解释。 +**第一层：模式匹配** -AI 推断的结果会在 Issue 卡片上以 hover 提示的形式展示，包含推断的错误类别和具体原因说明。 +系统首先通过规则引擎按优先级依次检查错误类型和错误消息，首个匹配的规则决定分类结果： + +| 检查顺序 | 匹配条件 | 分类结果 | +|----------|----------|----------| +| 1 | 错误消息包含 "Unexpected token ... is not valid JSON" | 无效参数 | +| 2 | 关联资源的 HTTP 状态码为 4xx 或 5xx | API 请求失败 | +| 3 | 错误类型包含 "Network" 或 "AbortError" | 网络错误 | +| 4 | 错误类型包含 "Syntax"、"Reference"、"Range"、"URI" 或 "Eval" | 代码错误 | +| 5 | 错误类型为 TypeError 且消息匹配空值访问模式（如 "Cannot read property of undefined"） | 非法对象访问 | +| 6 | 错误消息匹配无效参数模式（如 "invalid argument"、"unexpected token"） | 无效参数 | +| 7 | 错误消息包含 "API ERROR:" 或许可证相关错误 | API 请求失败 | +| 8 | 错误消息包含网络连接相关关键词（如 "timeout"、"connection"、"dns"） | 网络错误 | +| 9 | 以上均未匹配 | 未知错误 | + +**第二层：AI 推断** + +当模式匹配结果为「未知错误」时，系统会调用 AI 模型进行深度分析。AI 模型会结合以下信息进行判断： + +- **错误消息**：错误的描述文本 +- **堆栈信息**：完整的调用堆栈 +- **平台类型**：浏览器/JavaScript、Android/Kotlin/Java、iOS/Swift/Objective-C、Flutter/Dart、React Native、Unity/C# 等 + +AI 会输出错误分类和简要的原因解释（不超过 100 字）。推断结果在 Issue 卡片上以 hover 提示的形式展示，帮助您快速理解错误的根因。 ## 问题复现 diff --git a/zh/rum/error-tracking/issue-alerts.mdx b/zh/rum/error-tracking/issue-alerts.mdx index f44736b..8c0e386 100644 --- a/zh/rum/error-tracking/issue-alerts.mdx +++ b/zh/rum/error-tracking/issue-alerts.mdx @@ -105,25 +105,24 @@ Flashduty RUM 自动将 SDK 上报的错误事件聚合为 Issue，帮助您优 | **匹配条件** | 基于 Error 属性的筛选条件，同一规则内多个条件为 AND 关系 | | **告警级别** | 匹配后设定的优先级：P0（Critical）/ P1（Warning）/ P2（Info） | -规则按优先级顺序匹配，首个匹配即生效。 +规则按优先级顺序从上到下逐条评估，**首个匹配的规则立即生效**，后续规则不再检查。您可以通过拖拽调整规则顺序来改变优先级。 #### 支持的匹配字段 -| 字段 | 说明 | 示例 | -| --------------------------------- | ------------------------------------------- | --------------------------- | -| 用户 ID（`error.usr_id`） | 上报错误的用户标识 | `vip_001` | -| 用户邮箱（`error.usr_email`） | 用户邮箱地址 | `*@vip.com` | -| 错误类型（`error.error_type`） | 错误的类型分类 | `TypeError`、`SyntaxError` | -| 错误消息（`error.error_message`） | 错误的描述文本 | 包含 `Cannot read property` | -| 错误堆栈（`error.error_stack`） | 堆栈信息 | 包含 `undefined` | -| 页面 URL（`error.view_url`） | 错误发生的页面地址 | 包含 `/payment` | -| 环境（`error.env`） | 错误发生的环境 | `production`、`staging` | -| 版本（`error.version`） | 应用版本号 | `1.0.0` | -| 服务（`error.service`） | 错误所属的服务 | `payment` | -| 浏览器（`error.browser_name`） | 浏览器名称 | `Chrome` | -| 是否崩溃（`error.is_crash`） | 是否为崩溃错误 | `true` | -| 指纹（`error.fingerprint`） | 指纹信息 | `06375381216fe431` | -| 自定义字段（`context`） | 通过 context 上报的自定义属性，支持三层嵌套 | `context.user.level` | +| 字段 | 说明 | 示例 | +| --------------------------------------- | -------------------------- | --------------------------- | +| 用户 ID（`error.usr_id`） | 上报错误的用户标识 | `vip_001` | +| 用户邮箱（`error.usr_email`） | 用户邮箱地址 | `*@vip.com` | +| 页面 URL（`error.view_url`） | 错误发生的页面完整地址 | 包含 `/payment` | +| 页面路径（`error.view_url_path`） | 错误发生的页面路径部分 | `/checkout/confirm` | +| 错误类型（`error.error_type`） | 错误的类型分类 | `TypeError`、`SyntaxError` | +| 错误消息（`error.error_message`） | 错误的描述文本 | 包含 `Cannot read property` | +| 环境（`error.env`） | 错误发生的环境 | `production`、`staging` | +| 服务（`error.service`） | 错误所属的服务 | `payment` | +| 设备类型（`error.device_type`） | 用户设备类型 | `mobile`、`desktop` | +| 操作系统（`error.os_name`） | 用户操作系统名称 | `Windows`、`iOS` | +| 浏览器（`error.browser_name`） | 浏览器名称 | `Chrome`、`Safari` | +| 是否崩溃（`error.is_crash`） | 是否为崩溃错误 | `true` | 匹配方式支持「包含」和「不包含」两种操作。 diff --git a/zh/rum/explorer/overview.mdx b/zh/rum/explorer/overview.mdx index d4031ad..f4069b1 100644 --- a/zh/rum/explorer/overview.mdx +++ b/zh/rum/explorer/overview.mdx @@ -76,6 +76,41 @@ Flashduty RUM **查看器**（RUM Explorer）是一款强大的数据分析工 +## 保存视图 + +保存视图功能允许您将当前的查询状态保存为可复用的视图，方便快速切换不同的分析场景。每个账户最多可创建 **20 个**保存视图，视图仅您自己可见。 + +### 视图保存的内容 + +每个保存视图包含以下信息： + +| 保存项 | 说明 | +|--------|------| +| **时间范围** | 当前选择的时间筛选条件 | +| **查询类型** | 当前选择的事件类型（如 Sessions、Views、Actions、Errors 等） | +| **查询语句** | 搜索栏中的 DQL 筛选条件 | +| **自定义列** | 数据表格的列配置 | + +### 视图操作 + + + + 点击查看器顶部的视图菜单，选择「保存为新视图」，输入视图名称后确认即可创建。视图名称不可重复。 + + + 点击视图菜单，在视图列表中点击目标视图即可切换。切换后，查看器会自动恢复该视图保存的时间范围、查询类型、查询语句和列配置。 + + + 在视图列表中，点击目标视图右侧的操作菜单，选择「编辑视图」可修改视图名称。如果您修改了当前视图的查询条件，还可以通过「保存修改」将最新状态更新到视图中。 + + + 在视图列表或操作菜单中选择「删除视图」，确认后即可删除。删除当前正在使用的视图后，查看器会自动切换回默认视图。 + + + 通过操作菜单选择「切换默认视图」，查看器会清空所有筛选条件，恢复到初始状态。 + + + ## 下一步 diff --git a/zh/rum/quickstart/app-management.mdx b/zh/rum/quickstart/app-management.mdx index 438b3dd..02a902b 100644 --- a/zh/rum/quickstart/app-management.mdx +++ b/zh/rum/quickstart/app-management.mdx @@ -129,6 +129,15 @@ Tracing 设置允许您将 RUM 数据与后端链路追踪系统关联，实现 +### 链接打开方式 + +Tracing 跳转链接支持两种打开方式： + +| 打开方式 | 说明 | +|----------|------| +| **弹窗**（`popup`） | 在当前页面内以弹窗形式打开链路追踪详情，无需离开 RUM 查看器。这是默认方式 | +| **新标签页**（`tab`） | 在浏览器新标签页中打开链路追踪详情，适合需要更大视图空间的场景 | + 配置完成后，您可以在资源详情中通过 Trace ID 直接跳转到对应的后端链路追踪记录，快速排查前后端关联问题。 ## 隐私设置 From 2bb6b7665fb88e965a6a0960244bcedda3a3e085 Mon Sep 17 00:00:00 2001 From: ysyneu Date: Tue, 17 Mar 2026 21:02:56 +0800 Subject: [PATCH 2/2] docs: remove deprecated subscribe rules section from routing docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subscribe rules (订阅规则) is a deprecated feature no longer shown to new users. Removed the section added in f015 from both zh/ and en/ routing-rules.mdx. Co-Authored-By: Claude Opus 4.6 --- .../alert-integration/routing-rules.mdx | 14 -------------- .../alert-integration/routing-rules.mdx | 14 -------------- 2 files changed, 28 deletions(-) diff --git a/en/on-call/integration/alert-integration/routing-rules.mdx b/en/on-call/integration/alert-integration/routing-rules.mdx index 85e61c2..617bf50 100644 --- a/en/on-call/integration/alert-integration/routing-rules.mdx +++ b/en/on-call/integration/alert-integration/routing-rules.mdx @@ -119,20 +119,6 @@ Before using name mapping mode, ensure channel names exactly match label values, -## Subscribe Rules - -In addition to routing rules, the system also supports **subscribe rules**. Subscribe rules run after routing rules and are used to additionally deliver alerts to interested channels without affecting the original routing logic. - -| Comparison | Routing Rules | Subscribe Rules | -| :--- | :--- | :--- | -| Configuration Location | Integration Details → Routing tab | Channel → Subscribe Settings | -| Execution Order | Runs first | Runs after | -| Purpose | Determine which channels alerts are delivered to | Additionally deliver matching alerts to the current channel | - - -Channels matched by routing rules and subscribe rules are automatically deduplicated — the same alert will not generate duplicate incidents in the same channel. - - ## FAQ diff --git a/zh/on-call/integration/alert-integration/routing-rules.mdx b/zh/on-call/integration/alert-integration/routing-rules.mdx index cce712f..a9a27ed 100644 --- a/zh/on-call/integration/alert-integration/routing-rules.mdx +++ b/zh/on-call/integration/alert-integration/routing-rules.mdx @@ -120,20 +120,6 @@ keywords: ["路由规则", "告警路由", "分发策略", "协作空间", "分 -## 订阅规则 - -除了路由规则外，系统还支持**订阅规则**。订阅规则在路由规则之后执行，用于将告警额外投递到感兴趣的协作空间，而不影响原有的路由逻辑。 - -| 对比项 | 路由规则 | 订阅规则 | -| :--- | :--- | :--- | -| 配置位置 | 集成详情 → 路由页签 | 协作空间 → 订阅设置 | -| 执行顺序 | 先执行 | 后执行 | -| 作用 | 决定告警投递到哪些协作空间 | 将符合条件的告警额外投递到当前空间 | - - -路由规则和订阅规则匹配到的协作空间会自动去重——同一条告警不会在同一个空间中重复生成故障。 - - ## 常见问题