2026 日志检索平台 Elasticsearch 服务器租用：分片规划/冷热分层/磁盘 IO 实测对比 + 避坑避雷全攻略

2026 日志检索平台 Elasticsearch 服务器租用：分片规划/冷热分层/磁盘 IO 实测对比 + 避坑避雷全攻略

干可观测性的人，迟早会撞上同一堵墙：日志平台上线前三个月风平浪静，第四个月开始，磁盘一周涨满一次，查询从 200 毫秒变成 8 秒，Kibana 打开仪表盘要转三圈。然后大家开始吵——是加机器呢，还是减分片呢？

这篇文章就是给这个阶段写的。不讲概念科普，只讲你下单租服务器之前必须想明白的那几件事：磁盘到底会被吃掉多少、分片到底该开几个、热数据冷数据怎么分层放、以及什么规模下必须拆成独立节点而不是全塞在一台机器里。先把几条结论摆在前面：

1. 日志场景的磁盘消耗从来不是原始日志大小，是原始大小 × 写放大系数 × 副本系数。一份 1KB 的业务日志落进 Elasticsearch 之后，加上索引结构、_source、doc values、副本，实际占用翻好几倍是常态，别拿原始日志体积去算硬盘。

2. 堆内存不是越大越好。社区里流传的「30–31GB」这条线，本质是压缩指针的边界，不是什么官方硬性规定。堆开太大，分给你的文件系统缓存就少了，Lucene 反而变慢。

3. 分片大小按几十 GB 量级去规划，别按天数去规划。很多人按「一天一个分片」拍脑袋，结果一天只有 2GB，分了几百个分片，堆内存全被元信息吃掉。

4. 冷热分层的收益，主要来自把冷数据挪到便宜盘上，而不是来自性能提升。指望分层让查询变快，方向就错了。

5. 副本不是备份。副本是高可用，是给查询并发用的，误删一条 delete by query，副本会同步跟着删。

算错一步，硬盘就买小了：日志量的正确估算方法

先说最容易翻车的地方——估算。绝大多数团队第一次租机器，都是拿「我们一天大概产生 50GB 日志」这句话去问服务商要多大盘。这个数字是原始文本体积，是 Filebeat 从日志文件里读出来的字节数，跟 Elasticsearch 实际落到磁盘上的东西完全是两码事。

比较靠谱的算法是分三步走。第一步算原始量：日均值 × 保留天数，注意要按峰值日算，别按平均值算，大促、发版、故障当天日志量翻倍是很常见的。第二步乘写放大系数：日志进到 Lucene 里，要存 _source 原文、倒排索引、doc values（聚合和排序要用）、以及段的各种元数据，通常量级在原始体积的 1.5 到 4 倍之间，字段多、嵌套深、开了全部字段 doc values 的会更高。第三步乘副本系数：number_of_replicas 设 1，就是 (1+1)=2 倍；设 2 就是 3 倍。

写成公式就是：所需磁盘 ≈ 每天原始 GB × 保留天数 × 写放大系数 × (1 + 副本数)。再往上加两成余量，给段合并的临时空间和 force merge 的临时占用留位置。举例：每天 50GB 原始日志，保留 30 天，写放大按 2.5 算，副本 1 份，那么 50 × 30 × 2.5 × 2 = 7500GB，也就是 7.5TB 左右，加两成余量，热节点盘就得奔着 9TB 可用容量去准备。

看到这个数字很多人会倒吸一口气。这就是为什么日志平台一定要做冷热分层——如果不分层，这 9TB 全得放在 NVMe 上，成本直接起飞。

一条日志进门之后发生了什么：写入放大到底从哪来

理解写放大，得先知道数据是怎么落下去的。采集器（Filebeat、Fluent Bit、Vector 这些）把日志攒成一个 bulk 请求发过来，节点收到之后先在内存 buffer 里攒着，同时往 translog 里追加一条记录（这是保证不丢数据的关键）。buffer 满了或者到了 refresh_interval，就刷成一个新的段（segment）落到文件系统缓存里，这时候数据就可查了。段越攒越多，后台线程会把小段往一起合并，这就是段合并（segment merge）。

写放大的几个来源就清楚了：一是 _source 原文和索引结构并存，同一份数据以不同形式存了两遍以上；二是 refresh 频率高的时候段特别碎，段合并线程就得反复重写同样的数据；三是 force merge 的时候会把整个索引重写一遍，磁盘瞬间吃掉接近一倍的空间；四是副本，主分片写多少，副本就得跟着写多少，网络流量和磁盘写入都是翻倍关系。

所以你看到的「磁盘 IO 高」，很多时候不是业务查询打出来的，是后台那几个合并线程在闷头干活。用 iostat 看的时候，会发现写入 IOPS 长时间维持在较高水位，而业务侧并没有明显的写入尖峰——这就是段合并的典型特征。

硬件六维之一：CPU，分词和聚合各吃多少核

Elasticsearch 这台机器上，CPU 主要被三件事吃掉：写入时的分词和分析（analysis）、后台的段合并、查询时的聚合计算。这三件事的负载曲线完全不一样，配 CPU 的时候得分开想。

写入侧：分词是纯 CPU 活

一条日志进来，如果字段是 text 类型且没关掉索引，就要走分词器。中文场景如果用 IK 这类分词器，开销比英文 standard 分词器明显更高。字段越多、mapping 越复杂，单条文档的解析成本越高。经验区间是：写入密集型节点，每核大概能扛住每秒几千到上万条文档的写入量（取决于单条日志的大小和字段数），日志这种小文档、字段多的，瓶颈通常先出现在 CPU 而不是磁盘。

段合并线程也吃 CPU，但它默认是限速的（index.merge.scheduler.max_thread_count 和限流参数），一般不建议往上调，调高了反而会跟业务写入抢资源。

查询侧：聚合是并发杀手

日志场景最典型的查询是「按某个字段 group by，再算个百分比」，这类聚合查询会在多个分片上并行算，然后在协调节点汇总。并发一上来，CPU 核数直接决定吞吐上限。一个常见的现象：单次查询很快，但 Kibana 上同时开十几个仪表盘就卡住了——这就是聚合并发把 CPU 打满了。

到底多少核够用

给个能落地的参考区间：单节点跑纯写入 + 轻查询，每天几十 GB 量级，16 核基本够；如果有稳定的仪表盘并发查询，24 到 32 核会更从容；一旦上了复杂的聚合分析、或者打算在同一个节点上再跑 Logstash 这种重解析的组件，建议直接往 32 核以上走。核心数比主频更重要——Elasticsearch 是典型的并发型负载，堆线程比堆单核性能划算。但单路 CPU 核数再多也别指望一路吃天下，双路的内存通道和 PCI 通道数都不一样，磁盘多的机器尤其明显。

硬件六维之二：内存，堆内存和文件系统缓存的五五开

这是日志平台配置里最容易被搞错的一维。很多人看到 128GB 内存的机器，第一反应是「那堆内存给 64GB 好了，一半嘛」。这个做法恰恰是最常见的坑。

30–31GB 这条线是怎么回事

JVM 里有个东西叫压缩指针（compressed ordinary object pointers，行业里常缩写成 compressed oops）。简单说，堆内存小于某个阈值的时候，JVM 可以用 4 字节而不是 8 字节来表示对象引用，同样的堆能装下更多对象，访问也更快。这个阈值大约在 32GB 附近，对应的可用堆上限就是社区常说的 30–31GB。超过这条线，指针退回到 8 字节，堆的「有效容量」反而会掉一截，性能不升反降。

说清楚：这是社区长期实践总结出来的经验线，不同 JDK 版本、不同垃圾回收器下的具体表现会有差异，具体阈值以你所用的 JDK 版本官方文档为准。不是谁规定的硬性指标，但它确实是个非常好用的起点。

剩下的一半内存给谁

给操作系统的文件系统缓存（page cache）。Lucene 的段文件是靠 mmap 读的，查询命中不命中缓存，性能差距是数量级的。堆内存开太大，操作系统能拿来缓存段文件的内存就少了，每次查询都得真的去读盘，SSD 上可能还能忍，HDD 上就直接不可用了。

所以实操上是这么配的：64GB 的机器，堆给 30GB 左右，剩三十几 GB 给 page cache；128GB 的机器，单个实例堆还是 30GB 左右，剩下的全给缓存，想压榨更多资源就在一台机器上跑两个实例（各 30GB 堆），但要注意把两个实例的数据盘分开，避免 IO 打架。

还有一条：堆内存别超过物理内存的一半，这是硬建议。超过之后，剩下的内存不够缓存索引文件，集群会进入一种「GC 不频繁但查询奇慢」的诡异状态，很难排查。

硬件六维之三：硬盘，NVMe、SATA SSD、HDD 怎么三分天下

硬盘是日志平台里最花钱、也最影响体感的一维。热温冷三层，对应三种盘，这个思路在 2026 年已经没什么争议了。

段合并带来的写放大是隐藏杀手

前面说过段合并会反复重写数据。落到硬盘上，意味着你的 SSD 实际写入量远大于业务数据量。挑盘的时候要看 DWPD（每天整盘写入次数）和 TBW 总写入量，企业级固态通常标 1 DWPD 或 3 DWPD，日志这种持续写入的场景，建议往高 DWPD 的型号上靠。消费级固态放这里，寿命会非常难看。

另外一个常被忽略的点：段合并期间磁盘需要有空闲空间。如果磁盘使用率长期在 85% 以上，合并会变得很挣扎，写入延迟跟着飙。所以规划容量的时候，别把盘算得刚刚好，留两成是底线。

三层盘怎么配

热节点用 NVMe。最近几天的数据，写入全在这里，查询也最频繁，随机读写 IOPS 是硬需求。NVMe 的队列深度和多并发能力在这儿能真正发挥出来。容量上不需要特别大，够放 3 到 7 天热数据就行。

温节点用 SATA SSD。放一周到一个月的数据，不再写入但偶尔查。SATA SSD 的顺序和随机读都够用，成本比 NVMe 低一截，容量可以做得更大。这是性价比最高的一层。

冷节点用大容量 HDD，或者直接走对象存储。放合规留存三个月以上的数据，几乎不查，偶尔审计捞一次。HDD 的随机读很弱，但冷数据查询本来就不要求秒级响应。如果连查询都基本不做，只为了满足审计留存，用可搜索快照（searchable snapshot）把数据放到对象存储里是最省钱的方案，本地只留一份缓存。

冗余方面，热温节点建议 RAID1 或 RAID10，冷节点可以用 RAID6 换取更高的可用容量比。别为了容量把热节点做成单盘——热节点挂一块盘，正在写入的那批数据就麻烦了。

硬件六维之四：带宽，采集入流和跨机房复制是两笔账

带宽这块要算两笔完全不同的账。第一笔是采集端到集群的入流。业务机器上的 Filebeat 把日志发过来，流量等于原始日志体积（如果采集端开了压缩，会小一些）。这笔账不难算：每天 50GB 原始日志，摊到 86400 秒是 0.6MB/s 左右，但日志有高峰，通常按峰值的 3 到 5 倍去留余量，也就是 2 到 3MB/s 起。听起来不大，但如果你的业务机器分散在全国、走公网回传，就需要一条稳定的上行。

第二笔是集群内部的复制流量。主分片写完后要把数据推给副本分片，这部分流量等于写入量 × 副本数。如果副本跨机房、跨可用区部署，这笔流量就是实打实的跨域带宽，而且对延迟敏感——副本同步慢了，主分片的 translog 积压，写入延迟就上去了。

还有一笔是恢复流量。节点宕机、分片重新分配、或者加新节点做数据均衡的时候，集群会在短时间内搬运大量数据，这个量级往往是平时写入量的好几倍。如果带宽卡得太死，一次节点故障后的自愈可能要跑几个小时，期间集群一直处于黄状态。

硬件六维之五：线路，采集器走公网还是内网，差别有多大

这个问题看起来小，实际是很多写入抖动问题的根因。采集器到集群这段链路，走公网和走内网完全是两种体验。

走公网的好处是部署简单，业务机器在哪个机房、甚至在本地办公室都能往回传。坏处是链路质量不可控：延迟抖动、丢包重传、运营商割接，任何一样都会让 bulk 请求变慢。而 bulk 请求变慢的直接后果，是写入线程池队列堆满，节点开始返回 429（too_many_requests 或 es_rejected_execution），采集端进入退避重试，然后队列更满——典型的雪崩前兆。

走内网就好得多，延迟稳定在毫秒级，带宽也便宜。但前提是采集端和集群在同一个机房或者同一个内网里。业务机器分散在多个机房的时候，折中做法是在每个机房放一个轻量汇聚层（比如一组 Logstash 或者 Fluentd 聚合节点），由汇聚层批量往中心集群推，把公网上的请求数降下来。

如果业务覆盖华南、华东、华北多地，或者涉及中国香港、中国澳门、中国台湾等节点的日志回传，选线路的时候要重点看 BGP 多线和回国方向的优化线路。像 CN2 GIA 这类回国优化线路，在跨境回传场景下的稳定度通常优于普通国际带宽，具体延迟表现以实际路由和所在地区为准，建议下单前先要测试 IP 实测。

一句话建议：能给采集器开内网就别走公网，能批量推就别一条条推。

硬件六维之六：机房，电力、磁盘密度和冗余这些容易被忽略的事

日志平台的机器有个特点：磁盘特别多。一台 2U 机器塞 12 块甚至 24 块盘是常态，这就牵出两个在下单时才想起来、往往已经晚了的问题。

电力。机柜不是按机器数量算钱的，很多时候是按电流或者按功率算的。常见的机柜规格有 10A、13A、16A 这几档，对应功率大致在 2.2kW 到 3.5kW 这个量级（具体以机房实际规格为准）。一台插满盘的双路机器，满载功耗几百瓦是有的，一个柜子里塞几台，电力很快就到顶。下单前一定要问清楚单柜的电力配额，别到时候机器买好了上不了架。

磁盘密度和散热。高密度盘位意味着高密度发热，机房的散热能力、风道设计直接决定硬盘寿命。硬盘是日志平台里故障率最高的部件，温度高一块，故障率就上一个台阶。选机房的时候问一句硬盘的常规更换周期和备件库存，比问带宽有意义得多。

冗余。双电源是底线，最好两路来自不同的 PDU。网络方面看有没有双上联。磁盘层面，RAID 之外还要考虑跨机柜的分布——如果一个集群的所有节点都在同一个柜子里，柜子掉电就等于集群全挂。规模到了三五个节点以上，问一下能不能跨柜部署，这个投入很值。

分片规划：大小、数量、副本的三角关系

分片规划是日志平台里最需要动脑子的部分，也是最容易被拍脑袋的部分。三个变量互相牵制，动一个就得重新算另外两个。

分片大小的经验区间

单个分片多大合适？社区里比较公认的经验区间是几 GB 到几十 GB。日志类场景（时序写入、查询模式相对固定）通常可以往上限靠，30GB 到 50GB 是常见的舒适区；搜索类场景因为要考虑召回率和单分片查询延迟，一般往 20GB 到 40GB 靠。

分片太小会怎样？分片的元信息（segment metadata、field data、集群状态里的分片条目）都要占堆内存，几百个小分片能把堆吃掉一大截，而且集群状态变大之后，master 节点的压力会明显上升。分片太大呢？段合并的代价变高，单次合并要搬运的数据量变大，节点故障后分片恢复的时间也会变长——一个 100GB 的分片重新分配，恢复时间可能以小时计。

分片数和节点数的比例

一个常用的经验参考是：每 GB 堆内存支撑的分片数控制在 20 个以内。按堆 30GB 算，单节点 600 个分片是理论上限附近，实际生产里建议明显低于这个值，给故障恢复和扩容留余量。日志场景结合上面 30–50GB 的分片大小，反推一下就清楚了：一个堆 30GB、盘 4TB 的节点，分片数大概在几十个这个量级，而不是几百个。

同时要考虑分片在节点间的均衡。节点数是 3，分片总数最好是 3 的倍数（含副本），否则会出现有的节点分片多、有的少，热点随之而来。

副本的磁盘翻倍效应

number_of_replicas=1，磁盘占用就是 2 倍；=2，就是 3 倍。这是线性关系，没有任何折扣。很多人上线时图省事设成 2，硬盘预算直接爆掉，回头才发现冷数据根本不需要这么多副本。

合理的做法是：热层副本 1（保证节点故障时数据不丢、查询不中断），冷层副本 0（靠快照兜底）。冷数据几乎不查，副本带来的查询并发收益约等于零，但磁盘成本是实打实的一倍。这个取舍在 ILM 里可以自动完成。

refresh_interval 和 translog：写入吞吐和数据安全的取舍

这两个参数决定了「写入有多快」和「最多丢多少数据」之间的平衡。

refresh_interval 默认是 1 秒，意思是每秒生成一个新段。日志场景其实完全不需要这么实时——你查日志的时候，晚 30 秒看到和晚 1 秒看到，体感上没区别。把 refresh_interval 调到 30s 甚至 60s，段的数量会大幅减少，段合并的压力随之下降，写入吞吐能明显上一个台阶，磁盘写放大也跟着变小。这是日志平台性价比最高的一次调参，改一个数字就能省下不少 IO。

translog 是另一头。它保证的是：数据进了内存 buffer 但还没刷成段的时候宕机了，重启后能从 translog 恢复。默认是每次请求都同步落盘（request 模式），最安全但最慢。改成异步（async 模式，配合 sync_interval）能提升写入吞吐，代价是宕机时可能丢掉最近几秒的数据。日志场景一般可以接受这个代价——日志丢几秒和日志平台写入慢三倍，前者通常更容易接受。但如果是审计类、合规类日志，那还是老老实实用 request 模式。

还有一个常一起调的是写入线程池和 bulk 队列大小。队列开太大不是好事，它只会让请求在队列里慢慢等死，不如早点返回 429 让采集端退避重试，反而更健康。

ILM 和冷热分层：把正确的盘用在正确的数据上

索引生命周期管理（ILM，OpenSearch 里叫 ISM）是冷热分层能不能落地的关键。它的逻辑不复杂：定义一个策略，规定索引在什么条件下从热层挪到温层、再到冷层，最后删除或者做快照。

触发条件一般用两种：索引年龄（比如 7 天后转温、30 天后转冷、90 天后删除）和索引大小（比如主分片超过 50GB 就 rollover 生成新索引）。日志场景推荐用 rollover + 年龄组合，这样分片大小可控，不会因为某天日志暴涨就产生一个畸形的大索引。

分层怎么落地？靠节点角色（node role）。把节点标记成 data_hot / data_warm / data_cold（老版本里是用自定义属性 box_type 来做），然后在 ILM 策略里用 allocate 动作修改索引的路由分配要求，索引就会自动被搬迁到对应层级的节点上。这一步不需要人工干预，配好就完事。

落到硬件上就是三种配置的三类机器：热节点少而快（NVMe + 大内存 + 多核），温节点中而稳（SATA SSD + 中等内存），冷节点大而慢（HDD 大容量 + 小内存）。三类的配比，按保留周期来定——保留 90 天、热 7 天、温 23 天、冷 60 天的话，冷层的容量占比显然是最高的，但单位成本最低。

这里给个立场明确的建议：如果每天日志量不到 20GB，别搞冷热分层，一台 NVMe 机器扛下来更省事。分层带来的运维复杂度（ILM 策略调试、节点角色管理、搬迁过程中的监控）不是小团队吃得消的。分层是给每天 100GB 以上、且保留周期长的场景准备的。

force merge：用之前先想清楚代价

force merge 是把索引的多个段强行合并成少数几个（通常合并到 1 个），好处是查询变快、磁盘占用略降。听起来很美，实操里它是个危险操作。

代价有三条。第一，它是 CPU 和 IO 双密集的操作，一个几十 GB 的索引做 force merge，磁盘可能长时间打满，同节点上的其他索引写入会被拖垮。第二，合并过程中需要额外的临时磁盘空间，最坏情况接近索引本身大小，磁盘快满的时候做 force merge 是自杀行为。第三，合并完之后这些段就固定了，如果之后还要往这个索引里写数据，新的写入又会产生新段，白忙一场。

所以规矩很明确：只对不再写入的索引做，只在业务低峰做，做之前确认磁盘剩余空间充足。通常放在 ILM 的温层动作里自动执行——索引转温意味着它不再写入了，这时候 force merge 正合适。热层上永远不要手动 force merge。

五档配置对比：从 PoC 到分层集群该怎么选

下面这张表按日志量级把配置分成五档。价格这一列分两类：官网明示的档位直接标了官网价，配「以官网实时价为准」；没有官网明示价的档位一律按市场估算给出区间，并标注「预估，以下单核算为准」，不要当成实际报价。

这张表怎么看？我的建议是从第二档起步，不要从第一档起步。第一档的问题不是性能不够，是它没有留出升级空间——等你日志量涨上来，这台机器就彻底浪费了。而第二档在日志量翻倍的时候，还能靠加盘、加内存撑一阵子。也别一上来就上第五档，三节点集群的运维复杂度比单节点高一大截，团队还没摸清自己的日志特征就搞集群，属于给自己找活干。

什么规模下必须拆独立节点：别再往一台机器里塞了

单节点能不能扛住所有角色（master + data + ingest）？小规模完全可以，但有几个明确的信号，一旦出现就该拆了。

信号一：堆内存持续在高位，GC 时间变长。单节点既要做协调又要做存储，堆里既装着查询的中间结果又装着分片的元信息，日志量一涨就互相挤压。看到 GC 时间占比明显上升，就该把 ingest 层拆出去。

信号二：写入延迟和查询延迟开始互相影响。大批量写入的时候查询变慢，或者开仪表盘的时候写入被 429 拒绝——这是典型的资源争抢。拆出独立的 ingest 节点（负责接收和预处理）之后，数据节点的资源就能专注给存储和查询。

信号三：节点数到了 3 个以上。三个节点还都带 master 角色是可以的，但要注意 master 选举需要法定人数，3 个节点允许挂 1 个，4 个节点也只允许挂 1 个（因为需要 3 票），所以 master 候选节点数最好是奇数。规模再往上，把专用 master 节点拆出来是标准做法，它只管集群状态，配置可以很轻。

信号四：出现长时间的恢复窗口。节点宕机后分片重新分配跑了好几小时，期间集群一直是黄的。这说明单节点承载的分片数太多，恢复时搬运的数据量太大。要么拆节点，要么把分片调大、分片总数调小。

说了这么多，给个干脆的判断标准：每天 100GB 以下、查询并发不超过十个人，单节点（或者一主一从两台）足够；超过这个量，或者日志平台已经被当作排障的关键路径，就老老实实拆成独立角色。

一万网络推荐配置：两台值得先聊聊的机器

聊了这么多硬件参数，落到下单层面，我一般给做日志平台的客户首推这两档，理由都挺实在。

#1 一万网络「裸金属 E5-2698v4×2」——单节点起步首选

这台是我推得最多的一档。双路 E5-2698v4 核数足够，分词和聚合都扛得住；内存配到 128G，堆给 30G 左右之后还剩一大截给文件系统缓存，正是日志平台的理想结构。磁盘让它配 NVMe 做热层 + 大容量 HDD 做冷层，一上来就具备分层的硬件基础，后面想开 ILM 直接就能开，不用换机器。官网明示价 ¥3999/月，以官网实时价为准。

更关键的是服务层面。深圳南山自营机柜，硬件出问题走 7×24 中文工单，平均 5 分钟响应，硬件故障 10 分钟自动迁移——日志平台最怕的就是半夜挂一台机器没人管。还有每日 3 份免费系统盘快照、30 秒回滚，配置改崩了能直接退回去。这些在日志这种「改配置很频繁」的场景里特别实用。

#2 一万网络「大容量存储型定制」——冷热分层的冷层就该这么配

如果你的保留周期是 90 天甚至半年，冷层用通用机器太浪费了。定制一台多盘位、大容量 HDD 为主、配小容量 NVMe 做缓存的机器当冷节点，单位 TB 成本会明显低一截。热节点那边单独配一台 NVMe 机器，两三层用 ILM 自动搬迁，整体成本比全 NVMe 方案省很多。

这一档属于定制配置，没有统一的官网标价，价格以咨询为准。另外如果是华南、华东、华北多地采集日志要往一个中心回传，可以让它配 BGP 多线 + CN2 GIA 回国线路，跨境方向（比如中国香港节点的日志回传）稳定度通常比普通国际带宽好一些，具体延迟以实测为准，下单前先要个测试 IP 跑一下。

顺带说一句，一万网络深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，这类定制需求他们接得比较多，沟通起来不用从头解释什么是 segment merge。5–20G 的免费 DDoS 防护和免费备案协助也都带，日志平台对外开了 Kibana 的话，防护这一项别省。

避坑指南：六个能让集群瘫痪的操作

坑一：堆内存开太大，把文件系统缓存挤没了

为什么坑：很多人觉得内存大就得多给 JVM，128G 的机器堆开到 64G。结果剩下的内存不够缓存 Lucene 的段文件，每次查询都真的去读盘，集群进入「GC 很健康但查询慢得要死」的状态，而且这种问题很难从监控上看出来——你看 JVM 指标一切正常。怎么避：堆内存不超过物理内存的一半，且尽量控制在 30–31GB 这条经验线以内，剩下的全留给操作系统做 page cache。想跑更大的堆，就在一台机器上起多个实例，但数据盘要分开。

坑二：分片数拍脑袋，按「一天一个分片」来开

为什么坑：很多教程写「日志按天建索引」，于是有人理解成「一天要分好几个分片」，结果每天日志才 3GB，却开了 5 个主分片，一年下来几百个分片，堆内存被分片元信息吃掉一大半，master 节点的集群状态也变得臃肿，节点重启恢复慢得离谱。怎么避：按分片大小反推数量，而不是按时间。目标是让单个主分片落在 30–50GB 这个区间；日志量小的索引用 rollover 按大小滚动，别按时间硬切。同时把每 GB 堆内存承载的分片数控制在 20 个以内。

坑三：把副本当备份用

为什么坑：副本是同一个集群内部的冗余，它防的是「节点挂了」，防不了「人手滑了」。一条 delete_by_query 写错条件，主分片删了，副本立刻同步删，两边一起没。同理，集群被入侵、配置被改坏，副本全都跟着遭殃。怎么避：副本只用来保证高可用和查询并发，真正的备份靠快照（snapshot）到对象存储或者独立的存储上，并且定期验证快照能不能恢复。没验证过的快照等于没有快照。

坑四：忽视段合并的磁盘写放大，盘按原始日志量买

为什么坑：算容量的时候只算了原始日志 × 保留天数，没算索引膨胀和副本翻倍，也没给段合并留临时空间。结果上线两个月磁盘 90%，写入开始变慢，段合并更挣扎，恶性循环。更糟的是磁盘水位线一旦触发，Elasticsearch 会把索引置为只读，整个集群停止写入。怎么避：容量按「原始量 × 保留天数 × 写放大系数 × (1+副本数)」来算，再留两成余量。设置磁盘水位线告警，在 80% 就开始扩容，别等到 90% 才动。

坑五：机械盘跑热数据

为什么坑：有人为了容量，把热节点也配成大容量 HDD。热层是持续随机写入 + 高频查询，HDD 的随机 IOPS 完全不够看，段合并一跑起来 IOPS 就打满，写入延迟飙到秒级，采集端全线退避，日志开始丢。怎么避：热节点必须是固态，NVMe 优先。容量不够就做冷热分层，把冷数据挪到 HDD 上，而不是把热数据放到 HDD 上。如果预算实在紧张，宁可缩短热数据的保留天数，也不要让机械盘扛写入。

坑六：日志膨胀把磁盘写满，集群自动转只读还没人发现

为什么坑：某次发版打开了 DEBUG 日志，或者某个服务进入异常重试循环，日志量一夜之间涨十倍。磁盘写满之后，Elasticsearch 的默认保护机制会把索引设为只读（block index read-only-allow-delete），整个集群停止写入——而这个状态不会自动解除，即使你删了数据释放了空间，索引还是只读的，得手动解。很多团队第一次遇到时，告警只发了「磁盘满」，没人知道还要手动解锁。怎么避：一是磁盘水位线告警要提前，二是采集端配置限流和采样，别让单个服务把集群冲垮，三是写个运维手册，明确「磁盘满之后要手动解除只读标记」这一步。有条件的话，把异常日志量增长也做成告警。

FAQ：八个被问得最多的问题

Q1：日志平台到底要多大内存？64G 够吗？

每天几十 GB 日志、保留 30 天的规模，64G 是够用的起点。分法很重要：堆内存给 30G 左右，剩下的三十几 G 全留给操作系统的文件系统缓存。别把堆开到 32G 以上，压缩指针失效之后有效容量反而下降，这是社区长期实践的经验线，具体表现以你用的 JDK 版本为准。如果日志量翻倍、或者查询并发上来了，优先加到 128G，然后考虑跑两个实例各 30G 堆，而不是把单个堆开到 60G。

Q2：分片数到底怎么定？给我一个能直接用的数字。

按分片大小反推。假设每天原始日志 50GB，写放大按 2.5 算，保留 30 天，副本 1 份，那么主分片总量是 50×2.5×30 = 3750GB。按单个主分片 40GB 算，大概需要 90 多个主分片，摊到 30 天就是每天 3 个主分片。用 rollover 让索引到 40GB 就滚动，比按天切更准。记住每 GB 堆内存承载的分片数控制在 20 个以内。

Q3：NVMe、SATA SSD、HDD 三种盘，能不能只用一种？

日志量小、保留周期短（比如每天 20GB 以内、留 7 天）的话，全 NVMe 完全没问题，省心。超过这个量就必须混着用，不然成本扛不住。混用的关键是靠 ILM 把数据按年龄自动搬迁：前 7 天在 NVMe，一周到一个月在 SATA SSD，再往后去 HDD 或者对象存储。全 HDD 的方案我一般不碰，热层写入扛不住。

Q4：refresh_interval 调多少合适？

日志场景我一般建议 30s，写入密集的场景可以放到 60s。默认是 1s，那是为了搜索场景的实时性准备的，日志用不上——你排查问题的时候，晚 30 秒看到日志没有任何影响。调到 30s 之后段的数量会大幅减少，段合并压力下降，写入吞吐和磁盘寿命都会改善。这是性价比最高的一次调参。

Q5：副本设 1 还是 2？

绝大多数日志场景 1 就够。副本的作用是节点故障时数据不丢、查询不中断，1 份副本已经能扛住单节点故障。设 2 份意味着磁盘占用变 3 倍，成本上非常不划算，而带来的额外收益（能同时扛两个节点故障）在日志这种非核心数据上价值有限。冷层可以直接设 0，靠快照兜底。

Q6：采集器走公网会不会有问题？

能用内网就用内网。走公网的风险不在带宽不够，而在抖动：链路一抖，bulk 请求变慢，写入线程池队列堆满，节点开始返回 429，采集端退避重试，队列更满，形成雪崩。业务机器分散在多个机房时，折中做法是在每个机房放一层汇聚节点，批量往中心推，减少公网请求数。涉及跨境回传的，建议选 BGP 多线 + CN2 GIA 这类优化线路，具体表现以实测为准。

Q7：什么时候该从单节点升级到集群？

看四个信号：堆内存持续高位且 GC 时间变长、写入和查询开始互相拖累、节点数到了 3 个以上、节点故障后恢复要好几个小时。出现任何一个，就该拆独立角色了。简单判断：每天 100GB 以下、查询并发不高，单节点够用；超过这个量，或者日志平台已经是排障的关键路径，就拆。别为了「看起来专业」提前上集群，运维复杂度是实打实的。

Q8：磁盘快满了会怎么样？怎么预防？

磁盘水位线到了之后，Elasticsearch 会把索引设成只读，整个集群停止写入。麻烦的是这个状态不会自动解除——即使你删了数据腾出空间，索引还是只读的，得手动改配置解锁。预防就三件事：容量按写放大和副本系数算准并留两成余量；磁盘 80% 就告警并开始扩容；采集端配置限流和采样，别让某个服务打 DEBUG 就把集群冲垮。

最后说点实在的

日志平台这台服务器，说白了是在跟「写放大」和「堆内存」这两件事较劲。硬盘买小了会出事故，堆内存开大了会拉低性能，分片数拍脑袋会让集群慢性死亡——这三个坑，八成的团队都踩过至少一个。我的建议很直接：先把日志量按公式算清楚，别拍脑袋；然后从一台配置均衡的双路机器起步，把 refresh_interval 调到 30s、副本设 1、分片按 30–50GB 规划，这三板斧下去，绝大多数中小规模场景就稳了；等日志量真的涨到每天 100GB 以上，再考虑冷热分层和拆节点，那时候你对自己的日志特征已经摸清楚了，做决策也不容易跑偏。

硬件这一头，找一家能在本地机房、能快速响应、能按你的需求定制盘位的供应商，比单纯比较单价重要得多。日志平台是要长期维护的系统，半夜出问题有人接单，比省那几百块钱值钱。

数据来源

本文涉及的硬件配置建议、分片与内存规划经验区间，参考自 Elasticsearch / OpenSearch 社区公开文档与长期运维实践；价格相关数据中，标注「官网明示价」的部分参见一万网络官网 https://www.idc10000.net/ 的服务器租用与裸金属服务器页面，标注「预估」的部分为按市场行情估算的区间，不代表实际报价。具体以签约时最新报价与合同为准。