dt-alerting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

dt-alerting

Configure and understand the full alerting lifecycle in Dynatrace — from anomaly detector setup through Grail event storage, problem grouping, and workflow notification delivery.

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

The Alerting Lifecycle

告警生命周期

┌─────────────────────────────────────────────────────────────────────┐
│  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_EVENT                │
│  ─────────────────────────────────────────────────────────────────  │
│  1. 基于DQL的  · Grail调度的服务器端检测器                          │
│  2. 边缘端     · 受监控主机或进程上的OneAgent                      │
│  3. 流水线     · OpenPipeline摄取流过滤器匹配器                    │
│  4. 合成监控   · 全球分布的合成检查节点                            │
│  5. 外部来源   · Events API、工作流或OneAgent本地摄取              │
└──────────────────────────────┬──────────────────────────────────────┘
                               │ 每个实体每次触发都会创建DAVIS_EVENT
                               ▼
             ┌─────────────────────────────────────┐
             │  事件存储于Grail                    │  可通过DQL持久化和查询。
             └──────────────────┬──────────────────┘  每个实体每次触发对应一条事件。
                                │ 通过根因和影响图关联
                                ▼
             ┌─────────────────────────────────────┐
             │  问题（降噪）                      │  共享相同根因
             └──────────────────┬──────────────────┘  和影响图的事件→合并为一个问题。
                                │ 问题事件触发工作流
                                ▼
             ┌─────────────────────────────────────┐
             │  工作流通知                        │  过滤问题并路由至
             └─────────────────────────────────────┘  邮件、Slack、ServiceNow、Webhook。

When to Use This Skill

何时使用此技能

Detector setup — "How do I create an anomaly detector?", "What kind of detector should I use?", "What is the difference between adaptive and seasonal?"
Alert event history — "Query all alert events for this service", "Show me which metrics triggered alerts last week"
Problem denoising — "Why did these two alerts merge into one problem?", "How does Davis group alerts?"
Notification setup — "How do I send a Slack message when a problem opens?", "Set up a ServiceNow ticket on critical problems"
Best practices — "How do I avoid alert storms?", "Which sensitivity setting should I use?"
Over-alerting analysis — "Why am I getting too many alerts?", "How do I reduce alert fatigue?", "Which detector is firing the most?", "How do I tune sensitivity or thresholds to avoid noise?"
Notification routing — "How do I route alerts to the right team?", "Set up scalable problem filters in workflows", "Send Slack notifications only to the team responsible for the affected service"

检测器设置 — "如何创建异常检测器？"、"我应该使用哪种检测器？"、"自适应基线和季节性基线有什么区别？"
告警事件历史 — "查询此服务的所有告警事件"、"显示上周哪些指标触发了告警"
问题降噪 — "为什么这两个告警合并成了一个问题？"、"Davis如何分组告警？"
通知设置 — "问题出现时如何发送Slack消息？"、"针对严重问题创建ServiceNow工单"
最佳实践 — "如何避免告警风暴？"、"我应该使用哪种敏感度设置？"
过度告警分析 — "为什么我收到太多告警？"、"如何减少告警疲劳？"、"哪个检测器触发最频繁？"、"如何调整敏感度或阈值以避免噪声？"
通知路由 — "如何将告警路由到对应团队？"、"在工作流中设置可扩展的问题过滤器"、"仅向负责受影响服务的团队发送Slack通知"

Agent Instructions

Agent操作说明

First step for any alerting setup request — Before recommending a specific detector or model, load

references/anomaly-detectors.md

and use its category and model decision guide to identify which detector category (DQL-based, Edge, Pipeline, Synthetic, External) and which model (Static, Adaptive, Seasonal) best fits the user's use-case. Only proceed with configuration guidance once the right detector type has been established.

Consolidate, don't multiply — When a user asks to alert on multiple entities of the same kind (e.g. "alert on services A, B, and C"), always recommend a single combined detector rather than one detector per entity. Use

by: { <dimension> }

in the DQL

timeseries

call to split results per entity, and a single

filter:

clause to scope to the relevant entities. Pair the combined detector with a single
dt.alert_group
tag shared across all alert conditions and the corresponding workflow notification filter. This keeps the number of detector configs small, ensures consistent routing, and makes the workflow notification channel reusable for future entities added to the same group.

Example for three services — one detector, one workflow:

dql

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")}) }

Set

dt.alert_group: "checkout-team"

in the detector's event properties, then filter the notification workflow on

matchesPhrase(dt.alert_group, "checkout-team")

. If a new service must be covered, add it to the single

filter:

list — no new detector or workflow rule needed.

告警设置请求的第一步 — 在推荐特定检测器或模型之前，加载

references/anomaly-detectors.md

，并使用其中的类别和模型决策指南，确定最适合用户场景的检测器类别（基于DQL的、边缘端、流水线、合成监控、外部来源）和模型（静态、自适应、季节性）。只有确定了正确的检测器类型后，再提供配置指导。

整合而非分散 — 当用户要求对同类多个实体设置告警时（例如："为服务A、B、C设置告警"），始终建议使用单个组合检测器，而非为每个实体单独创建检测器。在DQL的

timeseries

调用中使用

by: { <dimension> }

按实体拆分结果，并使用单个

filter:

clause限定相关实体。将组合检测器与一个共享的
dt.alert_group
标签配对，该标签需在所有告警条件和对应的工作流通知过滤器中统一设置。这样可以减少检测器配置数量，确保路由一致，并使工作流通知渠道可复用，方便后续添加同组实体。

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

dql

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:

列表中 — 无需创建新的检测器或工作流规则。

Intent Mapping

意图映射

User Request	Action	Reference
"how to alert on ...", "create an alert on ...", "create anomaly detector", "set up alerting", "configure alert rule"	Explain detector categories and variants, guide through model selection	anomaly-detectors.md
"what kinds of anomaly detectors", "edge alert", "pipeline alert", "synthetic alert", "OneAgent alert"	Explain the five alert source categories and their trade-offs	anomaly-detectors.md
"static vs adaptive", "which detector model", "seasonal detector"	Compare models, apply decision guide	anomaly-detectors.md
"query alert history", "which alerts fired", "Davis events in Grail"	Query `dt.davis.events` in Grail via `fetch dt.davis.events`	davis-events.md
"why did alerts merge", "problem grouping", "denoising"	Do NOT explain merging rules here — load `dt-obs-problems` and refer to `problem-merging.md` for the full merge logic	dt-obs-problems/references/problem-merging.md
"send Slack notification", "email on problem", "ServiceNow ticket", "notify on alert"	Explain problem-triggered workflow setup	workflow-notifications.md
"alert storm", "too many notifications", "reduce noise"	Filtering strategy, denoising, sensitivity tuning	workflow-notifications.md + anomaly-detectors.md

Analyzing existing problems — If the user wants to query or investigate active/closed problems (root cause, impact, trending), load
dt-obs-problems
instead. This skill covers configuration and flow, not problem query analytics.

Detector health monitoring — If the user asks whether detectors are running or failing, load
dt-platform
(ANALYZER_EXECUTION_EVENT, ANOMALY_DETECTOR_STATUS_EVENT). This skill covers setup, not operational health.

用户请求	操作	参考文档
"如何对...设置告警"、"为...创建告警"、"创建异常检测器"、"设置告警"、"配置告警规则"	解释检测器类别和变体，指导模型选择	anomaly-detectors.md
"有哪些类型的异常检测器"、"边缘告警"、"流水线告警"、"合成监控告警"、"OneAgent告警"	解释五大告警来源类别及其权衡	anomaly-detectors.md
"静态vs自适应"、"选择哪种检测器模型"、"季节性检测器"	对比模型，应用决策指南	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）。本技能仅覆盖设置，不涉及运行健康状况。

Prerequisites

前置条件

Access to a Dynatrace environment with Settings v2 write permissions for detector configuration
For querying alert history: DQL permissions on
```
dt.davis.events
```
Load
```
dt-dql-essentials
```
before writing DQL queries

拥有带有Settings v2写入权限的Dynatrace环境，用于配置检测器
查询告警历史：需拥有
```
dt.davis.events
```
的DQL权限
编写DQL查询前，请加载
```
dt-dql-essentials
```

Knowledge Base Structure

知识库结构

#	Reference	Content
1	anomaly-detectors.md	Detector types, model selection, configuration, best practices
2	davis-events.md	Davis event storage in Grail, key fields, DQL query patterns
3	workflow-notifications.md	Problem-triggered workflows, filtering, notification channels

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

Key Concepts

核心概念

Alert Source Categories

告警来源类别

Five fundamental categories of anomaly detectors, distinguished by where detection runs and how the alert event reaches Dynatrace:

#	Category	Detection runs on	Latency	Alert logic owner
1	DQL-based	Grail (server-side, scheduled)	Minutes	Dynatrace
2	Edge	OneAgent on the monitored host/process	Seconds	Dynatrace (OneAgent)
3	Pipeline	OpenPipeline ingest path (in-stream)	Near-zero	Dynatrace (pipeline rule)
4	Synthetic	Synthetic checker node (worldwide)	Seconds	Dynatrace (synthetic node)
5	External	Customer / external tool	Caller-defined	Customer

See

references/anomaly-detectors.md

for the full breakdown of each category, including trade-offs and configuration entry points.

异常检测器分为五大基础类别，区分依据是检测运行位置和告警事件到达Dynatrace的方式：

#	类别	检测运行位置	延迟	告警逻辑归属
1	基于DQL的	Grail（服务器端，调度执行）	分钟级	Dynatrace
2	边缘端	受监控主机/进程上的OneAgent	秒级	Dynatrace（OneAgent）
3	流水线	OpenPipeline摄取路径（流内）	近零延迟	Dynatrace（流水线规则）
4	合成监控	全球分布的合成检查节点	秒级	Dynatrace（合成节点）
5	外部来源	客户/外部工具	调用方定义	客户

查看

references/anomaly-detectors.md

获取每个类别的完整说明，包括权衡和配置入口。

Detector Models at a Glance

检测器模型概览

Model	Threshold	Best for
Static	Fixed value you define	Known hard limits (e.g. error rate > 5%)
Adaptive baseline	Learned from recent history	Metrics with no fixed limit but clear normal behavior
Seasonal baseline	Learned with time-of-day / day-of-week awareness	Traffic, request rate, or any metric with recurring patterns

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

Davis Events vs. Problems

Davis事件 vs. 问题

Concept	Table	Scope
Davis event	`fetch dt.davis.events`	One record per detector trigger per entity
Problem	`fetch dt.davis.problems`	One record per correlated group of events sharing root-cause and impact

A single problem typically contains multiple events. Querying problems gives the operational view; querying events gives the raw alert history.

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

单个问题通常包含多个事件。查询问题可获得运维视角；查询事件可获取原始告警历史。

Problem Denoising

问题降噪

For questions about why alerts merged into a problem or how Davis groups events, load

dt-obs-problems

— the merge logic and rules are documented in

dt-obs-problems/references/problem-merging.md

. This skill covers alert configuration and flow only.

关于告警为何合并为问题或Davis如何分组事件的问题，请加载

dt-obs-problems

— 合并逻辑和规则记录在

dt-obs-problems/references/problem-merging.md

中。本技能仅覆盖告警配置与流程。

Quick Start

快速开始

Check What Alerts Fired in the Last 24 Hours

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

dql

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

dql

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

Check Alert Volume by Category

按类别查看告警数量

dql

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

dql

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

See All Active Problems (→ load dt-obs-problems for full query patterns)

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

dql

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

dql

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

Best Practices

最佳实践

Match the model to the metric's behavior — Use static for hard SLO boundaries, adaptive for metrics without a natural fixed limit, seasonal for anything that follows business hours or weekly patterns.
Scope detectors narrowly — An entity selector that covers only relevant entities reduces noise and makes problems more actionable.
Tune sensitivity before going to production — Start with LOW sensitivity and move to MEDIUM or HIGH only after observing false-positive rates.
Let Davis denoise before notifying — Trigger workflow notifications on problems, not individual alert events. A problem groups correlated alerts so you notify once per incident, not once per metric.
Filter notifications by severity level — Route
```
event.severity <= 2
```
problems to on-call channels immediately; route
```
event.severity >= 3
```
problems to lower- urgency channels. Either set severity in the detector config or assign in a pipeline rule or workflow.
Use
dt.alert_group
event property for routing — Assign
```
dt.alert_group
```
to route alerts to the right team. Either set a static value in the detector config, use dynamic assignment through DQL query result mapping or assign in a pipeline rule.
Combine same-condition alerts into one detector and one workflow — When alerting on multiple entities with the same metric and threshold, merge them into a single DQL-based detector using
```
by: { <dimension> }
```
and a combined
```
filter:
```
clause. Assign the same
```
dt.alert_group
```
value to every condition in that detector and point the workflow notification channel at that single group. One detector + one workflow per logical alert group scales better than N detectors + N notification rules, and adding a new entity is a one-line filter change rather than a full detector/workflow addition.

模型匹配指标行为 — 静态模型适用于硬SLO边界，自适应模型适用于无自然固定限制的指标，季节性模型适用于遵循营业时间或每周规律的指标。
缩小检测器范围 — 仅覆盖相关实体的实体选择器可减少噪声，使问题更具可操作性。
投产前调优敏感度 — 从低敏感度开始，仅在观察到误报率后再调整为中或高敏感度。
让Davis先降噪再通知 — 基于问题触发工作流通知，而非单个告警事件。问题会将关联告警分组，因此每次事件只需通知一次，而非每个指标通知一次。
按严重级别过滤通知 — 将
```
event.severity <= 2
```
的问题立即路由至值班渠道；将
```
event.severity >= 3
```
的问题路由至低优先级渠道。可在检测器配置中设置严重级别，或通过流水线规则或工作流分配。
使用
dt.alert_group
事件属性进行路由 — 分配
```
dt.alert_group
```
以将告警路由到对应团队。可在检测器配置中设置静态值，通过DQL查询结果映射动态分配，或在流水线规则中分配。
将相同条件的告警合并为一个检测器和一个工作流 — 当对多个实体的相同指标和阈值设置告警时，使用
```
by: { <dimension> }
```
和组合的
```
filter:
```
clause将其合并为单个基于DQL的检测器。为该检测器中的所有条件分配相同的
```
dt.alert_group
```
值，并将工作流通知渠道指向该分组。每个逻辑告警组对应一个检测器+一个工作流，比N个检测器+N个通知规则更具扩展性，新增实体只需修改一行过滤器，无需创建完整的检测器/工作流。

dt-alerting

Original

Translation

dt-alerting

dt-alerting

The Alerting Lifecycle

告警生命周期

When to Use This Skill

何时使用此技能

Agent Instructions

Agent操作说明

Intent Mapping

意图映射

Prerequisites

前置条件

Knowledge Base Structure

知识库结构

Key Concepts

核心概念

Alert Source Categories

告警来源类别

Detector Models at a Glance

检测器模型概览

Davis Events vs. Problems

Davis事件 vs. 问题

Problem Denoising

问题降噪

Quick Start

快速开始

Check What Alerts Fired in the Last 24 Hours

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

Check Alert Volume by Category

按类别查看告警数量

See All Active Problems (→ load dt-obs-problems for full query patterns)

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

Best Practices

最佳实践

Related Skills

相关技能