Datadog 指标导出器

要解决的问题

在 Node.js 服务里，dd-trace 会自动采集 Redis、Express、Postgres 等主流库的运行时指标，但很多业务语义——下单成功率、每用户平均订单金额、某个特性开关带来的延迟差异——藏在应用代码内部，不在框架埋点的射程里。硬把这些指标塞进系统层，要么得改动业务代码到处打点，要么自定义计数器散落各处、格式不一，最后在 Datadog 里难以聚合和告警。这个技能要填的正是这个坑：给开发者一个统一的出口，把自定义指标和追踪数据按统一协议送进 Datadog，并让它们能被正确聚合、过滤和 SLO 化。

核心能力

工作路径分三层：

• 协议层：指标通过 DogStatsD（UDP/命名管道）发送，进程内不阻塞请求；追踪数据走 Datadog API v2 上报。两条链路职责分明，计数、计时类指标走 DogStatsD，分布式追踪走 API。
• 聚合层：支持直方图聚合，不再只存平均值和总数——平均值在长尾场景里基本没有信息量，直方图才能还原分布形态，和 Datadog 的分位数监控直接对齐。
• 标签与 SLO：支持基于标签的过滤器和 SLO 跟踪。同一指标在不同 env、service、team 标签维度下拆分，直接为 SLO 错误预算计算提供输入。

典型用法是：在业务关键路径上记录计数或耗时，带上一组结构化标签，剩下的聚合、过滤和 SLO 判定交给 Datadog 侧完成。

适用边界与注意点

• 底层依赖 dd-trace，目前面向 Node.js 应用；其他语言需要对应语言的 Tracer。
• DogStatsD 走 UDP，指标本身不保证送达，适合监控数据而非控制链路。
• 标签基数（cardinality）需要提前规划，高基数标签是 Datadog 账单和查询延迟的常见来源。
• 直方图聚合需要配置 bucket 边界，默认 bucket 对非常规量级的指标（比如微秒级内部调用和秒级外部请求）都可能失真。
• 它导出的是“数据出口”，不替代 APM 自动埋点；自动检测到的 span 和手工导出的指标应视为互补，不要重复上报。