Datadog 主机计费：二十小时扩容如何留下月度峰值

摘要

Datadog 的主机高水位方案剔除每小时读数中最高的 1%，再以余下读数的最大值计算月度计费主机数。短期扩容能否被剔除，取决于它在整月读数中的位置和持续时间。
在本文自建的 720 小时算例中，20 小时监控 400 台、其余 700 小时监控 100 台，高水位计量仍为 400 台。假设另一份混合方案承诺 100 台，超额部分则为 6,000 主机小时；两者尚不是价格。

弹性基础设施有一种很讨人喜欢的结束方式：工作做完，把机器关掉。Datadog 的监控采购还要多问一句，关掉以后，合同用什么单位记住刚才那段工作？

公司公开文件给出了两种主机计费结构。高水位方案按整月小时读数筛选出一个主机数；月度加小时方案收取最低月度承诺，再按小时计算超出部分。机器可以很短命，决定费用的统计值却有自己的寿命。

这件事最容易在“我们已经缩容了”的汇报里消失。缩容改变当前运行状态。月度峰值如何形成，是另一个采购决定。

Datadog 将基础设施主机定义为物理或虚拟的操作系统实例，并逐小时记录被监控的独立主机数。高水位方案称为 HWMP：把最高的 1% 小时读数排除，取剩余 99% 的最大值作为月度计费主机数。这个缓冲能消化最极端的一小段时间，整条负载曲线仍决定剩下的峰值。

用一个自建算例看清它。假设某个 30 天月份恰好有 720 条小时读数，其中 700 条是 100 台，另外 20 条是 400 台。这里没有真实客户，也没有一张等待报销的账单。

即便分别按排除 7 条或 8 条最高读数计算，剩下的记录里仍有 400 台的小时。高水位计量因而保持 400 台。这个例子避开了公开文字未详述的边界舍入问题：扩容的 20 个小时足够长，结果在这两种取整下相同。

400 是月度计费主机数。那 300 台额外主机在算例中运行了 20 小时。合同把一条时间序列压成一个计量值，财务承担的是这个计量值乘以适用价格后的后果。

Datadog 同时列出 MHP，即月度最低承诺加超额小时的混合结构。继续使用同一组假设读数，再假设合同的月度最低承诺是 100 台。超出的 300 台持续 20 小时，产生 6,000 个超额主机小时；100 台的月度最低承诺继续存在。

本文假设负载下的计量方式	得到的计量结果
HWMP，排除最高 1% 后取余下峰值	400 台月度计费主机
MHP，假设月度最低承诺 100 台	100 台月度最低承诺，加 6,000 超额主机小时

把 400 和 6,000 放在一起比大小，计算器也救不了采购。前者是主机数，后者是时间累积量，混合结构还带着最低承诺。需要的缺口很具体：实际订单价格、承诺条款和被监控主机的逐小时记录，可能改变哪一种结构更合算。

稳定负载与短期扩容购买的是不同的费用形状。高水位方案给月度主机数定价；混合结构让承诺以上的持续时间进入计算。工程团队在意什么时候退出扩容，采购团队还要在意退出时间究竟进入哪一条计费公式。

Datadog 的 Bill Overview 文件提供了很有用的检查入口。对采用第 99 百分位计量的组织，导出的主机 CSV 在对应测量小时为每台主机填写 Usage Value 1；采用求和口径时，同名列填的是主机小时。官方举的满 30 天例子是 720。

同一个列名可以容纳不同单位。把所有行加起来之前，应先知道组织采用哪种口径。月末仍在的主机清单、月度平均主机数与决定峰值的那个小时，各自回答不同的问题。只递交最后一天的截图，可能把决定采购成本的时间段恰好裁掉。

费用还有产品边界。Datadog 列出的其他聚合规则包括求和、平均和最大值，产品也有包含用量、承诺与配额。这里计算的是主机方案，日志、容器、自定义指标和整张账单各有规则。公开文件的默认计费周期是自然月，订单另有规定时按订单处理。

弹性让机器能及时退场。它留下多少监控成本，由买下的计量规则决定。技术团队把系统做得灵活，采购最好也认识这份灵活在合同里长什么样。