1. 课程导入与可观测性全景
在生产环境中，故障从来不会按照我们设计好的剧本出现。一个看似简单的“接口变慢”投诉，背后可能是某个区域的负载均衡器健康检查抖动、某个微服务的连接池耗尽、某条 Pub/Sub 订阅积压，或者干脆是上游依赖的第三方 API 触发了限流。Google Cloud 的可观测性套件正是为应对这种“症状与根因之间隔着多层抽象”的现实而设计的。本课程的目标不是让你记住每个产品的菜单在哪里，而是让你在面对一个真实的 SLO 劣化时，能够沿着一条清晰的证据链，从告警走到根因，并给出可验证的修复方案。
可观测性套件的组成与分工
Google Cloud 的可观测性能力并不是单一产品，而是一组围绕“采集—存储—分析—响应”四个环节协同工作的服务。理解它们各自的位置，比孤立地学习某个产品的按钮更重要。
Cloud Monitoring 是可观测性的中枢。它负责接收指标（Metrics）、管理告警策略（Alerting Policy）、维护自定义仪表盘（Dashboard）和正常运行时间检查（Uptime Check）。指标数据默认保留 6 周，这意味着你可以在故障发生后的数天内回溯对比。告警策略的核心不是“阈值设多少”，而是“用什么条件触发、通知谁、附带哪些标签”，这直接决定了故障响应的第一分钟是否有效。
Cloud Logging 负责日志的采集、路由和查询。它通过日志路由器（Log Router）把不同来源的日志分流到不同的接收端（Sink）：可以保留在 Logging 中供即时查询，也可以导出到 BigQuery 做长期分析，或导出到 Cloud Storage 做归档。生产故障诊断中，日志的价值往往不在于“有没有”，而在于“能不能在正确的时间窗口内，用正确的过滤条件把噪声去掉”。
Cloud Trace 提供分布式追踪能力。当一个请求穿过多个微服务时，Trace 会把每个服务内部的 Span 串联起来，形成一条完整的调用链。它回答的是“这个请求在哪个环节慢了”，而不是“这个服务整体慢不慢”。对于延迟类故障，Trace 通常是缩小范围的第一把手术刀。
Cloud Profiler 则从代码层面回答“CPU 和内存被谁消耗了”。它通过低开销的采样，持续收集函数级的资源使用画像。当监控显示某个 Pod 的 CPU 使用率异常升高，而日志和 Trace 都没有明显异常时，Profiler 往往能指出是哪个函数在“偷偷”消耗资源。
Error Reporting 负责聚合和归类应用错误。它把散落在日志中的异常堆栈自动归并成“错误组”，并统计发生次数和影响范围。它的价值在于把“日志里有很多报错”变成“有一个错误组在 10 分钟内从 0 涨到 2000 次”。
这五个产品的关系可以用一张全景图来理解：Monitoring 是指标和告警的入口，Logging 是事件和上下文的仓库，Trace 是请求路径的显微镜，Profiler 是代码资源的透视仪，Error Reporting 是异常聚合的看板。它们共享同一个项目边界和 IAM 权限体系，数据之间可以互相跳转，这是 Google Cloud 可观测性区别于“拼凑多个开源工具”的关键优势。
生产故障诊断的核心挑战
可观测性工具再强大，也不能自动消除故障诊断中的固有困难。这些困难可以归纳为五个方面，理解它们有助于你在后续章节中带着问题去学习，而不是被动地记忆功能。
第一，症状与根因之间存在多层抽象。用户报告“页面打不开”，可能对应的是前端 CDN 缓存失效、后端 API 超时、数据库连接池满、或者某个中间件线程阻塞。每一层都有自己的指标和日志，但没有任何一层会直接告诉你“根因在这里”。诊断的本质是沿着证据链逐层排除，而不是期待一个“一键定位”的按钮。
第二，数据量大但信噪比低。一个中等规模的生产系统每天可能产生数十 GB 的日志和数百万个时间序列。如果告警策略设置不当，你会被淹没在通知里；如果日志过滤条件写得太宽，查询结果会多到无法阅读。真正有效的诊断，往往依赖于“在正确的时间窗口内，用正确的标签组合，把数据缩小到可读的范围”。
第三，时间窗口难以对齐。监控指标的时间戳、日志的时间戳、Trace 的 Span 时间戳，可能来自不同的采集代理，存在秒级甚至分钟级的偏差。当你试图把“CPU 在 14:23:10 飙升”和“日志在 14:23:15 出现超时”关联起来时，需要先确认这些时间是否在同一个时钟基准上。Google Cloud 的指标和日志默认使用 UTC 时间戳，但应用日志如果由应用自己写入，可能使用本地时区，这是排查时常见的陷阱。
第四，多服务调用链容易断裂。在微服务架构中，一个请求可能经过 5 到 10 个服务。如果某个服务没有正确传递 Trace 上下文（Trace Context），调用链就会在那里断开，导致你只能看到前半段，看不到后半段。诊断这类问题时，需要同时检查 Trace 的完整性、日志中是否有 Trace ID 字段、以及服务间是否使用了统一的追踪库。
第五，告警疲劳与误报。如果每个指标都设一个阈值告警，运维团队很快会对通知麻木。有效的告警策略应该基于 SLO（Service Level Objective）的燃烧率（Burn Rate），而不是简单的静态阈值。例如，对于一个 99.9% 可用性的 SLO，当错误预算在 1 小时内消耗超过 2% 时触发告警，比“错误率超过 1% 就告警”更能反映真实的服务健康度。
课程学习路径与实战环境准备
本课程共 30 章，按照“先建立全景，再深入工具，最后综合实战”的逻辑组织。前几章会逐一拆解 Monitoring、Logging、Trace、Profiler 和 Error Reporting 的核心概念与操作；中间部分会进入告警策略设计、SLO 管理、日志查询语言、Trace 分析技巧等专题；后段则会通过一个模拟的生产故障场景，把前面学到的工具串联起来，完成一次从告警到根因定位的完整演练。
为了能够动手实践，你需要准备一个 Google Cloud 项目，并确保以下条件满足：
- 项目已启用结算（Billing），因为部分可观测性功能在免费额度之外会产生费用。
- 当前账号拥有
roles/monitoring.admin、roles/logging.admin、roles/cloudtrace.admin等角色，或者直接使用 Owner 角色进行学习。 - 已安装并初始化
gcloudCLI，可以通过gcloud config list确认当前项目。 - 准备一个可部署的示例应用（课程中会提供基于 Cloud Run 的微服务示例），用于产生真实的指标、日志和 Trace 数据。
如果你暂时没有生产环境，可以使用 Google Cloud 提供的 Observability 沙盒项目，或者用 Terraform 脚本快速创建一个包含 Cloud Run、Pub/Sub 和 Cloud SQL 的最小环境。课程中的示例参数（如项目 ID、区域、服务名）均为教学假设，你需要替换成自己的实际值。
最后需要强调的是，可观测性不是“装好工具就完事”的一次性任务，而是一种持续改进的工程实践。工具会告诉你“发生了什么”，但“为什么发生”和“如何防止再次发生”仍然依赖你对系统架构、依赖关系和业务逻辑的理解。本课程的目标，是让你在面对一个真实的 SLO 劣化时，能够有条不紊地沿着证据链走下去，而不是在多个控制台之间盲目切换。