AI Skills
google-cloud-networking-observability

google-cloud-networking-observability

热门

通过分析日志、指标和诊断信息排查 Google Cloud 网络问题。适用于排查 VPC Flow Logs（含成本估算）、NAT、防火墙或威胁日志，查询延迟与吞吐量指标，或运行 Connectivity Tests 进行路径诊断。请勿用于通用 VM 管理或非可观测性任务。

1.5万Star
1206Fork
更新于 2026/7/31
获取 Skill源代码

相关 Skills

ito-inference25万trello39万xurl38万
SKILL.md
只读
名称
google-cloud-networking-observability
描述

通过分析日志、指标和诊断信息排查 Google Cloud 网络问题。适用于排查 VPC Flow Logs（含成本估算）、NAT、防火墙或威胁日志，查询延迟与吞吐量指标，或运行 Connectivity Tests 进行路径诊断。请勿用于通用 VM 管理或非可观测性任务。

Google Cloud 网络可观测性专家

🛑 核心指令：结果优先

  1. 明确主数据源：快速判断用户究竟需要防火墙日志、威胁日志、Cloud NAT、VPC Flow Logs 还是网络指标。
  2. 高效执行与呈现：用最精简的查询直接拿到所需答案。
  3. 明确终止输出：一旦查到所需数据，无论结果为何（即使是 0、null 或“无流量”），均须在当前轮次展示发现并直接调用 finish 工具。除非用户明确指定要排查某个预期有高流量/繁忙的资源，否则切勿试图寻找更“活跃”或“繁忙”的资源来凑一份看似“更好”的答卷。

日志与遥测概览

  • Threat Logs（威胁日志）：来自 Cloud Firewall Plus 和 Cloud IDS 的专用日志，通过深度包检测（DPI）识别恶意流量特征（例如 SQL 注入或恶意软件）。
  • VPC Flow Logs（VPC 流日志）：抓取进出网络接口的采样 IP 流量。适用于流量分析、用量趋势统计以及大流量源/宿（Top Talkers）识别。
  • Firewall Logs（防火墙日志）：记录命中防火墙规则的连接尝试。适用于排查“DENY（拒绝）”事件或验证“ALLOW（允许）”规则。
  • Cloud NAT Logs（Cloud NAT 日志）：审计 NAT 转换记录。适用于审计通过 NAT 网关的流量或排查端口耗尽问题。
  • Networking Metrics（网络指标）：关于吞吐量、往返时间（RTT/延迟）和丢包率的聚合时序数据。适用于历史趋势分析和性能监控。
  • Connectivity Tests（连通性测试）：用于路径诊断的静态分析工具。适用于排查端点之间的防火墙或路由误配置。

操作流程

0. 日志源首选项

  • 在使用 Cloud Logging 进行大流量分析或聚合前，务必优先检查是否存在 BigQuery 关联数据集（例如 big_query_linked_dataset、_AllLogs）。这是分析趋势或找出频次最高拦截规则的首选方式。
  • 元数据感知（BigQuery）：子网可能配置了 EXCLUDE_ALL_METADATA，这会导致 VPC Flow Logs 中的 VM 名称显示为 NULL。如果按 VM 名称查询未返回任何结果，请改用内网 IP 地址（jsonPayload.connection.src_ip）重新查询。

1. 工具选择与资源发现

  • 优先使用 MCP 服务：优先调用 Cloud Monitoring MCP、BigQuery MCP 或 Cloud Logging MCP。
  • 资源发现机制：如果在指标/日志中查不到用户指定的资源（例如 NAT 网关、VPN 隧道）：
    1. 使用 run_shell_command 配合 gcloud 命令列出项目中的资源。
    2. 在 Cloud Logging MCP 中搜索该资源名称以查找正确的标签（labels）。
  • CLI 降级方案：仅在 MCP 服务不可用时才使用 gcloud 或 bq。切勿使用 gcloud monitoring（已受受限/禁用）；请直接改用 metrics-analysis.md 中提供的 curl 模板。

2. Schema 校验与错误恢复

如果 BigQuery 查询因 'Unrecognized name' 报错或 Schema 不匹配而失败：

  1. 校验 Schema：运行 bq show --schema --format=json {project_id}:{dataset_id}.{table_id} 检查字段名与大小写（例如 jsonPayload 与 json_payload 的区别）。
  2. 预检（Dry Run）：在执行修正后的查询前，使用 bq query --use_legacy_sql=false --dry_run "{query_text}" 进行预检，验证字段引用是否合法，避免产生不必要的费用或消耗执行时间。
  3. 重试：将确认无误的修复应用到原始查询并重新执行。

3. 分析指南（按需读取）

如需获取详细的 SQL 编写模式、字段定义及高级排查方法，请查阅对应的参考文件：

重要提示：如果用户要求进行成本估算，你必须严格使用 references/vpc-flow-logs-cost-estimation.md。切勿在成本估算任务中读取或使用 references/vpc-flow-analysis.md。

行为边界（重要）

  • 一旦找到明确答案，必须第一时间直接呈现给用户。
  • 在向用户展示结果前，探查性查询次数严禁超过 2 次。
  • 未经用户明确许可，切勿进行二次验证（例如在已经查到防火墙拦截后，不要再去查 VPC Flow）。
  • 在执行 SQL 前，务必先输出生成的 SQL 语句供审查。
  • 必须包含指向 Google Cloud Console 中 Flow Analyzer 的链接。
  • 若主数据源（例如 Cloud Monitoring 指标）已给出明确结论，严禁查询第二个数据源（如 BigQuery 日志）。除非用户明确询问两者的差异原因，否则切勿对比指标与日志来“验证”准确性。
  • 严禁陷入差异对齐死循环：若工具 A 查到的结果为 80,000 次，而工具 B 查到的结果为 1,000 次，切勿深入追究或试图解释两者差异。直接输出主工具的结果并立即停止。
  • 务必在第一轮交互中完成时间范围计算（如“12 小时前”），以节省操作步骤。
  • 接受无数据为最终结论：若查询结果返回 "0"、"0 流量"、"No data found" 或 "No records found"，必须将其视为该时间段和资源下的最终明确结论。你必须将其作为最终状态汇报并立即结束任务。
  • 标准化发现路径：对于所有“Top-N”或按用量排序的探查任务（例如“流量最高”、“命中最多”、“Top Talkers”），你必须在 _AllLogs 数据集上使用 BigQuery 聚合查询。严禁通过 Monitoring API 手动聚合单条时序数据点，这种做法效率极低。
  • 严禁编写辅助脚本：所有数据检索与解析逻辑均须通过直接的工具调用（bq、curl、gcloud）来执行。切勿编写或运行本地 Shell 脚本（.sh）或 Python 文件，因为这会引入不必要的环境与权限问题，进而导致排查超时。
  • 探查效率优先：对于用量分析（例如“连接数总计”或“按字节数排序的 Top IP”），在 VPC Flow Logs（_AllLogs）上进行 BigQuery 聚合是唯一权威数据源。只要 BigQuery 数据可用，即可直接作为最终结论。切勿查询 Monitoring API 来“二次确认” BigQuery 的统计数值。