> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# 告警
> 检测问题复发并将事件路由至正确的响应人员。
告警监控可测量的条件，并在触发时创建事件。当某个故障需要及时响应时，无论策略是否能拦截，都应使用告警。
## 创建并测试告警
1. 前往 **Analyze → Alerts**，点击 **new alert**。也可以从某个典型错误的铃铛图标直接创建。
2. 填写名称、严重级别、触发类型、条件、评估间隔、触发次数、时间窗口和通知渠道。
3. 保存告警后，打开其详情页并运行 **test**。
4. 前往 **Analyze → Issues**，对告警创建的事件执行确认、分配、讨论、订阅和解决操作。
表单的第一部分用于标识告警及应触发它的信号。
第二部分控制条件需持续多长时间、评估频率以及通知发送的目标。
保存后，在告警列表中确认规则已启用，并核对其触发条件、时间窗口、严重级别和渠道是否符合预期。
在将告警用于生产响应之前，请先对其进行测试。
```bash theme={null}
fp alerts create high-errors \
--trigger-kind metric_threshold \
--severity warning \
--trigger-spec '{"metric":"error_count","op":">","value":50,"window_secs":900}'
fp alerts show high-errors
fp alerts test high-errors
fp alerts update high-errors --severity critical --yes
```
使用 `fp alerts list` 查看规则，使用 `fp alerts delete ` 删除规则。
完整的告警命令集请参阅 [`fp alerts` 参考文档](/zh/reference/cloud-cli#alerts)。
告警条件可基于错误、评估分数、评估组合或自定义 SQL。添加接收人、测试规则，并打开生成的事件进行确认、分配、评论、订阅和解决。
## 良好的告警设计原则
* 在名称中体现条件和受影响的工作流。
* 明确限定环境范围。
* 设置合理的时间窗口和阈值，避免对单次无害事件做出反应。
* 附上能引导响应人员定位会话的链接或查询。
* 在启用规则之前先指定负责人。
在解决审计发现的问题后，针对策略覆盖范围之外可能再次发生的相同故障添加告警。