diff --git a/en/ai-sre/artifacts.mdx b/en/ai-sre/artifacts.mdx index ca47320e..795097ec 100644 --- a/en/ai-sre/artifacts.mdx +++ b/en/ai-sre/artifacts.mdx @@ -43,6 +43,23 @@ The artifact gallery has no entry point for manually uploading or creating files - **Search box**: fuzzy-search published artifacts by title; the query fires automatically 300ms after you stop typing. - **Scope**: a three-way **All / Personal / Team** switch (the same two-level scope shared with the other resources under AI SRE). Selecting "Team" expands a searchable, multi-select team picker; selecting no team means "all teams visible to me." +### View toggle and sorting + +The top-right of the list page offers a **Card view / List view** toggle; your choice is persisted in the browser (card view is the default). + +**List view** presents artifacts in a table with these columns: + +| Column | Description | +|---|---| +| Name | Artifact title; click to open the detail page | +| Scope | Team name for team artifacts, creator name for personal artifacts | +| From conversation | Title of the source conversation; click to jump to it. Shows plain text "Conversation deleted" when the source conversation was deleted or has no title | +| Created at | Artifact creation time | +| Updated at | Artifact last-updated time | +| Actions | Rename, download, delete, etc. | + +The **Created at** and **Updated at** columns support header sorting (ascending / descending toggle); sorting is executed server-side, with **Updated at descending** as the default. + ### Artifact cards Each card shows: diff --git a/en/ai-sre/im.mdx b/en/ai-sre/im.mdx index 6c6d7004..2eac62ae 100644 --- a/en/ai-sre/im.mdx +++ b/en/ai-sre/im.mdx @@ -143,6 +143,18 @@ After the switch, AI SRE: Knowledge bundles already mounted into this session are not removed — mounts are conversation-scoped, so switching back to a previously-mounted team will not duplicate the mount reminder. +## /feedback — Rate an AI SRE Reply + +--- + +Once an AI SRE reply lands in a group chat, anyone in the group can rate it — not only whoever started the investigation. Send `/feedback` to the bot to rate or comment on the reply you are looking at: + +- **Entry and resolution:** `/feedback` is backed by the AI SRE side (POST /safari/session/latest-reply → POST /safari/feedback/create); it resolves "the message you are looking at" into the corresponding reply event even if you never took part in that conversation. +- **Eligibility:** **not limited to session members** — any account member who can use AI SRE may rate (read-only group-chat readers included); an AI SRE answer posted into a group chat is public, and the reader who spotted the error is exactly whose opinion we want. +- **How to rate:** choose `like` / `dislike` / `none`; a comment-only submission (no rating) is allowed and does not wipe an earlier rating you gave, while an explicit `none` clears the existing rating. +- **Stored per rater:** each reply is keyed by **(reply event, rater)** — when several people rate the same reply, each gets its own row and they do not overwrite one another. +- **Console side:** the console conversation header also offers thumbs-up feedback on replies (see [Feedback](/en/ai-sre/sessions#feedback)), sharing the same rating system as IM `/feedback`. + ## Relationship to Console Sessions --- diff --git a/en/ai-sre/sessions.mdx b/en/ai-sre/sessions.mdx index a9e21baa..81ad52f7 100644 --- a/en/ai-sre/sessions.mdx +++ b/en/ai-sre/sessions.mdx @@ -226,7 +226,66 @@ The preview panel provides **Copy**, **Download**, and **Close** actions. Report-type artifacts (such as operational insight reports) can be generated as HTML containing Mermaid diagrams and charts, viewable directly in the rendered view. For operational insight capabilities, see Operational Insight Reports. -All published artifacts can also be viewed and managed in one place on the **Artifacts** page in the left navigation (list, search, filter by personal / team scope, rename, download, and delete) — see Artifacts. +All published artifacts can also be viewed and managed in one place on the **Artifacts** page in the left navigation (list, search, filter by personal / team scope, card / list view toggle, sort by created / modified time, rename, download, and delete) — see Artifacts. + +### Status Page Update Drafts + +The agent can call the `statuspage_draft` tool to **draft** an announcement for your public status page — a new incident or maintenance event, or an update appended to an existing event. Drafts are saved server-side and rendered in the conversation as a **status page update draft card**; but a draft is **never published automatically**: publishing a status page reaches subscribers immediately and cannot be recalled, so that step is always left to a human — review each item in the status page publish form in the console, then click publish. + +#### What's on the draft card + +The card reuses the visuals, field order, and component status icons of the console's corresponding cards (IncidentCard / MaintenanceCard), so what reviewers see is exactly what will be published: + +| Content | Description | +|---|---| +| Title | For a new event, the form's `name` field (backend `title`, up to 255 characters); for an appended update, the title of the event it attaches to — the append-update form has no title field, so this serves as identification only (shows "Untitled status page update" when not provided) | +| Status / scheduled time | New maintenance shows "Scheduled for 〈start〉 → 〈end〉" (shows "No schedule set" when unset); otherwise the status text — incidents: Investigating / Identified / Monitoring / Resolved; appended maintenance updates: Scheduled / Ongoing / Completed | +| Body | The `message` field is **fully rendered** as Markdown — this is what customers will read; reviewers must see the whole picture, and it must not appear as plain text | +| Affected components | One chip per component: component status icon + name (hover shows "name · status") | +| Target & type | Bottom left shows "Will publish to 〈status page〉" (appended updates show "Update · 〈event title〉"); the right side labels the type: Incident / Maintenance | +| Warning banner | If the draft message contains Markdown the status page editor doesn't support and that would be **silently dropped** when loaded into the form (headings, code blocks, block quotes, images, strikethrough, inline code), the card lists each one in a warning banner — already detected by the tool at draft time | + +#### Card states + +| State | Behavior | +|---|---| +| Drafting | Skeleton screen, with "Drafting status page update…" at the bottom | +| Tool error | "Failed to generate draft" + the specific reason; you can ask the AI to try again, or create it manually on the status page | +| Incomplete draft | "Incomplete draft" + the same hint (the tool returned a result but no usable draft object) | +| Ready to review | Button is **Review →**: opens the corresponding status page form in the console in a new tab, with the draft content pre-filled (URL convention below) | +| Published | Button becomes a disabled **Published**; the bottom target becomes a link to the **published change** (`/status-page/{page_id}?menu=incidents\|maintenance&incident\|maintenance={change_id}`), so you can look back at what the draft eventually became | +| Draft expired / not found | Button becomes a disabled **Draft expired**, with "Draft expired or not found — ask the AI to draft a new one" — treated the same when the console query returns ResourceNotFound or a network error | + +Whether it has been published is a fact the card cannot observe on its own (publishing happens in the console, in another tab), so the card queries `GET /status-page/draft/info?draft_id=...` by draft ID, which returns `status: pending | published`. While the draft is still pending, it refreshes every time the window regains focus ("review here, publish there, come back" is the normal path); `published` and "draft not found" are both terminal states, and the result is cached for the lifetime of the current page. Read-only shared sessions don't render the review button, and the draft status query is skipped as well. + +#### Handoff URL for review + +The draft itself lives server-side (fc-statuspage's draft storage); only the `draft_id` crosses over to the console: the form pulls the body from `/status-page/draft/info` by ID. The URLs combine into four variants by "new / append" × "incident / maintenance": + +| Scenario | URL | +|---|---| +| New incident | `/status-page/{page_id}?menu=incidents&incident=new&draft={draft_id}` | +| New maintenance | `/status-page/{page_id}?menu=maintenance&maintenance=new&draft={draft_id}` | +| Append incident update | `/status-page/{page_id}?menu=incidents&incident={change_id}&action=add-update&draft={draft_id}` | +| Append maintenance update | `/status-page/{page_id}?menu=maintenance&maintenance={change_id}&action=add-update&draft={draft_id}` | + +`action=add-update` makes the detail page auto-expand the append-update form; without it, the route only opens the event itself and the draft is never read. `?draft=` carries only the draft ID — the draft is server-side state, not a chunk of JSON in the URL. + +#### Tool specifics + +| Field | Description | +|---|---| +| `page_id` / `page_name` | Target status page (required) and its display name (used on the card) | +| `type` | `incident` (incident) / `maintenance` (maintenance) | +| `change_id` | Omitted = new event; set = append an update to that event. Before drafting, the tool first checks `fduty status-page list` and `fduty status-page change-active-list` — if the target already has an active event, it should append rather than open another one (a second event reads to customers as another separate outage) | +| `title` / `message` | Title for a new event (≤255 characters) and the body (required, Markdown; the status page editor keeps only bold, italic, links, bulleted / numbered lists, tables, and `---` dividers) | +| `status` | New incident: `investigating` / `identified` / `monitoring` / `resolved`; new maintenance: omit (whether it advances on schedule is decided by the publish form's toggle); appended maintenance update: `scheduled` / `ongoing` / `completed` | +| `affected_components` | Affected components (`component_id` + `status`, optionally with display name `name`); incident component status: `operational` / `degraded` / `partial_outage` / `full_outage`, maintenance component status: `operational` / `under_maintenance` | +| `start_at_seconds` / `end_at_seconds` | Only for a new maintenance: planned window start and end, unix **seconds** (milliseconds and ISO strings are treated as invalid) | + + +Channel differences: the console (`web`) and automation channels render the card above; IM and API channels don't render cards — instead the agent puts a "[Review & publish](〈the same handoff URL〉)" link at the **start of the reply**, then summarizes the draft points in a sentence or two (IM message truncation doesn't parse Markdown, so the link comes first to be safe). If saving the draft failed (no `review_url`), it falls back to a text summary and points you to the status page in the console to verify manually. + ### Message Actions diff --git a/en/changelog/changelog.mdx b/en/changelog/changelog.mdx index 1ec8a9f0..5cc5b63d 100644 --- a/en/changelog/changelog.mdx +++ b/en/changelog/changelog.mdx @@ -4,6 +4,32 @@ description: "This page documents important updates and feature releases for Fla keywords: ["Changelog", "Product Release", "Feature Updates", "Flashduty", "Version History"] --- + + +### Silence detection for alert integrations + +Alert integrations (standard/Email/IM/Flashcat, etc.) add a **silence detection** setting: + +- When enabled, if an integration receives no valid event within the specified window (10 minutes to 48 hours, default 10 minutes), a Warning alert is generated +- "Auto-recover on new event" is on by default; the alert recovers as soon as the next event passes integration validation + +### AI SRE status page drafts + +AI SRE conversations can call the **statuspage_draft** tool to draft status page incident/maintenance updates: + +- Drafts are previewed in chat as cards (title, status, body, affected components) +- The AI only drafts and never publishes; the draft link opens the console publish form (prefilled via `?draft=`) for human review and release +- Draft states include pending review / published / expired + +### IM feedback and ratings + +Use **/feedback** in a work group chat to rate or comment on AI SRE replies: + +- You can submit a comment only without choosing a rating; ratings support like/dislike/none +- Each member's ratings are stored independently + + + ### React Native app support diff --git a/en/monitors/explore/explore.mdx b/en/monitors/explore/explore.mdx index fbdc8285..72959b12 100644 --- a/en/monitors/explore/explore.mdx +++ b/en/monitors/explore/explore.mdx @@ -50,6 +50,14 @@ When the query type includes logs, a log time distribution chart appears above t - 24 hours – 30 days: requires manual click to load. - Beyond 30 days: not supported. +### Log View + +Log-type query results are displayed row by row; each row contains the timestamp, body, and a field summary. If a batch of results contains fields whose value is identical in every row (common fields, such as Loki's stream labels), these fields are shown in the summary on every row by default, but they take up width on each row repeatedly. + +- The **Common Fields** button on the toolbar lists the fields that are identical across every row in the current batch, with their values; after checking **Hide Inline** in the popover, these common fields are collapsed out of the inline summary, and each row keeps only the content that differs (with a "+N fields" hint displayed) +- **Hide Inline** is off by default (common fields are shown by default); the toggle is session state, not persisted — refreshing the page restores the default +- Clicking a row expands its details; the details always show all fields of that row, unaffected by the **Hide Inline** toggle + ## Query Parameters In addition to the query expression, some data sources support private parameters: diff --git a/en/on-call/channel/escalation-rule.mdx b/en/on-call/channel/escalation-rule.mdx index 4aeb9bdd..2a2a531a 100644 --- a/en/on-call/channel/escalation-rule.mdx +++ b/en/on-call/channel/escalation-rule.mdx @@ -84,6 +84,8 @@ Determines how users are reached. **Cross-team webhook address scoping.** When selecting a Webhook bot address in a dispatch policy, addresses are grouped by ownership tier: **Current Channel** (already referenced by this channel), **Same Team** (referenced by other channels in the same team), and **Other Team** (referenced only by channels in other teams). Other-team addresses are collapsed by default and require manual expansion. Selecting an other-team address shows a **Cross-team** badge and warning; on save, a confirmation modal appears when cross-team addresses are present, preventing alerts from being sent to another team's chat by accident. + + When selecting or pasting a Webhook address from **Other Team**, the alias automatically gets a prefix of the source team name (e.g. `team-name-alias`; if an existing alias already starts with that prefix, it is not applied again, and when pasting, the prefix is added only if the alias is empty). After the prefix is added, the alias can still be modified manually. diff --git a/en/on-call/incident/handle-update-incident.mdx b/en/on-call/incident/handle-update-incident.mdx index eb536fdb..70f06c60 100644 --- a/en/on-call/incident/handle-update-incident.mdx +++ b/en/on-call/incident/handle-update-incident.mdx @@ -121,7 +121,7 @@ If you've snoozed and the snooze time has passed but you still haven't resolved -Click incident details in console, click **Snooze** button, select snooze duration, done. +Click incident details in console, click **More (⋮)** in the top-right, choose the **Snooze** submenu, select snooze duration, done. Only incidents in the Processing state can be snoozed. @@ -186,7 +186,10 @@ The **More** button at the top right of the incident details page groups supplem | :--- | :--- | | **Merge into Incident** | Merge the current incident into another target incident; after the merge, alerts from both incidents are consolidated and handled within the target incident | | **Quick Silence** | Jump to the alert silence configuration page of the incident's channel with key fields of the current incident pre-filled, so you can quickly create a targeted silence rule | +| **Snooze** | Only shown when the incident is in the Processing state. Opens a Snooze submenu where you pick a preset duration or a custom one; see [Snooze](#snooze). Not shown once the incident is closed or not in Processing | +| **Escalate** | Only shown when an escalation policy is enabled and the incident is not yet closed. Escalates the incident to a specific step of the escalation chain (the steps used for per-level escalation); the selected step's responder takes over | | **Unacknowledge** | Only shown if you have acknowledged and the incident is not yet closed; used to revoke a prior acknowledgment. Once all responders have unacknowledged, the incident reverts to **Triggered** | +| **Reassign** | Only shown when the incident is not closed. Opens a reassign dialog to hand the incident to another member | | **Invite Followers to War Room** | Only shown if a war room has been created for the incident; lets you pull additional members into the corresponding IM war room group | | **Close War Room** | Only shown if a war room has been created for the incident; closes the IM war room group. See [War Room](/en/on-call/advanced/war-room) for details | | **Custom Actions** | Jira, ServiceNow, ServiceDesk Plus, and general custom actions configured by administrators in integrations | diff --git a/en/on-call/incident/search-view-incident.mdx b/en/on-call/incident/search-view-incident.mdx index ca14552a..9bd54199 100644 --- a/en/on-call/incident/search-view-incident.mdx +++ b/en/on-call/incident/search-view-incident.mdx @@ -15,7 +15,7 @@ Flashduty On-call provides two entry points to view the incident list. One is wi | :---: | :--- | :--- | | 1 | Assignee | Defaults to incidents **Assigned to Me**, can switch to view all incidents in the account | | 2 | My Channels | Defaults to all channels, can switch to view incidents in **My Channels** | -| 3 | Processing Progress | Filter incidents by progress, defaults to **All** | +| 3 | Processing Progress | Filter incidents by progress, defaults to **Not Closed** (Triggered/Processing); switch to All or another progress as needed | | 4 | Time Filter | Supports relative time and custom range filtering | | 5 | Search | Supports searching by incident title, ID, labels, and custom fields. After an incident's title, labels, or custom fields are updated, query results may be slightly delayed | | 6 | More Filters | Supports rich dimension filtering, including severity, responders, related to me, creator, acknowledger, closer, snooze status, ever converged due to flapping, rare incidents, labels, and custom fields. The **Channels** and **Teams** filters are only visible under the global Incident Management entry, and Teams narrows incidents by the team that owns each channel; **Related to me** matches incidents where you are the creator, acknowledger, closer, or a responder | @@ -102,6 +102,10 @@ After selecting one or more incidents in the list, use the action bar above the Except for **AI Analysis**, the above batch operations require incident update permission. + +Batch selection supports **at most 100 incidents**: once the limit is reached, selecting more is rejected with the message "Batch operations support at most 100 items". To handle more, narrow the filters (such as time or assignee) and operate in batches. + + ### Custom Rendering Click the **Settings** button in the upper right corner of the incident list to customize display content and interaction behavior: diff --git a/en/on-call/integration/alert-integration/alert-sources/email.mdx b/en/on-call/integration/alert-integration/alert-sources/email.mdx index 18248068..1527f097 100644 --- a/en/on-call/integration/alert-integration/alert-sources/email.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/email.mdx @@ -62,6 +62,7 @@ By default, the system creates a new alert for every email, but you can switch t - You must fill in at least one **trigger** rule - You must set regex extraction rules for Alert Key. The system uses this field to find historical alerts for updates or closure; **if regex extraction fails, the system will use the email subject to generate an Alert Key** to ensure alerts aren't lost due to configuration errors + - The Alert Key regex must be a valid RE2 expression. It is validated when the rule is saved; an illegal expression is rejected with the message "Please enter a valid regex" - You can choose whether to discard emails when no rules match Configuration example: @@ -71,6 +72,16 @@ By default, the system creates a new alert for every email, but you can switch t drawing +#### Silence Detection + +In the integration card (edit and preview), the **Silence Detection** (Heartbeat) setting sits below the push settings: if no valid event arrives within the configured interval, the system generates a Warning alert. + +| Setting | Description | +| :--- | :--- | +| **Enable Silence Detection** | Switch, off by default. When on, only upstream events that pass integration validation refresh the detection time | +| **Detection Interval (minutes)** | A Warning alert is generated if no valid event arrives within this interval. Must be an integer between 10 minutes and 48 hours (default 10 minutes) | +| **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically | + ### Important Notes 1. The system will reject emails larger than 5MB diff --git a/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx b/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx index a8344562..fddf681b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx @@ -159,6 +159,18 @@ Nightingale supports configuring global webhook URLs in both the interface and c +## Silence Detection + +--- + +In the integration card (edit and preview), the **Silence Detection** (Heartbeat) setting is available below the alert push settings: if no valid event arrives within the configured interval, the system generates a Warning alert. + +| Setting | Description | +| :--- | :--- | +| **Enable Silence Detection** | Switch, off by default. When on, only upstream events that pass integration validation refresh the detection time | +| **Detection Interval (minutes)** | A Warning alert is generated if no valid event arrives within this interval. Must be an integer between 10 minutes and 48 hours (default 10 minutes) | +| **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically | + ## Severity Mapping --- diff --git a/en/on-call/integration/alert-integration/alert-sources/standard-alert.mdx b/en/on-call/integration/alert-integration/alert-sources/standard-alert.mdx index ea333ee4..552695d2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/standard-alert.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/standard-alert.mdx @@ -198,7 +198,8 @@ Supported target fields: | event_status | Alert status (Critical / Warning / Info / Ok) | | alert_key | Alert identifier | | labels | Alert labels | -| images | Image array | + +The above is the whitelist of target fields supported by the field mapping editor in integration settings. The `images` field can only be reported directly in the request payload; it is not supported through field mapping. **Variable syntax:** @@ -265,6 +266,16 @@ Combined with the field mapping above, `"severity": "high"` in the original JSON All `{{...}}` variables must resolve to a value in the original JSON, otherwise the request will fail. It is recommended to test your mapping configuration with a small dataset first. +## Silence Detection + +In the integration detail page (edit and preview), the **Silence Detection** (Heartbeat) card is available below the base settings card: if no valid event arrives within the configured interval, the system generates a Warning alert. + +| Setting | Description | +| :--- | :--- | +| **Enable Silence Detection** | Switch, off by default. When on, only upstream events that pass integration validation refresh the detection time | +| **Detection Interval (minutes)** | A Warning alert is generated if no valid event arrives within this interval. Must be an integer between 10 minutes and 48 hours (default 10 minutes) | +| **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically | + ## IV. Best Practices --- diff --git a/en/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx b/en/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx index 7045cc3c..fc5b6564 100644 --- a/en/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx @@ -63,11 +63,25 @@ By default, the system always creates new alerts for each message, but you can s - You must set up regex extraction rules for Alert Key. The system uses this field to find historical alerts for updates or closure. **If regex extraction fails, the system will use the random to generate an Alert Key** to ensure alerts won't be lost due to configuration errors - You can choose whether to discard messages when none of the rules match + + The regex extraction rule must be a **valid regular expression (RE2 syntax)**: on submit the frontend validates that it compiles, and an illegal regex (such as unsupported syntax) cannot be saved and shows "Please enter a valid regex". Only when the regex is valid but matches nothing does the system fall back to generating a random Alert Key. + + Configuration example: - Receive all messages, close the alert when the message content contains **RESOLVED**, otherwise trigger a new alert - Extract Alert Key from messages using the rule **/(.*)/**. +#### Silence Detection + +In the integration card (edit and preview), the **Silence Detection** (Heartbeat) setting is available below the base settings: if no valid event arrives within the configured interval, the system generates a Warning alert. + +| Setting | Description | +| :--- | :--- | +| **Enable Silence Detection** | Switch, off by default. When on, only upstream events that pass integration validation refresh the detection time | +| **Detection Interval (minutes)** | A Warning alert is generated if no valid event arrives within this interval. Must be an integer between 10 minutes and 48 hours (default 10 minutes) | +| **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically | + ### Notes - Wecom alert integration URL only supports Text and Markdown message types; other message types cannot be received diff --git a/en/on-call/integration/alert-integration/routing-rules.mdx b/en/on-call/integration/alert-integration/routing-rules.mdx index c1437f11..35957198 100644 --- a/en/on-call/integration/alert-integration/routing-rules.mdx +++ b/en/on-call/integration/alert-integration/routing-rules.mdx @@ -57,14 +57,14 @@ When using name mapping mode, if corresponding channel doesn't exist, delivers t Routing rules support viewing edit history, helping you track configuration changes and quickly roll back when needed. -Click the **Edit History** button on the routing configuration page to open the sidebar panel. History records are grouped by date, and each record includes the version number, operator, and modification time. The currently active version is labeled **Current Version**. +Click the **Edit History** button on the routing configuration page to open a dialog (history version list on the left, diff comparison area on the right). History records are grouped by date, and each record includes the version number, operator, and modification time. The currently active version is labeled **Current Version**. You can perform the following actions: | Action | Description | | :--- | :--- | -| **Compare** | Click any historical version to view the configuration differences between that version and the current version (Diff view) | -| **Restore** | In the comparison view, choose to restore routing rules to the selected historical version | +| **Compare** | By default, compare the selected historical version with the current version (built-in split Diff view); there is a version dropdown on each side, so you can compare any two historical versions | +| **Restore** | In the comparison view, choose to restore routing rules to the selected historical version; either side of the comparison can be restored | Edit history supports infinite scroll loading, fetching 50 records at a time. diff --git a/en/on-call/integration/webhooks/jira-sync.mdx b/en/on-call/integration/webhooks/jira-sync.mdx index 0244e4d3..de668bfb 100644 --- a/en/on-call/integration/webhooks/jira-sync.mdx +++ b/en/on-call/integration/webhooks/jira-sync.mdx @@ -48,8 +48,8 @@ In Integration Center, select **Webhook**, choose **Jira Sync** integration, and - **Project ID**: Select the project to sync to in Jira. - **Issue Type**: Select the issue type to sync to in Jira. - **Channel**: Select channels where this integration takes effect; only incidents in these channels can sync to Jira. -- **Severity Mapping**: Cannot be configured if the selected issue type doesn't support the priority field. -- **Custom Field Mapping**: Optionally sync incident labels, all labels, or custom field content to Jira fields (only text-type fields supported). +- **Severity Mapping**: Cannot be configured if the selected issue type doesn't support the priority field. The **Jira Priority** (result field) is required for each mapping row; the integration cannot be saved if any row is missing it. +- **Custom Field Mapping**: Optionally sync incident labels, all labels, or custom field content to Jira fields (only text-type fields supported). Both the **Key** (incident field) and the **Result Field** (Jira field) are required for each mapping row; the integration cannot be saved if any row is missing either. ### 3. About Updates diff --git a/zh/ai-sre/artifacts.mdx b/zh/ai-sre/artifacts.mdx index 58754b77..9c5a3d26 100644 --- a/zh/ai-sre/artifacts.mdx +++ b/zh/ai-sre/artifacts.mdx @@ -43,6 +43,23 @@ sidebarTitle: 产物 - **搜索框**：按标题模糊搜索已发布产物，输入停顿 300 毫秒后自动查询。 - **范围**：**全部 / 个人 / 团队** 三态切换（与 AI SRE 下其它资源统一的两级作用域一致）。选择「团队」后会展开一个可搜索、可多选具体团队的选择器；不选择任何团队等价于「我可见的全部团队」。 +### 视图切换与排序 + +列表页右上角提供 **卡片视图 / 列表视图** 切换，选择会保存在浏览器本地（下次进入沿用）；卡片视图为默认展示。 + +**列表视图** 以表格展示产物，列定义如下： + +| 列 | 说明 | +|---|---| +| 名称 | 产物标题，点击进入详情页 | +| 所属范围 | 团队产物显示团队名称，个人产物显示创建者姓名 | +| 来自对话 | 产物来源会话标题，点击跳转到对应会话；来源会话已删除或无标题时显示「会话已删除」纯文本 | +| 生成时间 | 产物创建时间 | +| 修改时间 | 产物最后更新时间 | +| 操作 | 重命名、下载、删除等 | + +**生成时间** 与 **修改时间** 列支持点击列头排序（升序 / 降序切换），排序在服务端执行；默认按 **修改时间降序**。 + ### 产物卡片 每张卡片展示： diff --git a/zh/ai-sre/im.mdx b/zh/ai-sre/im.mdx index 5bc348aa..68d9d2d3 100644 --- a/zh/ai-sre/im.mdx +++ b/zh/ai-sre/im.mdx @@ -143,6 +143,18 @@ IM 会话没有控制台那样的选择器 UI，但支持两条斜杠命令在** 已挂载到本次会话的知识包不会被移除——挂载是对话级别的，切回之前挂载过的团队不会重复注入提醒。 +## /feedback — 评价 AI SRE 的回复 + +--- + +AI SRE 的回复进入群聊后，群里任何人都可以评价它——不只是发起排查的人。向机器人发送 `/feedback`，即可对你正在看的那条回复给出评价或评论： + +- **入口与定位**：`/feedback` 由 AI SRE 侧提供后端（POST /safari/session/latest-reply → POST /safari/feedback/create），它能把你「当前看中的那条消息」解析为对应的回复事件，即使你没有参与过那次对话。 +- **评价资格**：**不限会话成员**——账户内任何可使用 AI SRE 的成员都可以评价（只读群聊读者同样可以）；群聊里 AI SRE 的回答是公开的，看错的人正是我们想收集反馈的人。 +- **评价方式**：可选 `like` / `dislike` / `none`；只写评论不选评价也可以提交（空评价不会清掉你之前给过的评价），显式的 `none` 才会清除已有评价。 +- **独立存储**：每条回复按 **(回复事件, 评价人)** 分开存储——同一条回复被群里多个人评价，会各留一行，互不覆盖。 +- **控制台侧**：控制台会话头部也有对回复的点赞反馈（见 [会话反馈](/zh/ai-sre/sessions#反馈)），与 IM 的 `/feedback` 共用同一套评价体系。 + ## 与控制台会话的关系 --- diff --git a/zh/ai-sre/sessions.mdx b/zh/ai-sre/sessions.mdx index 4a4214f1..f71b4e71 100644 --- a/zh/ai-sre/sessions.mdx +++ b/zh/ai-sre/sessions.mdx @@ -226,7 +226,66 @@ Agent 产出的文件会以产物形式提供预览。点击产物即在右侧 报告类产物（如运营洞察报告）可生成包含 Mermaid 图、图表的 HTML，并在渲染视图中直接查看。运营洞察相关能力见 运营洞察报告。 -所有已发布的产物也可在左侧导航 **产物** 页统一查看与管理（列表、搜索、按个人 / 团队筛选、重命名、下载与删除），详见 产物。 +所有已发布的产物也可在左侧导航 **产物** 页统一查看与管理（列表、搜索、按个人 / 团队筛选、卡片 / 列表视图切换、按创建 / 修改时间排序、重命名、下载与删除），详见 产物。 + +### 状态页更新草稿 + +Agent 可以调用 `statuspage_draft` 工具，为公开状态页**起草**一份公告——新建故障或维护计划事件，或向已有事件追加一条更新。草稿保存在服务端，并在对话流中渲染为一张**状态页更新草稿卡**；但草稿**永远不会被自动发布**：发布状态页会立刻触达订阅者且不可撤回，所以这一步始终留给人工——在控制台的状态页发布表单里逐项核对后再点击发布。 + +#### 草稿卡上有什么 + +卡片复用控制台同类卡片（IncidentCard / MaintenanceCard）的视觉、字段顺序与组件状态图标，让审阅者看到的就是将要发布的内容： + +| 内容 | 说明 | +|---|---| +| 标题 | 新建事件时为表单的 `name` 字段（后端 `title`，最长 255 字符）；追加更新时为其挂靠事件的标题——追加更新表单没有标题字段，此处仅作标识（未提供时显示「未命名状态页更新」） | +| 状态 / 计划时间 | 新建维护计划显示「计划于 〈开始〉 → 〈结束〉」（未设置时显示「未设置计划时间」）；其余情况显示状态文案——故障：排查中 / 已定位 / 监控中 / 已恢复；维护追加更新：已排期 / 进行中 / 已完成 | +| 正文 | `message` 字段**完整渲染**为 Markdown——这是客户将要读到的话，审阅者必须看到全貌，不以纯文本形式出现 | +| 受影响组件 | 每个组件一枚芯片：组件状态图标 + 名称（悬停显示「名称 · 状态」） | +| 目标与类型 | 底部左侧「将发布到 〈状态页〉」（追加更新显示「追加更新 · 〈事件标题〉」），右侧标明类型：故障 / 维护计划 | +| 警示条 | 草稿消息若含有状态页编辑器不支持、加载进表单时会被**静默丢弃**的 Markdown（标题、代码块、引用、图片、删除线、行内代码），卡片会以警示条逐条列出——这是起草时工具已检测到的 | + +#### 卡片状态 + +| 状态 | 表现 | +|---|---| +| 起草中 | 骨架屏，底部显示「正在起草状态页更新…」 | +| 工具报错 | 「没能生成草稿」+ 具体原因；可让 AI 再试一次，或直接去状态页手动创建 | +| 草稿不完整 | 「草稿不完整」+ 同样提示（工具返回了结果但缺少可用的草稿对象） | +| 可审阅 | 按钮为 **审阅 →**：在新标签页打开控制台状态页对应表单，草稿内容自动填入（URL 约定见下） | +| 已发布 | 按钮变为禁用的 **已发布**；底部目标变为**已发布变更**的链接（`/status-page/{page_id}?menu=incidents\|maintenance&incident\|maintenance={change_id}`），可回看草稿最终发布成了什么 | +| 草稿已过期 / 不存在 | 按钮变为禁用的 **草稿已过期**，提示「草稿已过期或不存在，请让 AI 重新起草一份」——控制台查询返回 ResourceNotFound 或网络错误时都按此处理 | + +「是否已发布」是卡片自己无法观察的事实（发布发生在另一个标签页的控制台里），因此卡片会按草稿 ID 请求 `GET /status-page/draft/info?draft_id=...`，返回 `status: pending | published`。草稿仍为 pending 时，窗口每次重新获得焦点都会刷新（「在这里审阅、去那里发布、再回来」是常规路径）；`published` 与「草稿不存在」都是终态，结果缓存在当前页面的生命周期内。只读分享会话不渲染审阅按钮，对草稿状态的查询也一并跳过。 + +#### 审阅交接 URL + +草稿本身保存在服务端（fc-statuspage 的草稿存储），跨到控制台的只有 `draft_id`：表单按 ID 从 `/status-page/draft/info` 拉取正文。URL 按「新建 / 追加」×「故障 / 维护」组合为四种： + +| 场景 | URL | +|---|---| +| 新建故障 | `/status-page/{page_id}?menu=incidents&incident=new&draft={draft_id}` | +| 新建维护计划 | `/status-page/{page_id}?menu=maintenance&maintenance=new&draft={draft_id}` | +| 追加故障更新 | `/status-page/{page_id}?menu=incidents&incident={change_id}&action=add-update&draft={draft_id}` | +| 追加维护更新 | `/status-page/{page_id}?menu=maintenance&maintenance={change_id}&action=add-update&draft={draft_id}` | + +`action=add-update` 让详情页自动展开追加更新表单；缺了它，路由只会打开事件本身，草稿不会被读取。`?draft=` 只携带草稿 ID——草稿是服务端状态，不是 URL 里的一段 JSON。 + +#### 工具要点 + +| 字段 | 说明 | +|---|---| +| `page_id` / `page_name` | 目标状态页（必填）与其显示名（用于卡片展示） | +| `type` | `incident`（故障）/ `maintenance`（维护计划） | +| `change_id` | 省略 = 新建事件；设置 = 向该事件追加更新。起草前工具会先查 `fduty status-page list` 与 `fduty status-page change-active-list`——目标已有进行中的事件时应追加，而不是再开一个（二次事件会被客户读成又一次独立故障） | +| `title` / `message` | 新建事件的标题（≤255 字符）与正文（必填，Markdown；状态页编辑器只保留加粗、斜体、链接、有序 / 无序列表、表格与 `---` 分隔线） | +| `status` | 新建故障：`investigating` / `identified` / `monitoring` / `resolved`；新建维护：省略（是否按计划自动推进由发布表单的开关决定）；追加维护更新：`scheduled` / `ongoing` / `completed` | +| `affected_components` | 受影响组件（`component_id` + `status`，可带显示名 `name`）；故障组件状态：`operational` / `degraded` / `partial_outage` / `full_outage`，维护组件状态：`operational` / `under_maintenance` | +| `start_at_seconds` / `end_at_seconds` | 仅新建维护计划：计划窗口起止，unix **秒**（毫秒与 ISO 字符串都会被视为非法） | + + +渠道差异：控制台（`web`）与自动化渠道渲染上述卡片；IM 与 API 渠道不渲染卡片——Agent 会在**回复开头**放一个「[审阅并发布](〈同样的交接 URL〉)」链接，再用一两句话总结草稿要点（IM 消息截断不识别 Markdown，链接放开头才安全）。若草稿保存失败（没有 `review_url`），它会改为文字总结，并引导你到控制台的状态页手动核对。 + ### 消息操作 diff --git a/zh/changelog/changelog.mdx b/zh/changelog/changelog.mdx index e2a20eed..dc114367 100644 --- a/zh/changelog/changelog.mdx +++ b/zh/changelog/changelog.mdx @@ -4,6 +4,32 @@ description: "本页面记录 Flashduty 产品的重要更新和功能发布" keywords: ["更新日志", "产品发布", "功能更新", "Flashduty", "版本记录"] --- + + +### 告警集成静默检测 + +告警集成（标准/Email/IM/Flashcat 等）新增**静默检测**设置： + +- 开启后，集成在指定时间内（10 分钟~48 小时，默认 10 分钟）未收到有效事件，将生成一条 Warning 告警 +- 「收到新事件后自动恢复」默认开启，收到下一条通过集成校验的事件即自动恢复该告警 + +### AI SRE 状态页草稿 + +AI SRE 会话可调用 **statuspage_draft** 工具起草状态页 incident/maintenance 更新： + +- 聊天内以草稿卡片预览（标题、状态、正文、影响组件） +- AI 只起草不发布，草稿链接跳转控制台发布表单（`?draft=` 预填），由人工审阅发布 +- 草稿状态包含待审阅/已发布/已过期 + +### IM 反馈与评价 + +工作群聊中使用 **/feedback** 可对 AI SRE 回复进行评价或仅评论： + +- 未选评价时可仅提交评论；评价支持 like/dislike/none +- 每个成员的评分独立存储 + + + ### React Native 应用支持 diff --git a/zh/monitors/explore/explore.mdx b/zh/monitors/explore/explore.mdx index 56381712..f2ecdd55 100644 --- a/zh/monitors/explore/explore.mdx +++ b/zh/monitors/explore/explore.mdx @@ -50,6 +50,14 @@ keywords: ["查询工作台", "Explore", "即时查询", "Prometheus", "Loki", " - 24 小时 – 30 天：需手动点击加载。 - 超过 30 天：不支持加载。 +### 日志视图 + +日志类查询的结果以行为单位展示，每行包含时间、正文及字段摘要。若本批结果中存在每行取值都相同的字段（公共字段，如 Loki 的 stream labels），这些字段默认会逐行展示在摘要中，但会重复占据每行的宽度。 + +- 工具条上的 **公共字段** 按钮会列出本批结果中每行相同的字段及其取值；勾选浮层中的 **行内隐藏** 后，这些公共字段将从行内摘要中折叠，行内只保留有差异的内容（并显示「+N 个字段」提示） +- **行内隐藏** 默认关闭（公共字段默认展示）；该开关为会话内状态，不持久化，刷新页面后恢复默认展示 +- 点击行可展开详情，详情始终展示该行的全部字段，不受 **行内隐藏** 开关影响 + ## 查询参数 除查询表达式外，部分数据源支持私有参数： diff --git a/zh/on-call/channel/escalation-rule.mdx b/zh/on-call/channel/escalation-rule.mdx index cc6f52fd..b3514544 100644 --- a/zh/on-call/channel/escalation-rule.mdx +++ b/zh/on-call/channel/escalation-rule.mdx @@ -85,6 +85,8 @@ src="https://download.flashcat.cloud/flashduty/video/escalate-rule.mp4" **跨团队 Webhook 地址提示。** 当您在分派策略中选择 Webhook 机器人地址时，系统会按地址的归属层级分组展示：**本空间**（当前协作空间已引用过）、**本团队**（同团队其他空间引用过）、**其他团队**（仅其他团队的空间引用过）。其他团队的地址默认折叠，需手动展开。选择其他团队的地址时会出现 **跨团队** 标识和警告提示；保存时若存在跨团队地址，会弹出确认对话框要求二次确认，避免告警误发到其他团队的群聊。 + + 选择或粘贴**其他团队**的 Webhook 地址时，别名会自动带上来源团队名的前缀（如 `团队名-别名`；若历史别名已以该前缀开头则不会重复累加，粘贴时仅当别名为空才补全），加完前缀后别名仍可手动修改。 diff --git a/zh/on-call/incident/handle-update-incident.mdx b/zh/on-call/incident/handle-update-incident.mdx index 83f2d58e..d2f16538 100644 --- a/zh/on-call/incident/handle-update-incident.mdx +++ b/zh/on-call/incident/handle-update-incident.mdx @@ -122,7 +122,7 @@ Flashduty On-call 推送的语音告警，在语音播报结束时，会提醒 -控制台点击故障详情，点击 **暂缓** 按钮，选择暂缓时长，完成。 +控制台点击故障详情，点击右上角 **更多（⋮）** → 选择 **暂缓** 子菜单，选择暂缓时长，完成。仅处理中的故障可暂缓。 @@ -187,7 +187,10 @@ Flashduty On-call 推送的语音告警，在语音播报结束时，会提醒 | :--- | :--- | | **合并至故障** | 将当前故障并入另一个目标故障，合并后两个故障的告警将集中在目标故障处理 | | **快速静默** | 跳转到当前故障所属协作空间的告警静默配置页面，并预填当前故障的关键字段，便于快速创建一条针对性静默策略 | +| **暂缓** | 仅当故障处于处理中时出现。进入暂缓子菜单后可从预设时长中选择或自定义暂缓时长，详见[暂缓处理](#暂缓处理)；故障已关闭或不处于处理中时该项不显示 | +| **升级** | 仅当升级策略已启用且故障未关闭时出现。将故障升级到分派链路中的指定环节（按升级策略逐级升级的环节），选择目标层级后由该环节处理人接管 | | **取消认领** | 仅当您已认领且故障尚未关闭时出现，用于撤销先前的认领操作。所有认领人员全部取消后，故障会回退为 **待处理** 状态 | +| **重新分派** | 仅当故障未关闭时出现。打开重新分派对话框，将故障重新分派给其他成员 | | **添加关注人员进入作战室** | 仅当故障已创建作战室时出现，支持将更多成员拉入对应的 IM 作战群组 | | **解散作战室** | 仅当故障已创建作战室时出现，解散后将关闭 IM 作战群组。详见[作战室](/zh/on-call/advanced/war-room) | | **自定义操作** | 由管理员在集成中配置的 Jira、ServiceNow、ServiceDesk Plus 与通用自定义动作 | diff --git a/zh/on-call/incident/search-view-incident.mdx b/zh/on-call/incident/search-view-incident.mdx index 4b3ab59f..4c007784 100644 --- a/zh/on-call/incident/search-view-incident.mdx +++ b/zh/on-call/incident/search-view-incident.mdx @@ -16,7 +16,7 @@ Flashduty On-call 提供了两个入口查看故障列表。一个是协作空 | :---: | :--- | :--- | | 1 | 分派人员 | 默认聚焦为 **分派给我** 的故障，可切换为查看整个账户下的故障 | | 2 | 我的协作空间 | 默认聚焦为全部协作空间，可切换为查看**我的协作空间**的故障 | -| 3 | 处理进度 | 按照处理进度筛选故障，默认为 **全部** | +| 3 | 处理进度 | 按照处理进度筛选故障，默认为 **未关闭**（待处理/处理中），可切换为全部或其他进度 | | 4 | 时间筛选 | 支持相对时间和自定义区间筛选 | | 5 | 键入检索 | 支持搜索故障标题、ID、标签和自定义字段。故障标题、标签、自定义字段更新后，查询结果可能存在短暂延迟 | | 6 | 更多筛选 | 支持丰富的维度筛选，包括严重程度、处理人员、与我相关、发起人员、认领人员、关闭人员、暂缓状态、抖动收敛过、新奇故障、标签和自定义字段等。其中**协作空间**和**团队**筛选仅在全局故障管理入口下可见，团队按协作空间归属的团队过滤故障；**与我相关**匹配我作为发起人员、认领人员、关闭人员或处理人员的故障 | @@ -103,6 +103,10 @@ Flashduty On-call 提供各种维度的筛选能力，并给您足够多的灵 除 **AI 分析** 外，以上批量操作均需具备故障更新权限。 + +批量选择**最多支持 100 条**故障：勾选数量达到上限后，继续勾选会被拒绝并提示「批量操作最多支持选择 100 项数据」。需要处理更多故障时，请缩小筛选范围（如按时间、分派人员）分批操作。 + + ### 自定义渲染 点击故障列表右上角的 **设置** 按钮，可以定制化展示内容和交互行为： diff --git a/zh/on-call/integration/alert-integration/alert-sources/email.mdx b/zh/on-call/integration/alert-integration/alert-sources/email.mdx index 5006d4e3..b61911d7 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/email.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/email.mdx @@ -64,6 +64,7 @@ keywords: ["告警集成", "邮件Email集成", "监控告警", "数据接入"] - 您至少需要填写一条**触发**规则； - 您必须设置 Alert Key 的正则提取规则。系统使用该字段来查找历史告警，以便对其进行更新或关闭；**如果正则提取失败，系统将使用邮件标题来生成 Alert Key**，以确保告警不会因为配置错误而丢失； + - Alert Key 的正则表达式必须为合法的 RE2 正则。保存规则时系统会进行校验，非法的表达式会被拦截并提示「请输入合法的正则表达式」； - 您可以选择，当所有的规则都不匹配时，是否丢弃邮件。 配置示例： @@ -73,6 +74,16 @@ keywords: ["告警集成", "邮件Email集成", "监控告警", "数据接入"] drawing +#### 静默检测 + +在集成卡片（编辑与预览）中，**静默检测**（Heartbeat）配置位于推送设置下方：在指定时间内未收到有效事件时，系统会生成一条 Warning 告警。 + +| 配置项 | 说明 | +| :--- | :--- | +| **启用静默检测** | 开关，默认关闭。开启后，仅成功通过集成校验的上游事件会刷新检测时间 | +| **检测时间（分钟）** | 在指定时间内未收到有效事件，即生成一条 Warning 告警。取值须为整数，范围为 10 分钟 ~ 48 小时（默认 10 分钟） | +| **收到新事件后自动恢复** | 开关，默认开启。收到下一条有效事件时，自动恢复静默检测产生的告警 | + ### 注意事项 1. 如果邮件消息体大于 5MB，系统会直接拒绝接收。 diff --git a/zh/on-call/integration/alert-integration/alert-sources/flashcat.mdx b/zh/on-call/integration/alert-integration/alert-sources/flashcat.mdx index b56e1a7a..8a35ecef 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/flashcat.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/flashcat.mdx @@ -211,6 +211,18 @@ keywords: ["告警集成", "夜莺集成", "Flashcat集成", "n9e", "监控告 +## 静默检测 + +--- + +在集成卡片（编辑与预览）中，告警推送设置下方提供 **静默检测**（Heartbeat）配置：在指定时间内未收到有效事件时，系统会生成一条 Warning 告警。 + +| 配置项 | 说明 | +| :--- | :--- | +| **启用静默检测** | 开关，默认关闭。开启后，仅成功通过集成校验的上游事件会刷新检测时间 | +| **检测时间（分钟）** | 在指定时间内未收到有效事件，即生成一条 Warning 告警。取值须为整数，范围为 10 分钟 ~ 48 小时（默认 10 分钟） | +| **收到新事件后自动恢复** | 开关，默认开启。收到下一条有效事件时，自动恢复静默检测产生的告警 | + ## 严重程度映射 --- diff --git a/zh/on-call/integration/alert-integration/alert-sources/standard-alert.mdx b/zh/on-call/integration/alert-integration/alert-sources/standard-alert.mdx index 99a93446..90f1321c 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/standard-alert.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/standard-alert.mdx @@ -196,7 +196,8 @@ curl -X POST '{api_host}/event/push/alert/standard?integration_key={integration_ | event_status | 告警状态（Critical / Warning / Info / Ok） | | alert_key | 告警标识 | | labels | 告警标签 | -| images | 图片数组 | + +以上为集成设置中字段映射编辑器支持的目标字段白名单。`images` 字段仅支持在请求 Payload 中直接上报，不支持通过字段映射配置。 **变量语法：** @@ -263,6 +264,16 @@ curl -X POST '{api_host}/event/push/alert/standard?integration_key={integration_ 所有 `{{...}}` 变量必须能在原始 JSON 中解析到值，否则请求会报错。建议先用少量数据测试映射配置是否正确。 +## 静默检测 + +在告警集成详情页（编辑与预览）中，基础设置卡片下方提供 **静默检测**（Heartbeat）配置卡片：在指定时间内未收到有效事件时，系统会生成一条 Warning 告警。 + +| 配置项 | 说明 | +| :--- | :--- | +| **启用静默检测** | 开关，默认关闭。开启后，仅成功通过集成校验的上游事件会刷新检测时间 | +| **检测时间（分钟）** | 指定时间内未收到有效事件，即生成一条 Warning 告警。取值须为整数，范围为 10 分钟 ~ 48 小时（默认 10 分钟） | +| **收到新事件后自动恢复** | 开关，默认开启。收到下一条有效事件时，自动恢复静默检测产生的告警 | + ## 四、最佳实践 --- diff --git a/zh/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx b/zh/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx index b455b5d8..06182e66 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/wecom-alert.mdx @@ -64,11 +64,25 @@ keywords: ["告警集成", "企微", "监控告警", "数据接入"] - 您必须设置 Alert Key 的正则提取规则。系统使用该字段来查找历史告警，以便对其进行更新或关闭；**如果正则提取失败，系统将随机来生成 Alert Key**，以确保告警不会因为配置错误而丢失； - 您可以选择，当所有的规则都不匹配时，是否丢弃消息。 + + 正则提取规则必须是**合法的正则表达式（RE2 语法）**：提交时前端会校验其可编译性，非法正则（如不支持的语法）无法保存，并提示「请输入合法的正则表达式」。只有正则合法但未匹配到内容时，系统才会随机生成 Alert Key。 + + 配置示例： - 接收所有消息，当消息内容中包含 **RESOVED** 字样时，关闭告警，否则触发新告警； - Alert Key 从消息内容中提取，规则为 **/(.\*)/**。 +#### 静默检测 + +告警集成详情页（编辑与预览）的基础设置卡片下方提供 **静默检测**（Heartbeat）配置卡片：在指定时间内未收到有效事件时，系统会生成一条 Warning 告警。 + +| 配置项 | 说明 | +| :--- | :--- | +| **启用静默检测** | 开关，默认关闭。开启后，仅成功通过集成校验的上游事件会刷新检测时间 | +| **检测时间（分钟）** | 指定时间内未收到有效事件，即生成一条 Warning 告警。取值须为整数，范围为 10 分钟 ~ 48 小时（默认 10 分钟） | +| **收到新事件后自动恢复** | 开关，默认开启。收到下一条有效事件时，自动恢复静默检测产生的告警 | + ### 注意事项 - 企微告警集成地址仅支持接收 Text、Markdown 消息类型，其他消息无法接收。 diff --git a/zh/on-call/integration/alert-integration/routing-rules.mdx b/zh/on-call/integration/alert-integration/routing-rules.mdx index dbc2db67..c5092e96 100644 --- a/zh/on-call/integration/alert-integration/routing-rules.mdx +++ b/zh/on-call/integration/alert-integration/routing-rules.mdx @@ -58,14 +58,14 @@ keywords: ["路由规则", "告警路由", "分发策略", "协作空间", "分 路由规则支持查看编辑历史，帮助你追踪配置变更并在需要时快速回滚。 -点击路由配置页面中的 **编辑历史** 按钮，打开侧边栏面板。历史记录按日期分组显示，每条记录包含版本号、操作人和修改时间。当前生效的版本会标注为 **当前版本**。 +点击路由配置页面中的 **编辑历史** 按钮，打开对话框（左侧为历史版本列表，右侧为差异对比区）。历史记录按日期分组显示，每条记录包含版本号、操作人和修改时间。当前生效的版本会标注为 **当前版本**。 你可以执行以下操作： | 操作 | 说明 | | :--- | :--- | -| **对比** | 点击任意历史版本，查看该版本与当前版本的配置差异（Diff 视图） | -| **恢复** | 在对比视图中，选择将路由规则恢复到指定的历史版本 | +| **对比** | 默认对比所选历史版本与当前版本的配置差异（内置分屏 Diff 视图）；左右两侧各有一个版本下拉，可以选择任意两个历史版本进行对比 | +| **恢复** | 在对比视图中，选择将路由规则恢复到指定的历史版本；对比两侧均可恢复 | 编辑历史支持无限滚动加载，每次加载 50 条记录。 diff --git a/zh/on-call/integration/webhooks/jira-sync.mdx b/zh/on-call/integration/webhooks/jira-sync.mdx index 95ef40a0..fd9d5422 100644 --- a/zh/on-call/integration/webhooks/jira-sync.mdx +++ b/zh/on-call/integration/webhooks/jira-sync.mdx @@ -49,8 +49,8 @@ keywords: ["Jira", "工单同步", "Webhook", "Issue跟踪", "故障关联"] - **项目 ID**：选择需要同步至 Jira 的项目。 - **事务类型**：选择需要同步至 Jira 的事务类型。 - **协作空间**：选择该集成生效的协作空间，只有该协作空间内的故障才可以同步至 Jira 中。 -- **严重程度映射**：如果选择的事务类型不支持优先级字段，则无法配置该映射关系。 -- **自定义字段映射**：可以选择将故障的某些标签或所有标签以及自定义字段内容同步至 Jira 的字段中（仅支持文本类型的字段）。 +- **严重程度映射**：如果选择的事务类型不支持优先级字段，则无法配置该映射关系。每行的 **Jira 优先级**（结果字段）为必填项，缺省时无法保存集成配置。 +- **自定义字段映射**：可以选择将故障的某些标签或所有标签以及自定义字段内容同步至 Jira 的字段中（仅支持文本类型的字段）。每行的 **Key**（故障字段）与 **结果字段**（Jira 字段）均为必填项，缺省时无法保存集成配置。 ### 3. 关于更新