编程开发 编辑复核
日志查询与告警规则设计
把事故信号转成低噪声日志查询和告警，定义分组、窗口、阈值、负责人和误报处理。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名可观测性工程师。请从用户影响和可行动性设计日志与告警，不追求把每条异常都通知人，也不泄露敏感字段。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 定义事件、用户影响、时间窗口和分组维度
2. 写查询、过滤、聚合和去重逻辑
3. 设计阈值、告警级别、抑制和升级规则
4. 补充运行手册、误报复盘和隐私检查
输入变量：
- 目标信号（{{signal}}）：说明要发现的异常和用户影响。
- 日志结构（{{log_schema}}）：提供字段、级别、时间和请求标识。
- 观测平台（{{platform}}）：说明查询语法和告警能力。
- 隐私边界（{{privacy}}）：列出不可进入日志和告警通知的字段。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先在历史日志上回放查询，估算误报和漏报。
- 告警上线后用实际响应时间和无效告警率持续调阈值。
WHEN IT FITS
适用判断
适合这些情况
- 要为某类问题预先设计查询和告警，而不是出事后临时写。
- 你知道日志的字段结构和查询语法。
- 需要平衡告警灵敏度和噪音。
换个做法更好
- 你正在排查一个具体事件：用《日志事件分析与排查顺序》。
- 日志还没有结构化：先解决日志格式，否则查询写不了。
- 你不确定日志里有哪些字段：先看一遍实际日志样本。
FAILURE MODES
常见翻车与修正
- 查询用了你的日志系统不支持的语法。
把日志系统名称、版本和一条实际日志粘进输入，要求语法与之匹配并说明依据。
- 告警阈值是拍脑袋定的，上线后要么天天响要么从不响。
要求基于你提供的历史数据分布来定阈值，没有数据时明确写「需观察两周后调整」并给出初始保守值。
- 告警只说「出错了」，值班的人不知道该做什么。
要求每条告警配处理指引：先看什么、常见原因、什么情况下升级。
ACCEPTANCE
怎么判断输出合格
- 查询语法与你的日志系统匹配，能直接跑。
- 阈值有数据依据，或明确标注为待调整的初始值。
- 每条告警都配了处理指引。
- 考虑了噪音控制，比如聚合窗口和抑制规则。
SAFETY BOUNDARY
使用边界
- 日志样本贴入前去掉用户标识和请求体内容，日志往往是个人信息最集中的地方。
- 告警阈值设得过敏感会造成告警疲劳，上线前先用历史数据回放验证触发频率。