日志合规留存期动辄半年到一年，全量热存成本太高，答案就是按访问频率做冷热分层：热数据放高性能存储，冷数据转入对象存储或归档存储，整体成本能省下60%以上。
日志存储成本吃紧的根源在合规要求，不在技术
很多运维团队都有这种感受：日志量每个月涨得吓人，存储扩容像无底洞，其实真正把成本推高的不是日志增速，而是合规留存期把数据“钉死”在了昂贵的热存储上。
《网络安全法》要求网络日志留存不少于六个月，等保2.0对关键设备日志也有明确留存要求，这个“六个月”加上等保合规的审计追溯需求，让日志从“查完就删”变成了“必须留着”，数据库、防火墙、应用系统、API调用，哪类日志都跑不掉。
存储费用的逻辑很简单：数据越热访问越频繁，单位存储成本越高，SSD和本地盘每TB价格贵但查询快，对象存储每GB每月几毛钱但访问有延迟，合规只要求数据“在”，没要求数据“都热着”，这就是冷热分层能省钱的根本原因。
冷热分层方案与落地路径：一份能直接抄的作业
冷热分层的核心思想并不复杂,就是把日志的生命周期拆开管理，访问频繁的近期日志放热存储，满足快速检索需求；访问概率低的远期日志转冷存储，主要承担“存着以备不时之需”的角色。
热层和冷层分别该放什么
热存储层承载近期日志，通常是最近7天到30天的数据，这层数据用于日常排障、安全事件溯源和业务分析，检索频率高，对响应时间敏感，推荐使用ES热节点或ClickHouse，配合SSD或高性能云盘。
冷存储层承载合规留存期内的老日志，即30天到180天甚至更久，这层基本没人查，只在等保审计或安全追溯时才偶尔捞一次数据，推荐使用对象存储OSS或S3 Glacier，配合压缩技术进一步降低空间占用。
归档层针对超过合规留存期但仍需保留的审计类数据，直接丢到磁带库或极冷存储，成本最低，查询要等几分钟甚至几小时。
还有一个实际问题：日志留存六个月的具体计算口径，行业共识认为，留存期从日志生成时间算起，满六个月后可以删除，因此第180天要清理最早一批数据，这个清理动作在分层架构里自动完成，不需要人工介入。
冷热分层存储的落地实操路径
第一步,梳理现有日志源和存储位置，盘点哪些系统的日志最占空间，通常访问日志、错误日志、审计日志是三个大头。
第二步,规划分层策略，定义一个统一的日志传输管道，比如用Filebeat或Fluentd采集日志，写入Kafka缓冲，然后分别路由到热存储和冷存储。
第三步,配置生命周期规则，在对象存储或ES上配置冷热迁移策略，比如ES的ILM（Index Lifecycle Management）能实现索引在热节点存7天后自动转到冷节点，再在30天后快照到对象存储并删除本地副本。
一个典型的ES ILM策略配置步骤：创建策略定义热期、温期、冷期，关联到索引模板，设置滚动更新条件，然后观察迁移是否按预期执行，这是一套可验证的完整技术路径，很多团队的日志存储成本优化就是从这一步开始的。
冷热分层的压缩比很可观，文本日志压缩率通常在5:1到10:1之间，加上冷存储本身单价低，成本差距从第二个月开始就会明显显现。
日志合规留存期怎么算：六个月并非一刀切
网安法说“不少于六个月”，但很多企业实际上留得更久，银行、政务、医疗行业的合规要求比通用规定更严，日志留存可能要一年到三年不等，这是行业内常见的合规分化现象。
| 行业/场景 | 常见日志留存期 | 冷热分层必要性 |
|---|---|---|
| 互联网企业 | 6个月 |
高（日志量大） |
| 金融机构 | 1-3年 | 极高（数据量大且审计严格） |
| 政务系统 | 1年以上 | 高（按规定归档） |
| 中小企业 | 6个月 | 中（日志量相对小） |
判定冷热分层的收益，核心看两个量：日志总量和留存时长。 日志总量越大，留存期越长，冷热分层省下的钱越多。
如果每天产生500GB日志,留存六个月就是90TB，全热存按3元/TB/天算，半年存储成本约8万元；冷热分层后只有前30天是热存，其余160天是冷存，冷存每TB每天只要几毛钱，总体成本降到原来的三分之一到四分之一。
这个成本差异对预算敏感的中小团队尤其重要,很多企业被问到一个问题日志存储成本太高怎么办答案往往不是“删日志”，而是“让老日志去更便宜的地方待着”，这才是合规与成本兼得的思路。
冷热分层如何支撑等保建设和安全审计
等保2.0要求对日志进行集中管理和安全审计，但并不要求审计时从头到尾扫一遍全部数据，实践中，日常审计只查最近一个月的日志，老日志仅在出现安全事件或合规抽查时才需要回溯。
借助冷热分层架构,日常审计跑在热数据上，响应快；安全事件回溯时查询冷数据，虽然慢一些但能查到，这样就兼顾了等保合规要求的“可追溯”和日常运维的“高效率”。
日志冷热分层方案还有个隐形好处：缩小了高敏感数据的暴露面，老日志沉到冷存储后，被误删或篡改的风险更低，配合WORM（一次写入多次读取）特性，还能满足部分行业的防篡改要求。
冷热分层常见误区与边界
有一种观点认为直接把日志压缩扔进对象存储就完事了,这不可取，冷存储有一套完整的分层策略，不是简单“放进去”，查询接口、生命周期规则、数据校验都需要提前规划。
冷热分层不适用所有日志类型,实时风控日志、在线交易日志必须全量热存，因为业务决策依赖毫秒级查询，这类日志的留存期通常很短，不存在“存六个月”的问题。
对于混合云或全云架构的团队,建议优先启用云厂商原生的日志服务冷热分层能力，比如简米云SLS的冷热存储、酷番云CLS的归档能力，这类方案能直接利用平台能力提升运维效率，采购时直接问“冷热存储怎么计费”，对比后选性价比高的。
冷热分层后的目标状态
理想状态下,日志体系应该自己“转”起来：数据产生后进入热存储，按预设策略自动迁移到冷存储，到期后自动清理，运维人员不用关心数据在哪一层，只需要在查询时知道近期的快、远期的稍慢即可。
Q&A：日志冷热分层高频问题
Q1：日志留存六个月，但冷存储查询很慢怎么办？
缓慢的查询速度是冷存储的固有特性,可以搭配临时恢复或缓存机制来规避，需要回溯老日志时，先恢复索引到热区再查询，虽然整体耗时会上升，但审计频率低，成本收益仍然划算，用一周一次的频率去换70%以上的存储成本下降，从审计和收益角度是值得的。
Q2：冷热分层按什么条件划分？
按时间是最常用的策略,但也可以结合索引大小、项目或日志类型来异步管理，有两种务实做法：一是按时间滚动，二是按日志源归属，前者简单直接，后者适合业务隔离需求，运维难度会稍高，如果团队一站式规划，建议先按时间配置，后续再做结构调整。
Q3：冷热分层能否满足等保审计的追溯要求？
可以,等保的关键要求是日志记录完整、不可篡改、可追溯，冷数据保存的日志内容未经删改，因此可以完整支撑等保审计，前提条件是按需补充校验机制，确保冷数据在迁移中没有缺失。