dt-alerting

dt-alerting

在 Dynatrace 中配置并了解完整的告警生命周期——从异常检测器设置，到 Grail 事件存储、问题分组和工作流通知发送。

告警生命周期

┌─────────────────────────────────────────────────────────────────────┐
│  Alert Sources — five categories, each fires a DAVIS_EVENT          │
│  ─────────────────────────────────────────────────────────────────  │
│  1. DQL-based  · Grail-scheduled server-side detector               │
│  2. Edge       · OneAgent on monitored host or process              │
│  3. Pipeline   · OpenPipeline ingest-stream filter matcher          │
│  4. Synthetic  · Worldwide synthetic checker node                   │
│  5. External   · Events API, Workflow, or OneAgent local ingest     │
└──────────────────────────────┬──────────────────────────────────────┘
                               │ DAVIS_EVENT created per trigger per entity
                               ▼
             ┌─────────────────────────────────────┐
             │  Event stored in Grail              │  Persisted and queryable via DQL.
             └──────────────────┬──────────────────┘  One event per trigger per entity.
                                │ correlated by root-cause and impact graph
                                ▼
             ┌─────────────────────────────────────┐
             │  Problem (Denoising)                │  Events sharing the same root-cause
             └──────────────────┬──────────────────┘  and impact graph → one Problem.
                                │ problem event triggers workflow
                                ▼
             ┌─────────────────────────────────────┐
             │  Workflow Notification              │  Filters problems and routes to
             └─────────────────────────────────────┘  email, Slack, ServiceNow, webhook.

何时使用此技能

• 检测器设置——“如何创建异常检测器？”、“应该使用哪种检测器？”、“自适应检测器和季节性检测器有什么区别？”
• 告警事件历史记录——“查询此服务的所有告警事件”、“显示上周触发告警的指标”
• 问题降噪——“为什么这两条告警合并成了一个问题？”、“Davis 如何对告警进行分组？”
• 通知设置——“如何在问题开启时发送 Slack 消息？”、“为严重问题创建 ServiceNow 工单”
• 最佳实践——“如何避免告警风暴？”、“应该使用哪种灵敏度设置？”
• 过度告警分析——“为什么我收到这么多告警？”、“如何减轻告警疲劳？”、“哪个检测器触发次数最多？”、“如何调整灵敏度或阈值以避免噪声？”
• 通知路由——“如何将告警路由给正确的团队？”、“在工作流中设置可扩展的问题筛选条件”、“仅向负责受影响服务的团队发送 Slack 通知”

Agent 指令

任何告警设置请求的第一步——在推荐特定检测器或模型之前，先加载 references/anomaly-detectors.md，并使用其中的类别和模型决策指南，确定最适合用户用例的检测器类别（DQL-based、Edge、Pipeline、Synthetic、External）和模型（Static、Adaptive、Seasonal）。只有在确定了合适的检测器类型后，才能继续提供配置指导。

合并配置，而非增加数量——当用户要求针对多个同类实体设置告警时（例如“针对服务 A、B 和 C 设置告警”），始终推荐使用一个组合检测器，而不是为每个实体各设置一个检测器。在 DQL 的 timeseries 调用中使用 by: { <dimension> } 按实体拆分结果，并使用单个 filter: 子句限定相关实体范围。为所有告警条件及对应的工作流通知筛选器设置同一个 dt.alert_group 标签。这样可以减少检测器配置数量、确保路由一致，并使工作流通知渠道可供以后添加到同一组的新实体复用。

针对三个服务的示例——一个检测器，一个工作流：

timeseries avg(dt.service.request.response_time),
  by: { dt.smartscape.service },
  filter: { in(dt.smartscape.service, {toSmartscapeId("SERVICE-0000000000000001"), toSmartscapeId("SERVICE-0000000000000002"), toSmartscapeId("SERVICE-0000000000000003")}) }

在检测器的事件属性中设置 dt.alert_group: "checkout-team"，然后在通知工作流中使用 matchesPhrase(dt.alert_group, "checkout-team") 进行筛选。如果需要覆盖新服务，只需将其添加到单个 filter: 列表中——无需创建新检测器或工作流规则。

意图映射

用户请求	操作	参考
“如何针对……设置警报”、“针对……创建警报”、“创建异常检测器”、“设置警报”、“配置警报规则”	说明检测器类别和变体，并引导选择模型	anomaly-detectors.md
“有哪些类型的异常检测器”、“边缘警报”、“管道警报”、“合成警报”、“OneAgent 警报”	说明五种警报来源类别及其权衡	anomaly-detectors.md
“静态模型与自适应模型”、“选择哪种检测器模型”、“季节性检测器”	比较模型，并应用决策指南	anomaly-detectors.md
“查询警报历史记录”、“哪些警报已触发”、“Grail 中的 Davis 事件”	通过 fetch dt.davis.events 在 Grail 中查询 dt.davis.events	davis-events.md
“为什么警报会合并”、“问题分组”、“降噪”	此处不要解释合并规则——加载 dt-obs-problems，并参阅 problem-merging.md 了解完整的合并逻辑	dt-obs-problems/references/problem-merging.md
“发送 Slack 通知”、“问题发生时发送邮件”、“ServiceNow 工单”、“警报时发送通知”	说明由问题触发的工作流设置	workflow-notifications.md
“警报风暴”、“通知太多”、“减少噪声”	过滤策略、降噪、灵敏度调整	workflow-notifications.md + anomaly-detectors.md

分析现有问题 — 如果用户想要查询或调查 活跃/已关闭的问题（根本原因、影响、趋势），请改为加载 dt-obs-problems。 此技能涵盖配置和流程，不涵盖问题查询分析。

检测器运行状况监控 — 如果用户询问检测器是否正在 运行或出现故障，请加载 dt-platform（ANALYZER_EXECUTION_EVENT、 ANOMALY_DETECTOR_STATUS_EVENT）。此技能涵盖设置，不涵盖运行状况。

前提条件

• 拥有 Dynatrace 环境的访问权限，并具有用于检测器配置的 Settings v2 写入权限
• 如需查询警报历史记录：拥有针对 dt.davis.events 的 DQL 权限
• 编写 DQL 查询前先加载 dt-dql-essentials

知识库结构

#	参考	内容
1	anomaly-detectors.md	检测器类型、模型选择、配置、最佳实践
2	davis-events.md	Grail 中的 Davis 事件存储、关键字段、DQL 查询模式
3	workflow-notifications.md	由问题触发的工作流、过滤、通知渠道

关键概念

警报来源类别

异常检测器有五种基本类别，按检测的运行位置以及警报事件到达 Dynatrace 的方式区分：

#	类别	检测运行位置	延迟	警报逻辑所有者
1	基于 DQL	Grail（服务端，定时运行）	分钟级	Dynatrace
2	边缘	受监控主机/进程上的 OneAgent	秒级	Dynatrace（OneAgent）
3	管道	OpenPipeline 摄取路径（流内）	近乎为零	Dynatrace（管道规则）
4	合成	合成监测节点（全球范围）	秒级	Dynatrace（合成节点）
5	外部	客户 / 外部工具	由调用方定义	客户

每种类别的完整说明（包括权衡和配置入口）请参阅 references/anomaly-detectors.md。

检测器模型一览

模型	阈值	最适用场景
静态	由你定义的固定值	已知的硬性限制（例如，错误率 > 5%）
自适应基线	根据近期历史数据学习得出	没有固定限制但正常行为明确的指标
季节性基线	根据时段 / 星期几的规律学习得出	流量、请求率或任何具有重复模式的指标

Davis 事件与问题

概念	表	范围
Davis 事件	fetch dt.davis.events	每个实体的每次检测器触发对应一条记录
问题	fetch dt.davis.problems	每组根因和影响相同的关联事件对应一条记录

一个问题通常包含多个事件。查询问题可了解运维视图；查询事件则可查看原始告警历史。

问题降噪

如果要了解告警为何合并为一个问题，或 Davis 如何对事件分组，请加载 dt-obs-problems——合并逻辑和规则记录在 dt-obs-problems/references/problem-merging.md 中。本技能仅涵盖告警的配置和流程。

快速入门

查看过去 24 小时触发的告警

fetch dt.davis.events, from: -24h
| filter event.status == "ACTIVE"
| summarize alert_count = count(), by: {event.name, event.category, dt.smartscape_source.id}
| sort alert_count desc
| limit 20

按类别查看告警量

fetch dt.davis.events, from: -24h
| summarize count = count(), by: {event.category, event.status}
| sort count desc

查看所有活跃问题（→ 加载 dt-obs-problems 查看完整查询模式）

fetch dt.davis.problems, from: -24h
| filter not(dt.davis.is_duplicate) and event.status == "ACTIVE"
| fields event.start, display_id, event.name, event.category
| sort event.start desc
| limit 20

最佳实践

1. 根据指标的行为选择模型 — 对严格的 SLO 边界使用静态模型；对没有自然固定阈值的指标使用自适应模型；对遵循营业时间或每周规律的指标使用季节性模型。
2. 将检测器的范围限定得更精准 — 实体选择器只涵盖相关实体，可减少噪声，让问题更便于采取行动。
3. 投入生产前调整灵敏度 — 从 LOW 灵敏度开始，观察误报率后再调整为 MEDIUM 或 HIGH。
4. 先让 Davis 降噪，再发送通知 — 针对问题而非单个告警事件触发工作流通知。问题会将相关告警归为一组，因此每起事故只通知一次，而不是每个指标都通知一次。
5. 按严重级别筛选通知 — 将 event.severity <= 2 的问题立即发送到值班频道；将 event.severity >= 3 的问题发送到紧急程度较低的频道。可在检测器配置中设置严重级别，也可在管道规则或工作流中分配。
6. 使用 dt.alert_group 事件属性进行路由 — 分配 dt.alert_group，将告警路由给合适的团队。可在检测器配置中设置静态值，通过 DQL 查询结果映射动态分配，也可在管道规则中分配。
7. 将条件相同的告警合并到一个检测器和一个工作流中 — 对多个实体使用相同指标和阈值发出告警时，可将它们合并到一个基于 DQL 的检测器中，使用 by: { <dimension> } 和组合的 filter: 子句。为该检测器中的每个条件分配相同的 dt.alert_group 值，并将工作流通知渠道指向该组。每个逻辑告警组使用一个检测器和一个工作流，比使用 N 个检测器和 N 条通知规则更易扩展；添加新实体只需修改一行筛选条件，无需完整新增检测器和工作流。

相关技能

• dt-obs-problems — 查询、分析和跟踪已检测的问题
• dt-obs-predictive-analytics — 使用 MCP 分析器工具进行临时异常和新颖性检测（不涉及持久化告警配置）
• dt-platform — 异常检测器的运行状况（执行事件、故障率）
• dt-platform-costs — 异常检测器 DQL 产生的查询成本
• dt-sdlc-quality-gates — 用于部署门禁告警的 Site Reliability Guardian
• dt-dql-essentials — 编写检测器查询和告警历史查询所需的 DQL 语法