Datadog 监控蓝图生成器

要解决的实际问题

在 Datadog 里手工维护监控器时，最容易出问题的不是点不开页面，而是同一套告警逻辑在多个环境里被复制成不同版本：阈值写法不一致、异常检测参数丢失、message 和标签随意改动，最后 Terraform 里的 datadog_monitor 资源和线上实际状态逐渐漂移。尤其当需要覆盖指标、日志、APM trace 以及复合条件时，人工拼 JSON 和 HCL 很容易漏字段，也不利于 code review 和回滚。

这个技能如何工作

该技能围绕 Datadog API v2 的监控器定义展开，把一次创建或更新监控器需要的关键信息整理成可复用流程：

• 监控类型解析：区分 metric、log、apm_trace 和 composite 等场景，避免把不同数据源的查询条件混在一起。
• 定义组装：将查询语句、阈值、异常检测、通知消息和标签等参数组织成 Datadog monitor 定义。
• Terraform 输出：把定义映射为 datadog_monitor 资源，便于纳入基础设施代码管理。

典型工作步骤可以看作：

• 明确监控目标，例如某个服务延迟、错误率或业务指标。
• 选择正确的监控器类型，并准备对应查询条件。
• 配置阈值和异常检测规则，减少只靠固定阈值带来的漏报或抖动。
• 生成 datadog_monitor 资源，再交由 Terraform 执行 plan 和 apply。

适用边界与注意点

• 该技能解决的是监控器蓝图和 Terraform 资源生成，不替代 Datadog agent、日志采集器或 APM tracer 的部署。
• 生成结果是否可用，取决于账户权限、组织策略、指标命名以及数据是否已经正确上报。
• 异常检测的效果依赖历史数据量和业务波动形态，上线前建议先用测试监控器观察一段时间。
• 复合监控器依赖已有监控器作为组合条件，设计时要先确认引用对象稳定且语义清晰。