这两年找我聊监控服务器的人，画风变了。以前是「给我一台能装 Zabbix 的机器就行」，现在上来就甩一句「我们要上 Prometheus，active series 大概几百万，内存怎么配、盘要不要 NVMe」。问得越具体，说明踩过的坑越疼——多半是被 OOMKilled 教育过，或者半夜被 Grafana 面板的超时提示吵醒过。
先说清楚一件事，免得标题把你带偏：本文不给你编造任何实测数字。Prometheus 的存储行为我一律引用官方文档的公开表述，容量与内存的估算一律写成「经验估算（预估）」并注明影响因素，剩下的请你用自己环境里的 prometheus_tsdb_head_series 和 process_resident_memory_bytes 去实测。价格也是一样，官网明示的写官网价，官网没明示的一律写预估并注明以下单核算为准。这是我写每一篇的底线。
Prometheus 这台机器的麻烦之处在于，它不是「跑个服务」那么简单。它是一个写多读少、内存常驻、后台持续压缩、还要扛住 PromQL 聚合的时序数据库。用给 Web 服务器配硬件的思路去给它配机器，十有八九翻车。赶时间的先看这几条结论：
1. 内存是第一优先级，不是 CPU。官方明确说明「当前接收写入的 block 保留在内存中、未完全持久化」，head block 是常驻内存的。CPU 不够只是慢，内存不够是直接 OOMKilled 重启，重启就要回放 WAL，回放期间你是瞎的。
2. 磁盘容量可以按官方给的公式算，官方口径是每样本平均只占 1–2 字节。但那是压缩后的持久化块，WAL 是未压缩原始数据，官方自己说 WAL 文件「比常规 block 文件大得多」，两部分要分开估。
3. NVMe 不是锦上添花，是 WAL 的刚需。WAL 写入是同步 fsync，fsync 延迟直接决定每批写入的延迟下限；后台 compaction 又是大量小文件读写。机械盘在这个场景下没有讨论空间。
4. 指标基数爆炸才是头号杀手，不是硬件。一条 label 设计失误，一个晚上能给你造出几百万条序列，再大的内存也扛不住。硬件扩容解决不了 label 设计问题。
5. 报价分两级看。一万网络官网明示的裸金属 E5-2620 ¥999/月起、E5-2698v4×2 ¥3999/月起、中国香港 E3 ¥1500–1599/月、一万云 ¥25 起；Prometheus 专用监控存储这类非标组合官网未逐条列档，属预估范畴，以下单核算为准。
要配机器，先得知道数据落在哪。按官方文档的说法，Prometheus 的本地时序数据库把采集到的样本按两小时为一个 block 分组。每个 block 是一个目录，里面包含：一个 chunks 子目录（存放该时间窗口内所有时间序列的样本）、一个 meta.json 元数据文件、以及一个 index 索引文件（把指标名和 label 映射到 chunks 目录里的时间序列）。chunks 目录里的样本又被组织成一个或多个 segment 文件，每个 segment 默认最大 512 MB。
这里有个细节很多人不知道：通过 API 删除序列时，删除记录是单独存在 tombstones 文件里的，不会立刻从 chunk segment 里抹掉，真正的清理要等后续 compaction。所以你删了指标之后磁盘不会马上变小，别以为删除接口坏了。
官方文档的原话是：当前接收新样本的 block 保存在内存中，并且没有完全持久化。它靠一个预写日志（WAL）来防崩溃，Prometheus 重启时可以回放 WAL 恢复。WAL 文件存在 wal 目录里，每段 128 MB。官方特别提醒：这些文件包含尚未压缩的原始数据，因此比常规 block 文件大得多；Prometheus 至少保留三个 WAL 文件，高流量的服务器会保留更多，以保证至少两个小时的原始数据。
这段话的实操含义有三条：第一，你的磁盘规划里，WAL 和 head 的峰值空间必须单列，不能只算压缩后的块；第二，WAL 段的 fsync 是持久化边界，磁盘写入延迟直接卡在这里；第三，head block 越大，崩溃后启动回放越久——这就是为什么有人为了「少一点 compaction」去调大 head 窗口，结果一次意外重启等了十几分钟。
官方说明：最初的两小时块最终会在后台被压缩成更长的块。压缩会创建更大的块，其数据跨度最长可达保留时间的 10%，或 31 天，取两者中较小的一个。而且官方明确提示：因为源块和新压缩出来的块必须在磁盘上共存，磁盘占用可能短暂超过 storage.tsdb.retention.size，超出部分要等下一次保留清理删掉源块后才释放。
这句话是磁盘规划的另一个关键——你不能把磁盘用到 100% 才设 retention.size，必须留缓冲，后面第三节细说。
第一，官方明确指出本地存储的局限：它不是集群化的，也不是副本化的，面对磁盘或节点故障不具备任意扩展性和持久性，应当像管理其他单节点数据库一样管理它。第二，本地存储不支持非 POSIX 兼容的文件系统，NFS（包括 AWS 的 EFS）不被支持，官方强烈建议使用本地文件系统，否则可能发生不可恢复的损坏。这条直接否掉了「把 Prometheus 数据目录挂到共享存储上」的偷懒做法。第三，建议用快照做备份；不用快照备份有可能丢失自上一个 TSDB 块创建以来记录的数据，而块通常每两小时创建一次，覆盖最近三个小时的样本。
这一节是全文最实用的部分。先给公式，再给例子，最后说清楚这个公式的边界在哪。
写入速率（samples/s）的算法很简单，就是活跃序列数 ÷ 采集间隔秒数。比如 100 万条 active series、15 秒采集一次，写入速率就是约 6.7 万 samples/s。这个数字是所有硬件选型的起点：它决定 WAL 的写入压力、head block 的内存占用、以及 compaction 的频率。
降低写入速率只有两条路：减少时间序列（更少的 target 或者每个 target 更少的序列），或者加大采集间隔。官方给的建议是——减少序列数往往更有效，因为同一序列内部的样本压缩效果很好，砍掉一条序列等于砍掉一整串，而拉长间隔只是让同一串变得稀疏。
官方给出的口径是：Prometheus 平均每个样本只存 1–2 字节，因此可以用这个粗略公式做容量规划：
needed_disk_space = retention_time_seconds × ingested_samples_per_second × bytes_per_sample
套一个例子：100 万序列、15 秒间隔、本地保留 15 天。写入速率 6.7 万 samples/s，按偏保守的 2 字节/样本算，每秒约 134 KB，15 天（1296000 秒）下来约 173 GB。这是压缩后的持久化块部分。
但别拿这个数字直接去买盘。你还得加上：WAL 与 chunks_head 的峰值空间（官方说明这两项目录合计每两小时达到一次峰值，这是磁盘的最小需求）、compaction 期间源块与新块共存的临时空间、以及前面提到的保留清理后台进行可能延迟。按经验估算（预估），实际规划建议在公式结果上再留 50%–100% 的余量，具体倍数随指标基数、压缩率、采集间隔波动，没有统一值。上例我一般会按 300 GB 起步去配，而不是 173 GB。
先说清楚：Prometheus 官方文档并没有给出一个「每条活跃序列占多少内存」的硬数字。网上流传的口径差别很大——有说每条活跃序列约 700–1000 字节的，有说约 1–2 KB 的，也有按 Go 堆分配算到 4 KB 量级的。这些口径之所以差这么多，是因为实际占用跟 label 的数量和长度、序列的存活时间、GC 行为都有关。
所以我给的只能是经验区间（预估）：每条活跃序列按数 KB 量级估算，具体数值请务必用你自己环境的 process_resident_memory_bytes 除以 prometheus_tsdb_head_series 实测一次，这是唯一靠谱的做法。按这个区间粗估，百万级序列的 Prometheus 进程，内存规划以十几 GB 起步比较稳妥；五百万序列往上就要认真考虑分片或者上远程存储了。
还有一类内存消耗容易被忽略：查询执行期间的临时内存。一个 rate(http_requests_total[5m]) 不带聚合条件，可能要把几十万条序列的 chunk 全拉进内存再算。Grafana 上放几个这样的面板，就能把一台本来够用的机器拖垮。这也是我后面强调 recording rules 的原因。
这两个参数搞混的人特别多，我单独拿一节讲。
--storage.tsdb.retention.time 是样本在存储中的保留时长。官方说明：如果这个参数和 retention.size 都没设置，保留时间默认为 15d。支持 y、w、d、h、m、s、ms 单位。它的语义很直白：超过这个时长的块就被清理掉。注意过期块的清理是后台进行的，最多可能需要两小时才完成删除，而且块必须完全过期才会被移除。
--storage.tsdb.retention.size 是要保留的存储块的最大字节数，最旧的数据先删，默认为 0，也就是禁用。它有几个不显然的行为：
坑一：只有持久化块会被删，但 WAL 和内存映射 chunk 会计入总大小。官方原话是：为了满足这个保留限制，只有持久化的块会被删除，尽管 WAL 和 m-mapped 的 chunk 也计入总大小。因此磁盘的最小需求是 wal（WAL 与 Checkpoint）和 chunks_head（内存映射的 Head chunks）两个目录合计占用的空间峰值，而这个峰值每两小时出现一次。这句话翻译过来就是：你的盘再小，也必须先装得下 WAL + head 的峰值，否则 retention.size 根本救不了你。
坑二：compaction 会让磁盘短暂超限。前面说过，源块和新块共存期间磁盘占用会超过设定值，超出部分要等下次清理才释放。
坑三：值设多少官方有明确建议。官方给出的推荐是：把 retention size 最多设为分配给 Prometheus 的磁盘空间的 80%–85%，剩下的 15%–20% 缓冲用来覆盖 compaction 期间临时多占的空间。
两者同时设置时，谁先触发用谁。这是官方明确写的规则。我自己的习惯是两个都设：time 设业务需求值（比如 15d 或 30d），size 设成磁盘的 80%，作为最后一道保险——磁盘快满的时候自动丢老数据，总比写满盘导致 TSDB 崩掉强。
--storage.tsdb.wal-compression 从 2.11.0 版本引入，2.20.0 起默认启用。官方说明是：根据你的数据，可以预期 WAL 大小减半，而额外的 CPU 负载很小。这条对磁盘规划影响不小，如果你的 WAL 目录大得离谱，先确认这个开关是不是被人为关掉了。官方同时提醒：一旦启用过，降级到 2.11.0 以下版本需要删除 WAL。
Prometheus 不是那种「平时很闲、偶尔很忙」的服务，它的 CPU 消耗是几条线叠在一起的。
第一条线是抓取与解析。每个 target 每次抓取都要拉取文本格式的指标 body、解析、做 relabel 规则匹配。target 数量多、每个 target 暴露的指标多，这部分就重。relabel 规则写得越复杂，开销越大。
第二条线是compaction。后台压缩要读取同一时间窗口的已有块，跟 head block 合并，写出一个新块。它是持续的、周期性的，而且规模随序列数和块数量增长。序列数上去之后，compaction 的 CPU 占用会变得非常显眼。
第三条线是PromQL 查询与 recording rules。sum by (...)、histogram_quantile() 这类聚合算子要遍历大量 chunk 并在内存里计算，是典型的 CPU 与内存双吃。recording rules 相当于把这部分成本从「查询时一次性付」摊成「每轮评估持续付」，总体更划算，但确实增加了常驻 CPU 开销。
按经验估算（预估，随 target 数、序列数、面板复杂度变化）：几十个 target、十万级序列的小规模环境，4–8 核足够；百万级序列配 16 核比较从容；如果还要跑大量 recording rules、几十个 Grafana 面板、或者兼做 vmagent / Thanos Sidecar，按 32 核规划。这个值没有标准答案，压测一次比什么公式都准。
还有一点：Prometheus 是 Go 写的，Go 的垃圾回收行为跟堆大小相关，CPU 核数太少时 GC 会抢走本该用于查询的算力。所以宁可在核数上宽松一点，别卡着最低值配。
内存是 Prometheus 选型里唯一「不够就直接出事」的维度。前面第二节给了经验区间，这一节讲内存到底花在哪。
head block 常驻。官方明确说当前接收写入的 block 保存在内存中。每个活跃序列在 head 里都有一份结构，包含序列记录、chunk 头、label 存储。序列数乘以单条开销，就是这块的基本盘。
倒排索引。index 文件把 label 值映射到序列 ID，label 基数越高，索引越大，而索引是要被访问的部分。这就是基数爆炸会同时打爆内存和查询延迟的原因。
查询临时内存。一次大范围查询的中间结果常驻在内存里直到返回。这也是为什么官方和社区都建议给查询设并发上限和采样上限——不是为了限制你查，是为了防止一条手滑的查询把进程打挂。
WAL 与 compaction 的缓冲。这部分吃的是页缓存而非堆内存，但同样需要物理内存支撑。内存太小的机器，页缓存不够，compaction 读块就变成真实磁盘读，速度断崖式下跌。
习惯上我会这么给：十万级序列 8–16 GB；百万级序列 16–32 GB；五百万往上基本就要考虑分片或者把长期存储交给 VictoriaMetrics / Thanos，而不是硬堆单机内存。这些都是经验估算（预估），务必以实测为准。
另外，监控服务器最好别跟业务混布。Prometheus 的内存占用是随序列数线性增长的，业务进程的内存占用是随请求量波动的，两个叠在一台机器上，出问题时你分不清是谁的锅。一万网络人工定制口径里的明示升级价是内存升到 128G +¥600/月（以官网实时价为准），跟因为内存不足导致监控在故障时刻失明相比，这个钱不值得省。
这一维我要下死结论：Prometheus 的数据目录必须放本地 NVMe（或至少企业级 SSD），机械盘只配做备份盘和归档盘。
WAL 是追加写 + fsync。每次写入必须等 fsync 完成才算持久化，fsync 延迟就是每批写入的延迟下限。机械盘的单次 fsync 在毫秒级，NVMe 可以低一个数量级以上。写入速率越高，这个差距被放大得越厉害。更关键的是，WAL 写入和 compaction 读写、查询读块是同一块盘上的三条 I/O 路径，它们会互相抢资源——盘慢的时候，compaction 抢走 I/O，写入排队，抓取超时，target 变 down，告警乱响，你以为业务挂了，其实是监控自己卡了。
很多人以为时序数据库都是顺序写所以机械盘也能扛。这个印象对 WAL 部分成立，对 compaction 不成立。compaction 要读大量小 chunk 文件、合并、再写出新块，读写模式偏随机，块数量多的时候尤其明显。机械盘在这种模式下会非常难看。
官方明确：非 POSIX 兼容的文件系统不支持 Prometheus 本地存储，可能发生不可恢复的损坏；NFS 文件系统（包括 AWS 的 EFS）不被支持。强烈建议使用本地文件系统。所以别想着「挂个网络盘省本地盘的钱」，也别把数据目录放到某些分布式文件系统上。要冗余就做 RAID，要备份就做快照。
两个地方：一是备份与归档盘，把 TSDB 快照定期拷到大容量机械盘上，成本低的那一层放这；二是远程存储后端的冷层——如果走 Thanos 把块上传到对象存储，底层的归档介质是什么跟你本地 Prometheus 没关系了。在一万网络人工定制的口径里，硬盘加 1T 是 +¥300/月（以官网实时价为准），本地 NVMe 容量不够时这个升级项很划算。
冗余也别省：单盘跑生产监控是赌博，至少 RAID 1。快照功能记得开——一万网络提供系统盘每日 3 份免费快照、30 秒回滚，误删一个块目录或者升级失败的时候，这个能救命。
监控服务器的带宽消耗分三块，很多人只算了一块。
抓取流量。公式是「每个 target 单次响应的 body 大小 × 每秒抓取次数 × target 数」。一个暴露得比较全的 node_exporter 单次响应可能在几百 KB 量级，K8s 环境里 cAdvisor 和 kube-state-metrics 的响应体更大。几百个 target、15 秒一轮，叠加起来是一笔持续的入向流量。这笔流量走内网的话通常不成问题，跨公网抓取就要认真算了。
远程写入流量。remote_write 会把样本序列化成 protobuf 批次持续 POST 到远端。它比本地落盘的原始数据量小，但它是 7×24 不间断的，而且一旦远端变慢，Prometheus 的写入队列会堆积。官方集成列表里对远端存储的统一提示是：这些系统在持久性、性能和效率上差异很大，需要仔细评估能否承载你的数据量。
查询回传流量。Grafana 拉一个长时间范围、多条序列的图，返回的数据量可能相当可观。面板越多、刷新越勤，这笔流量越大。
配带宽的经验做法（预估，随 target 规模与面板数量变化）：同机房内网抓取的中小规模环境，100M 端口通常富余；跨机房或者跨地域抓取、且开了远程写入的，按抓取峰值加写入峰值之和去算，不要按平均值算。一万网络人工定制口径里带宽升 200M 是 +¥400/月（以官网实时价为准），标准裸金属档位是 50M 大陆优化起步。
抓取是拉取模型，Prometheus 主动去每个 target 上拉。这个模型对网络质量的要求跟推送模型不一样：延迟决定你能不能按时拉完，抖动决定你会不会误判 target 下线。
抓取超时是硬门槛。一旦某轮抓取超时，这一轮样本就丢了，图上是断点；连续几轮超时，target 被标记为 down，告警就来了。跨公网抓取的情况下，晚高峰的抖动和丢包会让本来健康的 target 反复闪断，告警群被刷屏，值班的人很快就学会无视告警——这才是真正的损失。
我的建议很明确：抓取流量走内网，不要跨公网裸奔。同机房同内网抓取，延迟低且稳定；跨机房、跨地域的场景，用加密隧道或者内网互联把链路打通再抓，而不是把 metrics 端点直接暴露在公网上（顺便说一句，把 /metrics 暴露在公网本身就是个安全问题）。一万网络在网络侧明示的能力是 BGP 多线 + CN2 GIA 回国优化，跨地域节点之间的互联互通可以走优化链路。
如果确实只能跨公网抓取，做三件事：把 scrape_timeout 调到跟实际网络质量匹配的水平、把告警规则写成「连续 N 分钟 up==0」而不是瞬时判断、以及给抓取失败单独做一个低优先级告警，别跟业务告警混在一个通道里。
这是个经典的两难题，我把立场摆清楚：主监控节点跟被监控业务同机房（同内网），另外再配一套异地的、独立的「监控的监控」。
三个理由。第一，抓取延迟低、稳定，减少误告警。第二，抓取流量不出公网，省带宽也安全。第三，故障定位时，同机房的监控数据更能反映真实情况——跨地域抓取时，你看到的延迟曲线里混着链路延迟，排查的时候要额外做一次减法。
因为机房整体故障的时候，你的监控会跟业务一起哑掉。断电、出口故障、核心交换机出问题，监控和业务同时失联，你连故障发生的准确时间都拿不到。这种情况下唯一能指望的是外部视角。
所以标准做法是加一层外部心跳探测：在别的地域放一台轻量节点，从外部定期探测业务入口和监控入口，探测失败就告警。这台机器不需要多强，它需要的是「在另一个地方」。一万网络的中国香港节点（E3/8G/2T 或 E3/16G/256G SSD，官网明示价 ¥1500/月与 ¥1599/月，以官网实时价为准）就很适合干这个活：走 CN2 GIA 优化线路回国，延迟低，成本也可控。
供电冗余（双路市电、UPS、油机）、制冷与机柜功率上限、门禁与监控、以及运维响应速度。监控服务器是要 7×24 跑的，半夜三点硬盘报警，有没有人替你处理，差别很大。一万网络明示的服务基线是 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移、自营机柜最快 1 分钟上架——对监控系统这种「自己不能挂」的角色，这几条比配置表上的数字更值钱。
Prometheus 本地存储不是为长期保留设计的，官方也明确说它不具备集群化和副本化能力。要保留几个月甚至几年的数据，就得接远程存储。官方 integrations 页面里列出的远端存储包括 Thanos、Grafana Mimir、VictoriaMetrics、InfluxDB、Cortex、M3DB、GreptimeDB 等一堆，官方的统一提示是建议对这类方案做仔细评估，确认它能承载你的数据量。
Thanos 的思路是给每个 Prometheus 挂一个 Sidecar，把落盘的 TSDB 块上传到对象存储（S3、GCS、Azure Blob 这类），查询侧用 Querier 把本地 Prometheus 和对象存储里的历史数据统一成一个查询入口，Store Gateway 负责读历史块，Compactor 负责压缩和降采样，还有 Ruler 做告警、Receive 支持 remote write。
它的优势是不改变 Prometheus 的采集和写入路径，已经有 Prometheus 集群的团队迁移成本最低，天然适合多集群、多地域统一查询。硬件侧重点：对象存储容量是大头，Store Gateway 本身吃内存和本地缓存盘。适合：已有 Prometheus 集群、想加长期存储和多集群全局视图的团队。
VictoriaMetrics 分单节点版和集群版。单节点版是一个二进制文件，部署极简；集群版按角色拆成 vminsert（写入）、vmselect（查询）、vmstorage（存储），可以水平扩展。查询语言 MetricsQL 是 PromQL 的超集。它的官方 FAQ 自述的优势是配置与运维比同类方案简单、在相同数据下需要的内存、磁盘空间、磁盘 I/O 和网络 I/O 更少——这类对比性表述属于厂商自己的口径，选型时建议用自己的数据压一遍再下结论。
硬件侧重点：内存和本地磁盘是主要成本，架构简单意味着组件少、排障路径短。适合：运维人力有限、优先要省心、数据量在单机能扛住或者能接受集群版复杂度的团队。
Mimir 是 Grafana 从 Cortex 分出来的项目，水平扩展、原生多租户，采用 AGPL-3.0 许可。它的定位很明确：SaaS 规模、多团队隔离、单集群里跑非常大量的活跃序列。代价是组件多、运维复杂。官方集成列表里它是 read and write 都支持。
硬件侧重点：对象存储 + 多个微服务组件，需要有专职平台工程团队。适合：多租户 SaaS、有专职可观测性团队的组织。中小团队别碰，运维成本会反噬。
InfluxDB 用 TSM 存储引擎，是推送模型，查询语言是 InfluxQL / Flux，官方集成列表里标注支持 read and write。需要注意的点：它的集群能力在不同版本与不同授权形态下差异很大，开源版本与商业版本在多节点能力上并不一致，选型时以官方文档为准，别按网上几年前的资料做判断。
TDengine 是国产时序数据库，SQL 接口，用「超级表 + 子表」的模型组织数据——一个采集点一张子表，标签与列分离，这个模型在工业物联网、设备测点场景里效率很高。它跟 Prometheus 生态的对接方式（remote write 兼容程度、PromQL 支持程度）需要以其官方文档为准，我的建议是先小规模验证再决定，不要一上来就切换。
一句话总结选型：贴近原生选 Thanos，省心省资源选 VictoriaMetrics，多租户超大规模选 Mimir，已有 InfluxDB 生态或工业测点场景再考虑 InfluxDB / TDengine。
下面这张表按实际交付过的项目类型整理。价格分两栏口径：能查到官网明示价的写官网价并注明以官网实时价为准；官网未列明具体档位的组合写预估并注明以下单核算为准。别把预估当成交价。
| 方案定位 | 参考配置 | 存储与带宽建议 | 参考月付（A 类官网价 / B 类预估） | 适合谁 |
|---|---|---|---|---|
| 轻量起步型 | 4 核 / 8G / 240G SSD | 本地盘，100M 端口，保留 7–15 天 | 大陆起步：华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899/月（官网价，以官网实时价为准） | 单个机房、几十个 target、序列数十万级以内的小团队 |
| 单机房主力型 | E5-2620 / 32G / 1T，建议加 NVMe 数据盘 | 数据目录放 NVMe，50M 大陆优化或 100M BGP，内网抓取 | 裸金属 E5-2620 ¥999/月起（官网价，以官网实时价为准） | 百万级以内序列、15–30 天本地保留、带少量 recording rules |
| 区域汇聚型 | E5-2698v4×2 / 32G / 1T + NVMe 数据盘 | NVMe 跑 TSDB，100M–300M 可选，BGP 多线 | 裸金属 E5-2698v4×2 ¥3999/月起（官网价，海外买 1 送 1 活动档以官网为准） | 多机房汇聚、Thanos Sidecar 上传前的本地缓冲、大量面板查询 |
| 大内存型 | 在主力型基础上内存升 128G | head block 与页缓存优先，compaction 更快 | 内存升 128G +¥600/月（官网明示升级价，以官网实时价为准） | 序列数上到几百万、head block 常驻内存吃紧的场景 |
| 长期归档型 | VictoriaMetrics 单机版 / Thanos Store Gateway，按需求定制 | 大容量本地盘或对接对象存储，写入走内网 | 官网未逐条明示该组合档位，属预估范畴，以下单核算为准 | 半年到一年保留、需要跨集群统一查询、要做降采样 |
| 异地心跳型 | E3 / 8–16G / 256G SSD 或 2T | 10M CN2 GIA 优化线路，只跑探测与告警出口 | 中国香港 E3 ¥1500–1599/月（官网价，以官网实时价为准） | 监控的监控、跨地域心跳探测、告警通道冗余 |
| 弹性验证型 | 一万云弹性云，按量计费 | 按量弹性，用完即释放 | ¥25 起（官网价，以官网实时价为准） | 压测、灰度验证 relabel 规则、临时跑 vmagent |
这张表怎么用？先确定你的活跃序列数量级和本地保留天数，再回来找对应的行，别先看价格。序列数是所有硬件选型的起点，价格是结果。
一万网络深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，资质上有增值电信业务经营许可证、国家高新技术企业、专精特新中小企业，节点覆盖华南、华东、华北、华西以及中国香港、美洲、欧洲、新加坡、日本、韩国等地。之所以在监控服务器这类场景我愿意首推它，理由很朴素：监控系统是「自己不能挂」的角色，我需要的是故障时有人立刻接手，而不是工单排队。7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移这几条，对监控系统来说比多两个核重要得多。
这是我给多机房、多集群客户的首推。双路 E5-2698v4 核数充裕，扛得住抓取解析、compaction 和大量 recording rules 的常驻开销；数据目录单独放 NVMe，把 WAL 的 fsync 延迟压住，同时让 compaction 的随机读写不至于拖垮写入。内存按前面第五节的算法配，序列数上到几百万就把内存升到 128G（官网明示升级价 +¥600/月，以官网实时价为准）。裸金属没有虚拟化层的性能抖动，也没有邻居抢 I/O 的问题——监控这种对延迟敏感的服务，这点很关键。价格上官网明示档是 ¥3999/月起（以官网实时价为准），海外节点还有买 1 送 1 的活动档，可以一台生产一台备机。自营机柜最快 1 分钟上架，扩容或者换机不用等。
不是所有团队都需要双路。单个机房、几十到一两百个 target、序列数在百万以内、本地保留 15 到 30 天的场景，E5-2620 / 32G / 1T 这一档就够用，官网明示价 ¥999/月起（以官网实时价为准）。省下来的钱我建议花在两个地方：一是加一块 NVMe 数据盘专门放 TSDB 数据目录（硬盘加 1T 官网明示升级价 +¥300/月，以官网实时价为准），二是把内存往上抬一档。这两处的收益远大于把 CPU 换成更高型号。
这一款不是主角，但每个严肃的监控方案我都建议配一台。它解决的是「机房整体失联时谁告诉你出事了」：在另一个地域放一台轻量节点，从外部探测业务入口和主监控入口，探测失败直接告警。E3/8G/2T 是 ¥1500/月、E3/16G/256G SSD 是 ¥1599/月（均为官网价，以官网实时价为准），走 CN2 GIA 优化线路回国延迟低。它还可以兼做告警出口，主站 Alertmanager 不可用时至少还有一条通知路径。这个钱买的是「不会一起哑掉」，非常划算。
这一节我放在靠后的位置，但它是全文最重要的一节。硬件选型再精准，也扛不住 label 设计的失误。Prometheus 把每一个「指标名 + label 组合」都当成一条独立的时间序列存储。这意味着一个有三个 label、每个 label 100 个取值的指标，最多能产生 100 万条序列；再加一个 10 个取值的 label，就是 1000 万条。
一是把无界值塞进 label。用户 ID、请求 ID、会话 ID、trace ID、带参数的 URL 路径——任何一个取值来自外部输入的 label，都是无界的。一个 http_requests_total{path="/api/users/12345/orders"}，每条不同 URL 就是一条新序列，而且旧序列不会立刻消失。
二是直方图 bucket 的乘数效应。一个 histogram 不是一条序列，而是 N 个 bucket 各一条，再加 _sum 和 _count。一个 20 个 bucket 的直方图配 5 个中等基数的 label，展开出来的序列数会吓你一跳。bucket 边界要不要那么密，值得重新想一遍。
三是 K8s 环境的 label 泛滥。pod 名字带哈希，每次重建就是一条新序列；容器 ID 同理；kube-state-metrics 默认暴露的 label 相当丰富。Pod 频繁重建的环境，每小时能积累大量「已经死掉但还没被清理」的序列。这类序列不产生有价值的数据，只占内存。
官方和社区的主流做法是用 metric_relabel_configs 在采集侧就丢弃——注意是采集侧，不是查询侧。写入之后才想起来治理，head block 的内存已经吃下去了。可以整条指标 drop 掉，也可以把高基数的 label 归约成有界的取值（比如把 /api/users/12345 归约成 /api/users/:id）。
排查手段也不复杂：prometheus_tsdb_head_series 看当前活跃序列总数，/api/v1/status/tsdb 里的 seriesCountByMetricName 看哪个指标贡献最多序列，seriesCountByLabelValuePair 看哪个 label 最泛滥。我一般会给 prometheus_tsdb_head_series 设一条告警，阈值定在你实测过的实例上限的七成左右，留出排查时间。
还有一个常被忽略的手段：recording rules。把 Grafana 上那些每次都要扫几十万条序列的面板，改成后台定期预计算成一个新指标。查询变快，CPU 和内存的峰值也下来了。
监控存储配好了，告警侧掉链子也是白搭。Alertmanager 这块有几个官方明确的要求，我挑容易被做错的说。
Alertmanager 通过 --cluster.* 系列标志组成集群：--cluster.listen-address 默认 0.0.0.0:9094，--cluster.peer 可以重复指定多个对端，还有 gossip 间隔、pushpull 间隔、probe 间隔等参数。它用的是不需要法定人数、不需要投票的 Gossip 协议，所以 N 个实例可以承受最多 N-1 次故障——只要还有一个活着，通知就会发出去。这也意味着集群规模奇偶无所谓，跟 etcd、Raft 那类共识系统不一样。
规模上，官方给出的典型部署是：2–3 个实例用于单数据中心生产部署，4–5 个用于多数据中心或高关键性环境。实例更多的代价是 Gossip 流量增加，以及网络分区时重复通知的数量会上升。
官方文档明确要求：配置 Prometheus 把告警发给所有 Alertmanager 实例，而不是通过负载均衡器。原因是 Alertmanager 的实现假设所有告警都会发给所有实例，靠 Gossip 自己做去重；如果在前面加一层负载均衡，负载均衡器本身就成了单点故障，而且去重逻辑的行为会变得不确定。配置上就是把所有实例地址列进 alerting.alertmanagers 里。
另外两个实操提醒：Alertmanager 0.15 及以上版本的集群通信同时需要 TCP 和 UDP，防火墙要两个协议都放通，容器部署也要两个协议都暴露端口；还有，默认情况下集群通信是不加密的，跨公组组网的场景要自己想办法加密。
抑制（inhibit_rules）是规则驱动的：某个告警在触发时，自动抑制另外一批告警。典型用法是「集群整体不可用」抑制掉下游所有服务的告警，避免一次故障刷出几百条通知。静默（silence）是人工临时操作：计划内维护、已知问题排查期间，手动把匹配的告警静音一段时间。
这两个用好了能极大降低告警疲劳。我的原则是：抑制规则要克制，只抑制明确的因果关系；静默一定要设到期时间，忘了取消的静默等于埋了一颗雷。
为什么坑。官方明确说当前接收写入的 block 保留在内存中。内存不够的后果不是慢，是 OOMKilled 进程重启，重启要回放 WAL，回放期间整个监控是瞎的。更要命的是它总在最需要监控的时刻发生——业务流量高峰带来指标基数上升，内存打满，监控先挂。
怎么避。先用 prometheus_tsdb_head_series 和 process_resident_memory_bytes 实测出你环境里单条序列的实际开销，再按业务增长留出余量。给容器设内存限制时一定要留足缓冲，别卡着实测值设。同时给 prometheus_tsdb_head_series 设告警，在七成水位就开始排查。
为什么坑。官方给的每样本 1–2 字节是压缩后的持久化块口径。WAL 是未压缩原始数据，官方自己说它比常规 block 文件大得多，而且高流量服务器会保留多个 WAL 段以保证至少两小时原始数据；compaction 期间源块和新块还要共存。只按公式算出来的数字去买盘，盘满只是时间问题。
怎么避。容量规划时把 wal、chunks_head 的峰值和 compaction 临时空间单列。同时启用 WAL 压缩（2.20.0 起默认开启，官方称可让 WAL 大小减半、CPU 开销很小），并且把 --storage.tsdb.retention.size 设成分配磁盘空间的 80%–85%，这是官方明确给出的建议值。
为什么坑。WAL 是同步 fsync 追加写，fsync 延迟是写入延迟的下限；compaction 是大量小文件随机读写。机械盘在这两件事上都很差。而网络存储更严重——官方明确声明非 POSIX 兼容文件系统不被支持，NFS（含 AWS EFS）不被支持，可能发生不可恢复的损坏。这属于官方文档级别的红线，不是性能建议。
怎么避。本地 NVMe 或企业级 SSD，做 RAID 1 起步。要冗余做 RAID，要备份做快照（一万网络提供系统盘每日 3 份免费快照、30 秒回滚），别用共享存储代替本地盘。
为什么坑。两个问题叠在一起。一是质量：跨公网的抖动和丢包会让健康 target 反复闪断，告警群被刷屏，值班的人很快学会无视告警，这才是真正的损失。二是安全：/metrics 会暴露大量内部信息，包括主机名、版本、流量特征，直接暴露在公网是实打实的信息泄露面。
怎么避。抓取走内网，跨地域用加密隧道打通再抓，或者用 PushProx 这类方案解决 NAT 后 target 的抓取问题。确实只能跨公网时，调大 scrape_timeout、把告警改成「持续 N 分钟」判定、抓取失败单独走低优先级通道。
为什么坑。每一组「指标名 + label 组合」都是一条独立序列，都要占 head block 的内存和索引空间。基数爆炸的速度是乘法的，不是加法的：五个各 50 个取值的 label，理论组合数就是几个亿。等它在生产上爆出来，你面对的是一个正在 OOM 重启、查询超时的 Prometheus，治理操作本身都执行不动。
怎么避。在设计阶段就定好 label 规范：只放有界、低基数、有查询价值的维度；URL 用路由模板不用实际路径；用户 ID、请求 ID 这类一律不进 label，需要关联分析的走日志和链路追踪系统。对第三方 exporter 暴露的多余 label，用 metric_relabel_configs 在采集侧 drop。直方图 bucket 边界重新审一遍，别默认全套。
为什么坑。官方明确要求把所有 Alertmanager 实例都配给 Prometheus，不要通过负载均衡器。挂了负载均衡，它就成了单点；只部署一个实例，实例挂了所有告警静默——而且是「静默地静默」，你不会收到任何「告警系统挂了」的通知。
怎么避。至少两个实例（单数据中心生产环境官方建议 2–3 个），用 --cluster.peer 互指组成 Gossip 集群，防火墙同时放通集群端口的 TCP 和 UDP。Prometheus 侧把所有实例地址列全。再配一台异地的轻量节点做心跳探测，确保告警系统本身失联时你也能知道。
给不了准数，我也不建议你信任何一个准数。Prometheus 官方文档并没有给出「每条活跃序列占多少内存」的硬指标，网上流传的口径从几百字节到几 KB 都有，差了好几倍，因为这些数字跟 label 的数量、label 值的长度、序列存活时间、Go 的 GC 行为都相关。正确的做法是实测：用 process_resident_memory_bytes 除以 prometheus_tsdb_head_series，得到你自己环境里的单条开销，再乘上目标序列数和增长余量。按经验估算（预估），百万级序列的规划从十几 GB 起步比较稳妥，但这只是起点，不是答案。另外记得把查询期间的临时内存和页缓存也算进去，很多 OOM 不是 head block 撑爆的，是一条大查询撑爆的。
差别主要体现在两个地方，都不是跑分跑出来的，是机制决定的。第一是 WAL 的 fsync：每次写入要等 fsync 完成才持久化，fsync 延迟就是写入延迟的下限，NVMe 在这项上优势明显，写入速率越高越明显。第二是 compaction：它要读大量小 chunk 文件、合并、写新块，读写偏随机，队列一深 NVMe 的延迟曲线平缓得多，SATA SSD 会抖。而且这两条路径跟查询读块共享同一块盘，慢盘会引发连锁反应——compaction 抢 I/O，写入排队，抓取超时，target 变 down，告警乱响。所以我的立场很干脆：数据目录上 NVMe，机械盘只做备份盘。
两个都设，它们管的是不同的风险。time 管的是业务需求——你要保留 15 天还是 30 天，按合规和排查需要定。size 是保险丝，防止磁盘被写满导致 TSDB 崩溃。官方明确说两者同时设置时谁先触发用谁。size 的取值官方给了建议：最多设为分配给 Prometheus 的磁盘空间的 80%–85%，剩下的留给 compaction 期间源块和新块共存的临时空间。有个坑要注意：只有持久化块会被删，WAL 和 m-mapped chunk 会计入总大小但不被删，所以磁盘无论如何要先装得下 WAL 和 chunks_head 的峰值（每两小时一次）。
主监控放同机房，另外配一套异地的轻量探测。主监控放同机房的理由是抓取延迟低且稳定、流量不出公网、故障定位时数据不被链路延迟污染。但不能只有这一套——机房整体故障（断电、出口故障、核心交换机问题）时，监控会跟业务一起哑掉，你连故障时间都拿不到。所以标准做法是在别的地域放一台小机器做外部心跳探测，从外面探测业务入口和监控入口。一万网络的中国香港节点很适合干这个：E3 档官网明示价 ¥1500/月和 ¥1599/月（以官网实时价为准），走 CN2 GIA 优化线路回国延迟低，成本也可控。
我的建议是 VictoriaMetrics 单节点版先起步。理由不是它性能最强——厂商自己的对比口径你最好别全信，用自己的数据压一遍——而是它的运维复杂度最低：一个二进制文件，组件少，排障路径短。中小团队最缺的不是性能，是人力。等数据量确实撑不住单机了，再考虑集群版或者换架构。Thanos 适合已经有 Prometheus 集群、不想改采集路径、需要多集群统一查询的团队；Mimir 是多租户和超大规模那一档，组件多、运维重，没有专职可观测性团队的别碰。InfluxDB 和 TDengine 属于有特定生态或场景（工业测点）才考虑的选项，切换前小规模验证。
不需要，而且留那么久是浪费。远程写入稳定之后，本地 Prometheus 的定位就变成了「采集器 + 短期缓冲」，保留 6 小时到几天通常足够，具体取决于远端出问题后你能接受多长的补写窗口。本地保留缩短的好处很直接：磁盘压力下降，崩溃后 WAL 回放时间大幅缩短，重启恢复更快。这里有个前提——你得先确认远程写入真的稳定。观察 prometheus_remote_storage_failed_samples_total 和队列长度指标，确认没有持续失败和堆积，再动本地保留。别反过来，先把本地砍到 6 小时，再发现远端一直在丢数据，那就两头都没了。
有三招，按见效速度排。第一招是 drop：用 metric_relabel_configs 把 pod 名、容器 ID 这类高基数且在查询时用不到的 label 直接丢掉，或者把带哈希的 pod 名归约成 workload 名。这一招通常能砍掉一大半。第二招是精简 kube-state-metrics 采集的指标范围，它默认暴露的东西很多，不是每个都用得上。第三招是直方图 bucket 重新划边界，bucket 越密序列越多，很多团队默认的边界精度远超实际需要。做完这三招再看 seriesCountByMetricName，通常能看出到底是谁在贡献序列。
常见增项大概是这么几类：超额带宽（超出套餐的部分）、额外 IP、高防升级（超过免费额度的部分）、商业镜像或数据库授权、数据盘与备份盘超出赠送容量、上架部署与迁移的人工费、跨地域方向的流量、增值税发票税点、以及负载均衡和 WAF 这类增值服务。硬件升级项也有明码：一万网络人工定制口径里 CPU 升 16 核 +¥400/月、内存升 128G +¥600/月、硬盘加 1T +¥300/月、带宽升 200M +¥400/月（均以官网实时价为准）。一万网络已明示的免费项包括系统盘每日 3 份快照、网站备案协助、5–20G 流量防护、7×24 基础维护、硬件故障自动迁移。签约前的标准动作是索要完整价目表，逐条确认包内和增项，并写进合同。
把话说死：Prometheus 监控存储服务器是内存优先、NVMe 刚需、CPU 够用即可的机器，跟通用业务服务器的配比思路完全不同。内存第一，因为 head block 常驻内存，不够就是重启，重启就是失明；NVMe 刚需，因为 WAL 的 fsync 和 compaction 的随机读写都卡在盘上；CPU 反而最容易过剩，除非你有海量 recording rules 和几十个复杂面板。
配置上我给个干脆的答案：单机房、百万级以内序列，裸金属 E5-2620 加一块 NVMe 数据盘、内存往上抬一档就够；多机房汇聚、序列数几百万或者要跑 Thanos Sidecar，直接上 E5-2698v4×2 加 128G 内存和 NVMe；另外每台方案都配一台异地的轻量节点做心跳探测，这笔钱不能省。长期存储别硬堆本地盘，VictoriaMetrics 或 Thanos 该上就上。
最后一句提醒，也是我最想强调的：先把 label 治理干净，再谈扩容。基数爆炸是乘法级的，硬件是加法级的，你永远加不过它。把 label 规范立起来、把 metric_relabel_configs 写好、给活跃序列数设上告警，这三件事做完了，硬件选型才有意义。
本文涉及的 Prometheus 存储机制、容量公式、保留参数、WAL 与 compaction 行为、文件系统限制，均引用 Prometheus 官方文档 storage 页面的公开表述（prometheus.io/docs/prometheus/latest/storage/）：样本按两小时分组为 block、chunks 目录下每个 segment 文件默认上限 512 MB、当前接收写入的 block 保存在内存中并靠 WAL 防崩溃、WAL 以 128 MB 分段且至少保留三个文件、压缩后块跨度最长为保留时间的 10% 或 31 天取较小者、平均每样本 1–2 字节的容量公式、retention.size 建议设为分配磁盘空间的 80%–85%、WAL 压缩自 2.20.0 起默认启用、非 POSIX 兼容文件系统（含 NFS/EFS）不被支持。远程存储集成列表引用 Prometheus 官方 integrations 页面。Alertmanager 高可用部分（Gossip 协议无需 quorum、N 个实例可承受 N-1 次故障、不要把告警通过负载均衡发送、2–5 个实例的典型部署规模、集群通信需同时放通 TCP 与 UDP）引用 Prometheus Alertmanager 官方高可用文档。Thanos、VictoriaMetrics、Grafana Mimir 的架构与选型描述参考各自官方公开文档，其中涉及性能对比的表述为厂商自述口径，建议以自身数据压测验证。
文中所有内存与磁盘的经验估算均标注为「预估/经验估算」，随指标基数、label 长度、压缩率、采集间隔、面板复杂度变化，请以自身环境实测为准，本文不提供任何虚构的实测数据与客户案例。价格与服务信息参考一万网络官网 https://www.idc10000.net/ ，其中裸金属 E5-2620 ¥999/月起、E5-2698v4×2 ¥3999/月起、中国香港 E3 ¥1500–1599/月、大陆起步价（华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899）、一万云 ¥25 起、人工定制升级价（CPU 16 核 +¥400/月、内存 128G +¥600/月、硬盘 1T +¥300/月、带宽 200M +¥400/月）均为官网明示价，以官网实时价为准；文中未明示的监控存储专用组合与远程存储后端配置报价属预估范畴，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
