Metrics 告诉我们“系统发生了什么变化”，而 Logs 更擅长告诉我们“具体发生了什么”。

日志收集的核心并不是简单地把日志文件复制到另一台机器，而是建立一条从产生、采集、解析、传输、存储到查询分析的完整链路。

一、日志与日志系统#

1.1 什么是日志#

日志（Log）是系统运行过程中产生的事件记录。

例如：

1
2026-09-14 10:32:11 INFO  Application started
2
2026-09-14 10:32:15 INFO  Request GET /api/users
3
2026-09-14 10:32:18 ERROR Database connection refused

一条日志通常包含：

1
时间
2
级别
3
来源
4
消息
5
上下文

例如：

1
2026-09-14 10:32:18
2
       │
3
       ├── 时间
4
       ├── ERROR
5
       ├── backend
6
       └── Database connection refused

日志和 Metrics 的区别可以简单理解为：

1
Metrics
2
→ 数值化状态
3

4
Logs
5
→ 具体事件记录

例如：

1
CPU = 95%

属于：

1
Metric

而：

1
OutOfMemoryError: Java heap space

属于：

1
Log

1.2 为什么需要日志#

当监控发现：

1
HTTP 5xx ↑

Metric 可以告诉我们：

1
错误率升高了

但还需要知道：

1
什么请求失败？
2
为什么失败？
3
哪个服务失败？
4
什么时候开始？
5
异常信息是什么？

这时就需要日志。

因此：

1
Metrics
2
   │
3
   ▼
4
发现异常
5
   │
6
   ▼
7
Logs
8
   │
9
   ▼
10
分析原因

这也是实际运维中：

1
监控
2
+
3
日志

经常配合使用的原因。

二、日志的来源#

一个 Linux 系统中，日志可能来自多个位置。

1
                        Logs
2
                          │
3
       ┌──────────────────┼──────────────────┐
4
       │                  │                  │
5
       ▼                  ▼                  ▼
6
     System            Application        Container
7
       │                  │                  │
8
   journald            log file           stdout
9
   syslog              stdout             stderr
10
   kernel              stderr

2.1 系统日志#

Linux 本身会产生：

1
内核事件
2
服务状态
3
认证信息
4
启动信息
5
系统错误

现代 Linux 系统中常见来源之一是：

1
systemd-journald

查看：

1
journalctl

例如查看：

1
journalctl -u nginx

只查看最近一小时：

1
journalctl --since "1 hour ago"

查看本次启动：

1
journalctl -b

2.2 文件日志#

很多应用会直接写入：

1
/var/log/

例如：

1
/var/log/
2
├── nginx/
3
├── mysql/
4
├── redis/
5
└── ...

Nginx 常见：

1
access.log
2
error.log

应用也可能：

1
/app/logs/application.log

因此日志采集器需要能够：

1
读取文件
2
持续跟踪文件
3
识别新增内容

2.3 标准输出与标准错误#

现代容器化应用非常常见的日志方式是：

1
stdout
2
stderr

例如：

1
Application
2
   ├── stdout
3
   └── stderr
4
         │
5
         ▼
6
Container Runtime

Kubernetes 官方也建议容器化应用将日志写入标准输出和标准错误，这也是 Kubernetes 日志收集最常见的基础方式。

Docker 同样提供专门的 Logging Driver 来处理容器的日志输出。Docker Engine 默认使用 json-file logging driver，但也支持 local、journald、syslog、fluentd 等方式。

三、日志级别#

应用通常会对日志进行分级。

常见级别：

1
TRACE
2
DEBUG
3
INFO
4
WARN
5
ERROR
6
FATAL

不同框架名称可能略有不同。

可以粗略理解：

1
DEBUG
2
→ 调试细节
3

4
INFO
5
→ 正常运行信息
6

7
WARN
8
→ 潜在问题
9

10
ERROR
11
→ 请求或操作发生错误
12

13
FATAL
14
→ 严重错误，可能导致程序退出

例如：

1
INFO
2
Application started
3

4
WARN
5
Connection pool is near capacity
6

7
ERROR
8
Database connection refused

3.1 为什么不能全部输出 DEBUG#

开发环境可能需要大量 DEBUG 日志。

但生产环境如果：

1
所有请求
2
+
3
所有变量
4
+
5
所有 SQL
6
+
7
大量调试信息

全部输出，就可能导致：

1
日志量暴增
2
磁盘增长
3
网络带宽增加
4
存储成本增加
5
查询困难

因此生产环境通常会根据实际需要设置日志级别。

四、日志格式#

4.1 非结构化日志#

最简单的日志：

1
2026-09-14 10:31:20 ERROR Database connection refused

人比较容易阅读，但程序解析起来比较麻烦。

4.2 结构化日志#

更适合集中式日志系统：

1
{
2
  "timestamp": "2026-09-14T10:31:20Z",
3
  "level": "ERROR",
4
  "service": "backend",
5
  "message": "Database connection refused"
6
}

结构化日志可以明确区分：

1
timestamp
2
level
3
service
4
message

后续查询时可以直接按照字段过滤：

1
level = ERROR
2
service = backend

而不是通过字符串搜索整行文本。

4.3 为什么结构化日志重要#

假设有：

1
100 万条日志

如果都是：

1
纯文本字符串

分析器通常需要先进行：

1
解析
2
提取字段

如果日志本身已经结构化：

1
JSON

那么采集系统更容易建立：

1
字段
2
索引
3
过滤条件
4
聚合

这会直接影响后面的集中式日志分析。

五、日志轮转 Log Rotation#

5.1 为什么需要日志轮转#

假设：

1
application.log

每天增长：

1
2 GB

一个月之后可能达到：

1
60 GB

如果一直写同一个文件：

1
磁盘最终会被写满

因此需要：

1
Log Rotation

典型过程：

1
application.log
2
       │
3
       ▼
4
application.log.1
5
       │
6
       ▼
7
application.log.2
8
       │
9
       ▼
10
application.log.3.gz

旧日志可以：

1
压缩
2
保留
3
删除

5.2 logrotate#

Linux 中常见工具：

1
logrotate

可以根据：

1
时间
2
文件大小

轮转日志，并支持压缩、保留数量等操作。

例如配置：

1
/var/log/myapp/*.log {
2
    daily
3
    rotate 7
4
    compress
5
    missingok
6
    notifempty
7
}

含义大致是：

1
每天轮转
2
保留 7 份
3
压缩旧日志
4
日志不存在不报错
5
空日志不轮转

5.3 日志轮转的一个常见坑#

应用打开了：

1
application.log

执行轮转后：

1
application.log
2
→ application.log.1

如果应用仍然持有原文件描述符，就可能出现：

1
文件名已经变了
2
但进程仍然写旧文件

因此某些应用轮转后需要：

1
reload
2
reopen
3
HUP

等机制重新打开日志文件。

所以：

1
Log Rotation
2
≠
3
只改文件名

还要考虑：

1
应用如何重新打开日志

六、日志收集#

6.1 什么是日志采集#

日志采集就是：

1
Log Source
2
    │
3
    ▼
4
Collector / Agent
5
    │
6
    ▼
7
Backend

例如：

1
/var/log/nginx/access.log
2
          │
3
          ▼
4
      Log Agent
5
          │
6
          ▼
7
   Central Log Server

日志采集器通常需要完成：

1
读取
2
解析
3
过滤
4
添加字段
5
缓存
6
批量发送

6.2 Agent#

Agent 通常运行在：

1
被监控服务器

上。

例如：

1
Server A
2
  └── Log Agent
3

4
Server B
5
  └── Log Agent
6

7
Server C
8
  └── Log Agent

统一发送：

1
        ┌── Server A ── Agent ──┐
2
        ├── Server B ── Agent ──┤
3
        └── Server C ── Agent ──┘
4
                                 │
5
                                 ▼
6
                         Central Log Backend

这种方式非常适合大量服务器。

6.3 为什么通常使用 Agent#

如果没有 Agent：

1
Central Server
2
   │
3
   ├── SSH Server A
4
   ├── SSH Server B
5
   ├── SSH Server C
6
   └── ...

中心服务器主动去每台机器拉日志，管理会比较复杂。

使用 Agent：

1
Server
2
  │
3
  └── Agent
4
       │
5
       └──► Central Backend

日志产生在哪里，就在那里进行采集。

七、日志采集器应该做什么#

一个成熟的日志采集器通常不仅是：

1
cat log

而是完整的数据处理过程：

7.1 Tail#

持续读取新增日志。

例如：

1
application.log

应用继续写：

1
Line 100
2
Line 101
3
Line 102
4
...

Agent 只读取新增内容，而不是每次都重新读取整个文件。

7.2 Position / Offset#

采集器需要知道：

1
“我已经读到哪里了？”

例如：

1
application.log
2
             │
3
             ├── 已读取到 Line 1000
4
             │
5
             └── 新增 Line 1001+

因此通常需要保存：

1
文件位置
2
offset
3
inode / file identity

这样 Agent 重启后才能尽量从正确位置继续。

OpenTelemetry 的 filelog receiver 等日志采集能力同样包含文件跟踪、日志轮转识别和 checkpoint 等机制。

7.3 Parse#

例如原始日志：

1
127.0.0.1 - - [14/Sep/2026:10:30:12 +0800] "GET /api HTTP/1.1" 200 1234

采集器可以解析成：

1
client_ip = 127.0.0.1
2
method    = GET
3
path      = /api
4
status    = 200
5
bytes     = 1234

7.4 Enrich#

采集器还可以增加额外字段：

1
host
2
service
3
environment
4
container
5
pod
6
namespace

例如：

1
{
2
  "service": "backend",
3
  "environment": "production",
4
  "host": "node-01",
5
  "level": "ERROR",
6
  "message": "Database connection refused"
7
}

这样后面的集中式系统就可以方便地进行过滤和聚合。

八、集中式日志#

8.1 为什么需要集中式日志#

假设有：

1
100 台服务器

每台都有：

1
/var/log/app.log

用户访问出现异常时，如果要求运维：

1
SSH 到 Server 1
2
SSH 到 Server 2
3
SSH 到 Server 3
4
...

逐台搜索：

1
ERROR

效率会非常低。

集中式日志就是：

1
Server 1 ─┐
2
Server 2 ─┤
3
Server 3 ─┤
4
Server 4 ─┤
5
           ▼
6
      Central Backend
7
           │
8
           ▼
9
         Search

于是可以统一查询：

1
service = backend
2
level = ERROR
3
time > 10:30

8.2 集中式日志的核心能力#

一个日志平台通常需要：

1
采集
2
传输
3
存储
4
索引
5
查询
6
过滤
7
聚合
8
可视化
9
权限
10
保留策略

因此：

1
日志系统
2
≠
3
日志文件服务器

它实际上是一整套数据处理系统。

九、集中式日志的典型架构#

最简单：

1
                ┌── Agent ── Server A
2
                │
3
Log Sources ────┼── Agent ── Server B
4
                │
5
                └── Agent ── Server C
6
                         │
7
                         ▼
8
                  Central Backend
9
                         │
10
                         ▼
11
                      Query

更完整：

1
Logs
2
 │
3
 ▼
4
Collection
5
 │
6
 ▼
7
Parsing
8
 │
9
 ▼
10
Buffer / Queue
11
 │
12
 ▼
13
Storage
14
 │
15
 ▼
16
Index
17
 │
18
 ▼
19
Search
20
 │
21
 ▼
22
Visualization

中间还可以加入：

1
Filtering
2
Sampling
3
Enrichment
4
Routing

十、日志传输#

日志从 Agent 到中心系统，通常需要通过网络发送。

例如：

1
Agent
2
  │
3
  │ TCP / HTTP / gRPC / Syslog
4
  ▼
5
Log Backend

常见问题：

1
网络断开
2
连接超时
3
服务不可用
4
认证失败
5
数据发送过快

因此日志系统也会受到网络质量影响。

10.1 Buffer#

假设：

1
日志产生速度
2
>
3
日志发送速度

那么：

1
日志会积压

例如：

1
Producer
2
  │
3
  │ 10000 logs/s
4
  ▼
5
Agent
6
  │
7
  │ 5000 logs/s
8
  ▼
9
Backend

这时候需要考虑：

1
Memory Buffer
2
Disk Buffer
3
Queue
4
Backpressure

否则后端短暂故障可能直接造成日志丢失。

十一、日志可靠性#

11.1 至少要回答几个问题#

一个日志系统不能只问：

1
“能查到日志吗？”

还应该考虑：

1
日志会不会丢？
2
日志会不会重复？
3
日志会延迟多久？
4
后端挂了怎么办？
5
磁盘满了怎么办？
6
日志保留多久？

11.2 At-least-once 与重复日志#

日志采集中，经常需要在：

1
不丢日志

与：

1
不重复

之间做权衡。

例如：

1
发送成功

但 Agent 在收到确认前突然崩溃。

重启后可能重新发送之前的数据：

1
Log A
2
Log A

于是出现：

1
Duplicate

因此集中式日志系统经常需要依赖：

1
offset
2
ack
3
checkpoint
4
id

等机制提高可靠性。

对于日志而言：

1
至少一次

通常比：

1
完全不重复

更容易保证。

十二、Docker 日志#

容器环境通常会把应用输出写到标准输出和标准错误：

1
stdout
2
stderr

这里进一步从日志系统角度理解。

1
Container
2
   │
3
   ├── stdout
4
   └── stderr
5
         │
6
         ▼
7
     Docker Logging Driver
8
         │
9
         ▼
10
       Storage

Docker 当前默认 logging driver 为：

1
json-file

同时还提供：

1
local
2
syslog
3
journald
4
gelf
5
fluentd
6
...

等驱动。

查看：

1
docker info

也可以直接：

1
docker info --format '{{.LoggingDriver}}'

查看当前默认 Logging Driver。

12.1 Docker 日志磁盘问题#

容器日志如果持续增长：

1
Container
2
   │
3
   ▼
4
Logs
5
   │
6
   ▼
7
Host Disk
8
   │
9
   ▼
10
100%

最终可能导致：

1
Docker 异常
2
数据库异常
3
应用写文件失败
4
整个服务器磁盘不足

因此：

1
容器日志
2
+
3
日志轮转
4
+
5
日志保留策略

必须一起考虑。

Docker 官方也特别提示日志文件可能造成宿主机磁盘耗尽，并提供 local logging driver 等机制减少这类风险。

十三、Kubernetes 日志#

Kubernetes 环境的日志结构比单机 Docker 更复杂。

1
Pod
2
 │
3
 ├── Container A
4
 └── Container B
5
        │
6
        ▼
7
      stdout
8
      stderr
9
        │
10
        ▼
11
   Node-level logging
12
        │
13
        ▼
14
 Central Logging

Kubernetes 官方将：

1
Node-level logging agent

作为常见的集群级日志方案，并推荐在每个 Node 上运行一个日志 Agent；常见实现方式是使用 DaemonSet，使每个节点运行一个 Agent。

13.1 为什么不能只依赖 Pod 本地日志#

Pod 可能：

1
被删除
2
被重新调度
3
Node 故障
4
Container 重启

如果日志只保存在：

1
Pod / Node 本地

就可能随着运行环境消失。

因此集群日志应该尽量做到：

1
Pod Logs
2
   │
3
   ▼
4
Node Agent
5
   │
6
   ▼
7
Central Backend

使日志生命周期独立于：

1
Pod
2
Container
3
Node

Kubernetes 官方也明确指出，集群级日志应该拥有独立于 Node、Pod 和 Container 生命周期的存储与管理方式。

十四、Node Agent、Sidecar 与直接上报#

Kubernetes 集群级日志常见有三种基本思路。

14.1 Node-level Agent#

1
Node
2
 │
3
 ├── Pod A
4
 ├── Pod B
5
 ├── Pod C
6
 │
7
 └── Log Agent
8
          │
9
          ▼
10
       Backend

优点：

1
每个 Node 一个 Agent
2
应用基本无需修改

这也是非常常见的方案。

14.2 Sidecar#

1
Pod
2
├── Application
3
└── Log Sidecar
4
         │
5
         ▼
6
      Backend

适合：

1
应用只能输出文件
2
不同日志需要特殊处理

但代价是：

1
每个 Pod 增加额外容器
2
CPU / Memory 增加
3
配置复杂

14.3 应用直接发送#

1
Application
2
     │
3
     ▼
4
Log Backend

应用自己负责：

1
发送
2
重试
3
认证

这样可以减少中间层，但会让应用与日志基础设施耦合。

因此：

1
Node Agent
2
→ 通用性强
3

4
Sidecar
5
→ 针对单个工作负载定制
6

7
Direct
8
→ 应用主动管理日志输出

十五、日志解析与多行日志#

15.1 为什么多行日志是问题#

很多异常不是一行：

1
ERROR Application failed

而是一整个 Stack Trace：

1
ERROR Application failed
2
java.lang.RuntimeException: ...
3
    at com.example.App.run(App.java:100)
4
    at com.example.Main.main(Main.java:20)
5
...

如果采集器简单按：

1
一行 = 一条日志

最终可能变成：

1
Log 1 → ERROR Application failed
2
Log 2 → java.lang.RuntimeException
3
Log 3 → at com.example.App.run
4
Log 4 → at com.example.Main.main

原本的一次异常就被拆散了。

因此日志采集器需要支持：

1
Multiline Parsing

把多行内容重新组合：

1
Stack Trace
2
     │
3
     ▼
4
Single Log Record

15.2 多行解析要谨慎#

如果正则配置错误：

1
正常日志

可能被错误合并成：

1
一条超长日志

所以多行规则需要根据具体应用日志格式设计。

十六、时间戳与时区#

日志分析中非常重要的一项信息：

1
Timestamp

例如：

1
2026-09-14 10:30:00

如果不同服务器：

1
Server A → UTC
2
Server B → UTC+8
3
Server C → UTC+9

集中后可能导致：

1
事件顺序混乱

因此日志系统应该明确：

1
时间格式
2
时区
3
时间同步

生产系统通常需要保证服务器时钟同步，否则：

1
Log
2
+
3
Metric
4
+
5
Trace

之间可能难以正确关联。

十七、日志与敏感信息#

日志里非常容易出现：

1
密码
2
Token
3
Cookie
4
Session ID
5
身份证号码
6
手机号
7
邮箱
8
数据库连接信息

这是一类很严重的问题：

1
应用正常运行
2
 ↓
3
日志记录敏感信息
4
 ↓
5
集中式日志平台
6
 ↓
7
更多人可以查询

于是敏感信息的暴露范围反而扩大。

因此日志系统应该遵循：

1
不要记录不必要的敏感信息

并同时考虑：

1
脱敏
2
权限控制
3
加密传输
4
访问审计
5
保留期限

例如：

1
password=123456

不应该直接写进生产日志。

更合理：

1
password=******

或者根本不记录。

十八、日志保留策略#

日志并不是：

1
保存越久越好

因为日志量可能非常大。

例如：

1
每天 20 GB

一年就是：

1
7 TB+

因此需要制定：

1
Retention Policy

例如：

1
热数据
2
→ 7 天
3

4
温数据
5
→ 30 天
6

7
归档
8
→ 180 天

具体策略取决于：

1
业务需求
2
合规要求
3
成本
4
排障周期
5
审计要求

同时需要明确：

1
删除
2
压缩
3
归档

之间的区别。

十九、日志系统的性能问题#

日志系统本身也可能成为性能瓶颈。

主要观察：

1
日志产生速率
2
采集速率
3
传输速率
4
写入速率
5
查询速率
6
存储容量

例如：

1
Application
2
  │
3
  │ 50 MB/s
4
  ▼
5
Agent
6
  │
7
  │ 40 MB/s
8
  ▼
9
Backend

那么：

1
10 MB/s

会持续积压。

进一步：

1
Buffer
2
→ 越来越大

最后可能：

1
Agent 磁盘写满

因此日志系统也需要监控：

1
Queue Length
2
Dropped Logs
3
Send Errors
4
Backend Latency
5
Disk Usage

这就是：

1
“监控日志系统本身”

二十、日志故障排查#

日志系统出现问题时，可以按照：

1
Source
2
 ↓
3
Agent
4
 ↓
5
Network
6
 ↓
7
Backend
8
 ↓
9
Query

逐层排查。

20.1 Agent 没有采集#

例如：

1
application.log
2
有新日志

但中心平台没有。

首先：

1
文件路径对吗？

然后：

1
Agent 是否运行？

再：

1
Agent 是否读取到新增内容？

然后：

1
offset 是否正确？

20.2 日志采集后没有发送#

查看：

1
Agent Logs

检查：

1
连接
2
认证
3
TLS
4
后端地址
5
队列

20.3 网络问题#

检查：

1
ss -ntp

以及：

1
nc -vz <backend> <port>

如果使用 HTTP，可以：

1
curl -v http://<backend>:<port>

20.4 后端收到了，但查不到#

这时继续检查：

1
索引
2
时间范围
3
字段
4
解析
5
写入状态
6
查询条件

一个非常常见的问题：

1
日志实际上已经写入

但 Dashboard 查询的：

1
时间范围

不正确。

二十一、一个完整的集中式日志案例#

假设有三台 Web Server：

1
Server 1
2
Nginx
3

4
Server 2
5
Nginx
6

7
Server 3
8
Nginx

每台都有：

1
access.log
2
error.log

架构：

1
Server 1
2
 ├── access.log
3
 ├── error.log
4
 └── Agent
5
       │
6
       │
7
Server 2│
8
 ├── access.log
9
 ├── error.log
10
 └── Agent
11
       │
12
       │
13
Server 3│
14
 ├── access.log
15
 ├── error.log
16
 └── Agent
17
       │
18
       └──────────────┐
19
                      ▼
20
              Central Log Backend
21
                      │
22
                      ▼
23
                   Search
24
                      │
25
                      ▼
26
                Visualization

最终可以统一查询：

1
service = nginx
2
status >= 500
3
time = last 1 hour

得到：

1
Server 1 → 502
2
Server 2 → 500
3
Server 3 → 502

然后再进一步根据：

1
upstream
2
request_uri
3
client_ip
4
response_time

定位问题。

二十二、日志与 Metrics 的结合#

假设 Prometheus 发现：

1
HTTP 500 ↑

Grafana 显示：

1
        5xx
2
          │
3
          │        /\
4
          │       /  \
5
          │______/    \____

这个时候可以根据时间：

1
10:30

去查询日志：

1
10:30 ERROR Database connection refused

于是：

1
Metric
2
→ 告诉你异常从什么时候开始
3

4
Log
5
→ 告诉你具体发生了什么

这就是可观测性中非常核心的协同方式。

二十三、日志与 Trace 的关系#

随着系统变成微服务：

1
Client
2
  │
3
  ▼
4
API Gateway
5
  │
6
  ▼
7
Service A
8
  │
9
  ▼
10
Service B
11
  │
12
  ▼
13
Database

一次用户请求可能经过：

1
A
2
B
3
C
4
D

此时只搜索：

1
ERROR

可能找到数千条日志。

如果日志中包含：

1
trace_id
2
span_id

就可以：

1
Trace ID = abc123

查询与这一次请求有关的日志：

1
Service A
2
Service B
3
Service C

于是：

1
Metrics
2
   │
3
   ▼
4
异常发生
5

6
Logs
7
   │
8
   ▼
9
具体错误
10

11
Traces
12
   │
13
   ▼
14
请求经过哪些服务

OpenTelemetry 当前的日志设计也非常重视与其他遥测信号的关联，并支持把 Trace ID、Span ID 等上下文关联到日志中。

不过：

Trace、OpenTelemetry 和完整的 Metrics / Logs / Traces 体系属于进阶主题。

二十四、常见日志采集工具#

日志采集领域存在大量工具。

典型可以分成：

1
轻量 Agent
2
   │
3
   ├── Fluent Bit
4
   ├── Vector
5
   └── Filebeat

以及：

1
Telemetry Collector
2
   │
3
   └── OpenTelemetry Collector

例如 Fluent Bit 可以作为轻量级日志采集器，负责：

1
Input
2
→ Filter
3
→ Output

而 OpenTelemetry Collector 则进一步提供：

1
Receiver
2
→ Processor
3
→ Exporter

这样的通用遥测处理管道，并支持日志数据。

OpenTelemetry 官方日志规范明确支持：

1
文件日志
2
日志轮转
3
文件位置 checkpoint
4
Syslog
5
解析
6
处理
7
导出

并强调与现有日志系统和日志库进行兼容。

二十五、日志系统的整体模型#

到这里可以把日志系统串起来：

1
                  Application
2
                       │
3
              ┌────────┴────────┐
4
              ▼                 ▼
5
           Log File           stdout
6
              │                 │
7
              └────────┬────────┘
8
                       ▼
9
                    Agent
10
                       │
11
             ┌─────────┼─────────┐
12
             ▼         ▼         ▼
13
           Parse     Filter    Enrich
14
             │         │         │
15
             └─────────┼─────────┘
16
                       ▼
17
                    Buffer
18
                       │
19
                       ▼
20
                    Network
21
                       │
22
                       ▼
23
               Central Backend
24
                       │
25
             ┌─────────┼─────────┐
26
             ▼         ▼         ▼
27
           Storage    Index     Query
28
                                 │
29
                                 ▼
30
                           Visualization

因此集中式日志系统真正解决的是：

1
统一采集
2
统一存储
3
统一检索
4
统一分析

二十六、日志系统与 ELK / Elastic Stack#

后续文章会进入：

1
ELK / Elastic Stack

最经典的组合：

1
Log
2
 │
3
 ▼
4
Logstash
5
 │
6
 ▼
7
Elasticsearch
8
 │
9
 ▼
10
Kibana

可以暂时这样理解：

1
Logstash
2
→ 日志采集 / 处理 / 转发
3

4
Elasticsearch
5
→ 日志存储 / 索引 / 查询
6

7
Kibana
8
→ 日志可视化 / 分析

不过现代 Elastic Stack 的实际架构可以加入：

1
Beats
2
Elastic Agent
3
Logstash
4
Elasticsearch
5
Kibana

等不同组件。

因此这一篇只建立：

1
日志为什么要集中化

下一篇再重点研究：

1
Elasticsearch
2
Logstash
3
Kibana

的具体实现。

二十七、日志收集与分析的运维思维#

从运维角度，一条日志真正的生命周期是：

1
产生
2
 ↓
3
采集
4
 ↓
5
解析
6
 ↓
7
传输
8
 ↓
9
存储
10
 ↓
11
索引
12
 ↓
13
查询
14
 ↓
15
分析
16
 ↓
17
保留 / 删除

任何一环出现问题，都可能导致：

1
日志丢失
2
日志延迟
3
查询不到
4
磁盘爆满
5
成本增加

所以排查日志问题时，不应该只检查：

1
“日志平台有没有这条日志”

而应该从源头一路追：

1
Application
2
 ↓
3
Log Source
4
 ↓
5
Agent
6
 ↓
7
Buffer
8
 ↓
9
Network
10
 ↓
11
Backend
12
 ↓
13
Index
14
 ↓
15
Query

二十八、总结#

日志系统可以先记住下面这条主线：

1
Log Source
2
    │
3
    ▼
4
Collection Agent
5
    │
6
    ├── Tail
7
    ├── Parse
8
    ├── Filter
9
    ├── Enrich
10
    └── Buffer
11
    │
12
    ▼
13
Central Backend
14
    │
15
    ├── Storage
16
    ├── Index
17
    └── Query
18
          │
19
          ▼
20
      Visualization

Linux 环境中：

1
systemd-journald
2
logrotate
3
应用日志文件
4
stdout / stderr

解决的是：

1
日志产生与本地管理

而集中式日志进一步解决：

1
多服务器
2
多容器
3
多服务
4
统一采集
5
统一搜索

最终可以把三类可观测数据暂时区分为：

1
Metrics
2
→ 数值变化
3
→ Prometheus
4

5
Logs
6
→ 具体事件
7
→ 日志系统 / ELK
8

9
Traces
10
→ 请求调用链
11
→ OpenTelemetry 等

下一阶段再把它们逐渐关联起来：

1
Metrics
2
   │
3
   ▼
4
发现异常
5
   │
6
   ▼
7
Logs
8
   │
9
   ▼
10
定位错误
11
   │
12
   ▼
13
Traces
14
   │
15
   ▼
16
定位调用链上的具体环节

日志收集不是“把文件搬到另一台机器”，而是建立一条可持续、可检索、可分析的数据管道。对于运维而言，真正重要的是知道日志从哪里产生、经过哪些环节、在哪里可能丢失，以及如何最终利用日志定位故障。