集中式日志管理：从 rsyslog 到 Loki 与 ELK 的选型

一台服务器时，tail -f 加 grep 就是全部日志方案。服务器变成五台、十台之后，「登录每台机器逐个翻日志」彻底失效，集中式日志管理成为刚需。本文按技术演进的顺序讲三种方案，帮你按团队规模选择，而不是盲目上最重的那个。

为什么必须集中#

分散日志有三个致命伤：

Linux 自带的 rsyslog 本身就支持把日志转发到远端。发送端 /etc/rsyslog.d/50-forward.conf：

1
*.* @@log-server:514

（@@ 表示 TCP，@ 是 UDP；生产用 TCP 防丢。）

接收端开启监听并写入按来源分目录的文件：

1
$ModLoad imtcp
2
$InputTCPServerRun 514
3
$template RemoteHost,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
4
*.* ?RemoteHost

优点：零新增组件、资源占用忽略不计、稳定跑了几十年的老方案。缺点：只能 grep，没有结构化解析，没有 Web 界面，检索大数据量时全靠手动。

适用：服务器少于十台、日志量小、团队习惯命令行。

ELK = Elasticsearch + Logstash + Kibana，是日志分析领域的事实标准。管道是：

1
Filebeat(采集) → Logstash(解析/富化) → Elasticsearch(存储/索引) → Kibana(查询/展示)

实际部署常用 Filebeat 直接写 ES，跳过 Logstash 以省资源，解析交给 ES 的 ingest pipeline。

核心能力是全文检索：每条日志的每个词都被倒排索引，「找出所有包含 timeout 且来自 api-server 的日志」毫秒返回。Kibana 的 Discover 界面、可视化图表和告警插件构成了完整的日志分析工作流。

代价是资源：Elasticsearch 基于 JVM，给全文索引建的倒排表让存储放大到原始日志的 1.5~3 倍，一个中等规模集群轻松吃掉几十 GB 内存。个人项目单节点 ES 最低建议 4GB 堆内存起步。

适用：日志需要复杂检索与分析、有专门运维人力、资源预算充足。

Grafana Labs 出品的 Loki 提出了一个关键洞察：大部分时候人们查日志是先按「哪个服务、哪台机器」缩小范围，再在里面 grep。所以 Loki 只为标签建索引（如 job="nginx", host="web1"），日志原文压缩存储，不做全文索引。

1
Promtail(采集) → Loki(存储) → Grafana(查询)

架构和 Prometheus 几乎同构（Loki 自称是「日志界的 Prometheus」），查询语言 LogQL 也神似 PromQL：

1
{job="nginx"} |= "timeout" | json | status >= 500

含义：取 job=nginx 的日志流 → 过滤含 timeout 的行 → 按 JSON 解析 → 筛 status 字段 ≥ 500。

优点：存储成本低一个数量级（压缩率通常 10:1 以上）、内存友好、与 Grafana 天然集成——点一下就能从指标曲线跳到同时间段的日志。缺点：不做全文索引意味着「不按标签过滤的全文搜索」很慢；高基数标签（如把 user_id 做成标签）会拖垮索引，使用上有纪律要求。

适用：已经在用 Prometheus + Grafana、日志主要用于排障而非复杂分析、追求低成本。

维度	rsyslog	ELK	Loki
部署复杂度	极低	高	中
全文检索	无（靠 grep）	强	弱（标签+过滤）
存储成本	原始大小	1.5~3 倍	约 1/10
学习成本	低	高	中
适合规模	< 10 台	中大规模、重分析	中小规模、重排障

三个方案有个共同前提：应用输出结构化日志（JSON）比纯文本好处理一百倍。

1
{"ts":"2026-10-11T10:30:00+08:00","level":"error","service":"api","trace_id":"abc123","msg":"db query timeout","latency_ms":2300}

字段明确后，任何管道都能准确解析；而 2026/10/11 ERROR something happened 这种自由文本，到了平台侧还得写正则猜字段。改造应用日志格式，是投入产出比最高的日志治理动作。