课程导入：可观测性定义、三大支柱（指标、日志、链路）的关系、课程目标与学习路径
欢迎来到《云原生可观测性：Prometheus+Grafana+Loki栈实战》的第一章。在深入工具链之前，我们需要先建立一个共识：什么是可观测性？为什么它不仅仅是“监控”的换皮？在云原生环境中，系统由成百上千个微服务、容器、Service Mesh和Serverless函数构成，传统的“黑盒监控”已经无法回答“为什么系统变慢了”或“这个错误从哪里来”的问题。本章将为你奠定整个课程的理论基石，厘清指标（Metrics）、日志（Logs）、链路追踪（Traces）三大支柱的职责边界与协作关系，并明确你在未来30章中的学习路径与实战目标。
1.1 可观测性的定义：从监控到可观测性的范式迁移
核心原理：可观测性（Observability）源自控制理论，指系统内部状态可以通过外部输出被推断的程度。在软件工程中，它强调通过收集和分析系统产生的遥测数据（Telemetry Data），来回答任意关于系统行为的未知问题——即使这些问题在开发时并未预见到。传统监控（Monitoring）关注“已知的未知”（如CPU超过80%告警），而可观测性关注“未知的未知”（如为什么某个特定用户请求会偶发超时）。
在云原生环境中，系统拓扑动态变化、故障模式复杂，可观测性已成为与弹性、可移植性并列的核心能力。它不仅仅是工具链的堆砌，更是一种工程文化：所有组件都必须暴露其内部运行状态。三大支柱——指标、日志、链路追踪——正是实现这一目标的三类标准化数据模型。
| 维度 | 传统监控 | 云原生可观测性 |
|---|---|---|
| 关注点 | 基础设施健康（CPU、内存、磁盘） | 用户体验、业务SLO、分布式依赖 |
| 数据形态 | 离散的数值指标 | 指标+日志+链路三位一体 |
| 查询方式 | 预定义图表和固定告警 | 按需探索、临时查询、关联分析 |
| 故障处理 | 告警触发后人工排查 | 通过数据关联快速定位根因 |
判断方法：如何判断你的团队是否真正需要可观测性？当出现以下任一场景时，传统监控已力不从心：
- 一个请求跨5个以上微服务，无法通过单机日志定位延迟来源。
- 系统整体CPU不高，但用户反馈“卡顿”，无法用现有指标解释。
- 新版本上线后出现偶发错误，但错误日志分散在多个服务中。
1.2 三大支柱的职责边界与协作关系
核心原理：三大支柱并非三个孤立系统，而是同一事实的不同投影。指标提供趋势与状态，日志提供事件详情，链路追踪提供请求路径与耗时分解。它们的关系可以类比为：指标是“体温计”，告诉你发烧了；日志是“病历”，记录每次咳嗽和用药；链路追踪是“CT扫描”，精确定位病灶在哪根血管。
在实际排障中，三者必须协同工作。例如，Prometheus告警“P99延迟超过500ms”，此时需要查看Grafana仪表盘确认是哪个服务，然后通过Loki查询该服务的错误日志，最后通过Tempo或Jaeger查看该请求的完整链路，找到瓶颈Span。这种“指标→日志→链路”的降维排查路径，是云原生排障的标准动作。
三大支柱数据特征对比
| 特征 | 指标（Metrics） | 日志（Logs） | 链路（Traces） |
|---|---|---|---|
| 数据形态 | 数值型时间序列 | 文本（结构化或非结构化） | 树状Span结构 |
| 典型工具 | Prometheus, Thanos | Loki, ELK | Jaeger, Tempo, Zipkin |
| 存储成本 | 低（高压缩率） | 高（文本量大） | 中（需采样控制） |
| 查询语言 | PromQL | LogQL | TraceID查询/服务图 |
| 主要用途 | 告警、趋势分析、SLO | 错误详情、审计、调试 | 性能瓶颈、依赖分析 |
常见误区：很多团队将日志作为唯一数据源，试图通过“全量日志+关键字搜索”解决所有问题。这会导致两个后果：一是存储成本爆炸，二是无法回答“这个请求为什么慢”这类需要跨服务关联的问题。正确的做法是：用指标做筛选，用链路做定位，用日志做细节确认。
1.3 课程目标：构建统一可观测性平台
核心原理：本课程的目标是让你掌握一套基于Prometheus + Grafana + Loki + Tempo（可选）的开源技术栈，能够从零搭建一个覆盖指标、日志、链路三大维度的可观测性平台。课程强调“实战”而非“理论”，每一章都会围绕一个真实场景展开。
完成本课程后，你将具备以下能力：
- 指标体系设计：使用Prometheus采集K8s、应用、中间件指标，编写PromQL进行聚合分析，设计基于SLO的告警规则。
- 日志聚合分析：部署Loki，使用Promtail采集容器日志，通过LogQL进行全文检索和标签过滤，实现日志与指标联动。
- 链路追踪落地：集成OpenTelemetry SDK，将Trace数据发送至Tempo，在Grafana中实现“指标→日志→链路”的无缝跳转。
- 可视化与告警：构建专业的Grafana Dashboard，配置多级告警通知（钉钉/邮件/Webhook），建立故障响应SOP。
1.4 学习路径与章节地图
判断方法：课程分为四个阶段，每个阶段都有明确的交付物。建议按照顺序学习，因为后续章节会依赖前面搭建的环境。
| 阶段 | 章节范围 | 核心交付物 | 关键技能 |
|---|---|---|---|
| 基础篇 | 第1-5章 | 可观测性理论、Prometheus部署、指标采集 | PromQL基础、Exporter开发 |
| 进阶篇 | 第6-15章 | Grafana可视化、告警规则、Loki日志平台 | Dashboard设计、LogQL、告警收敛 |
| 高级篇 | 第16-25章 | 链路追踪、OpenTelemetry、K8s监控 | Trace采样、Service Mesh可观测性 |
| 实战篇 | 第26-30章 | 电商系统全链路监控、故障演练 | 排障方法论、容量规划、SLO管理 |
学习建议：每章结束后，请务必完成课后实验。建议准备一台4核8G的虚拟机或云主机（或使用Minikube），操作系统为Ubuntu 22.04。所有实验均提供Docker Compose或Helm Chart部署方式，确保你可以在本地完整复现。
1.5 案例拆解：一次真实的“慢请求”排障闭环
场景描述：某电商平台在促销活动期间，用户反馈“提交订单”页面响应时间从正常的200ms增加到5秒以上。运维团队通过传统监控发现所有服务器CPU、内存均正常，但业务指标显示订单接口成功率下降至95%。
排障过程：
- 第一步（指标）：在Grafana中查看订单服务的P99延迟曲线，发现从10:30开始飙升。同时查看Prometheus中该服务的QPS，发现流量并未明显增长，排除流量突增导致。
- 第二步（日志）：通过Loki查询订单服务日志，关键词“timeout”和“exception”，发现大量“Redis连接池获取连接超时”错误。日志时间戳与延迟飙升时间吻合。
- 第三步（链路）：在Tempo中搜索一条失败的订单Trace，发现Span“Redis GET user_cart”耗时4.8秒，而正常耗时小于5ms。进一步发现该Redis实例的CPU使用率并不高，但连接数达到上限。
- 根因：Redis最大连接数配置为1000，但促销活动导致连接数打满，新请求等待连接池释放。
- 解决：调整Redis连接池大小并增加最大连接数，同时优化代码中的连接释放逻辑。
复盘经验：如果没有链路追踪，我们可能需要花费数小时在多个服务日志中切换；如果没有日志，我们无法知道具体是Redis超时；如果没有指标，我们甚至不知道延迟从何时开始。三大支柱缺一不可，它们共同构成了排障的“黄金三角”。
总结复盘：本章的核心不是工具，而是思维。可观测性是一种“假设驱动”的排障方法：先通过指标缩小范围，再通过链路定位路径，最后通过日志确认细节。在后续章节中，我们将逐一实现这套方法论的工具链。请务必理解三大支柱的边界与协作方式，这是整个课程的地基。