第3章日志聚合与分析

3. 日志聚合与分析：ELK/EFK架构、日志采集规范、关键字检索、日志上下文关联

说到根因定位，日志永远是最直接的证据。但现实是，你面对的不是几行日志，而是成百上千台机器、每秒几万条日志的洪流。没有一套靠谱的日志聚合系统，你连问题发生的「时间窗口」都找不到。

我个人习惯把日志系统比作「案发现场的监控录像」。没有它，你只能靠猜。有了它，你才能回放事故发生的每一帧。今天我们就聊聊怎么搭好这套「监控录像」，以及怎么用它来破案。

3.1 ELK/EFK 架构：选哪个？

先说说架构选型。ELK 是 Elasticsearch + Logstash + Kibana，EFK 是把 Logstash 换成 Fluentd。我两个都用过，说说我的感受。

ELK 架构：Logstash 插件丰富，处理复杂日志格式很顺手。但有个坑——它吃内存。我曾经在 4G 的机器上跑 Logstash，结果 OOM 了。后来我学乖了，给 JVM 堆内存设了上限。

EFK 架构：Fluentd 是 Ruby 写的，资源占用更轻量。而且它原生支持 Kubernetes，如果你用容器化部署，EFK 几乎是标配。我在一个日活千万的项目里用的就是 EFK，稳定跑了两年没出过事。

怎么选？我的建议是：

传统虚拟机部署、日志格式复杂 → 选 ELK
容器化、K8s 环境、追求轻量 → 选 EFK
团队熟悉 Java 生态 → 选 ELK
团队熟悉 Ruby/Python → 选 EFK

核心要点：不管选哪个，Elasticsearch 是绝对核心。它负责存储和检索，性能直接决定了你能多快找到根因。

3.2 日志采集规范：别让脏数据毁了你的检索

你想想看，如果每台机器的日志格式都不一样，有的用 tab 分隔，有的用空格，有的干脆是自由文本……那 Elasticsearch 再强也救不了你。

我在项目中遇到过最头疼的事：开发同学在日志里随手打了几个中文字符，结果编码不一致，Kibana 里显示的全是乱码。排查了整整两个小时，才发现是日志采集器没指定 UTF-8。

所以，日志采集规范必须定死：

统一时间格式：ISO 8601 标准，带时区。比如 2025-01-15T14:30:00.123+08:00
固定字段顺序：时间、级别、线程、类名、消息。别乱排
结构化日志：能用 JSON 就别用纯文本。JSON 解析快，检索准
避免敏感信息：密码、身份证号别打出来。我曾经见过有人把数据库密码直接打在了 DEBUG 日志里……

# 推荐的结构化日志格式（JSON）
{
  "timestamp": "2025-01-15T14:30:00.123+08:00",
  "level": "ERROR",
  "thread": "http-nio-8080-exec-3",
  "logger": "com.example.OrderService",
  "message": "订单超时取消失败",
  "orderId": "ORD20250115001",
  "duration": 3500,
  "exception": "java.lang.RuntimeException: 数据库连接超时"
}

小技巧：在日志采集端就做好字段映射。比如用 Logstash 的 grok 插件，或者 Fluentd 的 parser 插件，把非结构化日志转成结构化字段。这样 Elasticsearch 里就能直接按 orderId 或 duration 做聚合查询。

3.3 关键字检索：从海量日志里捞出那一条

日志聚合好了，怎么查？很多人上来就搜 ERROR，结果出来几万条。这不叫检索，这叫刷屏。

我常用的检索套路是这样的：

先定时间范围：别搜全量，先缩小到故障发生前后 5 分钟
用精确字段：比如 orderId: "ORD20250115001"，而不是模糊搜 ORD20250115001
组合条件：level: ERROR AND duration > 3000，这样能过滤掉那些「假错误」
排除干扰项：NOT message: "健康检查"，把心跳日志去掉

# 一个实用的 Kibana 查询示例
level: ERROR 
AND logger: "com.example.OrderService" 
AND orderId: "ORD20250115001" 
AND NOT message: "重试"

嗯，这里要注意：Elasticsearch 的查询语法是 Lucene 风格的。如果你用 Kibana 的 KQL（Kibana Query Language），写法会略有不同。我个人习惯用 Lucene 语法，因为更灵活。

避坑指南：我曾经在线上环境直接搜 *，结果把 ES 集群查挂了。记住，生产环境不要做全表扫描。一定要加时间范围过滤，最好再配上 size 限制。

3.4 日志上下文关联：把碎片拼成完整故事

单条日志能告诉你的信息有限。真正有用的，是把同一请求的日志串起来。这就是日志上下文关联。

怎么做？核心是「Trace ID」。每个请求进来时，生成一个全局唯一的 ID，然后在整个调用链里传递。不管是微服务调用、异步消息、还是数据库查询，都带上这个 ID。

我在项目中用过两种方案：

方案一：MDC（Mapped Diagnostic Context）。Java 里用 SLF4J 的 MDC，把 Trace ID 塞进线程上下文。日志框架自动打印出来
方案二：Agent 注入。用 SkyWalking 或 Jaeger 的 Agent，自动在字节码层面注入 Trace ID。对业务代码零侵入

// Java 示例：用 MDC 传递 Trace ID
import org.slf4j.MDC;

public class OrderService {
    public void createOrder(OrderRequest request) {
        // 生成 Trace ID
        String traceId = UUID.randomUUID().toString();
        MDC.put("traceId", traceId);
        
        try {
            log.info("开始创建订单, orderId={}", request.getOrderId());
            // 业务逻辑...
            log.info("订单创建成功, orderId={}", request.getOrderId());
        } finally {
            MDC.clear();
        }
    }
}

有了 Trace ID，你在 Kibana 里搜 traceId: "xxx"，就能看到这个请求从入口到出口的所有日志。按时间排序，一目了然。

核心逻辑：日志上下文关联的本质，是把「机器视角」的日志，还原成「请求视角」的故事。你不再看某台机器发生了什么，而是看某个请求经历了什么。

3.5 知识体系：一张图看懂日志聚合与分析

下面这张图是我自己总结的，涵盖了日志从采集到分析的全链路。你可以把它当作一个检查清单，看看自己的系统覆盖了哪些环节。

说白了，日志聚合与分析就四个步骤：采好、聚好、查好、串好。每一步都有坑，但每一步也都有成熟的解法。你只要按这个体系去搭，根因定位的效率至少提升 50%。

我的经验：别想着一步到位。先跑通核心链路（采集→存储→检索），再慢慢加上下文关联和自动化分析。我见过太多团队一开始就想搞全链路追踪，结果连基础日志都没采全，最后不了了之。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

3. 日志聚合与分析：ELK/EFK架构、日志采集规范、关键字检索、日志上下文关联

3.1 ELK/EFK 架构：选哪个？

3.2 日志采集规范：别让脏数据毁了你的检索

3.3 关键字检索：从海量日志里捞出那一条

3.4 日志上下文关联：把碎片拼成完整故事

3.5 知识体系：一张图看懂日志聚合与分析