StatsD 指标聚合管道

它解决什么问题

StatsD 在本地进程里收指标，再按固定节奏吐出去。但到了真实环境，痛点很具体：同一批计数器既要进 Graphite 画长周期曲线，又要进 InfluxDB 做短窗口查询，还要按机房标签同步给 Datadog 做告警。结果就是三份配置、三套间隔、三种标签写法。更糟的是，聚合发生在客户端还是聚合端常常说不清，凌晨三点收到的延迟曲线锯齿状起伏，多半不是业务波动，而是 flush interval 和聚合规则没对上。

技能如何工作

这个技能不重新发明协议，而是围绕已有 StatsD 管道做配置收敛。

• 聚合规则：按指标名或前缀声明 aggregation rules，区分 counter、gauge、timer、set，保留均值、最大值、百分位等派生量。
• flush 间隔：为不同管道设置独立节奏，避免所有指标共用同一个 flush 点，减少抖动叠加。
• 标签路由：通过 tag-based dimensional routing，把指标按标签条件分发到 Graphite Carbon、InfluxDB Line Protocol 或 Datadog DogStatsD endpoint。

关键步骤是：先声明管道与目标端；再配置聚合规则与 flush 间隔；最后定义标签映射，让同一指标在不同后端保持可查询维度。

适用边界与注意点

• 它解决的是配置与路由层，不是重写采集 agent，也不负责指标语义定义。
• 管道会改变指标形态：打散、合并、重命名都可能影响下游查询，先在旁路验证再切流量。
• 标签值必须是稳定、低基数的维度，否则会放大后端写入压力。
• 输出端行为随版本变化，运行前对照 https://docs.datadoghq.com/ 核对当前字段与协议。
• 上游项目可信度未知时，先跑离线配置与小流量回放，不要把未审阅的规则直接放进敏感生产链路。