企业官网建设流程全解析

Google Cloud Networking Observability 之 VPC Flow Logs 流量分析实战指南

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills

导读

本文面向需要在 Google Cloud（GCP）中基于VPC Flow Logs（VPC 流日志）分析流量模式、流量规模与延迟（RTT）的开发者、SRE 与 AI Agent。文章以skills/cloud/google-cloud-networking-observability技能仓库中的 VPC Flow Analysis 参考文档 为主体，系统讲解从单条日志的探索式排查到大数据量趋势聚合的完整方法：通过 Cloud Logging MCP 查看日志、通过 BigQuery MCP 做高吞吐量聚合、以gcloud/bqCLI 作为兜底方案，并给出 RTT 延迟分析的字段选型与 Flow Analyzer 可视化手段。读完本文，你将掌握一套可直接复制运行的日志过滤器、SQL 模板与字段速查表，并能基于仓库源码理解这套分析流程在 Agent 工作流中的定位与边界。

1. VPC Flow Logs 是什么：何时选择它

VPC Flow Logs 捕获进出网络接口的 IP 流量采样。在google-cloud-networking-observability技能的整体"日志与遥测全景"中（见 SKILL.md），它与以下几类数据源分工明确：

因此，当问题属于"谁在跟谁通信、流量有多大、延迟多高"时，首选 VPC Flow Logs；而"某条防火墙规则是否放行/拦截了连接"则应交给防火墙日志分析（firewall-analysis.md），"NAT 端口是否耗尽"则应交给 Cloud NAT 分析（cloud-nat-analysis.md）。

值得注意的是，该技能仓库还提供了配套的 VPC Flow Logs 成本估算参考，二者是互补关系：前者回答"流量如何"、后者回答"要花多少钱"。SKILL.md 中明确要求成本估算任务必须使用独立的成本估算文档，不可与本文混用。

2. 两种分析模式：Exploratory Analysis 与 High-Volume Trends

在对 VPC Flow Logs 动手之前，先明确分析意图，这决定了选择哪条查询路径：

• 探索式分析（Exploratory Analysis）：查看单条或少量日志条目，用于理解特定事件、调试问题或调查异常。这种场景通常需要过滤并查看日志记录完整细节，适合用 Cloud Logging 的list_log_entries。
• 高吞吐量趋势分析（High-Volume Trends）：对海量日志按时间聚合，识别模式、度量流量规模、分析延迟分布或找出 Top Talkers。这类分析通常用 SQL 汇总数据，而不是逐条翻日志，适合用 BigQuery 对_AllLogs数据集执行聚合查询。

仓库的 MCP 使用文档（mcp-usage.md）给出了对应工具链：Cloud Logging MCP提供list_log_entries（高级过滤器检索日志条目）与list_log_names（发现项目中可用的日志）；BigQuery MCP提供list_dataset_ids、list_table_ids、get_table_info以及只读执行 SQL 的首选工具execute_sql_readonly（注：本文原文档中该工具写作execute_sql，实际以 MCP 服务器暴露的工具名为准，SKILL.md 中的用法模式为execute_sql_readonly，用于SELECT类日志分析）。

3. 查看日志：Cloud Logging MCP 过滤器（必查两个来源）

使用list_log_entries时，务必同时检索两个 VPC Flow Logs 来源，缺一不可：

• compute.googleapis.com/vpc_flows：来自 Compute Engine 子网的 VPC 流日志；
• networkmanagement.googleapis.com/vpc_flows：来自 Network Management（网络智能中心）的流日志数据。

完整过滤器模板：

(logName:"projects/{project_id}/logs/compute.googleapis.com%2Fvpc_flows" OR logName:"projects/{project_id}/logs/networkmanagement.googleapis.com%2Fvpc_flows") resource.type="gce_subnetwork"

要点说明：

• {project_id}需替换为实际项目 ID，注意日志名中的%2F是对/的 URL 编码（即vpc_flows对应compute.googleapis.com/vpc_flows），不要手写为未编码的斜杠；
• 两个来源用OR组合，外层再用括号包裹整个logName条件，避免与resource.type的AND优先级混淆；
• resource.type="gce_subnetwork"将结果收敛到子网维度。

此过滤器也适用于仓库中同目录其他参考文档的查询模式（如防火墙日志compute.googleapis.com/firewall、NAT 日志compute.googleapis.com/nat_flows），只是logName与resource.type不同。

4. 聚合趋势：BigQuery SQL 模板

对于高吞吐量场景，优先检查项目中是否已关联 BigQuery 数据集（例如big_query_linked_dataset或_AllLogs）。使用 BigQuery MCP 的execute_sql（只读执行对应execute_sql_readonly）执行以下 SQL 模式：

SELECT timestamp, JSON_VALUE(jsonPayload.connection.src_ip) AS src_ip, JSON_VALUE(jsonPayload.connection.dest_ip) AS dest_ip, CAST(JSON_VALUE(jsonPayload.bytes_sent) AS INT64) AS bytes_sent FROM `{project_id}.{dataset_id}._AllLogs` WHERE log_name IN ( 'projects/{project_id}/logs/compute.googleapis.com%2Fvpc_flows', 'projects/{project_id}/logs/networkmanagement.googleapis.com%2Fvpc_flows' ) AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR) ORDER BY timestamp DESC LIMIT 10

逐段拆解：

• _AllLogs是 Cloud Logging 关联到 BigQuery 后的统一日志数据集表，{dataset_id}需替换为实际数据集名；
• log_name IN (...)与日志过滤器一致，同时覆盖两个来源；
• JSON_VALUE(...)从jsonPayload中提取 JSON 字段，这是 BigQuery 侧读取流日志负载的标准方式；
• CAST(... AS INT64)把bytes_sent字符串转为整数，便于后续求和、排序；
• 时间窗口用TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)限定最近 1 小时，生产环境中可按需改为INTERVAL 6 HOUR/INTERVAL 24 HOUR等。

4.1 CLI 兜底：gcloud logging read 与 bq query

当 MCP 工具不可用时，使用gcloud与bq命令完成同样工作。

查看日志（gcloud）：

gcloud logging read '(logName:"projects/{project_id}/logs/compute.googleapis.com%2Fvpc_flows" OR logName:"projects/{project_id}/logs/networkmanagement.googleapis.com%2Fvpc_flows") AND resource.type="gce_subnetwork"' --project {project_id} --limit 10 --format json --quiet

聚合趋势（bq）：

bq query --use_legacy_sql=false --project_id {project_id} ' SELECT timestamp, JSON_VALUE(json_payload.connection.src_ip) AS src_ip, JSON_VALUE(json_payload.connection.dest_ip) AS dest_ip, CAST(JSON_VALUE(json_payload.bytes_sent) AS INT64) AS bytes_sent FROM `{project_id}.{dataset_id}._AllLogs` WHERE log_name IN ( "projects/{project_id}/logs/compute.googleapis.com%2Fvpc_flows", "projects/{project_id}/logs/networkmanagement.googleapis.com%2Fvpc_flows" ) AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR) ORDER BY timestamp DESC LIMIT 10 '

注意 BigQuery 侧字段使用下划线命名（json_payload、log_name），而 Cloud Logging 侧是驼峰命名（jsonPayload、logName），两者不要混用。这一点在"通用 BigQuery 指南"中有专门强调。

5. 通用 BigQuery 指南：Schema 校验、RTT 聚合与防重复计数

5.1 Schema 校验：先bq show --schema再执行

在不确定字段大小写（例如jsonPayload还是json_payload）时，必须先运行bq show --schema <source>校验 schema 后再执行查询。仓库 SKILL.md 给出了完整的错误恢复流程（适用于Unrecognized name或 schema 不匹配错误）：

1. 校验 Schema：bq show --schema --format=json {project_id}:{dataset_id}.{table_id}确认字段名与大小写；
2. Dry Run：用bq query --use_legacy_sql=false --dry_run "{query_text}"做试运行，在不产生执行成本的前提下验证字段引用是否合法；
3. 重试：修正后重新执行查询。

5.2 延迟（RTT）聚合：首选round_trip_time.median_msec

VPC Flow Logs 中用于 RTT 分析的主要字段是json_payload.round_trip_time.median_msec：

• 类型为double，提供亚毫秒精度的中位数延迟；
• 同时覆盖TCP 与 Falcon（Falcon 是 Google 内部的拥塞控制/传输协议）两类流量；
• 分析时按reporter（SRC或DEST）过滤，避免流量规模被重复计数。

5.3 备选：TCP-only 的rtt_msec

对于纯 TCP 流量，还可以使用json_payload.rtt_msec：

• 类型为int64，RTT 取整毫秒精度；
• 仅对 TCP 流量填充，覆盖范围比round_trip_time.median_msec更窄；
• 可按下述方式做聚合统计：

SELECT AVG(json_payload.rtt_msec) AS average_rtt_msec, MAX(json_payload.rtt_msec) AS max_rtt_msec FROM ...

字段选型结论：一般情况下，round_trip_time.median_msec因精度更高、覆盖更广而优先于rtt_msec；只有在确认场景为纯 TCP 且对整毫秒精度足够时才使用后者。

6. 可视化分析：Flow Analyzer

除了日志与 SQL，Google Cloud 控制台的Flow Analyzer（网络智能中心）提供可视化流量分析，用于识别 Top Talkers，支持：

• 可视化展示区域（region）、VPC 与实例之间的流量流向；
• 按源或目的维度过滤；
• 识别高带宽或高延迟连接。

在使用该技能的所有分析任务中，SKILL.md 的边界条款要求始终在答复中包含指向 Flow Analyzer 的 Google Cloud Console 链接（https://console.cloud.google.com/net-intelligence/flow-analyzer），以便用户从文本结果快速跳到可视化界面交叉验证。

7. 关键字段速查表

下表汇总了 VPC Flow Logs 分析中最常用的字段及其语义（出处：vpc-flow-analysis.md）：

结合仓库中 mcp-usage.md 与 SKILL.md 的补充说明，还有两个实战细节：

1. 元数据感知：子网可能配置了EXCLUDE_ALL_METADATA，导致 VPC Flow Logs 中 VM 名为 NULL。若按 VM 名查询无结果，应改用内部 IP（jsonPayload.connection.src_ip）重试；
2. 字段大小写：BigQuery 侧统一使用json_payload下划线命名（如json_payload.connection.src_ip、json_payload.bytes_sent、json_payload.round_trip_time.median_msec），Cloud Logging 过滤器侧使用jsonPayload驼峰命名，二者不可混用。

8. 在 Agent 工作流中的定位与执行边界

理解这份参考文档在 Agent 工作流中的位置，有助于正确使用它。根据 SKILL.md 的编排：

• 先查 BigQuery 关联数据集再查 Cloud Logging：高吞吐量分析或聚合一律优先走_AllLogs，这是找趋势与 Top Talkers 的首选路径；BigQuery 数据一旦可用即为最终结论，不要再用 Monitoring API "复核"计数；
• Top-N / 流量规模类任务统一走 BigQuery 聚合：禁止对单条时间序列手动聚合；
• 结果导向，及时终止：一旦拿到直接答案（即使结果是 0、无流量），立即汇报并结束，不要为了"更漂亮的答案"去翻更活跃的资源；同时禁止在度量与日志之间做"对账式"二次验证（除非用户明确询问为何两者不一致）；
• 禁止辅助脚本：所有数据获取与解析都应通过直接的bq、curl、gcloud工具调用完成，不写落地到磁盘的.sh/.py脚本，以减少环境与权限错误导致的调查超时。

此外，仓库要求在执行任何 BigQuery 查询前先打印生成的 SQL 供审查，且禁止在未获用户许可的情况下做第二次探查（例如发现防火墙拦截后再去查 VPC 流日志）。

9. 快速上手：一次典型排查的最小路径

综合全文，一次完整的 VPC 流量分析可归纳为四步：

1. 确认目标与模式：判断是"看单条事件"（Cloud Logging）还是"看趋势/规模"（BigQuery）；
2. 探索（可选）：用list_log_entries加本文第 3 节的双来源过滤器查看最近日志细节；
3. 聚合：对_AllLogs执行本文第 4 节的 SQL 模板，按reporter过滤避免重复计数，用round_trip_time.median_msec做延迟分析；不确定字段大小写时先bq show --schema校验；
4. 可视化兜底：把 Flow Analyzer 链接随结论一并交付，便于用户直观查看区域、VPC、实例间的流量流向与 Top Talkers。

仓库中其余参考文档（firewall-analysis.md、cloud-nat-analysis.md、metrics-analysis.md、connectivity-tests.md、vpc-flow-logs-cost-estimation.md）与本文相互配合，分别覆盖防火墙规则校验、NAT 审计、指标趋势、路径诊断与成本估算，共同构成完整的网络可观测性工具箱。

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills