Merge branch 'main' of github.com:flashcatcloud/flashduty-docs

Author: pijiang3

docs.json

@@ -422,6 +422,12 @@
                   "zh/monitors/alert-rules/victorialogs"
                 ]
               },
+              {
+                "group": "活跃告警",
+                "pages": [
+                  "zh/monitors/alert-rules/active-alerts"
+                ]
+              },
               {
                 "group": "规则仓库",
                 "pages": [
@@ -847,6 +853,12 @@
                   "en/monitors/alert-rules/victorialogs"
                 ]
               },
+              {
+                "group": "Active Alerts",
+                "pages": [
+                  "en/monitors/alert-rules/active-alerts"
+                ]
+              },
               {
                 "group": "Rule Repository",
                 "pages": [

en/developer/overview.mdx

@@ -36,7 +36,7 @@ Visit the [API documentation](https://developer-en.flashcat.cloud/en/flashduty/o
 
 ## MCP Server
 
-The Flashduty MCP Server implements the [Model Context Protocol](https://modelcontextprotocol.io/), providing AI tools with 16 tools across 6 functional modules:
+The Flashduty MCP Server implements the [Model Context Protocol](https://modelcontextprotocol.io/), providing AI tools with 18 tools across 6 functional modules:
 
 | Module | Tools | Capabilities |
 |--------|-------|-------------|

en/monitors/alert-rules/active-alerts.mdx

@@ -0,0 +1,70 @@
+---
+title: "Active alerts"
+description: "View all currently firing alerts to quickly understand your system's overall alert status"
+keywords: ["active alerts", "alert rule", "alert list", "severity", "labels"]
+---
+
+The active alerts page provides a consolidated view of all currently firing alerts, helping you quickly understand the overall alert status of your system. You can filter and browse by severity, title, labels, and more.
+
+<Note>
+The active alerts feature requires monit-edge version >= v0.36.0. Please ensure you have upgraded to this version or later. If you have not installed it yet, go to the [alert engine management](/en/monitors/engine/engine) page to complete the deployment.
+</Note>
+
+## Viewing active alerts
+
+**Menu entry**: Select a folder, then switch to the "Active Alerts" tab
+
+The active alerts list displays currently firing alerts in a table format. Default columns include:
+
+| Column | Description |
+|--------|-------------|
+| **Severity** | The severity level of the alert: Critical, Warning, or Info |
+| **Title** | The title of the alert event |
+| **Job** | The job label value carried by the alert |
+| **Instance** | The instance label value carried by the alert |
+| **Last updated** | The most recent time this alert was updated |
+| **Hash** | The unique identifier hash of the alert |
+| **Extra labels** | Other additional label information carried by the alert |
+
+## Filtering and searching
+
+The conditions bar at the top of the page helps you quickly locate the alerts you care about:
+
+- **Severity**: Filter by Critical, Warning, or Info
+- **Title**: Filter by the title of the alert event
+- **Hash**: Filter by the unique identifier hash of the alert
+- **Job**: Filter by the job label value
+- **Instance**: Filter by the instance label value
+- **Extra labels**: Filter by other additional labels
+
+All filter conditions use an "AND" relationship — only alerts matching all conditions are displayed.
+
+## Customizing columns
+
+Click the column configuration button in the upper-right corner of the list to:
+
+- **Show/hide columns**: Check or uncheck columns to control which ones are displayed
+- **Reorder columns**: Drag and drop to adjust the display order of columns
+
+The system remembers your column display preferences and automatically applies them on your next visit.
+
+<Tip>
+When you add a label-type column, the corresponding label filter automatically appears in the conditions bar, making it easy to quickly filter by that label.
+</Tip>
+
+## Deleting alerts
+
+If certain active alerts no longer need attention (for example, the alert rule has been adjusted but old alerts have not yet automatically recovered), you can manually delete them:
+
+<Steps>
+<Step title="Select alerts">
+Check the alerts you want to delete in the list. Multiple selection is supported.
+</Step>
+<Step title="Confirm deletion">
+Click the batch delete button. After confirmation, the selected alerts will be removed from the active alerts list.
+</Step>
+</Steps>
+
+<Warning>
+Deletion only removes the alert from the active alerts list. If the alert condition is still met, the alert will reappear the next time the alert engine runs its check.
+</Warning>

en/monitors/faq/faq.mdx

@@ -29,7 +29,6 @@ The overview page provides a global view of alert rules, consisting of the follo
 |------|-------------|
 | **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 |
 
 <Tip>

en/monitors/quickstart/quickstart.mdx

@@ -95,6 +95,10 @@ If you need stable rule bindings that are unaffected by data source renames, pre
 
 Configure how to query data sources and how to evaluate alert conditions. Please read the usage instructions on the right side of **Query Detection Method** on the page.
 
+| Config Item | Description |
+|--------|------|
+| **Query Offset** | Sets the query time offset (in seconds) to handle data source ingestion lag. For example, setting it to 60 shifts the query window back by 60 seconds, ensuring data has been fully written before querying |
+
 ### Detection Frequency and Effective Time
 
 ![Detection frequency & effective time](https://docs-cdn.flashcat.cloud/imges/mon/0980d71a653985a1706243fc6795685e.png)

en/on-call/channel/escalation-rule.mdx

@@ -20,6 +20,8 @@ src="https://download.flashcat.cloud/flashduty/video/escalate-rule.mp4"
 
 An escalation rule contains four core elements. The system matches rules from top to bottom, **stopping after the first successful match**.
 
+You can enable or disable individual escalation rules. Disabled rules are skipped during matching and will not trigger notifications. You can also copy an escalation rule to the current channel or another channel to quickly reuse existing configurations.
+
 ### 1. Trigger Conditions
 
 Determines which incidents trigger the current rule.
@@ -88,8 +90,8 @@ In each escalation level, you can enable the **Loop Notification** feature. When
 
 **Escalation Conditions**:
 
-- **Timeout without acknowledgment**: No one acknowledges within N minutes after incident trigger
-- **Timeout without closure**: Incident not resolved within N minutes after trigger
+- **Not closed**: Incident not closed within N minutes after trigger
+- **Not closed and not acknowledged**: Incident neither closed nor acknowledged within N minutes after trigger
 
 The minimum escalation timeout is 1 minute.
 

en/on-call/channel/noise-reduction.mdx

@@ -104,7 +104,7 @@ Flashduty On-call provides two grouping modes:
 | **Aggregation Window** | Optional toggle. When disabled, new alerts continue merging into the incident until the incident is closed. When enabled, alerts within the window are merged; alerts arriving after the window expires are grouped into a new incident |
 | **Window Timing Start** | Only configurable when the aggregation window is enabled. **Incident trigger** (default): Fixed timer starts from incident creation, stops grouping when the window duration is reached. **Alert merges into incident**: Timer resets each time a new alert merges in, the window recalculates from the last merge |
 | **Window Duration** | Only configurable when the aggregation window is enabled. Set the duration of the aggregation window |
-| **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 |
+| **Alert Storm Warning** | When merged alert count reaches a configured threshold, the system records an alert storm event in the incident timeline and triggers a warning notification, prompting urgent handling. You can configure up to 5 thresholds, each ranging from 2 to 10,000 |
 | **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) |
 
 <Tabs>
@@ -234,6 +234,7 @@ Define which alerts should be silenced, supports multiple condition combinations
 | **Severity** | Match by alert level | Only silence `Info` level |
 | **Title** | Match by alert title keywords | Title contains "Planned Maintenance" |
 | **Description** | Match by alert description content | Description contains "restart" |
+| **Integration** | Match by alert integration source | Only silence alerts from a specific integration |
 | **Labels** | Match by label key-value pairs | `host=db-master-01` |
 
 **Combination Logic**:

en/on-call/configuration/schedule.mdx

@@ -29,6 +29,7 @@ Understanding these concepts before configuration will help you better plan your
 | **Override** | Temporarily adjust the on-call person for a specific time period without modifying permanent rules (commonly used for leave, temporary coverage) |
 | **Date Mask** | Select which days to participate in on-call, e.g., Team A on-call Monday to Friday, Team B on weekends |
 | **Continuous Rotation** | When enabled, rotation boundaries are calculated based on shift start time, preventing shifts from being split at 00:00. Only supported when date mask is configured. See [Date mask and continuous rotation](#date-mask-and-continuous-rotation) for details |
+| **Fair Rotation** | The system automatically adjusts rotation order to ensure each member gets opportunities in different time periods, preventing someone from always being on-call during weekends |
 
 ![Schedule Concepts](https://docs-cdn.flashcat.cloud/images/png/3423a4f3133d5caa1f0aaebca970d404.png)
 
@@ -39,20 +40,39 @@ Understanding these concepts before configuration will help you better plan your
 <Steps>
   <Step title="Create a Schedule">
     Go to **Schedule Management**, click "Create Schedule"
+    - **Schedule Name**: 1–40 characters, must be unique within the account
+    - **Owning Team**: Specifies which team manages this schedule; team members gain edit permissions for this schedule
     - **Schedule Description**: Supports Markdown syntax, content can be included in notifications
-    - **Owning Team**: Specifies which team manages this schedule, not the on-call personnel
   </Step>
-  <Step title="Set Notification Reminders">
-    To prevent forgetting shifts or handoffs, the system provides two reminder types:
-    - **Handoff Notification**: N minutes before rotation (e.g., 15 minutes ahead), notifies both the outgoing and incoming personnel
-    - **On-duty Notification**: During on-call periods, sends a daily notification at a fixed time (e.g., 9:00 AM) reminding who's currently on-call
-    - **Channels**: Supports email, SMS, phone, IM (Feishu/Lark, Dingtalk, WeCom)
+  <Step title="Set Shift Notifications">
+    To prevent forgetting shifts or handoffs, the system provides two notification triggers:
+    - **Advance Notification**: Notifies both outgoing and incoming personnel N minutes before handoff (in 5-minute increments)
+    - **Scheduled Notification**: Sends a daily notification at a fixed time (e.g., 8:00 AM) reminding who is currently on-call
+
+    After enabling either notification trigger, you need to configure notification channels:
+
+    - **Personal Channels**: Send notifications directly to on-call personnel
+      - **Follow personal preference**: Each responder receives notifications via their personally configured channels
+      - **Follow unified settings**: Administrators select notification channels (SMS, email, and integrated IM apps)
+    - **Group Chat Channels**: Send notifications to group chats, supporting the following platforms:
+      - Feishu app, DingTalk app, Slack app (select chat groups via integrated IM apps)
+      - WeCom bot, DingTalk bot, Feishu bot (send via webhook URL)
+      - Slack bot, Telegram bot, Zoom bot
   </Step>
   <Step title="Define On-call Rules">
     This is the core step. You can add one or more layers of rules. Each layer includes:
-    - **On-call Personnel**: Select members participating in rotation
-    - **Rotation Cycle**: Supports day, week, custom duration
-    - **Time Restriction**: (Optional) This rule only takes effect during specific time periods
+
+    - **On-call Personnel**: Select members participating in rotation, supports grouping and primary/backup roles
+    - **Rotation Cycle**: Supports four units — hour, day, week, and month — with values from 1 to 30. For example, "2 days" means rotation every 2 days
+    - **Handoff Time**: When the rotation cycle is 1 week, you can specify the day and time for handoff
+    - **Fair Rotation**: When enabled, the system automatically adjusts rotation order to prevent someone from always being on-call during weekends
+    - **Date Mask**: Select which days of the week to schedule on-call. See [Date mask and continuous rotation](#date-mask-and-continuous-rotation) for details
+    - **Time Restriction**: (Optional) Restrict actual on-call hours within each rotation cycle, with the following modes:
+      - **No restriction**: Members are on-call for the entire rotation cycle
+      - **Daily**: Set daily on-call time ranges (e.g., 09:00–18:00), multiple periods can be added
+      - **Weekly**: Set day+time on-call ranges (e.g., Monday 09:00 – Friday 18:00), multiple periods can be added
+
+    <Note>When date mask is enabled, the "Weekly" restriction mode is unavailable since the date mask already provides day-of-week control. After setting time restrictions, there may be gaps with no one on-call — ensure other rules provide coverage.</Note>
   </Step>
 </Steps>
 
@@ -162,6 +182,17 @@ Consider enabling continuous rotation in the following scenarios:
   </Tab>
 </Tabs>
 
+## View schedule details
+
+---
+
+Click a schedule name to enter the detail page, where you can view the scheduling calendar and manage on-call rules. The upper right corner provides these options:
+
+- **View switcher**: Toggle between "Week", "Two Weeks", and "Calendar" (month view)
+- **Highlight my shifts**: When enabled, your on-call shifts are highlighted for quick identification
+
+Click any time slot in the calendar to view the current responders or create an override.
+
 ## View Personal Schedule
 
 ---

en/on-call/incident/search-view-incident.mdx

@@ -83,7 +83,7 @@ Incident details is the main entry point for investigating incidents, displaying
 | # | Area | Description |
 | :---: | :--- | :--- |
 | 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 |
+| 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. The snooze button supports customizable duration presets — you can access settings from the snooze dropdown to configure 3 preset durations (in hours or minutes), defaulting to 2 hours, 4 hours, and 12 hours |
 | 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 |
@@ -137,7 +137,7 @@ The incident details page supports one-click AI summary generation to help you q
 - **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.
+You can choose from different AI models (default is DeepSeek V3; DeepSeek R1 is also available for deep thinking and reasoning capabilities) and regenerate as needed. The generated summary supports real-time streaming output and can be saved as the incident description.
 
 <Tip>
 AI Summary is only available for incidents automatically triggered by alerts. Manually created incidents do not support this feature.

en/on-call/integration/alert-integration/alert-pipelines.mdx

@@ -114,6 +114,10 @@ Pipeline's inhibition feature is similar to channel inhibit rules, both supporti
 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.
 </Tip>
 
+<Note>
+Inhibition only matches source alerts that have been active within the last 10 minutes (600 seconds). If a source alert was triggered more than 10 minutes ago and has not been updated since, it will not be used for inhibition matching. Ensure your source alerts remain active within this time window.
+</Note>
+
 ## Reference Historical Data
 
 When editing alert processing rules, the right side of the page provides a **Related Alerts** panel showing historical alert data ingested through the current integration. You can write processing rules while referencing actual alert content, ensuring that condition expressions and action configurations meet expectations.