日志平台存储告警时，优先将旧索引转存对象存储做冷热分层，而不是直接加机器扩容。这个思路的核心是先让数据流动起来，再决定是否租用新资源,多数情况下可以省下六成以上成本。
存储告警出现时，先判断该扩容还是该瘦身
日志分析平台出现磁盘水位告警，第一反应是买机器或租云盘，这个操作方向不一定错，但成本效率比较低，我见过不少团队在存储告警后直接加了几台节点，结果三个月后又满了,问题并没有解决。
开始动手之前，先花二十分钟梳理一下现有数据的构成，打开你的日志检索界面，查一下按索引大小排名的前二十个索引，你大概率会看到这样一个规律：超过三十天的历史索引占据了70%以上的存储空间,但查询频率极低。
判断标准很简单： 近七天的日志被检索的次数占总检索量的九成以上，而超过三十天的日志几乎没有被查询过，这种情况说明你缺的不是存储空间，而是存储策略，这时候应该想的是调整存储结构,而不是扩容。
日志分析平台存储扩容方案：为什么转存对象存储比直接加机器划算
以Elasticsearch集群为例，自建节点每TB存储的月成本包含了机器折旧、SSD或HDD成本、机房电费和运维人力，转存到对象存储后，存储成本能下降一个量级。对象存储的低频访问模式，计费单价往往只有云盘和本地盘的几分之一，而且没有预留容量的压力用多少算多少,这是最大的区别。
另一个关键点是：加机器是“先付钱后使用”，租用对象存储是“用了再付钱”，日志数据不像业务数据那样需要极低延迟访问，它接受秒级甚至分钟级的加载等待,这就给了我们使用低成本存储的空间。
实现冷热分层在技术上也相当成熟，在Elasticsearch中可以通过索引生命周期管理（ILM）策略，把投递到热节点的新索引，在指定天数后自动转移到冷节点，再在更长时间后自动快照到对象存储，整个过程策略化运行,配置一次就不再需要人工干预。
日志存储扩容租用价格由什么决定，怎么选才不花冤枉钱
在决定租用方案时，先理解费用的构成，日志存储扩容租用价格主要由三块组成：存储量（每GB单价）、请求次数（读写调用费）和流量费用（公网流出），如果你只是写入数据并偶尔检索，流量费占比很低,主要关注存储量和请求费就行。
国内主流云厂商的对象存储定价逻辑相似，按量计费模式下，存储单价在每GB每月几分钱到一毛多之间，具体取决于存储等级。新建一个低频访问或归档存储类型的桶，比标准存储能节省大约一半的费用。
另外要注意，不少厂商对最小存储周期有要求，比如低频访问类型通常要求数据至少存放三十天，日志数据天然满足这个条件,所以不用担心额外支出。
自建日志存储和对象存储哪个便宜，要算总账
这是一个很常见的对比问题，自建日志存储看起来没有按量计费的概念，服务器买回来后随便用，但按三年折旧去算总成本，再除以可用容量，每GB每月的综合成本并不低，这还没算上机房带宽、UPS、硬盘更换、故障恢复的时间成本。
对象存储的优势在于没有闲置浪费，容量按实际占用计费，也不需要考虑硬件生命周期，对于日志这类持续增长且峰值不确定的数据,对象存储的费用弹性是自建方案做不到的。
不过有个场景例外：如果你的日志平台已经有一套空闲的冷节点，且磁盘是在跑其他业务时预留的冗余容量，那直接用起来更划算，先把在用的资源盘活,再去考虑租用的成本。
渐进式扩容策略：不一次性搬光所有数据
确定了租用对象存储的方向后，不建议把全部历史数据一次性搬迁过去，操作节奏要平缓,避免迁移过程中出现查询超时或数据校验不一致的问题。
推荐的做法是增量迁移，配合索引生命周期管理策略，让新产生的数据在达到设定天数后自动进入冷节点，再由冷节点自动快照到对象存储，存量数据按时间倒序逐月迁移，每天搬一个索引，完成后在对象存储中做校验,确认分片数量和文档数一致再清理本地副本。
在Elasticsearch中配置可以参考以下思路：
- 创建两个存储库，一个指向热节点盘，一个指向对象存储桶
- 设定ILM策略，热阶段保留七天后转入冷阶段
- 冷阶段保留三十天后执行快照操作，然后删除本地索引
- 快照完成前不要删除任何本地数据，等待状态变为SUCCESS再清理
这个方案的收益是：容量占用的增速能明显放缓，即使日增数据量继续上涨，也能保持一个相对平稳的余量。
租用扩容前，先把数据生命周期管理想清楚
租用存储并不是把数据丢过去就算完事，对象存储里的日志同样是持续累积的，如果只管搬不管清洗，一年后对象存储这边的体量也会成为负担，在这个阶段,需要定义清楚数据的保留周期。
- 热存储阶段保留最近七天的数据，用于日常排错和实时分析
- 冷存储阶段保留近三个月的索引，支持临时回溯查询，但查询频率相对较低
- 对象存储归档阶段保留一到两年，用于合规审计和极少数的安全追溯
- 超过归档周期的数据，配置生命周期规则让其自动过期删除
配置对象存储的生命周期规则很简单，在控制台里设置一个前缀规则，直接指定过多少天删除即可，这比再写一套脚本去清理数据更省心,也避免人工操作遗漏造成持续扣费。
这里还要留意一个问题：数据从热存储转冷存储再转对象存储，有两个阶段的数据是不可立即查询的，第一个是冷节点上被强制合并或关闭的索引，查询时有等待期；第二个是已归档到对象存储的索引，需要先执行恢复操作才能搜索。在计划中明确告知业务方哪些时间范围的数据查询会变慢，避免临时使用时产生误解。
日志存储空间满了怎么办，小成本方案同样能撑住增长
如果当前预算有限，也有折中方案：保留现有集群不变，把最占空间且无查询需求的业务日志直接转入对象存储，不保留本地副本，这类日志通常是网关访问日志、CDN回源日志等，格式固定，没有上下文关联,使用频率极低。
操作上可以单独写一条采集链路，将这类日志直接发到对象存储，而不经过Elasticsearch集群，需要查看时，用对象存储原生的日志检索功能或对接外部查询引擎完成分析。这样既有保存记录的能力，又不消耗集群容量。
还有一种场景是遇到大促或活动期间的日志峰值，这类短时高峰没必要改变架构，临时租用按小时计费的云存储做溢出缓冲即可，活动结束后停止写入，把数据转入长期归档区,费用可控。
近几年日志平台扩容租用的常态化趋势
根据工信部数据，国内企业级存储市场规模近年来保持双位数增长，主要动力来源于非结构化数据的爆发，日志数据作为非结构化数据中增长最快的类型之一，在整体数据存储成本中的占比持续上升,这也促使更多团队开始关注分层存储和冷热分离架构。
越来越多的企业在规划日志平台时，直接采用“热节点+对象存储”的混合租用模式。 这种模式不需要在初期投入高额硬件资源，而是随着数据量增长逐步调整资源配比，按需租用让中小团队也能用到与大型平台相当的存储架构,成本却降低了几个量级。
当云日志存储空间不够用的时候，回归存储的本质去思考数据流向，比单纯买空间更有价值，存储的架构应该跟着数据温度走，热的留近处，冷的放远处,这样成本才能降下来。
日志分析平台存储扩容租用经常被问到的几个问题
日志分析平台的对象存储租用后，每天增加的数据量如何估算费用
按日志产生速率和平均单条日志大小估算，比如每秒产生2000条日志，平均每条0.5KB，一天的增量约为80GB，用这个数值乘以每GB存储单价，再加上少量请求费用，就能得到月度预算，注意保留一定余量,因为日志突发场景的峰值可能远高于平均值。
Elasticsearch做冷热分层配置后，索引从热节点转到冷节点的过程是否影响查询
索引进入冷阶段后，副本数和段合并策略有所调整，查询速度会变慢，但数据一致性和完整性不受影响，如果当前有业务方正在查询该时间范围的日志，建议在低峰期执行索引转移操作,转移过程中仍可检索最近一段时间的数据。
对象存储中的数据被误删后能不能恢复，恢复周期需要多久
如果开启了对象存储的版本控制功能或回收站规则，被删除的数据可以在保留期内直接找回，操作时间在分钟级，没有开启相关规则的情况下，恢复难度较大，因此建议在上传日志数据时配置版本控制，同时设置合理的生命周期规则,防止对象存储中数据永久丢失。