From 45dda5aa3e7e9bfc10d977dee3635222f8bcf10b Mon Sep 17 00:00:00 2001 From: Flashduty AI-SRE Date: Thu, 22 Oct 2026 08:21:48 +0000 Subject: [PATCH 1/2] =?UTF-8?q?docs(doc-review):=202026-10-22=20diff=20aud?= =?UTF-8?q?it=20=E2=80=94=20Prometheus=20Alertmanager=20rename,=20related?= =?UTF-8?q?=20raw-log=20results,=20symbol-file=20time=20filter,=20typo=20r?= =?UTF-8?q?edirect?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - on-call/integration: alert-source card renamed to Prometheus Alertmanager (5 pages, zh+en) - on-call: related-query results split by query type (table vs raw log lines, 3-row hover cap) - rum: symbol-file list time-filter limits (30-day span, 365-day lookback) - docs.json: additive redirects for the product's erro-reporting typo path - held: IM natural-language chat settings (flag off in prod), schedule robot @ mentions (console control not shipped) --- docs.json | 8 ++++++++ en/on-call/incident/search-view-incident.mdx | 2 +- .../alert-sources/chronosphere.mdx | 12 ++++++------ .../alert-integration/alert-sources/cubeapm.mdx | 12 ++++++------ .../alert-integration/alert-sources/prometheus.mdx | 4 ++-- .../alert-sources/red-hat-openshift.mdx | 12 ++++++------ .../alert-integration/alert-sources/robusta.mdx | 2 +- .../alert-integration/alert-sources/signoz.mdx | 14 +++++++------- en/rum/error-tracking/source-mapping.mdx | 1 + zh/on-call/incident/search-view-incident.mdx | 2 +- .../alert-sources/chronosphere.mdx | 12 ++++++------ .../alert-integration/alert-sources/cubeapm.mdx | 12 ++++++------ .../alert-integration/alert-sources/prometheus.mdx | 4 ++-- .../alert-sources/red-hat-openshift.mdx | 12 ++++++------ .../alert-integration/alert-sources/robusta.mdx | 2 +- .../alert-integration/alert-sources/signoz.mdx | 14 +++++++------- zh/rum/error-tracking/source-mapping.mdx | 1 + 17 files changed, 68 insertions(+), 58 deletions(-) diff --git a/docs.json b/docs.json index 9a8375d45..079bf224e 100644 --- a/docs.json +++ b/docs.json @@ -3010,6 +3010,14 @@ { "source": "/webhook/history/list", "destination": "/zh/api-reference/on-call/integrations/webhook-history-list" + }, + { + "source": "/zh/rum/error-tracking/erro-reporting/web", + "destination": "/zh/rum/error-tracking/error-reporting/web" + }, + { + "source": "/en/rum/error-tracking/erro-reporting/web", + "destination": "/en/rum/error-tracking/error-reporting/web" } ], "navigation": { diff --git a/en/on-call/incident/search-view-incident.mdx b/en/on-call/incident/search-view-incident.mdx index ccbb5d44e..473440d70 100644 --- a/en/on-call/incident/search-view-incident.mdx +++ b/en/on-call/incident/search-view-incident.mdx @@ -172,7 +172,7 @@ Each entry is one row showing the entry-type icon (query or dashboard), the **pu - Hovering an entry opens a detail card with the full query expression (copyable), the named **variables** (filled in from the alert's labels; unresolved ones are highlighted in red), and the **time range** — the relative window on one line (for example "60 min before → 10 min after the alert") and the absolute start and end on the next. An **Open** button at the bottom opens the corresponding view in the Query Workbench or dashboard in a new tab - The number next to the heading is how many entries the snapshot holds; the **N with issues** badge counts the entries that render with a problem (query failed to render, dashboard variable unresolved, data source or dashboard deleted or unauthorized) - Only the first **3** entries show by default; the rest sit behind **N more**, which expands and collapses -- Below the entries are the **Related alert rule** card (rule name plus data source, clickable through to the rule) and the rule's **Queries**: main queries are listed by `A` / `B` with the **value at trigger time**, hover for the full expression with a copy button, and a no-data alert is marked **No data** on the matching main query; related queries show the **result table at trigger time** +- Below the entries are the **Related alert rule** card (rule name plus data source, clickable through to the rule) and the rule's **Queries**: main queries are listed by `A` / `B` with the **value at trigger time**, hover for the full expression with a copy button, and a no-data alert is marked **No data** on the matching main query; related queries show the **result at trigger time**: a result table for statistical queries, and for a VictoriaLogs / Loki related query whose query mode is **Raw** one log line per row with its fields laid out as `k=v` and the fields that do not fit collapsed into **+N fields**; the hover card shows at most 3 rows, and **View full data** next to its heading opens the query workbench with everything When the rule has no investigation entries configured, the block says "No investigation entries configured on the rule" and offers a **Configure** link. Other cases where entries cannot be shown: diff --git a/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx b/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx index 878b209aa..39db38983 100644 --- a/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx @@ -1,29 +1,29 @@ --- title: "Chronosphere alert integration" sidebarTitle: "Chronosphere" -description: "Receive Chronosphere alerts through Chronosphere's webhook notifier using a Flashduty Prometheus integration; with resolved notifications on, alerts close automatically." +description: "Receive Chronosphere alerts through Chronosphere's webhook notifier using a Flashduty Prometheus Alertmanager integration; with resolved notifications on, alerts close automatically." keywords: ["alert integration", "Chronosphere", "webhook", "Prometheus", "Alertmanager", "observability"] --- -Chronosphere's webhook notifier sends an HTTP POST to the URL you enter. The body is Prometheus Alertmanager JSON (`version` is `4`, with `status`, `alerts`, `fingerprint`, `labels`, `annotations`, `startsAt`, `endsAt`, plus an extra `notifier` field). The Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate Chronosphere integration is needed: create a Prometheus integration in Flashduty and paste its push URL into Chronosphere. +Chronosphere's webhook notifier sends an HTTP POST to the URL you enter. The body is Prometheus Alertmanager JSON (`version` is `4`, with `status`, `alerts`, `fingerprint`, `labels`, `annotations`, `startsAt`, `endsAt`, plus an extra `notifier` field). The Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate Chronosphere integration is needed: create a Prometheus Alertmanager integration in Flashduty and paste its push URL into Chronosphere.
## In Flashduty On-call -Get an integration push URL in either of the two ways below. **Choose the Prometheus integration type** in both, not Chronosphere. +Get an integration push URL in either of the two ways below. **Choose the Prometheus Alertmanager integration type** in both, not Chronosphere. ### Use a dedicated integration 1. In the Flashduty console, go to **Channels** and open a channel 2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration** -3. Select **Prometheus** and click **Save** +3. Select **Prometheus Alertmanager** and click **Save** 4. Open the generated integration card and copy the **Push URL**, in the form `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=` ### Use a shared integration 1. In the Flashduty console, go to **Integration Center → Alert Events** -2. Select **Prometheus** and enter an integration name +2. Select **Prometheus Alertmanager** and enter an integration name 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation 4. Click **Save** and copy the generated **Push URL** @@ -81,6 +81,6 @@ One notification can carry several alerts, and Flashduty handles each one separa ## Troubleshooting -- **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus +- **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus Alertmanager - **Alerts do not recover**: confirm the notifier has **Notify when resolved** selected (`send_resolved` is `true` in Terraform, `skip_resolved` is `false` in Chronoctl) and that the resolved notification's `fingerprint` matches the trigger - **No alerts arrive**: confirm a notification policy routes the relevant severities to this notifier, and that Chronosphere can reach `api.flashcat.cloud` diff --git a/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx b/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx index 1776eaa24..fc1882fff 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx @@ -1,29 +1,29 @@ --- title: "CubeAPM alert integration" sidebarTitle: "CubeAPM" -description: "Receive CubeAPM alerts through CubeAPM's webhook receiver using a Flashduty Prometheus integration; alerts close automatically when they resolve." +description: "Receive CubeAPM alerts through CubeAPM's webhook receiver using a Flashduty Prometheus Alertmanager integration; alerts close automatically when they resolve." keywords: ["alert integration", "CubeAPM", "webhook", "Prometheus", "Alertmanager", "observability"] --- -CubeAPM can send alert notifications by HTTP POST to any webhook URL. The default JSON body is compatible with the Prometheus Alertmanager webhook format (`receiver`, `status`, `alerts`, `groupLabels`, `commonLabels`, `commonAnnotations`, `externalURL`, and so on; each alert carries `status`, `labels`, `annotations`, `startsAt`, `endsAt`, `generatorURL`, `fingerprint`, plus CubeAPM's own `cubeImageURL` and `cubeSampleLog`). The Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate CubeAPM integration is needed: create a Prometheus integration in Flashduty and paste its push URL into CubeAPM. +CubeAPM can send alert notifications by HTTP POST to any webhook URL. The default JSON body is compatible with the Prometheus Alertmanager webhook format (`receiver`, `status`, `alerts`, `groupLabels`, `commonLabels`, `commonAnnotations`, `externalURL`, and so on; each alert carries `status`, `labels`, `annotations`, `startsAt`, `endsAt`, `generatorURL`, `fingerprint`, plus CubeAPM's own `cubeImageURL` and `cubeSampleLog`). The Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate CubeAPM integration is needed: create a Prometheus Alertmanager integration in Flashduty and paste its push URL into CubeAPM.
## In Flashduty On-call -Get an integration push URL in either of the two ways below. **Choose the Prometheus integration type** in both, not CubeAPM. +Get an integration push URL in either of the two ways below. **Choose the Prometheus Alertmanager integration type** in both, not CubeAPM. ### Use a dedicated integration 1. In the Flashduty console, go to **Channels** and open a channel 2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration** -3. Select **Prometheus** and click **Save** +3. Select **Prometheus Alertmanager** and click **Save** 4. Open the generated integration card and copy the **Push URL**, in the form `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=` ### Use a shared integration 1. In the Flashduty console, go to **Integration Center → Alert Events** -2. Select **Prometheus** and enter an integration name +2. Select **Prometheus Alertmanager** and enter an integration name 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation 4. Click **Save** and copy the generated **Push URL** @@ -69,6 +69,6 @@ One notification can carry several alerts, and Flashduty handles each one separa ## Troubleshooting -- **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus +- **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus Alertmanager - **Alerts do not resolve**: confirm that every alert in a customized Payload has `status` and `fingerprint`, and that the recovery notification carries the same `fingerprint` as the trigger - **No alerts arrive**: confirm CubeAPM can reach `api.flashcat.cloud` and that the alert rule uses this webhook receiver diff --git a/en/on-call/integration/alert-integration/alert-sources/prometheus.mdx b/en/on-call/integration/alert-integration/alert-sources/prometheus.mdx index 75fc27cae..95cf1425e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/prometheus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/prometheus.mdx @@ -34,7 +34,7 @@ Choose this option if all alerts go to one channel. It's the simpler setup. 1. In the Flashduty console, select **Channel** and open a channel 2. Select **Configuration** → **Integrations** → **Private integration**, then click **Add an integration**, and enter the integration page - 3. Select **Prometheus** integration, click **Save** to generate a card + 3. Select **Prometheus Alertmanager** integration, click **Save** to generate a card 4. Open the generated integration card and copy the **Push URL** @@ -48,7 +48,7 @@ Choose this method when you need to route alert events to different channels bas 1. In the Flashduty console, go to **Integration Center → Alert Events** - 2. Select **Prometheus** integration: + 2. Select **Prometheus Alertmanager** integration: - **Integration Name**: Define a name for this integration 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation 4. Click **Save** and copy the generated **Push URL** diff --git a/en/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx b/en/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx index 6aacc1c48..9a1e42d8f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx @@ -1,29 +1,29 @@ --- title: "Red Hat OpenShift alert integration" sidebarTitle: "Red Hat OpenShift" -description: "Receive OpenShift cluster alerts through the webhook receiver of OpenShift monitoring's built-in Alertmanager using a Flashduty Prometheus integration; alerts close automatically when they resolve." +description: "Receive OpenShift cluster alerts through the webhook receiver of OpenShift monitoring's built-in Alertmanager using a Flashduty Prometheus Alertmanager integration; alerts close automatically when they resolve." keywords: ["alert integration", "Red Hat OpenShift", "OpenShift", "Alertmanager", "webhook", "Prometheus", "Kubernetes"] --- -The OpenShift Container Platform monitoring stack ships its own Alertmanager (`alertmanager-main` in the `openshift-monitoring` project). The official documentation lists PagerDuty, Webhook, Email, Slack and Microsoft Teams as receiver types, and states that the features of a supported upstream Alertmanager version are supported in OpenShift as well. The webhook receiver sends Alertmanager JSON to the URL you set (`version` is `4`; each alert carries `status`, `labels`, `annotations`, `startsAt`, `endsAt`, `generatorURL`, `fingerprint`). The Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate OpenShift integration is needed: create a Prometheus integration in Flashduty and configure its push URL as a webhook receiver in the OpenShift Alertmanager. +The OpenShift Container Platform monitoring stack ships its own Alertmanager (`alertmanager-main` in the `openshift-monitoring` project). The official documentation lists PagerDuty, Webhook, Email, Slack and Microsoft Teams as receiver types, and states that the features of a supported upstream Alertmanager version are supported in OpenShift as well. The webhook receiver sends Alertmanager JSON to the URL you set (`version` is `4`; each alert carries `status`, `labels`, `annotations`, `startsAt`, `endsAt`, `generatorURL`, `fingerprint`). The Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate OpenShift integration is needed: create a Prometheus Alertmanager integration in Flashduty and configure its push URL as a webhook receiver in the OpenShift Alertmanager.
## In Flashduty On-call -Get an integration push URL in either of the two ways below. **Choose the Prometheus integration type** in both, not Red Hat OpenShift. +Get an integration push URL in either of the two ways below. **Choose the Prometheus Alertmanager integration type** in both, not Red Hat OpenShift. ### Use a dedicated integration 1. In the Flashduty console, go to **Channels** and open a channel 2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration** -3. Select **Prometheus** and click **Save** +3. Select **Prometheus Alertmanager** and click **Save** 4. Open the generated integration card and copy the **Push URL**, in the form `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=` ### Use a shared integration 1. In the Flashduty console, go to **Integration Center → Alert Events** -2. Select **Prometheus** and enter an integration name +2. Select **Prometheus Alertmanager** and enter an integration name 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation 4. Click **Save** and copy the generated **Push URL** @@ -114,6 +114,6 @@ One notification can carry several alerts, and Flashduty handles each one separa ## Troubleshooting -- **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus +- **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus Alertmanager - **Alerts do not resolve**: confirm the receiver does not set `send_resolved: false` - **No alerts arrive**: confirm the route `matchers` or **Routing labels** match the alert labels and the cluster can reach `api.flashcat.cloud` (with a cluster-wide HTTP proxy, see the `proxy_from_environment` note in the OpenShift documentation); `oc exec alertmanager-main-0 -n openshift-monitoring -- amtool config routes show --alertmanager.url http://localhost:9093` shows the effective routes diff --git a/en/on-call/integration/alert-integration/alert-sources/robusta.mdx b/en/on-call/integration/alert-integration/alert-sources/robusta.mdx index 373b050c9..72c37b842 100644 --- a/en/on-call/integration/alert-integration/alert-sources/robusta.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/robusta.mdx @@ -69,7 +69,7 @@ Problems that Robusta detects itself (`source` is `KUBERNETES_API_SERVER` and si -If your Prometheus alerts do not go through Robusta, Alertmanager can also push them straight to the Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus). +If your Prometheus alerts do not go through Robusta, Alertmanager can also push them straight to the Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus). ## Alert key diff --git a/en/on-call/integration/alert-integration/alert-sources/signoz.mdx b/en/on-call/integration/alert-integration/alert-sources/signoz.mdx index 4b420799d..7bb412493 100644 --- a/en/on-call/integration/alert-integration/alert-sources/signoz.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/signoz.mdx @@ -1,29 +1,29 @@ --- title: "SigNoz alert integration" sidebarTitle: "SigNoz" -description: "Receive SigNoz alerts through SigNoz's webhook notification channel using a Flashduty Prometheus integration; resolve notifications close the alert automatically." +description: "Receive SigNoz alerts through SigNoz's webhook notification channel using a Flashduty Prometheus Alertmanager integration; resolve notifications close the alert automatically." keywords: ["alert integration", "SigNoz", "webhook", "Prometheus", "Alertmanager", "observability"] --- -SigNoz's webhook notification channel sends Prometheus Alertmanager JSON (`status`, `alerts`, `fingerprint`, `labels`, `annotations`, `startsAt`, `endsAt`) to the URL you enter. The Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate SigNoz integration is needed: create a Prometheus integration in Flashduty and paste its push URL into SigNoz. +SigNoz's webhook notification channel sends Prometheus Alertmanager JSON (`status`, `alerts`, `fingerprint`, `labels`, `annotations`, `startsAt`, `endsAt`) to the URL you enter. The Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate SigNoz integration is needed: create a Prometheus Alertmanager integration in Flashduty and paste its push URL into SigNoz.
## In Flashduty On-call -Get an integration push URL in either of the two ways below. **Choose the Prometheus integration type** in both, not SigNoz. +Get an integration push URL in either of the two ways below. **Choose the Prometheus Alertmanager integration type** in both, not SigNoz. ### Use a dedicated integration 1. In the Flashduty console, go to **Channels** and open a channel 2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration** -3. Select **Prometheus** and click **Save** +3. Select **Prometheus Alertmanager** and click **Save** 4. Open the generated integration card and copy the **Push URL**, in the form `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=` ### Use a shared integration 1. In the Flashduty console, go to **Integration Center → Alert Events** -2. Select **Prometheus** and enter an integration name +2. Select **Prometheus Alertmanager** and enter an integration name 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation 4. Click **Save** and copy the generated **Push URL** @@ -53,12 +53,12 @@ SigNoz groups notifications by rule (`ruleId`); one notification can carry sever ## Recovery and deduplication - When SigNoz sends a notification with `status` set to `resolved`, Flashduty closes the alert with the same `fingerprint`. -- In current SigNoz rules the `severity` label is taken from the threshold row name (for example a threshold named `critical` or `warning`), which is also written to the `threshold.name` label. If you use a value that is not built in, such as `error`, configure a custom severity mapping on the Prometheus integration; otherwise it is treated as Warning. +- In current SigNoz rules the `severity` label is taken from the threshold row name (for example a threshold named `critical` or `warning`), which is also written to the `threshold.name` label. If you use a value that is not built in, such as `error`, configure a custom severity mapping on the Prometheus Alertmanager integration; otherwise it is treated as Warning. - The resolved notification arrives several minutes after the rule returns to normal (observed: about 30 seconds for firing, 6 to 10 minutes for resolved). This is expected. - The channel's **Test** button sends a `firing` test alert titled `Test Alert ()` with `severity` `critical`. It opens a Critical alert in Flashduty and is never followed by a resolved notification, so close that alert manually. ## Troubleshooting -- **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus +- **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus Alertmanager - **Alerts do not recover**: confirm **Send resolved alerts** is on for the SigNoz channel and that the resolved notification's `fingerprint` matches the trigger - **Resolved notifications arrive late**: SigNoz sends the resolved notification several minutes after the rule returns to normal, which is its default behavior diff --git a/en/rum/error-tracking/source-mapping.mdx b/en/rum/error-tracking/source-mapping.mdx index c73cd9bb9..edddaa350 100644 --- a/en/rum/error-tracking/source-mapping.mdx +++ b/en/rum/error-tracking/source-mapping.mdx @@ -523,6 +523,7 @@ On the Flashduty platform, symbol file management is done through the "Applicati | Feature | Description | |---------|-------------| | View Uploaded Symbol Files | List all uploaded files (SourceMaps, Mini Program SourceMaps, ProGuard mapping files, dSYMs, NDK native symbol files, Flutter symbol files, Electron Breakpad symbol files, and React Native bundle sourcemaps), including path, service name, version, size, and upload time. The Android tab shows both ProGuard mapping files and NDK native symbol files; NDK rows display build_id, arch, and lib_name columns. The Electron tab shows one row per native module with Module (lib_name), Debug ID (build_id), Architecture (arch), Service, Version, and Size columns, and supports searching by Debug ID | +| Filter by Upload Time | The list can be filtered by upload time. One filter spans at most 30 days, and the earliest start is 365 days back; symbol files uploaded earlier cannot be listed | | Filter by Platform | Switch between Web, iOS, Android, WeChat Mini Program, HarmonyOS, Flutter, Electron, and React Native tabs to view symbol files for each platform | | Version Management | Manage different application versions separately through `service` and `release-version` parameters | | Mini Program Dimensions | The WeChat Mini Program list shows AppID and Subpackage columns; the main package shows "Main Package", and an AppID that was not uploaded shows `-` | diff --git a/zh/on-call/incident/search-view-incident.mdx b/zh/on-call/incident/search-view-incident.mdx index 05955870c..ee9c88bec 100644 --- a/zh/on-call/incident/search-view-incident.mdx +++ b/zh/on-call/incident/search-view-incident.mdx @@ -173,7 +173,7 @@ AI 总结仅适用于由告警自动触发的故障，手动创建的故障不 - 悬停任意一条会弹出详情卡：完整的查询语句（可复制）、按名称列出的**变量**（由告警标签填入，`未解析` 的变量标红）、以及 **时间范围**（上一行是相对告警的前后时长，如「告警前 60 分钟 → 后 10 分钟」，下一行是绝对起止时间），底部是 **打开入口** 按钮，点击在新页签打开查询工作台或仪表盘对应视图 - 标题旁的数字是快照里的入口条数；**N 个异常** 徽标统计其中渲染有问题的入口（查询渲染失败、仪表盘变量未解析、数据源或仪表盘已删除 / 无权限） - 默认只显示前 **3** 条，其余收在 **还有 N 个** 后面，点击展开或收起 -- 入口列表下方是 **关联告警规则** 卡片（规则名称 + 数据源，点击跳转到规则）与 **查询语句**：主查询按 `A` / `B` 逐条给出**触发时刻的值**，悬停可看完整表达式并复制，无数据告警会在对应主查询上标注 **无数据**；关联查询给出**触发时刻的结果表格** +- 入口列表下方是 **关联告警规则** 卡片（规则名称 + 数据源，点击跳转到规则）与 **查询语句**：主查询按 `A` / `B` 逐条给出**触发时刻的值**，悬停可看完整表达式并复制，无数据告警会在对应主查询上标注 **无数据**；关联查询给出**触发时刻的结果**：统计类查询是结果表格，VictoriaLogs / Loki 且查询方式为「原文」的关联查询按一行一条日志展示，字段以 `k=v` 排开、放不下的字段收成「+N 个字段」；悬停卡里最多展示 3 条结果，标题右侧的 **查看完整数据** 会打开查询工作台看全量 规则尚未配置排查入口时，区块会提示「规则还没配排查入口」并提供 **去配置** 跳转。其他无法显示的情况： diff --git a/zh/on-call/integration/alert-integration/alert-sources/chronosphere.mdx b/zh/on-call/integration/alert-integration/alert-sources/chronosphere.mdx index 8306d049f..7028e17ba 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/chronosphere.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/chronosphere.mdx @@ -1,29 +1,29 @@ --- title: "Chronosphere 告警集成" sidebarTitle: "Chronosphere" -description: "通过 Chronosphere 的 Webhook 通知器，使用 Flashduty 的 Prometheus 集成接收 Chronosphere 告警，开启恢复通知后自动关闭告警。" +description: "通过 Chronosphere 的 Webhook 通知器，使用 Flashduty 的 Prometheus Alertmanager 集成接收 Chronosphere 告警，开启恢复通知后自动关闭告警。" keywords: ["告警集成", "Chronosphere", "Webhook", "Prometheus", "Alertmanager", "可观测性"] --- -Chronosphere 的 Webhook 通知器（Notifier）向您填写的 URL 发送 HTTP POST 请求，请求体是 Prometheus Alertmanager 格式的 JSON（`version` 为 `4`，包含 `status`、`alerts`、`fingerprint`、`labels`、`annotations`、`startsAt`、`endsAt`，另有一个 `notifier` 字段）。Flashduty 的 [Prometheus 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 Chronosphere 集成：在 Flashduty 创建 Prometheus 集成，把它的推送地址填进 Chronosphere 即可。 +Chronosphere 的 Webhook 通知器（Notifier）向您填写的 URL 发送 HTTP POST 请求，请求体是 Prometheus Alertmanager 格式的 JSON（`version` 为 `4`，包含 `status`、`alerts`、`fingerprint`、`labels`、`annotations`、`startsAt`、`endsAt`，另有一个 `notifier` 字段）。Flashduty 的 [Prometheus Alertmanager 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 Chronosphere 集成：在 Flashduty 创建 Prometheus Alertmanager 集成，把它的推送地址填进 Chronosphere 即可。
## 在 Flashduty On-call -您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus**，不是 Chronosphere。 +您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus Alertmanager**，不是 Chronosphere。 ### 使用专属集成 1. 进入 Flashduty 控制台，选择 **协作空间**，打开一个协作空间 2. 选择 **配置** → **集成数据** → **专属集成**，点击 **新增一个集成** -3. 选择 **Prometheus**，点击 **保存** +3. 选择 **Prometheus Alertmanager**，点击 **保存** 4. 打开生成的集成卡片，复制 **推送地址**，形如 `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=<集成密钥>` ### 使用共享集成 1. 进入 Flashduty 控制台，选择 **集成中心 → 告警事件** -2. 选择 **Prometheus**，填写集成名称 +2. 选择 **Prometheus Alertmanager**，填写集成名称 3. 配置默认路由并选择协作空间；创建后可在 **路由** 中增加更多规则 4. 点击 **保存**，复制生成的 **推送地址** @@ -81,6 +81,6 @@ Chronosphere 的 Webhook 通知器（Notifier）向您填写的 URL 发送 HTTP ## 排查问题 -- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus +- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus Alertmanager - **告警没有恢复**：确认通知器已选择 **Notify when resolved**（Terraform 的 `send_resolved` 为 `true`、Chronoctl 的 `skip_resolved` 为 `false`），并且恢复通知的 `fingerprint` 与触发时一致 - **收不到任何告警**：确认通知策略把该通知器加入了对应严重程度的路由，并检查 Chronosphere 能否访问 `api.flashcat.cloud` diff --git a/zh/on-call/integration/alert-integration/alert-sources/cubeapm.mdx b/zh/on-call/integration/alert-integration/alert-sources/cubeapm.mdx index 80020ac5d..96ee22d9b 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/cubeapm.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/cubeapm.mdx @@ -1,29 +1,29 @@ --- title: "CubeAPM 告警集成" sidebarTitle: "CubeAPM" -description: "通过 CubeAPM 的 Webhook 接收器，使用 Flashduty 的 Prometheus 集成接收 CubeAPM 告警，恢复时自动关闭告警。" +description: "通过 CubeAPM 的 Webhook 接收器，使用 Flashduty 的 Prometheus Alertmanager 集成接收 CubeAPM 告警，恢复时自动关闭告警。" keywords: ["告警集成", "CubeAPM", "Webhook", "Prometheus", "Alertmanager", "可观测性"] --- -CubeAPM 支持把告警通知以 HTTP POST 的方式发送到任意 Webhook URL，默认的 JSON 请求体与 Prometheus Alertmanager 的 Webhook 格式兼容（包含 `receiver`、`status`、`alerts`、`groupLabels`、`commonLabels`、`commonAnnotations`、`externalURL` 等；每条告警带 `status`、`labels`、`annotations`、`startsAt`、`endsAt`、`generatorURL`、`fingerprint`，另有 CubeAPM 自己的 `cubeImageURL`、`cubeSampleLog`）。Flashduty 的 [Prometheus 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 CubeAPM 集成：在 Flashduty 创建 Prometheus 集成，把它的推送地址填进 CubeAPM 即可。 +CubeAPM 支持把告警通知以 HTTP POST 的方式发送到任意 Webhook URL，默认的 JSON 请求体与 Prometheus Alertmanager 的 Webhook 格式兼容（包含 `receiver`、`status`、`alerts`、`groupLabels`、`commonLabels`、`commonAnnotations`、`externalURL` 等；每条告警带 `status`、`labels`、`annotations`、`startsAt`、`endsAt`、`generatorURL`、`fingerprint`，另有 CubeAPM 自己的 `cubeImageURL`、`cubeSampleLog`）。Flashduty 的 [Prometheus Alertmanager 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 CubeAPM 集成：在 Flashduty 创建 Prometheus Alertmanager 集成，把它的推送地址填进 CubeAPM 即可。
## 在 Flashduty On-call -您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus**，不是 CubeAPM。 +您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus Alertmanager**，不是 CubeAPM。 ### 使用专属集成 1. 进入 Flashduty 控制台，选择 **协作空间**，打开一个协作空间 2. 选择 **配置** → **集成数据** → **专属集成**，点击 **新增一个集成** -3. 选择 **Prometheus**，点击 **保存** +3. 选择 **Prometheus Alertmanager**，点击 **保存** 4. 打开生成的集成卡片，复制 **推送地址**，形如 `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=<集成密钥>` ### 使用共享集成 1. 进入 Flashduty 控制台，选择 **集成中心 → 告警事件** -2. 选择 **Prometheus**，填写集成名称 +2. 选择 **Prometheus Alertmanager**，填写集成名称 3. 配置默认路由并选择协作空间；创建后可在 **路由** 中增加更多规则 4. 点击 **保存**，复制生成的 **推送地址** @@ -69,6 +69,6 @@ CubeAPM 文档说明，Webhook 的 JSON 请求体默认与 Alertmanager 格式 ## 排查问题 -- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus +- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus Alertmanager - **告警没有恢复**：确认自定义 Payload 中每条告警的 `status` 和 `fingerprint` 都存在，且恢复通知的 `fingerprint` 与触发时一致 - **收不到任何告警**：确认 CubeAPM 能访问 `api.flashcat.cloud`，并且告警规则选择了该 Webhook 接收器 diff --git a/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx b/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx index eca1ba4a8..3f4bbfedd 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx @@ -35,7 +35,7 @@ keywords: ["告警集成", "Prometheus", "监控告警", "数据接入"] 1. 进入 Flashduty 控制台，选择 **协作空间**，打开一个协作空间 2. 选择 **配置** → **集成数据** → **专属集成**，点击 **新增一个集成** - 3. 选择 **Prometheus** 集成，点击 **保存**，生成卡片。 + 3. 选择 **Prometheus Alertmanager** 集成，点击 **保存**，生成卡片。 4. 打开生成的集成卡片，复制 **推送地址** @@ -49,7 +49,7 @@ keywords: ["告警集成", "Prometheus", "监控告警", "数据接入"] 1. 进入 Flashduty 控制台，选择 **集成中心 → 告警事件** - 2. 选择 **Prometheus** 集成： + 2. 选择 **Prometheus Alertmanager** 集成： - **集成名称**：为当前集成定义一个名称。 3. 配置默认路由并选择协作空间；创建后可在 **路由** 中增加更多规则 4. 点击 **保存**，复制生成的 **推送地址** diff --git a/zh/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx b/zh/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx index af5c6b2ad..7eb8a8910 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/red-hat-openshift.mdx @@ -1,29 +1,29 @@ --- title: "Red Hat OpenShift 告警集成" sidebarTitle: "Red Hat OpenShift" -description: "通过 OpenShift 监控内置 Alertmanager 的 Webhook 接收器，使用 Flashduty 的 Prometheus 集成接收 OpenShift 集群告警，恢复时自动关闭告警。" +description: "通过 OpenShift 监控内置 Alertmanager 的 Webhook 接收器，使用 Flashduty 的 Prometheus Alertmanager 集成接收 OpenShift 集群告警，恢复时自动关闭告警。" keywords: ["告警集成", "Red Hat OpenShift", "OpenShift", "Alertmanager", "Webhook", "Prometheus", "Kubernetes"] --- -OpenShift Container Platform 的监控栈自带 Alertmanager（`openshift-monitoring` 项目中的 `alertmanager-main`）。官方文档列出的接收器类型包括 PagerDuty、Webhook、Email、Slack 和 Microsoft Teams，并说明上游 Alertmanager 支持的配置项在 OpenShift 中同样支持。Webhook 接收器向您填写的地址发送 Alertmanager 格式的 JSON（`version` 为 `4`，每条告警带 `status`、`labels`、`annotations`、`startsAt`、`endsAt`、`generatorURL`、`fingerprint`）。Flashduty 的 [Prometheus 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 OpenShift 集成：在 Flashduty 创建 Prometheus 集成，把它的推送地址配置为 OpenShift Alertmanager 的 Webhook 接收器。 +OpenShift Container Platform 的监控栈自带 Alertmanager（`openshift-monitoring` 项目中的 `alertmanager-main`）。官方文档列出的接收器类型包括 PagerDuty、Webhook、Email、Slack 和 Microsoft Teams，并说明上游 Alertmanager 支持的配置项在 OpenShift 中同样支持。Webhook 接收器向您填写的地址发送 Alertmanager 格式的 JSON（`version` 为 `4`，每条告警带 `status`、`labels`、`annotations`、`startsAt`、`endsAt`、`generatorURL`、`fingerprint`）。Flashduty 的 [Prometheus Alertmanager 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 OpenShift 集成：在 Flashduty 创建 Prometheus Alertmanager 集成，把它的推送地址配置为 OpenShift Alertmanager 的 Webhook 接收器。
## 在 Flashduty On-call -您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus**，不是 Red Hat OpenShift。 +您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus Alertmanager**，不是 Red Hat OpenShift。 ### 使用专属集成 1. 进入 Flashduty 控制台，选择 **协作空间**，打开一个协作空间 2. 选择 **配置** → **集成数据** → **专属集成**，点击 **新增一个集成** -3. 选择 **Prometheus**，点击 **保存** +3. 选择 **Prometheus Alertmanager**，点击 **保存** 4. 打开生成的集成卡片，复制 **推送地址**，形如 `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=<集成密钥>` ### 使用共享集成 1. 进入 Flashduty 控制台，选择 **集成中心 → 告警事件** -2. 选择 **Prometheus**，填写集成名称 +2. 选择 **Prometheus Alertmanager**，填写集成名称 3. 配置默认路由并选择协作空间；创建后可在 **路由** 中增加更多规则 4. 点击 **保存**，复制生成的 **推送地址** @@ -114,6 +114,6 @@ OpenShift 官方文档提供两种方式配置接收器，任选其一。操作 ## 排查问题 -- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus +- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus Alertmanager - **告警没有恢复**：确认接收器没有关闭 `send_resolved` - **收不到任何告警**：确认路由的 `matchers` 或 **Routing labels** 与告警标签匹配，集群能访问 `api.flashcat.cloud`（集群使用 HTTP 代理时，参考 OpenShift 文档中 `proxy_from_environment` 的说明），可用 `oc exec alertmanager-main-0 -n openshift-monitoring -- amtool config routes show --alertmanager.url http://localhost:9093` 查看生效的路由 diff --git a/zh/on-call/integration/alert-integration/alert-sources/robusta.mdx b/zh/on-call/integration/alert-integration/alert-sources/robusta.mdx index c30d58cdf..34224a55c 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/robusta.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/robusta.mdx @@ -69,7 +69,7 @@ Robusta 自己检测到的问题（`source` 为 `KUBERNETES_API_SERVER` 等） -如果您的 Prometheus 告警不经过 Robusta，也可以让 Alertmanager 直接推送到 Flashduty 的 [Prometheus 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus)。 +如果您的 Prometheus 告警不经过 Robusta，也可以让 Alertmanager 直接推送到 Flashduty 的 [Prometheus Alertmanager 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus)。 ## Alert Key diff --git a/zh/on-call/integration/alert-integration/alert-sources/signoz.mdx b/zh/on-call/integration/alert-integration/alert-sources/signoz.mdx index 805205bc9..9ae57eee8 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/signoz.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/signoz.mdx @@ -1,29 +1,29 @@ --- title: "SigNoz 告警集成" sidebarTitle: "SigNoz" -description: "通过 SigNoz 的 Webhook 通知渠道，使用 Flashduty 的 Prometheus 集成接收 SigNoz 告警，恢复通知自动关闭告警。" +description: "通过 SigNoz 的 Webhook 通知渠道，使用 Flashduty 的 Prometheus Alertmanager 集成接收 SigNoz 告警，恢复通知自动关闭告警。" keywords: ["告警集成", "SigNoz", "Webhook", "Prometheus", "Alertmanager", "可观测性"] --- -SigNoz 的 Webhook 通知渠道向您填写的 URL 发送 Prometheus Alertmanager 格式的 JSON（`status`、`alerts`、`fingerprint`、`labels`、`annotations`、`startsAt`、`endsAt`）。Flashduty 的 [Prometheus 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 SigNoz 集成：在 Flashduty 创建 Prometheus 集成，把它的推送地址填进 SigNoz 即可。 +SigNoz 的 Webhook 通知渠道向您填写的 URL 发送 Prometheus Alertmanager 格式的 JSON（`status`、`alerts`、`fingerprint`、`labels`、`annotations`、`startsAt`、`endsAt`）。Flashduty 的 [Prometheus Alertmanager 集成](/zh/on-call/integration/alert-integration/alert-sources/prometheus) 与该格式兼容，因此不需要单独的 SigNoz 集成：在 Flashduty 创建 Prometheus Alertmanager 集成，把它的推送地址填进 SigNoz 即可。
## 在 Flashduty On-call -您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus**，不是 SigNoz。 +您可通过以下两种方式获取集成推送地址，任选其一即可。**集成类型都选择 Prometheus Alertmanager**，不是 SigNoz。 ### 使用专属集成 1. 进入 Flashduty 控制台，选择 **协作空间**，打开一个协作空间 2. 选择 **配置** → **集成数据** → **专属集成**，点击 **新增一个集成** -3. 选择 **Prometheus**，点击 **保存** +3. 选择 **Prometheus Alertmanager**，点击 **保存** 4. 打开生成的集成卡片，复制 **推送地址**，形如 `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=<集成密钥>` ### 使用共享集成 1. 进入 Flashduty 控制台，选择 **集成中心 → 告警事件** -2. 选择 **Prometheus**，填写集成名称 +2. 选择 **Prometheus Alertmanager**，填写集成名称 3. 配置默认路由并选择协作空间；创建后可在 **路由** 中增加更多规则 4. 点击 **保存**，复制生成的 **推送地址** @@ -53,12 +53,12 @@ SigNoz 按规则（`ruleId`）分组发送通知，一次通知可包含多条 ## 恢复与去重 - SigNoz 发送 `status` 为 `resolved` 的通知时，Flashduty 按相同的 `fingerprint` 关闭对应告警。 -- 新版 SigNoz 规则的 `severity` 标签取自阈值行的名称（例如阈值名 `critical`、`warning`），同时写入 `threshold.name` 标签。如果使用了 `error` 等未内置的取值，请在 Prometheus 集成中配置自定义严重程度映射，否则按 Warning 处理。 +- 新版 SigNoz 规则的 `severity` 标签取自阈值行的名称（例如阈值名 `critical`、`warning`），同时写入 `threshold.name` 标签。如果使用了 `error` 等未内置的取值，请在 Prometheus Alertmanager 集成中配置自定义严重程度映射，否则按 Warning 处理。 - 恢复通知在规则回到正常后延迟数分钟到达（实测触发后约 30 秒、恢复约 6 至 10 分钟），属正常现象。 - 渠道的 **Test** 按钮会发送一条 `status` 为 `firing` 的测试告警，标题为 `Test Alert (<渠道名称>)`，`severity` 为 `critical`。它会在 Flashduty 产生一条 Critical 告警，且不会有对应的恢复通知，请手动关闭该告警。 ## 排查问题 -- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus +- **Flashduty 返回 `Invalid parameters`**：推送地址不完整，缺少 `integration_key`，或集成类型不是 Prometheus Alertmanager - **告警没有恢复**：确认 SigNoz 渠道的 **Send resolved alerts** 已开启，且恢复通知的 `fingerprint` 与触发时一致 - **恢复通知延迟**：SigNoz 在规则回到正常后延迟数分钟才发送恢复通知，这是 SigNoz 的默认行为 diff --git a/zh/rum/error-tracking/source-mapping.mdx b/zh/rum/error-tracking/source-mapping.mdx index 413977090..29c42a916 100644 --- a/zh/rum/error-tracking/source-mapping.mdx +++ b/zh/rum/error-tracking/source-mapping.mdx @@ -524,6 +524,7 @@ FLASHCAT_API_KEY=your-api-key npx @flashcatcloud/flashcat-cli sourcemaps upload- | 功能 | 说明 | |------|------| | 查看已上传的符号文件 | 列出所有已上传的文件（SourceMap、小程序 SourceMap、ProGuard mapping 文件、dSYM、NDK 原生符号文件、Flutter 符号文件、Electron Breakpad 符号文件、React Native bundle sourcemap），包括路径、服务名、版本号、大小和上传时间。Android 标签页同时展示 ProGuard mapping 文件和 NDK 原生符号文件，NDK 行会显示 build_id、arch 和 lib_name 列；Electron 标签页每个原生模块一行，展示模块（lib_name）、Debug ID（build_id）、架构（arch）、服务、版本和大小列，并支持按 Debug ID 搜索 | +| 按上传时间筛选 | 列表支持按上传时间筛选符号文件。单次筛选的时间跨度最多 30 天，最早只能回溯到 365 天前；更早上传的符号文件无法筛出 | | 按平台筛选 | 在 Web、iOS、Android、微信小程序、HarmonyOS、Flutter、Electron 和 React Native 标签页之间切换，查看不同平台的符号文件 | | 版本管理 | 通过 `service` 和 `release-version` 参数为不同版本的应用分别管理 | | 小程序维度 | 微信小程序列表展示 AppID 和分包两列；主包显示「主包」，未上传 AppID 时显示 `-` | From 9701b656ac78446cf5aaea3ee9e124460b3efe8c Mon Sep 17 00:00:00 2001 From: Flashduty AI-SRE Date: Thu, 22 Oct 2026 08:25:54 +0000 Subject: [PATCH 2/2] =?UTF-8?q?docs(doc-review):=20follow-up=20=E2=80=94?= =?UTF-8?q?=20SLS=20per-series=20no-data=20restored,=20event=20block=20res?= =?UTF-8?q?tructure,=20editable=20group,=20investigation=20min=20step?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - monitors/alert-rules/sls.mdx: SLS now supports per-series no-data detection (only tencent_cls is excluded); drop the stale 'existing rules' section - monitors/quickstart: event block is flat and reordered (channel, notes, repeat, custom fields, related queries) and custom fields are tag+dialog - monitors/quickstart + folders: the group row is an editable dropdown when editing a rule - monitors/alert-rules/investigation-entries: 最小步长 is now a first-class query-entry field (Prometheus/Loki range queries) --- .../alert-rules/investigation-entries.mdx | 5 +++-- en/monitors/alert-rules/sls.mdx | 20 +++++++++---------- en/monitors/folders/folders.mdx | 1 + en/monitors/quickstart/quickstart.mdx | 10 +++++----- .../alert-rules/investigation-entries.mdx | 7 ++++--- zh/monitors/alert-rules/sls.mdx | 20 +++++++++---------- zh/monitors/folders/folders.mdx | 1 + zh/monitors/quickstart/quickstart.mdx | 10 +++++----- 8 files changed, 37 insertions(+), 37 deletions(-) diff --git a/en/monitors/alert-rules/investigation-entries.mdx b/en/monitors/alert-rules/investigation-entries.mdx index 0a69d1b30..47499c95d 100644 --- a/en/monitors/alert-rules/investigation-entries.mdx +++ b/en/monitors/alert-rules/investigation-entries.mdx @@ -27,7 +27,7 @@ A rule can hold many investigation entries. Each entry has three parts: the entr | Entry type | Button | Jumps to | Notes | |---------|------|--------|------| | **Dashboard entry** | Add dashboard entry | The dashboard viewer | Can target the whole dashboard, a tab, a section or a panel, and sets the values of that dashboard's template variables | -| **Query entry** | Add query entry | The Query Workbench | Stores one editable initial query (query type + query + query parameters) and optionally the data source it runs on | +| **Query entry** | Add query entry | The Query Workbench | Stores one editable initial query (query type + query + minimum step + query parameters) and optionally the data source it runs on | Neither type supports runbooks, tickets or arbitrary URLs. @@ -83,7 +83,8 @@ Time range semantics: | **Data source** | Defaults to `Alert event datasource` (the query is written against the rule's data source type); you can also pick a specific data source. When the rule's data source type is not queryable in the workbench, the `Alert event datasource` option is disabled and labelled `Alert event datasource (not supported for this rule type)`, so the entry must name a data source explicitly. **Changing the data source resets the query**, because the query language changed | | **Query type** | Only shown for data sources with more than one query type (Prometheus: Graph only / Raw only; Loki: Range / Instant; VictoriaLogs: Raw logs / Instant stats / Range stats). Prometheus "Graph + Raw" is not offered here because it is two executions and cannot be stored as one query. SQL-type data sources, SLS and Tencent CLS each have a single query mode and therefore no such row | | **Initial query** | The query editor, with the same syntax and completion as the Query Workbench. The whole expression is rendered as a Go template and inserted **verbatim — no automatic quoting or escaping** | -| **Query parameters** | The data source's named parameters, per data source type (Limit, Direction, Min step (s), the SLS project / logstore, the Tencent CLS region / topic / syntax). Parameter values are **not templated**; a `{{` is rejected (`query args do not support templates`) | +| **Minimum step** | Only for Prometheus / Loki when **Query type** is a range query; in seconds, minimum 1. It is the lower bound on the query step: the backend still derives the step from `max_data_points` but never goes below this value. Leave it empty for no lower bound | +| **Query parameters** | The data source's named parameters, per data source type (Limit, Direction, the SLS project / logstore, the Tencent CLS region / topic / syntax). Parameter values are **not templated**; a `{{` is rejected (`query args do not support templates`) | With the event data source selected, a rule type that the workbench does not support shows `Choose a datasource type under "Datasource and query" first, or pick a datasource for this entry`; an explicitly selected data source that was deleted or that you cannot use shows `The selected datasource is unavailable`. The data source's real type, permissions and provider-specific restrictions are re-checked by the workbench as the current user when the entry is opened or run. diff --git a/en/monitors/alert-rules/sls.mdx b/en/monitors/alert-rules/sls.mdx index 9e4305612..ac44eb91a 100644 --- a/en/monitors/alert-rules/sls.mdx +++ b/en/monitors/alert-rules/sls.mdx @@ -70,7 +70,14 @@ See [Alert recovery](/en/monitors/quickstart/quickstart#alert-recovery) for the This mode is used to monitor scenarios where "data is expected but actually missing". -SLS does not support per-series no-data detection. Only "**Alert when all queries return no data**" is available; "Alert if previously found data is now missing" is not supported. +SLS offers two no-data conditions; enable either one, or both as you need: + +| Condition | Fires when | Recovery | +|------|----------|----------| +| **Alert if previously found data is now missing** | Evaluated per series: that series returned data before and is missing now | Choose **Close automatically when data reappears**, **Close automatically after data recovers or the timeout elapses** (fill in **Auto-close time**, in seconds, minimum 1), or **Manual close only** | +| **Alert when all queries return no data** | All queries return empty results for N consecutive checks, where N comes from the **Trigger condition** shared by the tab | Fixed to **recover automatically once any query returns data again**; not configurable | + +Among log-service data sources only Tencent Cloud CLS lacks the per-series condition; see [Tencent Cloud CLS](/en/monitors/alert-rules/tencent-cls). ### Configuration @@ -79,16 +86,7 @@ SLS does not support per-series no-data detection. Only "**Alert when all querie ```sql * | SELECT host, max(__time__) as last_seen GROUP BY host ``` -2. **Evaluation Rules**: The alert fires when all queries return empty results for N consecutive checks. N comes from the **Trigger condition** shared by the tab. - -### Existing rules with per-series detection enabled - -If an existing SLS rule has per-series no-data detection enabled, opening its edit page turns that condition off automatically; the change takes effect when you save. The rule does not change unless you open the edit page. - -- If the rule has other enabled conditions (threshold evaluation, data exists), you can save directly. -- If this was its only condition, enable at least one condition before saving. - -Switch to "Alert when all queries return no data" and make sure at least one condition is enabled before saving. +2. **Evaluation Rules**: Enable a condition from the table above. With "Alert when all queries return no data", N comes from the **Trigger condition** shared by the tab; with "Alert if previously found data is now missing", each series is evaluated on its own and you can also set the recovery mode from the table. ### Recovery logic diff --git a/en/monitors/folders/folders.mdx b/en/monitors/folders/folders.mdx index 260c4a211..e007504ad 100644 --- a/en/monitors/folders/folders.mdx +++ b/en/monitors/folders/folders.mdx @@ -35,6 +35,7 @@ You can move alert rules to a different folder. The rules themselves do not chan - **One rule**: choose **Move** in the `⋮` menu at the end of its row. - **Several rules**: select them, then click **Move** above the list. +- **On the rule's edit page**: **Group** in block 1 is a dropdown; pick the target group and save to move the rule there. Both open the **Move to another folder** dialog: diff --git a/en/monitors/quickstart/quickstart.mdx b/en/monitors/quickstart/quickstart.mdx index f5e84488e..e67b7e55a 100644 --- a/en/monitors/quickstart/quickstart.mdx +++ b/en/monitors/quickstart/quickstart.mdx @@ -70,7 +70,7 @@ The create / edit alert rule page is one form with six sections, from top to bot | Config Item | Description | |--------|------| -| **Group** | The group path of the rule (for example, "Default / Database Alerts"). If the group has been deleted or you cannot access it, go back to the rule list and pick a group again | +| **Group** | The group path of the rule (for example, "Default / Database Alerts"). When you edit an existing rule this row is a dropdown listing, by full path, the groups you can write to: pick one and save to move the rule there. If the group has been deleted or you cannot access it, the row is not editable — go back to the rule list and pick a group again | | **Rule Name** | Name of the alert rule; does not support variable references (fixed names facilitate filtering and grouping operations). It must be unique within its group; imports, edits, and moves fail if the target group already contains that name | | **Additional Labels** | Similar to `labels` in Prometheus; attached to all alert events for filtering, routing, and inhibition. See below for value syntax | @@ -214,15 +214,15 @@ The repeat notification maximum count and interval, and the match and recovery c ### Event configuration -Event Configuration covers **Custom Fields & Related Queries** (collapsed by default), the notes description, and repeat notification settings. +Event configuration runs from the channel through the notes description and repeat notification settings to two flat subsections, custom fields and related queries. | Config Item | Description | |--------|------| -| **Custom Fields** | Similar to `annotations` in Prometheus; can attach dashboard URLs, SOP URLs, and so on | -| **Related Query** | Not used for threshold evaluation, but can be included in notes as variable references (for example, attach log samples) | -| **Notes Description** | Unstructured text field; supports variable references to help responders quickly locate issues | | **Channel** | Specify a channel in Flashduty On-call; if not specified, delivery follows integration routing rules | +| **Notes Description** | Unstructured text field; supports variable references to help responders quickly locate issues | | **Repeat Notification** | Continues notifying when alert is not recovered; configurable interval and maximum count (default 10000) | +| **Custom Fields** | Similar to `annotations` in Prometheus; can attach dashboard URLs, SOP URLs, and so on. Click `+` next to the heading and fill in **Field name** and **Field value** in the dialog; the fields you add are listed as `key=value` tags — click a tag to edit it, click the × on it to delete it, and a field name cannot be empty or repeated | +| **Related Query** | A separate subsection with its own add button; the result is not used for threshold evaluation, but can be referenced as a variable in the notes (for example, attach log samples) | The maximum notification count does not represent the number of message reminders end users receive. Because alert events generated by Monitors are delivered to On-call, they may be grouped and noise-reduced; the final send count depends on On-call configuration. diff --git a/zh/monitors/alert-rules/investigation-entries.mdx b/zh/monitors/alert-rules/investigation-entries.mdx index d957b542c..7424c80fa 100644 --- a/zh/monitors/alert-rules/investigation-entries.mdx +++ b/zh/monitors/alert-rules/investigation-entries.mdx @@ -27,7 +27,7 @@ keywords: ["调查入口", "排查入口", "告警规则", "仪表盘入口", " | 入口类型 | 按钮 | 跳转到 | 说明 | |---------|------|--------|------| | **仪表盘入口** | 添加仪表盘入口 | 仪表盘查看器 | 可定位到整个仪表盘、某个标签页、某个分组或某个图表，并为该仪表盘的模板变量指定取值 | -| **查询入口** | 添加查询入口 | 查询工作台 | 保存一份可编辑的初始查询（查询类型 + 查询语句 + 查询参数），并可指定在哪个数据源上执行 | +| **查询入口** | 添加查询入口 | 查询工作台 | 保存一份可编辑的初始查询（查询类型 + 查询语句 + 最小步长 + 查询参数），并可指定在哪个数据源上执行 | 两类入口都不支持 Runbook、工单或任意 URL。 @@ -83,7 +83,8 @@ keywords: ["调查入口", "排查入口", "告警规则", "仪表盘入口", " | **数据源** | 默认是 `告警事件的数据源`（查询按规则的数据源类型书写），也可以选择一个具体数据源。当前规则的数据源类型不支持查询工作台时，`告警事件的数据源` 一项被禁用并显示 `当前规则类型不支持`，此时入口必须显式指定数据源。**更换数据源会重置查询**（查询语言变了，旧语句没有意义） | | **查询类型** | 只有多查询类型的数据源才出现这一行（Prometheus：仅图表 / 仅原始；Loki：Range / Instant；VictoriaLogs：原始日志 / 即时统计 / 趋势统计）。Prometheus 的「图表 + 原始」不会出现在这里，因为它对应两次执行，一份查询存不下。SQL 类数据源与 SLS、腾讯云 CLS 都只有一种查询方式，因此没有这一行 | | **初始查询** | 查询语句编辑器，写法与查询工作台一致，可按数据源类型使用补全。整个表达式按 Go template 渲染，**原样输出，不自动加引号或转义** | -| **查询参数** | 数据源的命名参数，按数据源类型给出（如返回条数、检索方向、最小 step（秒）、SLS 的项目 / 日志库、腾讯云 CLS 的地域 / 日志主题 / 语法）。参数值**不做模板渲染**，出现 `{{` 会被拒绝（`query args do not support templates`） | +| **最小步长** | 仅 Prometheus / Loki 且 **查询类型** 为范围查询时出现，单位秒、最小 1。它是查询步长的下限：后端仍按 `max_data_points` 计算步长，但不会低于这里填的值。留空表示不设下限 | +| **查询参数** | 数据源的命名参数，按数据源类型给出（如返回条数、检索方向、SLS 的项目 / 日志库、腾讯云 CLS 的地域 / 日志主题 / 语法）。参数值**不做模板渲染**，出现 `{{` 会被拒绝（`query args do not support templates`） | 选择了事件数据源时，规则类型不是工作台支持的类型会显示 `请先在「数据源与查询」中选择数据源类型，或为该入口指定数据源`；指定的数据源已被删除或您无权使用时会显示 `所选数据源不可用`。数据源的真实类型、权限与专属限制由工作台在打开或执行时按当前用户重新校验。 @@ -150,7 +151,7 @@ outcome:="failure" 去重的身份判定： - **仪表盘入口**：同一仪表盘 + 同一定位对象即为重复，**与变量取值、时间范围无关**。重复项不能用来表达变量 fallback 或多实例。 -- **查询入口**：按标准化后的数据源、查询（模式、表达式、参数、最小 step）与时间范围判重；未指定数据源（使用事件数据源）作为独立取值参与比较。同一数据源上可以配置多份**不同**的查询。 +- **查询入口**：按标准化后的数据源、查询（模式、表达式、参数、最小步长）与时间范围判重；未指定数据源（使用事件数据源）作为独立取值参与比较。同一数据源上可以配置多份**不同**的查询。 这些校验同时在两个地方执行：入口弹窗里（只校验当前这一项，方便逐项修复），以及保存规则时（整组校验，错误文案显示在区块下方）。 diff --git a/zh/monitors/alert-rules/sls.mdx b/zh/monitors/alert-rules/sls.mdx index ab450d7ad..c6397f794 100644 --- a/zh/monitors/alert-rules/sls.mdx +++ b/zh/monitors/alert-rules/sls.mdx @@ -71,7 +71,14 @@ Monitors 按配置的时间范围执行 SLS 查询，按标签字段区分告警 此模式用于监控"预期应该有数据，但实际没有数据"的场景。 -SLS 不支持按曲线（per-series）的无数据检测，只能使用“**所有查询均无返回数据时告警**”判定，不支持“之前查到过数据，现在查不到了，就告警”。 +SLS 提供两种无数据判定，二选一或按需分别启用： + +| 判定 | 触发条件 | 恢复方式 | +|------|----------|----------| +| **之前查到过数据，现在查不到了，就告警** | 按曲线判定，每条曲线各自计算：这条曲线之前查到过数据、现在查不到即告警 | 可选 **数据重新出现后自动结束**、**数据恢复或超时后自动结束**（需填 **自动关闭时间**，单位秒、最小 1）或 **仅允许手工关闭** | +| **所有查询均无返回数据时告警** | 所有查询在连续 N 次检测中都返回空结果时告警，N 由该页签共享的 **触发条件** 决定 | 固定为 **任一查询重新查到数据后自动恢复**，不可配置 | + +云日志类数据源里只有腾讯云 CLS 不支持按曲线判定，见[腾讯云 CLS](/zh/monitors/alert-rules/tencent-cls)。 ### 配置方式 @@ -80,16 +87,7 @@ SLS 不支持按曲线（per-series）的无数据检测，只能使用“**所 ```sql * | SELECT host, max(__time__) as last_seen GROUP BY host ``` -2. **判定规则**：所有查询在连续 N 次检测中都返回空结果时，触发"数据缺失"告警。N 由该页签共享的“触发条件”决定。 - -### 存量已启用按曲线检测的规则 - -如果已有的 SLS 规则开启了按曲线的无数据检测，打开编辑页时该判定会被自动关闭，保存后生效；不打开编辑页，规则不会变化。 - -- 规则还有其他已启用的判定（阈值判定、数据存在）时，可以直接保存。 -- 这是规则唯一的判定时，需要先启用至少一项判定才能保存。 - -建议改用“所有查询均无返回数据时告警”，确认至少启用了一项判定后再保存。 +2. **判定规则**：选择上表中的判定方式并启用。选「所有查询均无返回数据时告警」时，N 由该页签共享的 **触发条件** 决定；选「之前查到过数据，现在查不到了，就告警」时，按曲线分别判定，可另外配置上表中的恢复方式。 ### 恢复逻辑 diff --git a/zh/monitors/folders/folders.mdx b/zh/monitors/folders/folders.mdx index 7f06756fd..619cb3f41 100644 --- a/zh/monitors/folders/folders.mdx +++ b/zh/monitors/folders/folders.mdx @@ -35,6 +35,7 @@ Monitors 使用树形文件夹结构来组织和管理告警规则。每条告 - **单条规则**：点击行尾 `⋮` 菜单里的 **移动**。 - **多条规则**：勾选规则后，点击列表上方的 **移动**。 +- **在规则编辑页**：打开规则后，区块 1 的 **所属分组** 是一个下拉框，选中目标分组并保存即完成移动。 两种入口都打开 **移动到其他分组** 对话框： diff --git a/zh/monitors/quickstart/quickstart.mdx b/zh/monitors/quickstart/quickstart.mdx index 34b2b1d82..1a5151d95 100644 --- a/zh/monitors/quickstart/quickstart.mdx +++ b/zh/monitors/quickstart/quickstart.mdx @@ -71,7 +71,7 @@ keywords: ["入门指南", "monitedge", "数据源", "告警规则", "快速开 | 配置项 | 说明 | |--------|------| -| **所属分组** | 规则所在的分组路径（如“默认分组 / 数据库告警”）。如果分组已被删除或您无权访问，需要返回规则列表重新选择分组 | +| **所属分组** | 规则所在的分组路径（如“默认分组 / 数据库告警”）。编辑已有规则时这一行是可编辑的下拉框，按全路径列出您有权限的分组，选中并保存即把规则移到新分组；分组已被删除或您无权访问时不可编辑，需要返回规则列表重新选择分组 | | **规则名称** | 告警规则的名称，不支持引用变量（固定名称便于过滤、聚合操作）。同一分组内必须唯一；导入、编辑或移动规则时如与目标分组中已有规则重名，操作会失败 | | **附加标签** | 类似 Prometheus 中的 `labels`，会附加到所有告警事件上，便于过滤、路由、抑制。值的写法见下文 | @@ -215,15 +215,15 @@ Go 模板可以使用以下变量： ### 事件配置 -事件配置包括自定义字段与关联查询（默认折叠）、备注描述和重复发送配置。 +事件配置依次为协作空间、备注描述、重复发送配置，以及自定义字段与关联查询两个平铺小节。 | 配置项 | 说明 | |--------|------| -| **自定义字段** | 类似 Prometheus 中的 `annotations`，可附加仪表盘 URL、SOP URL 等 | -| **关联查询** | 不作为阈值判定依据，但可放到备注中作为变量引用（如附加日志样例） | -| **备注描述** | 非结构化文本字段，支持引用变量，便于值班人员快速定位问题 | | **协作空间** | 指定 Flashduty On-call 中的协作空间，不指定则根据集成路由规则投递 | +| **备注描述** | 非结构化文本字段，支持引用变量，便于值班人员快速定位问题 | | **重复通知** | 告警未恢复时持续通知，可配置间隔和最大次数（默认 10000 次） | +| **自定义字段** | 类似 Prometheus 中的 `annotations`，可附加仪表盘 URL、SOP URL 等。点标题右侧的 `+` 在弹窗里填 **字段名** 与 **字段值**；已添加的字段以 `键=值` 标签列出，点标签可再次修改、点标签上的 × 删除，字段名不能为空也不能重复 | +| **关联查询** | 独立小节，有自己的新增按钮；查询结果不作为阈值判定依据，但可在备注中作为变量引用（如附加日志样例） | 最大通知次数并不代表终端用户收到的消息提醒次数。因为 Monitors 产生的告警事件会投递到 On-call，可能会被聚合降噪，最终发送次数取决于 On-call 配置。