前言日志平台接入大规模日志场景时最典型的挑战是日增 30TB 日志数据。这个量级下按天固定建索引、读写不分离、检索全索引扫一遍的传统做法全部会崩要么分片数失控要么写入把查询资源吃光要么一次检索要触达几千个分片。本文整理一套在这类场景下经过论证的架构设计思路核心是三件事可变索引粒度 动态索引路由、独立协调节点实现读写分离、面向场景的检索优化。先算容量账再谈设计最后给出可直接复用的 ILM 策略与索引模板。一、先把账算清楚容量与带宽评估动手设计之前先把数据量的账算清楚所有后续决策都建立在这些数字上。网络带宽日增 30TB平均下来是 30TB / 86400 秒 ≈347MB/s的持续写入启用压缩后大约可以压到110MB/s再考虑峰值放大和重传余量接入链路至少要具备2.5Gb/s的带宽。很多方案失败不是 ES 扛不住而是日志根本送不进来。写入速率等比缩小到 30GB/天的压测模型假设单条日志 300Byte可以推算出每秒写入速率单条日志大小Byte日志总量GB推算记录数每小时记录数每秒记录数30030107,374,1824,473,9241,243压测模型按此速率回放真实数据样例再线性外推到目标量级比拍脑袋估容量可靠得多。另外日志量评估要有方法论区分高峰与低谷、统计各机器的日产日志量做成表格持续跟踪而不是只看一个日均值。二、总体设计三个核心决策建立可变索引粒度日/时/分配合动态索引路由提升查询效率——高峰期索引更细低谷期索引更粗分片总数可控。独立部署协调节点实现检索与数据写入的路径分离。针对应用场景从部署架构、索引结构、检索方法三方面做匹配场景的优化而不是孤立地调某个参数。三、可变索引粒度日/时/分平滑切换为什么要可变粒度按天建索引在 30TB/天场景下单索引过大检索要扫的分片基数太高统一按分钟建索引又会让分片数量爆炸每天 1440 个索引。正确做法是让粒度跟随数据量动态变化高峰时段用分钟级索引低谷时段回落到小时级或天级。设计要点配置驱动在字典表/配置中心提供粒度配置项默认为“天”支持“时”和“分”调整后动态生效上层业务无感知。索引预生成定时线程每 30 分钟巡检一次按当前粒度提前创建未来的索引——日粒度在每天换日前 30 分钟生成次日的索引分钟粒度在每小时第 30 分钟预生成下一小时的 60 个分钟级索引。索引单独创建的性能消耗很低、单次数量少不影响正常读写。写入侧路由管理端将粒度配置同步到 RedisFlink 任务从 Redis 读取粒度信息并按粒度路由写入对应索引。这样切换粒度不需要重启数据处理任务。两种切换方式平滑切换在下一个索引预生成时点自动按新粒度生成下一轮索引强制切换立即同步 Redis 配置、立即按新粒度预生成索引Flink 任务定时同步配置完成写入路由切换程序再根据数据落点确认切换是否成功。查询侧路由检索接口根据查询时间条件 粒度配置生成查询范围内的索引名列表把无关索引直接从查询里排除掉——这是降低检索基数的钥匙。四、分片规划经验值与容量算例两条被反复验证的经验值每 GB 堆内存管理的分片数不超过 20 个1GB 堆对应 50 个分片是更早的老经验值新版本集群建议更保守单个分片承载数据 30~50GB配合 rollover 按大小滚动。算例日增 30GB、保留 180 天总量约 5.4TB按 50GB 一个滚动索引、3 主分片计算约 108 个滚动索引 × 3 324 个主分片再加 1 副本共 648 个分片按每 GB 堆 20 分片倒推需要约 33GB 堆内存——对应十余个 31GB 堆的数据节点。若集群确实需要放开分片上限可通过下面的配置调整配合前面的容量测算使用不要盲调PUT/_cluster/settings{persistent:{cluster:{max_shards_per_node:5000}}}五、ILM 生命周期与索引模板落地用 ILM 管理滚动与过期热阶段按 50GB 或 30 天 rollover180 天后删除PUT_ilm/policy/logs_policy{policy:{phases:{hot:{min_age:0ms,actions:{rollover:{max_primary_shard_size:50gb,max_age:30d}}},delete:{min_age:180d,actions:{delete:{delete_searchable_snapshot:true}}}}}}配套的索引模板字段名按通用日志模型示意重点是多格式日期与 keyword/text 的取舍PUT_template/logs_app{order:0,index_patterns:[logs_app-*],settings:{index:{lifecycle:{name:logs_policy,rollover_alias:logs_app},number_of_shards:3,number_of_replicas:1}},mappings:{properties:{log_time:{type:date,format:yyyy-MM-dd HH:mm:ss.SSS||yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||strict_date_optional_time||epoch_millis},collect_time:{type:date,format:yyyy-MM-dd HH:mm:ss.SSS||yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||strict_date_optional_time||epoch_millis},receive_time:{type:date,format:yyyy-MM-dd HH:mm:ss.SSS||strict_date_optional_time||epoch_millis},save_time:{type:date,format:yyyy-MM-dd HH:mm:ss.SSS||strict_date_optional_time||epoch_millis},log_file_id:{type:keyword},log_record_number:{type:long},host_ip:{type:keyword},log_source:{type:keyword},tag:{type:keyword},raw_message:{type:text},result:{properties:{level:{type:text,fields:{keyword:{type:keyword,ignore_above:256}}},message:{type:text,fields:{keyword:{type:keyword,ignore_above:256}}},log_time:{type:date,format:yyyyMMdd HH:mm:ss||yyyy-MM-dd HH:mm:ss.SSS||strict_date_optional_time||epoch_millis||HH:mm:ss,null_value:1970-01-01T00:00:00Z}}}}}}注意raw_message用 text 支撑全文检索过滤与聚合字段一律 keyword日期字段声明多格式兼容避免因上游时间格式不一致导致写入失败。六、检索侧调优并发查询的速度高度依赖缓存命中的分片分片数据在文件系统缓存里就快不在就慢。围绕这一点按时间条件路由索引让查询只触达必要的时间范围内的分片也保证有用的分片更有机会留在缓存中。读写分离独立部署协调节点检索链路不被数据写入抢占资源有副本分片时查询优先指定副本分片如preference设置避免与写入节点争抢。缓存容量规划分钟级 30GB 的数据量若期望较高命中率一般需要 100~150GB 内存作为缓存约为数据量的 30%~50%。search 线程池大小是(number_of_processors * 3) / 2并发用户数要按这个上限评估超出就该扩协调节点而不是硬扛。定期执行保温查询保持热点数据在缓存中的温度。七、字段与数据规范踩坑点这部分最容易被忽视但对检索体验影响最大四个时间戳缺一不可日志时间log_time、采集时间collect_time、接收时间receive_time、保存时间save_time。日志检索时用户最关注的是日志时间应以日志时间 行号作为主检索关键字段。无时间日志的兜底没有时间字段的日志行如堆栈的续行用多行合并采集功能收录日志时间为空时将采集时间赋给日志时间。第三方推送的日志若日志时间、采集时间都没有用接收时间兜底赋值并且要在接入规范里明确要求报文携带日志时间与采集时间。日志文件唯一 ID同一主机上不同文件应用日志/运行日志、不同主机上的同一对象都要能区分需要为每个日志文件设置一个不要太长的唯一 ID。K8s 场景要单独考虑Pod 漂移后日志文件换了位置续写逻辑上仍要视为同一个文件——而采集侧往往只能定位到 Service 级别定位不到 Pod这个矛盾要在 ID 设计上提前想清楚。分词优化通用分词对日志并不友好需要补充中文分词并针对日志类文本路径、类名、异常栈做专门的分词分析否则关键字查询的召回会很难看。八、典型分析场景对设计的要求架构最终要服务场景两个最高频的场景错误日志分析错误关键字查询依赖分词质量、错误记录的上下文查询按主机 文件 行号滚动取前后文、模糊匹配与正则过滤、多条件组合某系统某主机上某类 Error 日志。这要求字段设计里保留好过滤维度。跨系统关联分析通过全局流水号或唯一请求 ID 关联不同系统的日志固定时间范围内多系统日志按时间排序联动展示A→B 之间有关键字 K1、B→C 之间有关键字 K2把三个系统的日志串起来辅助定位。这要求日志时间规范统一否则跨系统排序就是灾难。结语面对日增 30TB 的日志场景真正的核心不是某个神奇参数而是先算清容量账让索引粒度随数据量弹性变化用路由把查询基数降下来用读写分离把资源冲突隔离开用严格的字段规范保住检索体验。这套思路同样适用于日增几百 GB 的中等规模场景只是粒度切换的触发点不同。你的日志平台单日数据量到什么量级了高峰期有没有遇到检索被写入拖垮的情况最后是怎么解决的欢迎在评论区交流。