1. 课程导入与可观测性全景

在生产环境中，故障从来不会提前打招呼。一个订单接口突然变慢、一批定时任务静默失败、某个可用区的数据库连接数飙升——这些现象背后往往横跨计算、网络、存储、数据库、应用多个层次。Oracle Cloud Infrastructure（OCI）把可观测性能力拆成若干原生服务，再通过统一的数据模型把它们串起来。理解这套体系的全貌，是后续所有排障工作的起点。

OCI 可观测性体系由哪些服务构成

OCI 的可观测性不是单一产品，而是一组协同工作的服务，核心包括：

• Logging（日志服务）：统一采集、存储和检索日志。它既能接收 OCI 原生服务产生的日志（如 VCN 流日志、审计日志、负载均衡访问日志），也能通过 Unified Monitoring Agent 采集计算实例上的自定义日志。
• Monitoring（监控服务）：以指标（Metric）为核心，采集资源与服务的时序数据，支持告警规则、通知和指标查询语言 MQL。
• Application Performance Monitoring（APM）：面向分布式应用的追踪能力，通过 Trace 还原一次请求跨服务、跨进程的完整调用链。
• Service Connector Hub：可观测性数据的“路由器”，把日志、指标、追踪从源服务搬运到目标服务（如 Object Storage、Streaming、Functions），实现归档、二次加工或跨系统转发。
• Notifications 与 Events：前者负责把告警送达邮件、短信、Slack 等通道，后者基于资源状态变化触发自动化响应。

这些服务共享 IAM 权限模型、区间（Compartment）隔离和标签体系，因此可以按业务维度统一治理，而不是各管一摊。

三大支柱在 OCI 中的定位

日志、指标、追踪被称为可观测性的三大支柱，它们回答的问题并不相同：

三者的关系可以这样理解：指标负责发现异常，追踪负责定位瓶颈，日志负责解释原因。只靠指标，你知道“延迟涨了”，但不知道涨在哪个服务；只靠日志，你能看到报错，却难以判断影响面；只靠追踪，你能看到调用链变慢，但未必知道底层资源是否已经打满。生产排障的高效路径，通常是从指标告警切入，用追踪缩小范围，最后用日志确认根因。

生产故障诊断的核心挑战

在真实生产环境中，排障的困难往往不在工具本身，而在于几个结构性问题。

第一，数据分散且关联困难。一次请求可能经过负载均衡、API 网关、多个微服务、数据库和缓存。指标在 Monitoring 里，日志在 Logging 里，追踪在 APM 里，如果没有统一的关联标识（如 Trace ID、资源 OCID、区间路径），你很难把三份数据拼成一条完整证据链。

第二，噪声远多于信号。一个中等规模系统每天可能产生数百万条日志，其中绝大多数是正常信息。如果告警阈值设置过松，会频繁误报；设置过紧，又会漏掉真正的异常。指标同样如此，CPU 偶尔冲到 90% 未必是问题，但持续 5 分钟的高位就值得关注。

第三，时间窗口错位。用户报障的时间点、指标异常的时间点、日志中错误出现的时间点，三者可能相差几十秒到几分钟。如果排查时不统一时间基准（建议统一使用 UTC 或明确标注时区），很容易得出错误结论。

第四，权限与区间隔离带来的盲区。OCI 的 IAM 策略和区间结构决定了你能看到哪些资源。跨区间、跨租户的调用链如果权限配置不完整，追踪数据会出现断点，导致误判为“服务未响应”。

学习路径建议

本课程后续内容将按“先建体系、再练单点、最后串成闭环”的思路展开。建议的学习顺序是：

1. 先掌握 Logging 与 Monitoring 的基本操作：如何开启日志、如何编写 MQL 查询、如何配置告警规则与通知通道。
2. 再深入 APM：如何接入应用、如何阅读 Trace、如何利用 Span 定位跨服务瓶颈。
3. 然后学习 Service Connector Hub 与 Events，把可观测性数据接入自动化流程，实现“告警即响应”。
4. 最后通过综合故障场景演练，把指标、日志、追踪三者串联使用，形成可复用的排障方法论。