谷歌云返点 GCP谷歌云流量异常排查

前言：流量异常，别先怀疑人生

做云上的人，最常见的“情绪触发器”之一，就是那句：告警说你的流量异常了。你还没来得及泡杯咖啡，监控图已经像心电图一样起伏不定；告警群里消息像弹幕一样刷屏，大家都在问：是不是被攻击了？是不是配置改坏了？是不是业务突然爆发了？

但问题是：你得先把“异常”是什么弄清楚。流量异常不是一个具体的故障描述，它更像天气预报：可能是下雨，也可能是下冰雹。你得先看云层（监控指标），再查雷达（日志与追踪），最后才决定要不要带伞（修复动作）。

下面我会按一条比较稳的排查路线，带你从“告警现象”走到“可验证结论”。文章会以 GCP 为背景，重点覆盖常见入口：负载均衡、Cloud CDN、Cloud Armor、VPC、防火墙、Cloud Logging/Monitoring、以及和账号/配额相关的一些坑。你可以把它当成排查剧本：每一步都知道自己要找什么证据。

第一步：先确认“异常”到底长什么样

排查的第一条铁律：先不要翻代码，不要急着改配置。先确认异常的形态。因为不同形态通常对应不同原因，能显著缩短排查时间。

1）异常是“突然飙升”，还是“缓慢爬坡”

如果是突然飙升，常见原因包括：

• 新版本上线导致调用次数增加
• 某个客户端重试风暴（比如超时重试策略不当）
• 爬虫/攻击流量开始涌入
• 负载均衡后端健康检查异常，导致转发策略变化
• 谷歌云返点 CDN 缓存命中率突然下降（源站压力瞬间增加）

如果是缓慢爬坡，常见原因包括：

• 真实业务增长（别急着否定它）
• 统计口径变化（比如指标维度改了）
• 慢性资源泄漏导致响应变慢进而触发更多重试
• 某段代码逐渐放大请求（例如分页游标异常）

建议你在告警发生后，第一时间截取关键时间窗（例如前后 30 分钟、1 小时、24 小时），观察走势。

2）异常是“入站”还是“出站”

有些人看到“流量异常”第一反应是入站被打了，但其实可能是出站（比如服务在向外请求时增加了）。

典型做法是把监控指标按方向拆开：

• 入站：Ingress 流量、LB 收到的请求数、HTTP(S) 请求数
• 出站：Egress 流量、服务对外调用请求

如果你是对外提供 API，通常关注入站；如果你是做爬取/代理/抓取，关注出站；如果你是内部服务互调，关注东西向（VPC）流量。

3）异常集中在哪些维度

维度越细，线索越直接。优先观察：

• 来源 IP 段（或国家/地区，如果有地理维度）
• 谷歌云返点 请求路径（/api/v1/xxx 还是 /login 之类）
• HTTP 状态码分布（2xx/4xx/5xx 的结构很关键）
• 用户代理（User-Agent）
• 协议（HTTP/HTTPS、QUIC/HTTP3，如果涉及）
• 后端服务/实例（哪个后端被打了）

举个直观例子：如果 5xx 飙升且集中在某个路径，八成跟后端错误有关；如果 4xx 飙升且来自特定 UA，可能是探测或爬虫；如果请求量飙升但 2xx 正常，可能是业务活动或缓存未命中导致请求更多。

第二步：快速定位流量“落点”——从入口到后端

GCP 的网络架构通常有“入口层”。入口层决定了你应该去哪里看日志和指标。你要做的事情，是把路径从“外部请求”追到“实际处理的服务”。

1）你的入口是哪个？（HTTP(S) LB / TCP LB / Ingress / VPN / 直接实例）

常见入口：

• Cloud Load Balancing：HTTP(S) Load Balancer、Network Load Balancer、SSL Proxy 等
• Cloud CDN：配合 HTTP(S) LB
• GKE Ingress：通常也是 LB 的一种表现
• Cloud NAT：用于出站，但有时被误认为是入站异常（要注意方向）
• 直接暴露的 VM 端口：这种情况需要非常小心，排查时要结合防火墙与实例日志

你可以先问自己一句：异常的请求“看起来像 HTTP 请求”还是“像别的协议”。如果监控里是 HTTP 维度，那优先从 HTTP(S) LB 和 Cloud CDN 查。

2）负载均衡的关键指标：请求数、延迟、错误率、后端健康

在 GCP Monitoring 里，LB 常见可观察的维度包括：

• Request Count：请求数
• Response Latency：延迟
• HTTP 4xx/5xx：错误码分布
• Backend Latency / Backend Healthy Hosts

排查技巧：把请求量和错误率放在同一个时间轴上看。比如：

• 请求量猛增但错误率不变：更像业务流量增长、爬虫但未触发应用异常，或 CDN 命中降低但应用能处理
• 请求量不一定巨大，但 5xx 急剧上升：可能是后端故障、依赖超时、数据库压力或代码异常
• 健康检查失败导致后端“变少”，随后错误率上升：典型是资源不足或应用不可用

谷歌云返点 3）如果启用了 Cloud CDN：盯住缓存命中率

CDN 的“异常”往往不体现在“总流量变了”，而是体现在“缓存命中率突然下滑”，导致更多请求落到源站。你的总费用也可能悄悄升温。

你可以重点观察：

• Cache Hit Ratio（缓存命中率）
• Cache Miss 带来的源站请求量
• 源站响应码（源站 4xx/5xx 是否激增）
• 缓存配置变化（Cache-Control、path rules、query string 规则）

一个常见翻车点是：某次上线改了响应头（Cache-Control），导致原本能缓存的资源变成不能缓存，命中率快速下降。结果就是“流量异常”只是表象，真正的问题是缓存策略被无意改坏了。

第三步：用日志把“猜测”变成“证据”

监控告诉你“异常发生了”，日志告诉你“异常为何发生”。你需要把日志落到两个层次：访问/网络层日志，以及应用层日志。

1）优先看访问日志与负载均衡日志

在排查 GCP 流量异常时，访问日志通常是最直接的证据：谁在访问、访问了什么路径、是否有重试、TLS 证书相关信息等。

你可以关注这些字段（具体以你的日志类型为准）：

• src_ip：来源 IP
• request_path：请求路径
• request_method：GET/POST
• status：响应状态码
• user_agent：用户代理
• latency：延迟（如果有）
• backend_service / target：后端信息

如果你发现来源 IP 集中在某些地址，并且 UA 明显像爬虫（例如某些批量抓取工具），那基本就有方向了。

2）把日志聚合到“异常窗口”，避免被历史数据淹没

很多同学一开始就全量翻日志，最后翻到天荒地老。建议你做“时间窗聚合”。例如：

• 告警开始前 10 分钟作为对照
• 告警开始后 30 分钟作为主分析窗口
• 按请求路径聚合 top N
• 谷歌云返点 按状态码聚合 top N
• 按源 IP 或 /24 段聚合 top N

你会发现：大多数异常都能在 top 列表里“自报家门”。

3）应用层日志：看错误堆栈与超时

如果监控显示 5xx 激增，应用层日志会给出更具体的原因：

• 错误码来源：是应用返回的 500，还是上游 LB 产生的 502/504
• 超时：依赖调用超时、数据库连接超时
• 资源耗尽：CPU、内存、线程池耗尽
• 限流触发：429 是否激增

排查时要留意一个经典现象：请求量看似并不疯狂，但延迟变高导致客户端重试，于是形成“雪崩式请求”。日志里通常会看到相同客户端短时间内重复请求。

第四步：网络路径与安全策略也可能是罪魁祸首

流量异常不一定来自恶意攻击，也可能是你自己的网络策略“误伤”。比如防火墙规则变化、Cloud Armor 规则更新、NAT/路由变更导致回流或重试。

1）检查防火墙：规则是否变更，是否放开了不该放开的端口

防火墙相关的排查思路：

• 确认异常发生前是否有规则变更
• 查看命中日志：是否出现大量被允许或被拒绝的请求
• 确认源 IP 范围是否发生了变化（例如某条规则从全开放变成只允许白名单）

如果你看到大量 403 或被拒绝记录，而同时请求量大幅增加，那就是“探测/攻击+你防不住”的组合拳。反过来，如果你发现从某个时间点开始，所有请求都开始 403，往往是规则误改或应用鉴权失效。

2）Cloud Armor（如果启用）：看是否有规则命中与误杀

Cloud Armor 的价值在于：它能在边缘层先挡住一部分坏流量。排查时你应当关注：

• 是否有规则更新导致误拦截
• 规则命中数量与来源区域/UA
• 是否触发了速率限制（rate-based）

很多时候，告警说“流量异常”，但你实际看到的是“拦截请求数暴增”。这依然是异常，只不过异常不在后端，而在边缘层。

3）路由/网关变化：NAT、路由表、VPC 子网

当出站/东西向流量异常时，路由可能成为关键。比如：

• 某条路由导致回程走了不同路径
• NAT 网关端口耗尽（这种更常见于出站连接数激增）
• MTU/协议不兼容导致重传

如果你的应用是发起到外部的请求，请同时看：

• 出站连接数是否激增
• 目标域名是否改变
• DNS 解析失败/重试是否增多

第五步：账号、配额与计费口径也要纳入怀疑清单

有些“流量异常”，其实是计费口径变化或配额策略导致的“间接异常”。你可以把它理解成：你以为车速变快了，实际上油门线被人改了。

1）检查是否有配额被打满导致重试

配额相关的现象通常不会只表现为“流量曲线突然变高”，但它可能引发错误率上升，从而触发重试风暴。

例如：

• API 调用配额限制导致失败，客户端重试次数变多
• 连接数限制导致失败，应用层重连
• 负载均衡后端资源限制导致延迟上升

排查建议：把错误率和请求量一起看，并检查错误是否集中在某类依赖。

2）检查计费：是否有指标口径变化或维度变化

监控面板如果被改过维度（例如从 region 维度变成 project 维度），你会看到曲线“看起来异常”。这类问题通常最烦，因为你找日志找不到根因。

建议你：

• 确认告警阈值和监控图表的定义没有变
• 对比最近变更记录（如 Terraform/控制台改动）
• 如果可能，复核指标的单位和聚合方式

第六步：可疑流量溯源——别只看“量”，要看“形状”

当你初步判断可能是外部流量异常（比如请求量激增），就进入溯源阶段。这里的目标不是“猜”，而是“找证据支持判断”。

1）按请求路径聚合：是不是集中在少数接口

攻击/爬虫的特征通常是集中访问少数路径：

• 登录接口疯狂尝试
• 某个下载链接被批量请求
• 某个不存在的路径反复探测

如果你看到大量对同一路径的请求，而且状态码多为 404 或 401/403，那么“探测”概率很高。反之如果路径分布与业务一致，可能是正常活动。

2）看用户代理与请求头：批量工具的“味道”很重

常见模式：

• User-Agent 固定且与常见浏览器不匹配
• 请求头缺失（Accept-Language、Sec-Fetch 等）
• 请求间隔极其规律（像计时器一样准）

当然，聪明的对手也会伪装，但在很多情况下你仍能从“规律性”找到线索。

3）看来源 IP：是否来自少量 IP 的集中打击

如果异常由少量 IP 触发，说明有针对性；如果来自海量 IP（但 UA 还比较相似），可能是分布式扫描或 botnet。

你可以用 /24（IPv4）或国家维度做快速聚合。注意：如果你启用了防火墙/Cloud Armor，拦截日志里也会有线索。

第七步：验证假设，别让排查变成“无限加班循环”

排查不是为了收集更多证据，而是为了更快得出“最可能原因”并验证。你需要写下假设，然后做验证动作。

1）假设A：业务增长导致请求增加

验证方法：

• 对照业务指标：用户数、下单数、曝光量是否在同一时间发生变化
• 对照日志：请求来源是否与正常用户画像一致（UA、地理分布、路径分布）
• 看错误率是否同步变化：正常增长一般不会导致 5xx 爆发

如果业务增长解释不了错误率变化，就转向假设B。

2）假设B：重试风暴/超时导致请求放大

验证方法：

• 检查应用日志：同一客户端的重复请求间隔是否明显变短
• 看延迟曲线是否先上升再导致请求量上升
• 检查客户端重试配置与熔断策略（如指数退避是否关闭）

如果你发现“延迟上升 → 重试增多 → 请求量飙升”的顺序，那么基本锁定方向。

3）假设C：爬虫/攻击流量导致请求增加

验证方法：

• 查看来源 IP/UA 的异常集中度
• 查看路径：是否集中在少数非业务关键接口
• 查看响应码：是否主要是 404/403/401，或是否触发限流
• 如果启用了 Cloud Armor，规则命中是否激增

验证成功后，你才会进入“处置动作”，例如加强规则、增加限流、加挑战验证等。

4）假设D：CDN 缓存策略改变导致回源请求激增

验证方法：

• 看缓存命中率是否在异常开始时同步下降
• 检查最近变更：Cache-Control、CDN path rules、查询参数缓存策略
• 看源站响应：回源后是否出现更多错误或延迟

如果是缓存策略问题，通常修复会比较“温柔”：恢复缓存头或调参即可。

第八步：给出可执行的处置动作（按场景）

谷歌云返点 当你验证了原因，就要做处置。处置动作要分级：先止血，再复盘，最后优化。

1）止血：先降低影响

• 如果是明显恶意流量：开启或加强边缘层限流/拦截（Cloud Armor、WAF 类能力）
• 如果是缓存命中下降：临时调整缓存策略或回滚相关变更
• 如果是后端错误：回滚到上一版本、临时扩容、或先修复依赖
• 如果是重试风暴：临时降低重试次数、增加退避、提升超时策略的合理性

谷歌云返点 2）复盘：把“异常发生原因”写成文档

复盘要抓三点：触发因素是什么、排查用到了哪些证据、最终如何验证。这样下一次你就不需要再从“监控像海浪一样起伏”开始感悟人生。

3）优化：让系统更“会自救”

常见优化方向：

• 更明确的告警：按请求路径、状态码、延迟、缓存命中率分别告警
• 更好的可观测性：把请求 ID、客户端信息、后端信息串起来
• 更稳的重试策略：指数退避、熔断、限流，避免雪崩
• 更严格的缓存配置审查：上线变更时对 Cache-Control 做检查

第九步：排查清单（建议你直接复制到工单里）

为了让这篇文章不止“读完很爽”，我给一个简洁但实用的排查清单，你可以直接用作事故工单或现场排查表。

1）告警与现象

• 告警开始时间：____
• 异常类型：入站/出站；请求数/带宽/错误率/延迟/缓存命中率
• 异常持续时间：____
• 是否有最近变更（代码/配置/网络/安全策略）：____

2）监控定位

• 入口：HTTP(S) LB / GKE Ingress / VM 直连 / 其他
• 请求曲线：是否同步上升
• 状态码：4xx/5xx 是否同步异常
• 后端健康：是否健康数下降或后端延迟上升
• CDN：缓存命中率是否下降、回源是否上升

3）日志验证

• 访问日志 top 路径：____
• 访问日志 top 源 IP 段/国家：____
• User-Agent 特征：____
• 应用日志错误堆栈/超时：____
• 是否出现重试风暴（同源短时间重复请求）：____

4）网络/安全策略

• 防火墙是否有变更：____
• Cloud Armor 命中规则是否激增：____
• 是否触发限流/挑战：____
• 路由/NAT 是否有异常：____

5）结论与处置

• 最可能原因：____
• 证据摘要：监控 + 日志关键点（3 条以内）
• 止血动作：____
• 修复动作：____
• 恢复验证：何时恢复到阈值内、观察多久：____

结尾：把排查变成“可重复的能力”

GCP 流量异常排查，说到底是一场“把不确定性压缩成确定性”的工作。你要做的不是凭感觉猜对，而是用证据一步步缩小范围：先看形态，再定位落点，再查日志，最后验证假设并闭环。

谷歌云返点 当你下次再遇到那条“流量异常”的告警，别急着把锅甩给网络、甩给云、甩给宇宙。打开监控，找时间窗；打开日志，聚合 top 列表；写下假设，做验证动作；最后把结论写成清单沉淀。你会发现：排查这件事，没有那么玄学，更多是方法论。

最后送你一句“排查老江湖”的话：如果你找不到原因，说明你还没把问题拆到足够细。流量异常不是一个点，它是一条路径；你要做的就是把路径走完。