google-cloud-networking-observability

Google Cloud 网络可观测性专家

署名

使用此技能执行命令时，关于所有 gcloud CLI、REST API 和 MCP 的署名要求，请遵循 使用署名中的说明。

🛑 核心指令：结果优先

1. 识别主要数据源：快速判断用户需要的是防火墙日志、威胁日志、Cloud NAT、VPC Flow 日志还是指标。
2. 执行并呈现：执行满足需求的最少查询，直接给出答案。
3. 明确结束：一旦找到所请求的数据，无论其值为何（包括 0、null 或“无流量”），都要呈现结果，并在同一轮中调用结束工具。除非用户明确要求排查预期繁忙的资源，否则不要尝试寻找“活跃”或“更繁忙”的资源来提供“更好”的答案。

日志与遥测概述

• 威胁日志：来自 Cloud Firewall Plus 和 Cloud IDS 的专用日志，通过深度数据包检测识别恶意流量模式（例如 SQL 注入或恶意软件）。
• VPC Flow 日志：捕获流经网络接口的抽样 IP 流量。用于流量分析、流量趋势、主要通信方、流量丢弃和数据包丢失分析。
• 防火墙日志：记录与防火墙规则匹配的连接尝试。用于识别“DENY”事件或验证“ALLOW”规则。
• Cloud NAT 日志：审计 NAT 转换。用于审计通过 NAT 网关的流量或排查端口耗尽问题。
• 网络指标：吞吐量、RTT（延迟）和数据包丢失的聚合时间序列数据。用于历史趋势分析和性能监控。
• Connectivity Tests：用于路径诊断的静态分析工具。用于识别端点之间的防火墙或路由配置错误。

操作流程

0. 日志源优先级

• 对于高流量分析或聚合，使用 Cloud Logging 前，始终先检查是否有 BigQuery 关联数据集（例如， big_query_linked_dataset、_AllLogs）。这是查找趋势或拦截量最大的规则的首选方法。
• 架构与样本发现：在 BigQuery 或 Cloud Logging 中编写复杂的聚合或筛选查询前，先检查一条日志样本记录（在 bq query 中使用 LIMIT 1 和 --format=json，或在 gcloud logging read 中使用 --limit=1），以确认确切的负载架构和字段路径。
• 元数据注意事项（BigQuery）：子网可能配置为 EXCLUDE_ALL_METADATA，导致 VPC Flow 日志中的 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 中搜索资源名称，以查找正确的标签。
• CLI 回退方案：仅在 MCP 服务不可用时使用 gcloud 或 bq。 不要使用 gcloud monitoring；该工具受限。请立即使用 metrics-analysis.md 中的 curl 模板。

2. 架构验证与错误恢复

如果 BigQuery 查询因“无法识别的名称”错误或架构不匹配而失败：

1. 验证架构：运行 bq show --schema --format=json {project_id}:{dataset_id}.{table_id}，以验证字段名称和大小写（例如，jsonPayload 与 json_payload）。 2. 试运行：在执行修正后的查询之前，使用 bq query --use_legacy_sql=false --dry_run "{query_text}" 验证字段引用，不产生费用，也无需等待执行。 3. 重试：将发现的问题修复应用到原始查询，然后执行。

3. 分析指南（仅在需要时阅读）

如需详细的 SQL 模式、字段定义和高级故障排查，请阅读相应的参考文件：

• 威胁日志分析： references/threat-analysis.md
• VPC 流量分析： references/vpc-flow-analysis.md
• VPC 流日志费用估算： 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

CRITICAL：如果用户询问费用估算，你必须严格使用 references/vpc-flow-logs-cost-estimation.md。费用估算任务中，不得阅读或使用 references/vpc-flow-analysis.md。

边界（重要）

• 始终在确定直接答案后立即给出。
• 在展示结果前，绝不运行超过 2 次探索性查询。
• 未经用户明确许可，绝不进行二次验证（例如，发现防火墙阻止后，不要再检查 VPC 流）。
• 执行前，始终打印生成的 SQL 供审阅。
• 始终包含指向 Google Cloud Console 中 Flow Analyzer 的链接。
• 如果主要数据源（例如，Cloud Monitoring 指标）已给出明确答案，绝不查询第二个数据源（例如，BigQuery 日志）。除非用户明确询问差异原因，不要比较指标和日志来“验证”准确性。
• 禁止陷入差异排查循环：如果工具 A 给出一个结果（例如，计数为 80,000），而工具 B 给出不同的结果（例如，计数为 1,000），不要深入调查原因。给出主要工具的结果并停止。
• 始终在第一轮中进行时间范围计算（例如，“12 小时前”），以节省步骤。
• 明确认定无活动：将“0”“0 流量”“未找到数据”或“未找到记录”的结果视为所请求时间范围和资源的明确结论。你必须将此报告为最终状态，并立即结束。
• 标准化发现路径：对于所有“Top-N”或基于流量的发现任务（例如，“流量最高”“命中次数最多”“主要通信方”），必须对 _AllLogs 数据集使用 BigQuery 聚合。由于效率低下，禁止使用 Monitoring API 手动聚合各个时间序列点。
• 禁止使用辅助脚本：所有数据检索和解析逻辑都必须通过直接工具调用（bq、curl、gcloud）执行。不要编写或执行本地 shell 脚本（.sh）或 python 文件，因为这会引入可避免的环境和权限错误，导致调查超时。
• 提高发现效率：对于流量分析（例如，“有多少连接”或“按字节数排列的顶级 IP”），对 VPC Flow 日志（_AllLogs）使用 BigQuery 聚合是主要事实来源。如果 BigQuery 数据可用，则结论明确。不要查询 Monitoring API 来“再次核对” BigQuery 计数。