signoz-creating-alerts

告警创建

根据自然语言意图创建 SigNoz 告警。自主 Agent 和交互式客户端遵循相同的流程。

前提条件

此技能会调用 SigNoz MCP 工具（signoz_create_alert、 signoz_list_alert_rules、signoz_get_field_keys 等）。请确认这些工具 可用；否则运行 signoz-mcp-setup。切勿退回原始 HTTP 请求或 伪造告警配置。

适用场景

当用户希望执行以下操作时，使用此技能：

• 创建、设置或配置新的告警规则。
• 当指标、日志量、延迟或错误率超过阈值时收到寻呼或通知。
• 检测服务、主机或信号的异常行为。
• 捕获无声的数据丢失（“如果 X 的数据停止到达，就触发告警”）。

当用户希望执行以下操作时，不要使用此技能：

• 了解现有告警监控什么 → signoz-explaining-alerts。
• 诊断现有告警为何触发 → signoz-investigating-alerts。
• 修改现有告警的阈值、查询或路由 → 直接调用 signoz_update_alert。

必需输入（严格）

创建告警会写入共享系统。请严格执行以下输入约定； 猜测会在错误的服务上创建嘈杂的告警：

输入	必需	缺失时的来源
告警意图（自然语言目标）	是	$ARGUMENTS 或最近一条用户消息
资源属性筛选条件（例如 service.name、k8s.namespace.name、host.name）	是	通过 signoz_get_field_keys + signoz_get_field_values 发现
阈值	threshold / PromQL 规则	推导合理的默认值并在预览中展示；用户仅要求在数据缺失时告警时，绝不可代为设置阈值
严重性	根据意图推断	按照步骤 5 中的严重性默认值确定
通知路由	是	直接路由：经过验证的频道显示名称；策略路由：确认现有组织策略适用于此规则

如果缺少必需输入且无法通过发现获取，在进行任何写入前停止 并通过宿主支持的澄清界面询问用户。

问题中应包含：

• 缺少的内容：具体说明所需信息（例如“要使用哪个资源属性筛选条件”）。
• 发现所得的候选列表：列出各属性的具体值，例如： service.name → frontend、checkout、payments； host.name → prod-api-1、prod-db-1。
• 自由输入项：允许用户填写未显示的值。

在自主模式下，升级处理或使用上游上下文；绝不可使用猜测的值调用 signoz_create_alert。

工作流

步骤 1：解析意图并检查缺失项

从用户请求中提取：

1. 监控目标：信号类型（指标 / 日志 / 链路追踪 / 异常） 及具体条件（CPU、错误率、p99 延迟、日志数量等）。
2. 资源范围：对应的服务、主机、命名空间或环境。
3. 阈值：数值和比较条件（“高于 80%”“低于 100/s”）。
4. 严重性：记录用户提到的严重性和紧急程度提示 （“给我发寻呼”“只需告知”）。步骤 5 将确定最终值。
5. 路由：直接指定的频道名称，或明确要求使用 已确认存在的组织通知策略。

将信号描述映射到告警类型：

用户描述	alertType	signal
指标、CPU、内存、延迟、请求速率	METRIC_BASED_ALERT	metrics
日志、错误日志、日志量、日志模式	LOGS_BASED_ALERT	logs
链路追踪、span、p99 延迟、慢请求	TRACES_BASED_ALERT	traces
异常、堆栈跟踪、崩溃	EXCEPTIONS_BASED_ALERT	(clickhouse_sql)

此表列出了当前可在 SigNoz 告警界面中编辑的类型。界面尚未提供的新类型， 例如用于 LLM 和 AI Agent span 遥测的 AI_TRACES_BASED_ALERT，也受支持。 仅当用户明确指定该类型，或表中没有合适类型时才使用，并说明界面没有 对应的编辑器。

如果缺少资源范围，请执行发现流程（步骤 2）。如果发现后仍缺少信息， 请停止并询问用户（参见上文的必需输入）。

步骤 2：发现资源属性和指标名称

如果用户没有指定服务／主机／命名空间，则适用 SigNoz MCP 指南：始终优先使用资源属性筛选器。请发现候选项，而不是猜测：

1. 使用 fieldContext=resource 调用 signoz_get_field_keys，枚举所选信号的资源属性。
2. 对最有可能的属性（通常依次为 service.name、host.name、k8s.namespace.name）调用 signoz_get_field_values，获取具体值。
3. 如果用户提到了指标名称，请使用搜索词调用 signoz_list_metrics，以验证准确的 OTel 指标名称。名称错误会导致告警永远不会触发。

在澄清请求中列出这些候选项（见上文的 必需输入）。不要擅自选择。

步骤 3：检查重复告警

确定范围后（由用户提供或在步骤 2 中发现），在探测数据或编写新配置之前，先检查现有告警：如果用户想更新现有规则，这两项工作都会白费。

调用 signoz_list_alert_rules 并翻阅所有分页： 在遍历完整个列表之前，pagination.hasMore 的值都为 true。此工具列出的是已配置的告警规则（持久状态）；不要使用 signoz_list_alerts，它返回当前已触发／活跃的告警实例，会悄无声息地漏掉已配置但当前未触发的规则。检查是否存在与用户意图匹配的规则（相同信号＋相同范围＋相似阈值）。如果存在可能重复的规则，请告知用户，并询问他们是仍要创建新规则、修改现有规则（此处不在范围内：使用 signoz_update_alert），还是取消。

步骤 4：探测所选筛选条件是否有数据（快速失败）

编写任何告警配置之前，请确认告警将监控的具体组合（指标 × 服务 × 其他筛选条件）确实会产生数据。最常见的静默失败是“指标存在于目录中，服务也存在于目录中，但该服务不会产生此指标”；各项单独检查都没问题，告警也能成功保存，却始终不会触发。

使用告警将采用的相同筛选条件，在最近 1 小时内运行一次探测，但使用能确认数据存在的最简单聚合方式：

• 指标：使用 signoz_query_metrics，并传入具体的 metricName 和告警的 filter；它会自动应用聚合默认值。如果必须使用完整的 v5 工具，请使用包含 metricName、timeAggregation 和 spaceAggregation 的指标聚合对象。指标不接受 count() 之类的表达式聚合，也不接受仅含筛选条件的探测。
• 日志：调用 signoz_aggregate_logs，传入 aggregation: "count" 和告警筛选条件。count() 是 Query Builder 表达式，不是辅助工具参数。
• 链路追踪：调用 signoz_aggregate_traces，传入 aggregation: "count" 和告警筛选条件。不要传入 aggregation: "count()"。

检查结果：

• 探测返回行 → 继续步骤 5。
• 探测结果为空 → 停止。不要构建一个之后还要让用户丢弃的告警配置。停止并询问用户（见上文的必需输入），说明缺少什么，并提供具体的恢复方案：
  • 服务不会产生该指标 → 调用 signoz_get_field_values signal=metrics name=service.name metricName=<metric> 列出确实会产生该指标的服务；让用户选择其他服务或其他指标。
  • 属性名称错误（使用了 service，而不是 service.name）→ 建议使用语义约定名称，然后重新探测。
  • 服务会产生该指标，但不在预期时间范围内产生 → 将探测时间范围扩大一次（例如最近 24h），再判定是否无数据。

例外：基于日志的崩溃 / panic / OOMKilled / FATAL 告警。 在健康系统中，这些告警本就不会匹配任何日志。探测结果按设计会为空。不要停止；应告知用户结果为零，并在保存前请用户确认。对此例外应从严适用：它仅适用于“发生坏事时提醒我”的日志查询，不适用于依赖持续数据流的告警。

步骤 5：构建告警配置

读取 signoz://alert/instructions 和 signoz://alert/examples MCP 资源，了解规范且适用于当前版本的配置结构。

编写完整负载；没有任何字段会替你填充。对于每条阈值或 PromQL 规则，请显式设置以下字段：

• schemaVersion: "v2alpha1"。省略 schemaVersion 时会按 v1 语义读取，并因缺少 v1 条件字段而遭拒。
• evaluation：{ "kind": "rolling", "spec": { "evalWindow": "5m0s", "frequency": "1m0s" } }，除非意图表明应采用其他频率。 v2alpha1 规则必填。
• notificationSettings：v2alpha1 规则必填；根据步骤 7 设置 usePolicy，并在高基数查询中设置 groupBy。
• labels.severity：使用下文严重性默认值中最高级别的严重性。没有此字段时，规则在告警列表中不会显示严重性。
• condition.compositeQuery.panelType: "graph"。省略时，存储值为空。

异常检测规则则使用 v1 结构：顶层的 evalWindow 和 frequency、condition.op / matchType / target / algorithm / seasonality，不包含 schemaVersion、thresholds、evaluation 或 notificationSettings。

阈值 / PromQL 的 condition.thresholds 必须包含 kind（使用 "basic"）和非空的 spec[]。当前 v2 无法将 alertOnAbsent 表示为唯一触发条件。对于只要求在数据缺失时触发的请求，请在进行任何写入前停止；只有在获得明确批准后，才提供组合阈值规则与缺失规则的方案。

对于大多数用户意图，配置属于少数几种模式之一：

模式	示例意图
单指标阈值	“CPU > 80% 时告警”、“p99 延迟 > 2s”
日志量阈值	“每分钟超过 N 条错误日志”
基于 Trace 的计数或百分位数	“checkout 的 p99 span 时长 > 2s”
错误率公式（A/B*100）：参见下方“常见查询形式”	“错误率 > 5%”
异常检测（Z-score）	“有异常流量时提醒我”
组合阈值 + 数据缺失（仅在批准后）	“数据停止到达时告警”
ClickHouse SQL 告警：使用 signoz://alert/examples 中的架构编写 SQL	复杂联接、构建器无法表达的自定义聚合
PromQL 告警：将查询委托给 signoz-generating-queries，然后返回此处	用户已有 PromQL 时

阈值 op 和 matchType 的取值。 使用以下 op 字词：above、 below、equal、not_equal、above_or_equal、below_or_equal 和 outside_bounds；equals 无效。异常规则使用 above：其绝对分数涵盖尖峰和下降。

比较	op	评估行为	matchType
above / exceeds / >	"above"	任意时刻触发越界	"at_least_once"
below / under / <	"below"	整个窗口内均触发越界	"all_the_times"
equal / =	"equal"	平均值触发越界	"on_average"
not equal / !=	"not_equal"	总和触发越界	"in_total"
		最新值触发越界	"last"

此技能写入载荷（并显示在预览中）的惯例：

• evalWindow: 5m0s、frequency: 1m0s：仅当意图表明需要更慢或更快的频率时才更改。
• CPU / 内存 / 延迟使用 matchType: "on_average"：平滑瞬时尖峰。
• 错误计数 / 错误率使用 matchType: "at_least_once"： 捕获任何越界情况。

严重性默认值。 按以下顺序确定每个阈值层级的严重性：

1. 采用下方第一个匹配的行（无需提示）；若均不匹配，则使用 warning。
2. 用户提示会覆盖默认值。明确指定的严重性（“critical”、“80% 时 warning”）优先于紧急程度提示。“呼叫我”、“叫醒我”或“紧急”设为 critical。“仅供参考”、“不要呼叫”或“低优先级”会将默认值降低一个级别（critical 降为 warning，warning 降为 info，info 保持 info）。与某个阈值关联的提示（“90% 时呼叫我”）仅适用于该层级。同一层级的紧急程度提示互相冲突时，请询问用户。
3. 按严重性为每个阈值层级命名，并将 labels.severity 设为最高层级；SigNoz 的告警规则列表会按此字段排序和筛选。每次触发都会带上此标签，因此对于多层级规则，只有 threshold.name 能显示触发的是哪个层级。异常规则没有层级：SigNoz 会使用该标签作为层级名称。第 8 步的预览会说明每个层级的严重性及原因。

告警意图	默认严重性
任何单次崩溃事件：OOMKilled / CrashLoopBackOff / panic / FATAL 日志行	critical
生产服务宕机 / 无数据	critical
SLO 消耗速率	14.4× 或更高：critical；6× 至低于 14.4×：warning；低于 6×（例如工单级别的 1×）：info
阈值高于 1% 的错误率	critical
错误日志或异常量超过计数阈值	warning
延迟恶化（p95/p99 高于目标值）	warning
CPU / 内存 / 磁盘压力	warning
请求率 / 流量异常	warning

示例：“checkout 错误率超过 2% 时提醒我”属于 critical （错误率行）；同一请求加上“仅供参考”则属于 warning。

属性名称：使用 signoz_get_field_keys 返回的确切键；可用时通常是 OTel 名称，例如 service.name，而不是 service。

注释模板：包含动态值；值班人员看到的是通知，而不是配置：

• summary：单行标题。包含资源范围和数值："checkoutservice error rate {{$value}}% above 3%"。
• description：较长的消息。包含 {{$value}}、{{$threshold}}、groupBy 的值（例如 {{$labels.service_name}}），以及说明该怎么做或去哪里查看的句子。对于基于计数的告警，请明确写出计数："{{$value}} crash log lines in the last 5 minutes from service {{$labels.service_name}}"。

使用 {{$value}} 表示超出范围的值，使用 {{$threshold}} 表示目标值，使用 {{$labels.<key>}} 表示 groupBy 的值（注意，SigNoz 会将带点的属性名替换为下划线：service.name → service_name）。

常见查询形态：约定

阅读 signoz://alert/examples，查看所有模式的权威 JSON（错误率、p99 延迟、日志量、数据缺失、异常、PromQL、ClickHouse SQL）。以下约定不在 schema 中：

• **错误率公式：**在组件查询 A 和 B 上设置 disabled: true，这样告警图表和通知中只会显示公式 F1。原始计数是中间值，并非告警信号：若忘记设置，预览中会出现 3 条序列，导致值班工程师阅读通知时产生困惑。
• **p99 延迟：**查询输出的单位是纳秒，但阈值应使用用户指定的单位（例如 target: 2、targetUnit: "s"）；SigNoz 会在评估期间进行转换。
• **低流量百分位数保护：**在百分位数查询的 having.expression 中添加 count() > N，并将 stepInterval 设置为所需的分桶大小（例如，“每分钟”设为 60）。不要在 A * (B >= N) 这类公式中自行添加比较运算符。
• **日志量激增：**用户说“任何服务”时，优先使用 groupBy: service.name，而不是硬性过滤：groupBy 会限定范围，同时让每个服务的通知都更有用。

步骤 6：试运行完整查询并验证阈值

步骤 4 确认了数据流通。步骤 6 要做两件事：

1. **验证查询结构。**运行完整的构建器规范（包含 groupBy、公式、已禁用的组件查询以及非字符串过滤器）：步骤 4 中单独使用 count() 的探测不会覆盖这些情况。 create-alert schema 接受的查询可能在评估时出错（数值型 groupBy、未加引号的布尔过滤器、聚合不匹配）。 任何 HTTP 5xx 或“filter type mismatch”都意味着：在继续执行（2）之前，先修正配置。对公式组件查询（A * 100 / B 中的 A、B）设置 disabled: true 是推荐做法，并非错误（参见步骤 5）。
2. **校准阈值。**使用已验证的查询，过去一小时内告警触发的次数是否合理？ 在最近 1 小时内运行完整的主查询（或公式）：

• 对所有 Builder、公式和 PromQL 查询使用 signoz_execute_builder_query：根据实际情况，将 compositeQuery.queries[].type 设为 builder_query / builder_formula / promql。告警 PromQL 规范仅包含 name / query / legend / disabled；试运行执行的 PromQL 规范还可以包含 step / stats。仍然省略仅适用于 Builder 的 stepInterval。 将字符串放入 spec.query，读取 signoz://promql/instructions，了解 SigNoz 要求的 UTF-8 引号选择器形式（{"metric.name.with.dots"}，而不是带下划线或不带引号的点分形式），并确保告警 PromQL 完全使用字面值：不求值 $var、$__rate_interval 或其他仪表板变量。
• 告警规范省略时间范围，但此试运行不能省略：将外层查询的 start / end 设为绝对 JSON 整数 Unix 毫秒值（例如 now−3600000 → now），否则 signoz_execute_builder_query 会因 missing start or end timestamp 失败。
• 对于按某个维度分组的意图，每次执行中的 groupBy[].name 都必须是 Step 2 中的确切键（例如 k8s.pod.name），不能为空。其他情况省略 groupBy。
• 更适合时使用 signoz_aggregate_logs / signoz_aggregate_traces。
• 如果告警查询通过 metricName 针对单个已知指标，则使用 signoz_query_metrics：该工具会自动应用聚合默认值，并接受 filter、groupBy 和 formula。此处不支持 PromQL；请改用 signoz_execute_builder_query。

从已持久化规则中的每个查询里省略 limit 和 order，包括 Builder 查询、公式输入和公式结果。对于分组告警查询，limit 加 order 会形成 Top-N 序列上限：只评估在整个评估窗口内排名靠前的 N 个组，因此 N 以外的序列永远不会被评估，短暂尖峰的组可能被排除，而按降序排列的 below 告警可能会排除所有触发告警的序列。只有在明确需要 Top-N 告警时（“针对最繁忙的五台主机发出告警”），才设置这些参数；使用 Query Builder v5 的 order，切勿使用仪表板的 orderBy。

试运行则有所不同：signoz_execute_builder_query 是带有响应预算的展示上下文，因此 signoz-generating-queries 为其规定的范围（每个查询设置正数 limit 和 v5 order）可以使用。它们只能保留在试运行信封中；绝不能复制到 signoz_create_alert 载荷中。由于试运行最多返回 limit 个组，基于此结果计算的触发次数只涵盖返回的组；当 groupBy 可能超过此上限时，应在预览中说明这一点，而不要将次数报告为完整结果。

计算有多少个评估点触发了拟定阈值。 在预览中显示为 “过去 1 小时内会触发 N 次”。 1 小时的窗口太短，无法评估大多数告警：只有极端情况才有实际意义：

• N 较大（例如 > 30） → 可能会造成告警风暴。请在预览中说明，并建议收紧阈值或添加迟滞（recoveryTarget）。
• N = 0 → 健康系统的预期结果；不要建议用户放宽阈值。只有当用户表示预期告警此时会触发时（例如正在发生事故），才提示这一点。
• N 较小且非零 → 报告次数；由用户判断阈值是否合适。仅凭 1 小时的数据，无法区分“调优得当”和“刚好捕捉到一次短暂事件”。

3. 例外情况：
   • 异常告警：运行底层指标查询，但不应用异常 functions 转换，以验证其形状和数据；然后跳过触发次数计算（Z 分数无法直接与原始值比较）。明确说明此操作验证的是基础查询，而不是异常评分。
   • 基于日志的 crash / panic / OOMKilled / FATAL 告警：这些告警在健康系统中有意保持零匹配。步骤 4 已显示零匹配结果并获得用户确认；跳过触发次数计算。 如果因某种原因跳过了步骤 4（例如，下游技能在流程进行到一半时调用此流程），这里同样适用无数据停止规则：结果为空 → 停止并询问用户（参见上文的 必需输入），而不是保存一个永远不会触发的警报。

步骤 7：确定通知路由

完成试运行并确定最终严重级别后，选择直接路由或组织策略路由。缺少渠道并不意味着可以改用策略路由。

对于已确认存在的、基于阈值或 PromQL 的规则的组织策略，设置 notificationSettings.usePolicy: true，保留已确认的匹配器标签和阈值层级，并省略阈值渠道和 preferredChannels。此技能不会创建策略。如果策略或匹配条件未得到确认，请停止并询问。异常规则只能使用直接路由。如果匹配条件按 severity 路由层级，请停止并询问：每个层级都会匹配为最高级别（步骤 5）。提供 threshold.name 匹配器、每个层级创建一条规则或直接路由这几种选项。

对于直接路由，复用同一操作中已完整分页的渠道结果，或持续分页调用 signoz_list_notification_channels，直到 hasMore=false；其 total 统计的是筛选后的匹配项。根据不可变的 displayName 而不是机器标识 name 进行匹配和路由；请用户选择时展示 displayName 和 kind。只有根据用户提供的配置才可提供创建选项，绝不自动创建。根据当前输入架构构建 signoz_create_notification_channel 参数；该架构定义了支持的提供商类型和身份字段：提供商设置必须放在 config 中，不能作为独立字段。询问用户是否需要测试通知，只有在用户同意时才设置 test: true。遇到 PERMISSION_DENIED 时，使用管理员创建的渠道，或使用来自主机密钥库的短期、最低权限凭证。如果路由仍未确定，请停止并询问。

在每个阈值的 channels 中填入返回的准确显示名称；异常规则则使用顶层的 preferredChannels。切勿用一种路由字段替代另一种。阈值层级没有渠道，或指定的 displayName 不存在，都会导致失败，除非 notificationSettings.usePolicy 为 true。v2alpha1 规则中的顶层 preferredChannels 会被存储但不使用，因此仅通过该字段路由的阈值规则会被保存，但不会通知任何人。

更新或处理包含密钥的渠道配置

signoz_update_notification_channel 会完整替换配置：解析 id，获取渠道，复制完整的 config，更改请求的字段，然后发送 id 和完整的 config。不要发送或更改 name 或 displayName。保留凭据和实际生效的 sendResolved，但不要回显它们。更改类型时，需要提供完整的新提供商配置。更新测试需要显式选择加入。

如果请求的测试在成功写入后失败，请分别报告变更和测试状态。如果写入后出现身份验证错误且 mutationCommitted: true，请保留 ID，并在完成身份验证后检查；不要重放变更或测试。传输成功并不能证明最终由提供商成功投递。

Slack webhook URL、PagerDuty 集成密钥和类似的 webhook 令牌都属于机密。当用户以内联方式提供这些信息时，将其视为不透明输入，并遵守以下规则：

• 不要回显机密。 不要在聊天输出、预览、确认消息、摘要或 <navigation_suggestions> 载荷中包含 webhook URL、集成密钥或任何类似密码的令牌。仅通过 displayName 指称渠道（"Slack channel Platform Alerts created"），并完全省略机密值。
• 不要将机密存入澄清上下文。 如果用户粘贴机密后你需要追问，不要将机密值放入澄清的 message、discovered_context 或主机可能为后续恢复而保存的任何其他字段。用符号化的方式指称它（例如“你刚才提供的 webhook”）。
• 仅传递一次。 将机密直接传给 signoz_create_notification_channel，不要在任何中间文案中保留它。创建调用成功后，通过显示名称指称渠道；如果失败，请让用户重新粘贴，而不要回显其提供的内容。
• 如果用户问的是“如何设置 Slack 渠道？”：这是文档问题，不是创建渠道的请求。请按文档说明操作（前往 SigNoz UI 的 Notification Channels 页面），不要在聊天中索要机密。如果用户似乎不确定是否要暴露令牌，优先推荐 UI 路径。

第 8 步：预览已准备好的配置

用一段通俗易懂的语言总结将要创建的内容：不要输出原始 JSON。面向用户的信息（触发条件、作用范围、阈值和通知路由）由摘要呈现；点击查看 JSON 并不能发现查询结构错误（第 6 步的试运行可以）。

摘要：当 [资源范围] 满足 [条件] 时，此告警将触发，每隔 [频率] 评估一次，并检查最近 [窗口] 的数据。严重级别：[等级]，依据为[表格行或用户线索]。阈值：警告级别为 X，严重级别为 Y。通知将通过[直接渠道／已确认的组织策略]发送。最近 1 小时的试运行：将触发 N 次。

第 9 步：保存并报告

1. 使用第 8 步中的配置调用 signoz_create_alert。
2. 名称冲突：如果 signoz_create_alert 返回名称重复错误，不要追加后缀，也不要调用 signoz_update_alert。停止操作，并告知用户现有告警阻止了创建；可以提出改用其他名称，或修改现有告警（这不在此技能的范围内）。
3. 成功后，报告：
   • 告警 ID 和名称。
   • 监控对象、阈值和严重级别。
   • 通知路由方式（直接渠道或已确认的组织策略）。
   • 试运行摘要（“最近 1 小时内将触发 N 次”）。

防护措施

• 严格校验输入，不要猜测 必须提供资源属性和通知路由。直接路由需要指定频道；策略路由需要确认匹配项已存在，且不需要直接频道。
• 始终对 signoz_list_alert_rules 进行分页 只读取第 1 页会遗漏重复项并产生噪声。
• 必须先试运行 在执行 signoz_create_alert 前，完成步骤 4 和步骤 6；永不触发的告警会造成虚假的安全感。
• 阈值运算符使用规范词语 使用步骤 5 中的 op 和 matchType 词语，绝不要使用 equals。
• 完整构造负载 自行设置 schemaVersion、evaluation、notificationSettings、labels.severity 和 panelType（步骤 5）；这些字段不会自动填充。
• 持久化告警查询中不要使用 limit 或 order 它们会将分组告警限制为排名靠前的 N 个序列（步骤 6）。仅在试运行封装中保留它们。
• 信号必须与 alertType 匹配 signal: "logs" 需要使用 LOGS_BASED_ALERT。不匹配会导致验证失败。
• 异常规则仅支持指标 anomaly_rule 与非指标 alertType 组合会被拒绝。
• 必须确认路由。 直接路由使用完整分页后的 signoz_list_notification_channels 返回的确切 displayName 值；对于阈值/PromQL 规则，将它们填入每个阈值的 channels；对于异常规则，则填入顶层 preferredChannels。已确认的策略路由需设置 notificationSettings.usePolicy，并省略直接频道字段。
• 绝不要回显频道密钥。 Slack webhook URL、PagerDuty 集成密钥及类似的 webhook 令牌都属于密钥。将它们传给 signoz_create_notification_channel 一次后，绝不要在聊天输出、预览、确认信息、摘要、澄清负载或导航建议中重复这些值。创建后仅通过显示名称引用频道；如果失败，请用户重新粘贴，而不是复述他们发送的内容。

示例

四种规范告警流程（多严重级别指标阈值、错误率公式、log-volume groupBy 和异常检测）见 references/examples.md。

其他资源

• signoz://alert/instructions 和 signoz://alert/examples MCP 资源：告警负载结构、需要明确设置的字段、阈值代码、筛选表达式语法，以及与当前版本一致的模式示例。始终优先使用这些资源，而不是任何转录副本。
• signoz-generating-queries 技能：用于编写 PromQL，或在将查询封装为告警前进行测试。