一、云原生时代为什么需要日志与追踪：从单体到微服务的痛点、可观测性的三大支柱、课程整体架构与学习路径

大家好，我是你们这门课的老朋友。今天咱们聊聊一个根本问题：云原生时代，为什么日志和追踪变得这么重要？

说实话，我刚开始做运维那会儿，系统还是单体架构。一台机器，一个进程，出了问题直接 SSH 上去看日志就行。那时候的日志，说白了就是个文本文件，用 grep 搜一搜，基本就能定位问题。

但现在呢？微服务、容器、K8s、Serverless……系统拆得七零八落。你想想看，一个请求过来，可能要经过十几个甚至几十个服务。这时候再靠 SSH 上去看日志，那简直是海底捞针。

1.1 从单体到微服务的痛点：我踩过的那些坑

先说说单体架构。嗯，它其实没那么不堪。对于小团队、小项目，单体架构开发简单、部署方便、调试也容易。我记得刚入行时，公司的一个核心业务系统就是单体应用。出了问题，我直接登录服务器，tail -f /var/log/app.log，基本就能搞定。

但微服务化之后，画风突变。我遇到过几个典型的痛点：

• 日志分散：几十个 Pod，分布在不同的节点上。你根本不知道问题出在哪个 Pod 里。我曾经为了找一个报错，把 20 多个 Pod 的日志挨个看了一遍，花了整整一个下午。
• 调用链断裂：一个请求从 A 服务到 B 服务再到 C 服务，每个服务只记录自己的日志。你很难把一次完整的请求串联起来。说白了，就是「只见树木，不见森林」。
• 排查效率极低：以前单体架构，一个请求的完整处理流程就在一个进程里。现在呢？请求可能被负载均衡转发，可能被服务网格拦截，可能被消息队列异步处理……你根本不知道它到底走了哪条路。

1.2 可观测性的三大支柱：日志、指标、追踪

那怎么解决这些问题呢？这就引出了可观测性的三大支柱：日志（Logs）、指标（Metrics）、追踪（Traces）。

我个人的理解是这样的：

• 日志：记录「发生了什么」。它是离散的事件，比如「用户登录失败」、「数据库连接超时」。日志最详细，但信息量也最大，需要靠搜索和过滤来定位问题。
• 指标：记录「系统状态怎么样」。它是聚合的数据，比如 QPS、延迟、错误率、CPU 使用率。指标适合做监控和告警，能告诉你系统「病了」，但很难告诉你「病因」。
• 追踪：记录「请求是怎么走的」。它是一次请求的完整调用链，能告诉你请求经过了哪些服务、每个服务花了多长时间。追踪最适合做性能分析和故障定位。

这三者缺一不可。我习惯把它们比作侦探破案：

• 指标是「报警电话」——告诉你出事了。
• 日志是「现场笔录」——记录每个细节。
• 追踪是「监控录像」——还原整个经过。

只有三者结合，你才能快速定位问题。举个例子：

有一次线上告警，说某个接口的 P99 延迟从 100ms 飙升到了 5s。指标告诉我「出问题了」。然后我通过追踪系统，发现这个请求在某个数据库查询上花了 4.8s。最后我查了那个数据库的慢查询日志，发现是一条 SQL 没有走索引。你看，指标、追踪、日志，缺一不可。

1.3 课程整体架构与学习路径

好了，说了这么多，咱们这门课到底要讲什么？我给大家梳理一下整体架构和学习路径。

这门课一共 30 个章节，我把它分成了四个阶段：

我个人建议的学习路径是这样的：

1. 先打基础：前 5 章一定要认真看。别急着上手工具，先把概念搞清楚。我见过太多人，ELK 搭得飞起，但连「什么是结构化日志」都说不清楚。
2. 动手实践：从第 6 章开始，每个章节都配有实战案例。我建议你跟着敲一遍代码，别光看。我记得我第一次搭 Jaeger 时，光配置就折腾了两天，但踩完坑之后，理解就深了。
3. 结合业务：学完基础篇和实战篇后，试着把你自己的业务系统接入可观测性。只有真正用起来，你才能体会到它的价值。
4. 关注进阶：最后 5 章是进阶内容，涉及大规模集群、成本控制等。这些内容可能你现在用不上，但等你系统规模上来了，你会发现它们才是真正的「救命稻草」。

好了，第一章的内容就到这里。下一章，咱们会深入聊聊日志收集的核心原理，包括日志的采集、传输、存储和检索。我会结合我在生产环境中的实际经验，给大家分享一些「避坑指南」。咱们下章见！