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

在 AWS 上排查网络问题，最令人头疼的往往不是“修不好”，而是“看不见”。当一个跨可用区的微服务调用出现间歇性超时，或一次跨区域复制突然变慢时，如果没有足够的数据支撑，工程师只能凭经验猜测：是安全组规则、NACL、路由表、NAT 网关、还是应用本身的问题？网络可观测性（Network Observability）要解决的正是这个“看不见”的问题——它通过系统性地采集、关联和分析网络各层产生的数据，把黑盒变成可推理的白盒。

需要先区分两个容易混淆的概念：监控（Monitoring）回答“系统是否正常”，依赖预先定义的指标和告警；可观测性（Observability）回答“为什么出现异常”，它要求数据足够丰富，能支持对未知问题的探索式排查。监控告诉你“延迟升高了”，可观测性则让你能追问“是哪条路径、哪个 ENI、哪个五元组、在哪个时间点开始升高的”。

四类核心数据来源

AWS 网络可观测性的数据可以归纳为四个支柱，它们各自回答不同层次的问题：

• 指标（Metrics）：CloudWatch 提供的时序数值，如 NAT 网关的 ActiveConnectionCount、ErrorPortAllocation，ALB 的 TargetResponseTime、UnHealthyHostCount，以及 VPC 流日志聚合出的 BytesOutToDestination。指标适合发现趋势和触发告警，但粒度粗、缺少上下文。
• 日志（Logs）：包括 VPC Flow Logs、Route 53 Resolver Query Logs、ALB/NLB 访问日志、CloudFront 日志、WAF 日志。日志是排查“具体哪个连接被拒绝”的关键，Flow Logs 中的 ACCEPT/REJECT 字段能直接定位安全组或 NACL 拦截。
• 追踪（Traces）：AWS X-Ray 以及 OpenTelemetry 采集的分布式追踪，把一次请求经过的每个服务、每次下游调用串成一条链路，能看出延迟发生在哪一跳。
• 流日志与流量镜像（Flow Logs / Traffic Mirroring）：Flow Logs 记录元数据（五元组、字节数、动作），Traffic Mirroring 则复制原始报文到分析实例，用于深度包检测。

这四类数据不是互相替代，而是互补。一个典型的排查路径是：指标告警发现异常 → 追踪定位到具体服务 → 日志确认连接被拒 → 流日志锁定源/目的与规则。理解它们各自的能力边界，是后续所有章节的基础。

故障诊断的基本流程

面对一个网络故障，盲目地逐个检查配置效率极低。一个可复用的诊断流程应当遵循“先界定、再分层、后验证”的原则。

第一步是界定范围。先回答几个问题：影响的是单个实例、单个可用区，还是整个区域？是持续发生还是间歇性？从什么时间点开始？这些信息决定了后续应该看哪个时间窗口的指标、哪个范围的流日志。例如，如果只有 us-east-1a 的实例受影响，那么问题很可能与可用区级别的 NAT 网关或子网路由相关，而不是全局性的安全组规则。

第二步是分层排查。AWS 网络路径可以按 OSI 层次拆解：安全组（有状态、实例级）→ 网络 ACL（无状态、子网级）→ 路由表（决定下一跳）→ DNS 解析（Route 53 Resolver）→ 应用监听。每一层都有对应的可观测数据。安全组和 NACL 的拦截会体现在 Flow Logs 的 REJECT 记录中；路由问题会导致流量根本不到达目标，Flow Logs 中可能完全没有记录；DNS 问题则要看 Resolver Query Logs。

第三步是定位证据。不要停留在“看起来像是安全组问题”，而要找到确凿的数据。例如，在 CloudWatch Logs Insights 中查询 Flow Logs：

fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| filter dstPort = 443
| sort @timestamp desc
| limit 20

如果返回的记录显示源 IP 属于你的应用子网、目的端口 443、动作为 REJECT，那么就可以确认是安全组或 NACL 拦截了出站流量。接下来再对比安全组的出站规则和 NACL 的出站规则，就能定位到具体是哪一条规则缺失或过严。

第四步是验证修复。修改规则后，不能仅凭“感觉好了”就收工。应当使用 VPC Reachability Analyzer 对源 ENI 和目的 ENI 做一次路径分析，确认路径可达；同时观察 CloudWatch 指标中相关计数是否回落，例如 UnHealthyHostCount 归零、TargetResponseTime 恢复到基线。只有数据确认恢复，才算闭环。

工具链概览与选择逻辑

AWS 提供的网络诊断工具很多，但并非每个问题都需要全部用上。选择工具的核心逻辑是：先确定数据源，再选择查询方式。