Google PCNE: 网络可观测性、可靠性和故障排除 — 学习指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

属于 Google Professional Cloud Network Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概览

Google Cloud 上的网络可观测性是指对描述 VPC、负载均衡器、混合连接和服务的可达性、性能和正确性的网络信号进行规范化的收集、关联和分析。可靠性源于为故障检测和安全修复而进行的设计：部署一流的遥测，在接触数据平面之前验证控制平面，仅在必要时通过数据包证据进行深入分析，并实现自动化回滚。本节将解释如何使用 Google Cloud 的工具和模式来检测、诊断和预防问题，同时在变更期间将风险降至最低。

流日志、日志记录、监控、指标和 SLO

VPC Flow Logs 在 VPC 防火墙评估后，于虚拟机网卡 (VM NIC) 层面提供经过采样和聚合的遥测数据。它们不是完整的数据包捕获，也不能替代防火墙规则日志记录来提供明确的允许/拒绝证据。关键控制项：

• 采样：0.0–1.0。更高的采样率能提高保真度，但会增加日志量和潜在成本。
• 聚合间隔：5秒–30分钟。更短的间隔可以缩短检测时间，但会增加条目数。
• 元数据：包含或排除实例和 VPC 元数据。包含元数据可进行更丰富的分析，排除则可限制敏感属性。

在子网上启用的典型命令：

• gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –logging-flow-sampling=0.5 –logging-aggregation-interval=interval-5-min –logging-metadata=INCLUDE_ALL_METADATA

使用日志接收器导出，以进行持久化分析和跨项目共享：

• BigQuery：用于 SQL 分析和长期趋势分析。
• Pub/Sub：用于向 SIEM/IDS 发送近乎实时的管道。
• Cloud Storage：用于归档。
• 导出到 BigQuery 的接收器示例：
  • gcloud logging sinks create flowlogs-to-bq bigquery.googleapis.com/projects/PROJECT/datasets/DATASET –log-filter=‘resource.type=“gce_subnetwork”’

防火墙规则日志记录通过记录允许/拒绝决策和匹配的规则来补充流日志。要观察被阻止的流量，请在规则集的底部附近添加一条启用了日志记录的全部拒绝规则：

• gcloud compute firewall-rules create deny-all –network=VPC –priority=65500 –direction=INGRESS –action=DENY –rules=all –enable-logging

Cloud Logging 允许进行结构化查询，并与请求日志、健康检查日志、NAT 日志和负载均衡器日志进行关联。为以下信号创建基于日志的指标：

• 到后端标签的被拒连接突然增加（可能是白名单配置错误）。
• 到某个端口的大量 SYN 重传（可能是饱和或黑洞）。
• NAT “无可用端口” 事件 (Cloud NAT 资源耗尽)。

Cloud Monitoring 聚合指标并提供仪表盘、告警和 SLO：

• 需要关注的指标：负载均衡器 5xx 速率、后端延迟、实例网卡字节数/数据包数、Cloud NAT 已分配/已使用/溢出端口数、Cloud Router BGP 会话状态、VPN 隧道丢包、Interconnect 链路利用率、丢包率和延迟。
• 仪表盘：为每个服务和每个连接构建仪表盘，并在项目间使用共享模板以实现一致的操作。
• 告警：优先选择能快速反馈的症状告警（错误率、延迟、丢包计数器），并在可能影响用户时，对原因告警（BGP 抖动、链路中断）进行呼叫通知。
• SLO：定义以用户为中心的 SLO（例如，全局 HTTP 成功率和延迟），并使用消耗速率告警来识别快速和慢速消耗。通过基于日志的指标，使用请求日志作为分子/分母，以进行精确的 SLO 评估。

权衡与故障模式：

• 低采样率或长聚合间隔会隐藏微突发和短暂的故障。
• 流日志无法看到防火墙处理前的丢包；需要依靠防火墙规则日志记录来获取拒绝证据。
• 不加筛选地记录过多日志会增加成本并可能减慢调查速度；应智能地导出和分区数据。

Network Intelligence Center 和高级诊断

Network Intelligence Center (NIC) 提供主动且结构化的诊断功能：

Connectivity Tests：

• 验证跨越路由、防火墙规则（包括分层策略）、服务账号/标签、负载均衡器、Cloud NAT 和混合连接的控制平面可达性。
• 路由诊断会计算选定的下一跳，并报告配置错误，例如路由缺失或非对称路径。
• 在任何网络变更前后使用，以检测意外的爆炸半径。它对控制平面进行建模，但不能保证数据平面的质量；需与数据包/指标证据结合使用。

Performance Dashboard：

• 一个由 Google 管理的视图，显示跨区域以及到互联网观测点的丢包和延迟。可用于检测宏观事件（区域性或全路径拥塞）与服务本地问题。

Network Topology：

• 可视化跨项目、跨 VPC 和混合连接及其流量（利用日志），以识别热点、意外的对等路径以及您可能不希望出现的传递行为。

Firewall Insights：

• 检测被遮蔽的规则、未使用的允许规则、过于宽松的来源以及缺少目标标签/服务账号的规则。它会推荐更严格的规则，以在不破坏已知流量的情况下减少攻击面。

Network Analyzer：

• 跨项目的静态和动态配置检查，以发现如下情况：
  • 健康检查被防火墙阻止（请记住允许 Google 健康检查源 IP 范围）。
  • 负载均衡器后端位于错误的区域或缺少命名端口。
  • 禁用了 Private Google Access 的子网会阻止没有外部 IP 的实例访问 API。
  • 导致重要前缀被黑洞的路由，或跨 VPN/Interconnect 的非对称路由。

操作指南：

• 将 NIC 检查集成到网络变更的 CI/CD 流程中，并按计划周期运行。将发现的问题视为可靠性债务，并根据其降低风险的影响来确定修复的优先级。

数据包镜像、负载均衡器和混合遥测

数据包镜像：

• 将虚拟机流量镜像到一个收集器（设备或托管式 IDS）以进行深度检查。按子网、网络标签或服务账号限定范围；限制为必要的协议以控制成本。
• 开销和权衡：镜像流量的出站会产生费用；过度的镜像可能会给收集器带来压力；不要在生产环境中随意进行镜像。针对事件，应使用有时间限制、范围狭窄的会话。
• IDS 集成：
  • Cloud IDS 利用数据包镜像提供托管的、带外的威胁检测。优先选择它以实现快速激活和减少维护工作。
  • 在需要特定签名或供应商生态系统的情况下，第三方 IDS 设备仍然是可行的选择。

负载均衡器日志和健康检查证据：

• HTTP(S) 负载均衡器的请求日志包含方法、URL、后端、响应代码、延迟以及通过 X-Forwarded-For 获取的客户端 IP。由于 traceroute 会在 Google Front Ends (GFEs) 处停止，因此应使用这些日志进行客户端路径分析。
• 在后端服务上启用日志记录，并配置采样以平衡成本与可见性。开启健康检查日志记录，以查看探测结果和失败原因。
• 限制客户端访问：通过标记实例并创建防火墙规则，在后端强制执行访问控制，只允许已批准的客户端范围和 Google 健康检查 IP。对于 L7 威胁缓解和逐步部署，应在强制执行前以预览模式使用 Cloud Armor 规则。

VPN 和 Interconnect 遥测：

• Cloud VPN (HA VPN) 指标：字节数、丢包数、加密错误、隧道正常运行时间以及 BGP 会话状态。针对数据包丢弃、频繁的 DPD 事件和 BGP 抖动设置告警。
• 吞吐量扩展：添加指向不同对等 IP 的隧道并分发流量；监控余量。如果您需要在 Cloud Routers 之间实现主备模式，优先使用本地的 MED 属性来影响路径选择。
• Interconnect 指标：每条链路的利用率、CRC 错误和可用性；关注持续超过 60–70% 的利用率和错误峰值。保持备用容量和多样化的线路。通过重传和排队指标来调查延迟增加的原因。
• 跨边缘的饱和信号：TCP 重传次数上升、在没有代码变更的情况下 99 百分位延迟增加、NAT 端口溢出事件以及队列占用率告警，这些都是即将产生影响的早期预警。

故障排查方法、事件处理和主动可靠性

从 DNS 到应用的结构化故障排查：

1. 识别出故障的用户流程和时间窗口；定位到具体区域和路径（通过 LB 的公共路径、通过 VPC 的私有路径或混合路径）。
2. DNS:

• 使用 Cloud DNS 日志、dig 输出和策略行为来验证解析。检查分离 DNS (split-horizon) 冲突，并确保转发策略已生效。
• 确认 TTL 和近期变更；陈旧的缓存可能会模拟服务中断。

3. 负载均衡器和边缘： -审查请求和健康检查日志。将 5xx 错误峰值与后端健康状况和部署事件关联起来。对于 L7，应信任请求日志而非 traceroute。

• 当访问受限时，验证防火墙规则中的客户端白名单和 Google 健康检查 IP。

4. 路由和防火墙：

• 使用 Connectivity Tests 进行确定性的控制平面评估。检查有效路由和分层防火墙策略。寻找非对称路由和被覆盖的规则。
• 对于被拒绝的数据包，依赖防火墙规则日志记录；在调查期间，可考虑在优先级堆栈的底部附近添加一条启用日志记录的全部拒绝规则。

5. 到 Google API 的出站流量：

• 如果实例没有外部 IP，请确认 Private Google Access 和/或 Cloud NAT 是否已配置。缺少任何一个都会导致间歇性故障和令人困惑的超时。

6. 混合连接：

• 检查 Cloud Router 和 VPN/Interconnect 指标。BGP 状态为 up 但路由未安装可能反映了属性偏好；验证 MED/local-pref 和 ASN。关注丢包和路径 MTU 问题。

7. 数据包证据：

• 如果控制平面看起来正确但症状持续存在，可小范围地使用 Packet Mirroring 在受影响的虚拟机或层级附近收集 PCAP；检查 SYN/SYN-ACK 计时、重传和 MSS/DF 位以发现 MTU 黑洞。

事件处理：

• 变更安全：通过将范围限定于标签/服务账号、使用较低优先级和禁用规则来分阶段进行变更；启用日志记录并通过金丝雀测试进行验证。对 L7 策略变更使用 Cloud Armor 预览模式。
• 回滚：预先定义回滚变更，将先前的配置保存在版本控制中，并在适用的情况下在应用边缘使用短生命周期的功能标志。
• 事后分析：根据日志和指标构建时间线，对促成因素进行分类（例如，宽松的允许规则被拒绝规则覆盖、NAT 耗尽），记录检测盲点，并添加保障措施：警报、NIC 检查和策略加固。

容量规划和主动可靠性：

• 跟踪余量目标：VPN/Interconnect 链路上保持 30–50% 的余量，NAT 端口持续使用率低于 60%，LB 后端 CPU 和 QPS 远低于自动扩缩容触发条件。
• 为关键风险构建基于日志的指标：拒绝流量峰值、NAT 溢出、BGP 抖动计数、5xx 错误率和 LB 后端连接错误。使用多窗口消耗率警报来捕捉快速和慢速事件。
• 综合监控：使用来自多个区域的 Uptime Checks 监控公共端点，并使用来自测试虚拟机的私有探测监控内部服务。
• 预防性改进：使用 Firewall Insights 优化防火墙规则，解决 Network Analyzer 的发现，在高峰事件期间缩短 Flow Log 聚合间隔，并将日志导出到 BigQuery 以进行周期性异常检测。

实际问题场景

Contoso Games 在 us-east1 和 europe-west1 运营一个全球性的 HTTP(S) 负载均衡游戏 API，并通过 HA VPN 连接到一个本地数据中心。欧洲用户报告在最近一次防火墙变更后出现间歇性超时和较高延迟。实例没有外部 IP，必须通过私有方式访问 Google API。

处理方法：

1. 确定时间窗口和 SLO 影响

• 理由：精确定位时间窗口可将查询范围限制在相关日志内，并将调查与影响用户的 SLO 对齐。一个消耗率警报确认了 europe-west1 区域的 SLO 正在快速消耗。

2. 使用 Connectivity Tests 验证控制平面

• 理由：创建一个从外部 HTTP(S) 负载均衡器前端到 europe-west1 后端服务的测试，以及一个从受影响的虚拟机到 Private Google Access VIP 的测试。测试标记出一个分层防火墙策略正在阻止对某些后端的健康检查，并且有一个子网缺少 Private Google Access 配置。

3. 通过日志确认边缘和后端健康状况

• 理由：筛选 europe-west1 的负载均衡器请求日志，条件为 response_code >= 500，以隔离后端错误。健康检查日志显示来自已知 Google 健康检查源 IP 的探测失败。这证明了是防火墙引起的后端抖动，而非应用回归。

4. 通过范围受限的变更恢复健康并保障安全

• 理由：添加一条以后端标签为目标的允许规则，允许健康检查源 IP 范围的流量。在此规则上启用日志记录。由于访问仅限于已知客户端，请验证白名单防火墙规则仅包含特定的客户端 IP 范围和健康检查范围。初始时保持新规则禁用，然后在低流量金丝雀测试期间启用，以限制爆炸半径。

5. 重建到 Google API 的私有出站流量

• 理由：在受影响的子网上启用 Private Google Access，以便没有外部 IP 的实例能够访问 Google 服务，而无需通过 VPN 或第三方防火墙进行发夹弯（hairpinning）。这可以降低延迟并消除一个瓶颈点。

6. 检查混合连接饱和度与 MTU

• 理由：审查 HA VPN 的丢包和利用率指标。一个隧道显示丢包率升高。通过向不同的本地对等 IP 添加第二个隧道来增加容量并分发流量。验证有效 MTU 和 MSS 钳制，以防止 VPN 路径上出现 PMTU 黑洞。

7. 对可疑的滥用客户端使用 Cloud Armor 预览模式

• 理由：从请求日志中发现，一小部分客户端 IP 在探测失败前流量激增。在 Cloud Armor 中添加一条使用预览模式的拒绝规则，以便在强制执行前验证阻止这些 IP 是否能减少后端负载，从而避免意外的用户影响。

8. 小范围使用 Packet Mirroring 确认数据平面行为

• 理由：将来自单个不健康后端虚拟机的流量镜像到 Cloud IDS，持续 15 分钟。PCAP 显示，在来自滥用 IP 的流量突发期间，出现了 SYN 积压耗尽，这证实了 Cloud Armor 策略的有效性以及实施速率限制的必要性。

9. 关闭事件并进行加固

• 理由：在启用健康检查允许规则、确认 Private Google Access、扩展 VPN 容量并强制执行经过审查的 Cloud Armor 规则后，错误率恢复到基线水平。为健康检查成功率、NAT 端口使用率、VPN 丢包率和各区域的 5xx 错误率添加仪表盘。创建基于日志的警报，用于监控针对后端标签的防火墙拒绝事件和 SLO 消耗率警报。记录该事件、根本原因（分层防火墙变更；滥用流量；VPN 饱和），并将 NIC Analyzer 和 Firewall Insights 检查添加到变更前检查清单中。

此序列展示了一个安全的、证据驱动的工作流：确认控制平面，观察数据平面，应用最小化的、可逆的变更，然后通过警报和自动化检查将经验制度化。

← GKE、容器和应用网络 · 所有领域 · 网络自动化、治理和成本运营 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →