Grafana把1.16TB日志成本砍了3倍

每天1.16TB日志、3.4万行/秒的处理量，放在传统方案里存储账单能吓死人。Grafana Loki团队用一套"偷懒"架构做到了，代价是查询时得等一等——这买卖划算吗？

他们的生产环境跑在EKS上，完整经历了从"这什么鬼"到"真香"再到"也不是没有坑"的全过程。以下是那份没加滤镜的实战记录。

Elasticsearch的索引膨胀病，Loki选择不治

传统日志系统的工作方式像个强迫症：每条日志进来，拆词、建倒排索引、存一份映射表。搜"ERROR"很快，但索引体积经常超过原始日志本身。规模上去后，你付的钱大部分花在维护这些索引上，而非日志内容。

Loki的解法近乎粗暴：只给标签建索引，日志内容压缩存成块。

遇到"ERROR: connection refused to database host db-prod-3"这种日志，Loki只记{namespace="payments", app="api-gateway"}这些标签，正文原封不动塞进压缩块。查询时先用标签定位到相关块，再暴力grep扫一遍。

代价很明显：任意文本搜索比Elasticsearch慢。收益也很实在：存储成本断崖式下跌。对于大多数运维场景——"给我payments命名空间最近一小时含ERROR的日志"——速度够用，账单好看。

打个比方：Elasticsearch是搜索引擎顺便存日志，Loki是存日志的系统顺便支持搜索。

把单体拆成五个零件，各自为战

传统日志系统一个进程包揽所有活：收日志、存日志、建索引、查日志。Loki拆成五个独立组件，每个按自己的瓶颈（CPU、内存、IO、网络）单独扩容。

Distributor（分发器）是第一个碰数据的人。所有日志推送先到它这里，校验标签、限流、拒绝过期样本，然后用一致性哈希环决定哪个Ingester（摄入器）接收。相同标签的日志永远去同一个Ingester，这是保证相关日志在内存里聚在一起的关键。

Elasticsearch的协调节点同时管路由和查询，Loki拆开是因为读写路径的扩展特性完全不同。Distributor几乎无状态、CPU消耗低，加减节点很随意。

Ingester是内存里的临时仓库。日志进来后先在这里攒成块，达到一定大小或时间后刷到对象存储（S3）。它同时把索引推给Index Gateway，把块推给Storage Backend。这个组件吃内存，因为要在本地维持活跃的日志流。

Querier（查询器）和Query Frontend（查询前端）处理读请求。Frontend负责拆分查询、排队、缓存结果，Querier实际去S3拉块并grep。读路径的瓶颈通常在带宽和解压缩CPU，而非索引查找。

Compactor（压缩器）后台运行，把小块合并成大块、重建索引、清理过期数据。没有它，S3上的小文件会泛滥成灾，查询性能随时间恶化。

生产环境的数字：省下的钱和吞下的苦

他们的配置经过几轮迭代才定型。初始阶段照搬文档，发现Ingester内存爆炸、查询超时、S3账单诡异上涨——典型的"能跑起来"和"能跑好"之间的差距。

第一个教训：Ingester的flush周期不能贪心。默认配置为了压缩率会把块攒很大，但内存占用和故障恢复时间直线上升。他们调到15分钟或500MB whichever comes first，内存曲线才平稳。

第二个教训：标签Cardinality是隐形杀手。有人把用户ID塞进标签，结果唯一标签组合爆炸，索引体积反超Elasticsearch。他们硬规约：标签只放环境、服务、实例级别的元数据，业务字段丢进日志正文。

第三个教训：查询并行度要配准。Query Frontend的split_queries_by_interval和parallelise_shardable_queries没调好时，大时间范围查询会卡死或把Querier内存撑爆。他们按24小时拆分、每查询最多16并发，找到了甜点。

最终账单：存储成本是同等规模Elasticsearch集群的1/4到1/3，查询延迟P99在5-30秒（取决于时间范围和结果集大小）。对于"查最近1小时ERROR"这类操作，通常2秒内返回；对于"查过去7天所有含特定trace ID的日志"，泡杯咖啡回来可能还没跑完。

什么场景该用，什么场景快跑

Loki不是银弹。他们的经验是：如果你的核心需求是"快速全文检索任意关键词"，比如安全团队要秒级搜IP地址、用户ID，Loki会让你失望。这类场景倒排索引仍是王者。

但如果你的查询模式固定、标签维度清晰——典型的微服务运维场景——Loki的性价比很难被击败。

他们内部把查询分为三类：实时排障（最近1小时，标签过滤+关键词grep）、短期回溯（最近24小时，同上）、历史审计（7天以上，仅标签过滤）。前两类体验良好，第三类他们直接建议导出到Athena做离线分析，而非硬怼Loki。

一个有趣的副产品：因为查询慢，工程师被迫把日志质量搞好了。结构化日志、一致的标签规范、有意义的错误码——这些"最佳实践"在Elasticsearch时代是建议，在Loki时代成了刚需。慢查询倒逼了好习惯。

他们的S3存储桶里，90天前的日志自动转冷存储，成本再降60%。Compactor把块大小维持在1GB左右，ListObjects调用次数从每月数亿次降到千万级。这些数字不会出现在官方文档的"快速开始"里。

部署18个月后，团队里仍有怀念Kibana秒级搜索的人。但财务部门的反馈更响亮：日志基础设施预算砍了一半，扩容申请从季度一次变成年度一次。当CTO在全员会上提到这个数字时，没人再提迁移回Elasticsearch的事了。

如果明天你的日志账单翻倍，你会选择更快的查询，还是更便宜的存储？