6.2 开源日志工具
6.2 开源日志工具
本节摘要：日志路线的开源主选是 ELK 全家桶（Elasticsearch- Logstash- Kibana）和轻量的 Loki。ELK 索引模型强、查询灵活但存储贵；Loki 标签索引省、索引依赖但正经搜索不那么自由。本节用"你更想按字段精筛还是更想省存储"做选型分叉，并给一套 ELK 从小到大可复制的接法，以及 Loki 的场景适配。
日志选型先答一个问题：你更在乎查询还是存储
先别急着看工具名，先问自己：你碰日志的需求,是只要"圈出时间范围+按服务/级别过滤+看正文"这种常规操作，还是要"任意字段精确筛选、复杂聚合、全文搜索"？前者，Loki 完全够且省翻天；后者，需要 ELK。
这个问题的答案基本帮你在 ELK 和 Loki 之间选好了。下面把两条路线各自拆开看。
ELK 全家桶：Elasticsearch、Logstash、Kibana 的铁三角
ELK 由三件套组成（现在官方叫 Elastic Stack，也带 Filebeat 等 beat 采集器）：
Elasticsearch：分布式搜索引擎，负责存日志和建索引。它的强项是倒排索引 + 分析聚合,你的日志随便怎么搜,只要字段建了索引,秒级返回。
Logstash：数据管道，负责采集、解析、转换、富化,再把日志送进 Elasticsearch。对了,第三章节讲的 Grok 解析,主战场就是这里。
（外围还要加）Kibana：可视化 UI,查日志、做搜索、画图、编排仪表盘,是全栈的门面。
再配 Filebeat 这样的轻量采集器负责在主机侧收日志,整条线是：Filebeat 采 → Logstash 解析 → Elasticsearch 存与索引 → Kibana 看与查。这是最主流、文档最多、社区最大的一条日志路线。
一句话接法总结成链路：
Filebeat → Logstash(解析) → Elasticsearch(索引) → Kibana(查询可视化)
Loki：轻量标签索引的偷懒派
Loki 的思路是"除非必要,不建索引"。它只对少数标签建索引（服务名、主机、level 这类），日志正文直接压缩成块存储，查询时按标签圈定范围再做流式匹配。所以它磁盘占用比 ES 低一个数量级,集群也轻得多,尤其和 Grafana 同门,Grafana 里就内嵌了日志查询,不需再装 Kibana 那套。
它不是没有代价：如果你需要正文全文索引、做复杂全文搜索,那其实还是 ES 合适。但"常规日志查故障"（圈时间、看级别、搜关键字、按服务过滤) Loki 完全应付得来,却省下一大笔存储和运维账。
一张表把它们摆稳妥
| 维度 | ELK(ES) | Loki |
|---|---|---|
| 索引模型 | 全文+字段索引 | 仅标签索引,正文压缩存 |
| 存储成本 | 高(通常翻几倍) | 低(低一个数量级) |
| 查询灵活性 | 极高(全文/聚合/字段) | 中(先标签圈再流式) |
| 可视化 | Kibana | Grafana 内嵌 |
| 学习门槛 | 偏高 | 偏低,与 Prometheus 心智一致 |
| 适合 | 中等量、多自由查询、预算够 | 海量、按标签查询为主、省钱 |
实战怎么接：一套 ELK 从小到大的路
给一支中小团队一条可照抄的路，从小慢慢长，别一上来全组件：
第一步，最小集：用 Docker 起一个单节点的 Elasticsearch + Kibana，Filebeat 从两台主机收 Nginx 和应用日志，先能搜就行。这一个最小集帮你把整条链路跑通，理解"搜得到"是什么感觉。
第二步，加 Logstash 解析：给日志洗完集（打结构化、Grok 拆字段、删敏感信息），你能按字段精确搜索了。这一步让日志从"能搜"变"能按字段筛"。
第三步，加索引生命周期：给日志按天按月配索引生命周期策略（热层全量存、温层降采样、冷层归档),不然日志量一涨存储就爆。
走到这里，一家中小团队的日志体系基本够用。后续要是量上去再考虑分布集群或者数据源拆分，但最开始的几十个 GB 这套足够。
别在采集端把 ELK 的"贵"越推越高
ELK 存储贵,有三成是索引策略不当推高的,不是工具本身的锅。最容易踩的三个点:不加生命周期策略——日志永久全精度,存储被跑批/杀猪日志灌爆;正确是配热温冷分层,老数据降采样归档。字段全量可搜索——每个字段都开 keyword,索引膨胀;正确是只对真正要精筛的字段建索引,正文普通字段不做全文。索引不合并——Elasticsearch 索引分片碎片化,查询和内存都吃亏;定期 force merge 收敛。这些跟选型无关,和你会不会养活你的索引有关,值得在动手前就规划,否则再好的 ELK 也变成怪物。
两套都别忘的"统一 trace ID"
不管是 ELK 还是 Loki,日志平台要真想当排障主力,就不能只搜字段,还得能"按一笔请求捞全链路"。做法是写日志时统一带上 trace_id,并把 trace_id 建成可索引字段——定位故障时,从监控告警到日志搜 trace_id,一步就把那笔请求在所有服务的日志全捞出来。这个习惯在两套系统里都成立,它让日志从"能搜单条"变成"能串一笔业务"。别等要排查了才后悔当初没统一字段——宁可最初多一行配置,也别在一场凌晨事故里拿不齐证据。选型定了只是开始,把它养活、用熟练,才是这套日志体系和值班室的真正磨合。真正的检验时刻在那一场凌晨事故——届时你搜得到、查得快、捞得全,这套体系才算没白搭。
本节要点回顾
- 先答一个问题：你要的是"常规查日志"还是"全文精筛",决定 ELK 还是 Loki。
- ELK 三件套：ES 索引+存储、Logstash 解析、Kibana 查询。
- ELK 强在查询：全文+字段+聚合,生态和文档最全。
- Loki 省在存储：标签索引+压缩正文,磁盘省一个数量级。
- 接法从小到大：先最小集跑通,再加解析,再上生命周期。
- Loki 与 Grafana 无缝：Grafana 内嵌日志查询，不用再装一套 Kibana。
- 按规模对号入座：小规模查常规上 Loki,要全文精筛上 ELK。
日志的班子也定了。链路追踪的路还差最后一条竖线——下一节看 Zipkin 与 Jaeger 这对难兄难弟怎么选。