在排查 Google Cloud 网络问题（VPC…

用于调查 GCP 网络可观测性问题：日志、指标与路径诊断，并强调先出结果、避免过度探索。

适用场景

解决思路

1. 先确定主要数据源：判断用户需要的是防火墙日志、威胁日志、Cloud NAT、VPC Flow 日志还是指标。
2. 执行最小必要查询并直接呈现答案。
3. 一旦找到所需数据，无论值是什么（包括 0、null 或“无流量”），在同一轮就呈现发现并调用 finish 工具；除非明确要求排查预期繁忙的资源，否则不要去找“更活跃”的资源来给出“更好”的答案。
4. 了解各类日志用途：威胁日志来自 Cloud Firewall Plus 和 Cloud IDS，通过深度包检测识别恶意流量（如 SQL 注入或恶意软件）；VPC Flow 日志采样网络接口的 IP 流量，用于流量分析、流量趋势和 top talkers；防火墙日志记录被防火墙规则匹配的连接尝试，用于识别 DENY 事件或验证 ALLOW 规则；Cloud NAT 日志审计 NAT 转换，用于审计经过 NAT 网关的流量或排查端口耗尽；网络指标是吞吐量、RTT（延迟）和丢包的时间序列聚合数据，用于历史趋势和性能监控；连通性测试是路径诊断的静态分析工具，用于识别端点之间的防火墙或路由配置错误。
5. 在进行高流量分析或聚合时，优先检查 BigQuery 关联数据集（如 big_query_linked_dataset、_AllLogs），这是查找趋势或 top-blocking 规则的首选方法。
6. 注意 BigQuery 元数据：子网可能配置了 EXCLUDE_ALL_METADATA，导致 VPC Flow 日志中 VM 名称为 NULL；如果按 VM 名称查询无结果，改用内部 IP 地址（jsonPayload.connection.src_ip）重试。
7. 优先使用 MCP 服务器：Cloud Monitoring MCP、BigQuery MCP 或 Cloud Logging MCP。
8. 资源发现：如果用户指定的资源（如 NAT 网关、VPN 隧道）在指标/日志中找不到，先用 run_shell_command 配合 gcloud 列出项目中的资源，再在 Cloud Logging MCP 中搜索该资源名以找到正确的标签。
9. CLI 回退：仅在 MCP 服务器不可用时使用 gcloud 或 bq；不要使用 gcloud monitoring（受限），立即使用 metrics-analysis.md 中的 curl 模板。
10. 如果 BigQuery 查询因 'Unrecognized name' 或 schema 不匹配失败：先用 bq show --schema --format=json {project_id}:{dataset_id}.{table_id} 验证字段名和大小写（如 jsonPayload 与 json_payload）；再用 bq query --use_legacy_sql=false --dry_run "{query_text}" 做 dry run 验证字段引用而不产生费用或执行时间；最后应用修正后重试原查询。
11. 按需阅读参考文件：威胁日志分析用 references/threat-analysis.md；VPC Flow 分析用 references/vpc-flow-analysis.md；VPC Flow 日志成本估算用 references/vpc-flow-logs-cost-estimation.md；Cloud NAT 分析用 references/cloud-nat-analysis.md；防火墙规则分析用 references/firewall-analysis.md；网络指标用 references/metrics-analysis.md；连通性测试分析用 references/connectivity-tests.md。
12. 如果用户要求成本估算，必须严格使用 references/vpc-flow-logs-cost-estimation.md，不要读取或使用 references/vpc-flow-analysis.md 来做成本估算。
13. 一旦识别出直接答案就立即呈现。
14. 在展示结果前，探索性查询不要超过 2 次。
15. 未经用户明确许可，不要做二次验证（例如找到防火墙阻断后不要再查 VPC Flow）。
16. 执行前始终打印生成的 SQL 供审查。
17. 始终附上 Google Cloud Console 中 Flow Analyzer 的链接：https://console.cloud.google.com/net-intelligence/flow-analyzer。
18. 如果主要数据源（如 Cloud Monitoring 指标）已给出结论性答案，不要再查询第二个数据源（如 BigQuery 日志）；除非用户明确问为什么两者不同，否则不要对比指标和日志来“验证”准确性。
19. 不要陷入差异循环：如果工具 A 给出结果（如 80,000 计数）而工具 B 给出不同结果（如 1,000 计数），不要深入解释差异；呈现主要工具的结果并停止。
20. 在第一轮就完成时间范围计算（如“12 小时前”）以节省步骤。
21. 把“0”、“0 流量”、“No data found”或“No records found”视为所请求时间范围和资源的结论性发现，必须报告为确定状态并立即终止。
22. 对于所有“Top-N”或基于流量的发现任务（如“最高流量”、“最多命中”、“top talkers”），必须使用 BigQuery 对 _AllLogs 数据集做聚合；禁止用 Monitoring API 手动聚合单个时间序列点，因为步骤效率低。
23. 禁止辅助脚本：所有数据检索和解析逻辑都作为直接工具调用（bq、curl、gcloud）执行；不要编写或执行本地 shell 脚本（.sh）或 python 文件，因为它们会引入可避免的环境和权限错误，导致调查超时。
24. 发现效率：对于流量分析（如“多少连接”或“按字节排名的 top IP”），BigQuery 对 VPC Flow 日志（_AllLogs）的聚合是主要事实来源；如果 BigQuery 数据可用，它就是结论性的，不要再查询 Monitoring API 来“复核”BigQuery 计数。

适用边界 · 注意事项

• 不要用于通用 VM 管理或非可观测性任务。
• 不要用 gcloud monitoring（受限），应改用 metrics-analysis.md 中的 curl 模板。
• 不要在主要数据源已给出结论时查询第二个数据源做验证，也不要陷入不同工具结果差异的深挖循环。