为什么你的 ELK 集群总在半夜崩？
我们公司做电商，大促期间日均日志量能冲到 1.2TB，平时也有 800GB 左右。最开始用 ELK，3 台 16C64G 的机器，Elasticsearch 7.10，单日索引大概 200 个，每个索引 5 个分片。结果每天晚上 2 点合并高峰期，CPU 直接飙到 90%，告警群响个不停。我试过调大 refresh_interval 到 30s，translog 的 flush_threshold_size 从 512MB 改成 1GB，确实写入吞吐上去了，但查询延迟从原来的 200ms 涨到了 1.5s，排障的时候等半天出不来结果。后来发现是分片太多，每个分片只有 10GB 左右，而官方建议是 30-50GB。我们把小索引合并，用 ILM 策略，7 天前的索引强制 merge 成 1 个分片，情况好转了一些，但成本还是高——每月的机器费用加存储，差不多 2000 块。
转向 Loki：省了钱，但查询真的慢
后来听说了 Grafana Loki，主打“不索引日志内容，只索引标签”，存储成本直接降了 70%。我们拿测试环境试了一下，用 S3 做后端，3 台 4C8G 的机器跑 ingester 和 querier，居然能扛住 800GB/天的写入。配置上，chunk_target_size 设成 1.5MB，max_chunk_age 设成 2h，压缩比能到 10:1 左右。但是，查询是真慢。因为不建倒排索引，只能靠标签过滤，然后再在 chunk 里暴力扫描。查一个具体的错误码，如果标签没覆盖到，就得扫描几个小时的日志，延迟几十秒是常事。对比 ELK 的 200ms，这体验落差太大了。我的看法是：Loki 适合那种“我知道日志在哪台机器哪个服务，只是想看看输出”的场景，不适合“我要在几百 GB 日志里搜一个模糊的关键词”。
ClickHouse：性能怪兽，但需要自己造轮子
再后来，我们尝试了 ClickHouse。把日志结构化后写入，用一个 3 节点的集群，每节点 8C32G，SSD 做存储。建表用 MergeTree，按天分区，按时间排序。写入速度确实猛，单节点每秒能写 50 万行，而且压缩比能到 15:1。查询也快，一个 group by 统计错误码，几亿行数据 1 秒内出结果。但是，ClickHouse 没有现成的日志采集和可视化方案，你得自己写 Fluent Bit 的配置，自己写 Grafana 的 SQL 查询，还要考虑数据过期删除（用 TTL 或者 ALTER TABLE DROP PARTITION）。我们花了差不多两周才把整个 pipeline 跑通。另外，ClickHouse 的 join 性能一般，如果你需要把日志和链路追踪关联，最好还是让日志里直接带上 trace_id。总的来说，ClickHouse 适合有研发能力、追求极致性能和成本的团队，小团队慎入。
我的独立观点：日志分析没有银弹，关键看你的查询模式
很多人一上来就问“哪个日志分析工具最好”，这问题本身就不对。我的经验是，先统计一下你 80% 的查询是什么。如果 80% 是“查看某个服务最近 10 分钟的日志”，那 Loki 足够了，成本低到忽略不计。如果 80% 是“搜索某个关键词，可能跨天”，那 ELK 的倒排索引值这个钱。如果 80% 是“做聚合分析，比如统计每分钟的错误率”，那 ClickHouse 或者 Druid 更合适。还有一个被忽视的点：日志的采集和解析。我们之前用 Logstash，CPU 占用太高，后来换成 Vector，同样的日志量，CPU 从 8 核降到 2 核，内存从 4G 降到 1G。具体配置是 Vector 的 transform 里用 remap，比 grok 快很多。总之，别盲目追求新技术，先搞清楚自己的查询模式，再选型。