先说个事：线上故障排查，Kibana转圈3分钟
上周我们订单服务挂了，我打开Kibana查日志，输入trace_id，转圈转了3分钟才出结果。那一刻我决定必须把日志系统重构了。我们每天日志量大概2.3TB，原始日志压缩后1.1TB，Elasticsearch集群18个数据节点，每个16核64G，2TB SSD，每天新增索引500GB左右。一个月服务器成本小十万，这还没算运维人力。后来我试了Loki+ClickHouse方案，现在成本降到2.8万，但查询体验有得有失。下面我把真实数据和踩坑过程写出来，给同样被日志折磨的兄弟参考。
对比维度：别只看全文检索，算算你的查询模式
我统计了我们团队过去一个月的2000次日志查询，结果有点意外：只有17%是全文关键词搜索，剩下的83%都是标签过滤（比如app=order, level=error）加聚合（比如按分钟统计错误数）。Elasticsearch的倒排索引在这种场景下其实很浪费。我做了几个对比测试：写入吞吐，ES单节点每秒8万条（我们压测的），Loki用promtail大概5万条，但Loki只索引标签不索引内容，存储只有ES的1/5。查询方面，过去24小时status=500按分钟分组，ES用了12秒，ClickHouse用了2.3秒。但全文搜索“NullPointerException”这种，ES 0.8秒，Loki要扫描所有chunk，用了22秒。所以没有银弹，看你的场景。
迁移步骤：从ELK到Loki+ClickHouse，我踩了这些坑
第一步，评估日志量。我们统计了7天，平均每天2.3TB，峰值3.1TB。第二步，选存储。Loki后端用MinIO，3节点每个4TB SSD，成本1.2万；ClickHouse用3节点，每个8核32G，2TB NVMe，成本2.1万。第三步，采集。原来filebeat，换成promtail，配置里保留必要标签：app, env, level, host。这里有个大坑：Loki的chunk存储如果不用SSD，查询会慢到哭。我们一开始用HDD，查询24小时日志要40秒，换SSD后4秒。第四步，查询层。Grafana同时接Loki和ClickHouse，简单查询走Loki，聚合分析走ClickHouse。第五步，冷热分离。7天内日志在Loki，7-30天在ClickHouse，30天以上直接扔S3 Glacier。另外，我们砍掉了debug日志，只保留info以上，存储直接降了60%。
我的独立观点：日志分析被ES带偏了
我觉得日志分析行业被Elasticsearch带偏了，大家都觉得必须全文索引，但实际工作中大部分查询是标签过滤和聚合。我们统计的83%就是证据。所以Loki+ClickHouse组合才是性价比之选，尤其适合微服务架构、日志量大的团队。但也不是万能，如果你需要复杂的全文检索、关联分析、或者安全审计，ES还是更好。另外，别迷信“日志全量采集”，很多日志根本没人看。我的建议：先花一周统计你的查询模式，再选工具，别跟风。最后提醒，Loki的LogQL学习曲线有点陡，但学会后很爽。