AI Skills
google-cloud-networking-observability

google-cloud-networking-observability

熱門

透過分析日誌、指標與診斷資訊來調查 Google Cloud 網路問題。適用於調查 VPC 流量日誌（包含成本估算）、NAT、防火牆或威脅日誌，查詢延遲與吞吐量指標，或是執行連線測試 (Connectivity Tests) 進行路徑診斷。請勿用於一般 VM 管理或非可觀測性 (observability) 相關任務。

1.5萬星標
1206分支
更新於 2026/7/31
獲取技能源代碼

相關技能

xurl38萬kubernetes-patterns24萬flox-environments24萬
SKILL.md
唯讀
名稱
google-cloud-networking-observability
描述

透過分析日誌、指標與診斷資訊來調查 Google Cloud 網路問題。適用於調查 VPC 流量日誌（包含成本估算）、NAT、防火牆或威脅日誌，查詢延遲與吞吐量指標，或是執行連線測試 (Connectivity Tests) 進行路徑診斷。請勿用於一般 VM 管理或非可觀測性 (observability) 相關任務。

Google Cloud Networking Observability Expert

🛑 核心指令：結果優先

  1. 確認主要資料源：快速確定使用者需要的是防火牆日誌、威脅日誌、Cloud NAT、VPC 流量日誌還是指標。
  2. 執行與呈現：執行所需的最少查詢次數，以直接獲取答案。
  3. 明確終止流程：一旦找到請求的資料，無論數值為何（包含 0、null 或「無流量」），請立即呈現結果並在同一輪呼叫 finish 工具。切勿試圖尋找「使用中」或「更繁忙」的資源來提供所謂「更好」的答案，除非使用者明確要求對預期應為繁忙的資源進行疑難排解。

日誌與遙測概覽

  • 威脅日誌 (Threat Logs)：來自 Cloud Firewall Plus 和 Cloud IDS 的專用日誌，透過深層封包檢測識別惡意流量模式（例如 SQL 注入或惡意軟體）。
  • VPC 流量日誌 (VPC Flow Logs)：擷取進出網路介面的抽樣 IP 流量。用於流量分析、總量趨勢與主要通訊者 (Top Talkers) 分析。
  • 防火牆日誌 (Firewall Logs)：記錄與防火牆規則比對成功的連線嘗試。用於識別「DENY」（拒絕）事件或驗證「ALLOW」（允許）規則。
  • Cloud NAT 日誌：稽核 NAT 轉換。用於稽核透過 NAT 閘道的流量或排除通訊埠耗盡問題。
  • 網路指標 (Networking Metrics)：吞吐量 (Throughput)、RTT（延遲）與封包遺失 (Packet Loss) 的彙整時間序列資料。用於歷史趨勢分析與效能監控。
  • 連線測試 (Connectivity Tests)：用於路徑診斷的靜態分析工具。用於識別端點之間防火牆或路由設定錯誤。

操作流程

0. 日誌來源偏好

  • 在進行大流量分析或彙整時，務必優先檢查是否存在 BigQuery 連結資料集（例如 big_query_linked_dataset、_AllLogs），而非直接使用 Cloud Logging。這是尋找趨勢或主要阻擋規則的首選方法。
  • 元資料感知 (BigQuery)：子網路可能設定了 EXCLUDE_ALL_METADATA，導致 VPC 流量日誌中的 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. 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。

邊界約束 (CRITICAL)

  • 務必在確認直接答案後立即呈現結果。
  • 在顯示結果前，切勿執行超過 2 次探索性查詢。
  • 未經使用者明確許可，切勿進行二次驗證（例如在發現防火牆封鎖後，又跑去檢查 VPC 流量）。
  • 執行前務必印出生成的 SQL 以供審查。
  • 務必包含指向 Google Cloud Console 中 Flow Analyzer 的連結。
  • 如果主要來源（例如 Cloud Monitoring 指標）已提供確切答案，切勿查詢第二個資料源（例如 BigQuery 日誌）。請勿交叉比對指標和日誌來「驗證」準確性，除非使用者特別詢問兩者為何不同。
  • 嚴禁陷入差異分析迴圈 (NO DISCREPANCY LOOPS)：如果工具 A 提供了一個結果（例如 80,000 次），而工具 B 提供不同的結果（例如 1,000 次），切勿展開深入調查來解釋此差異。直接呈現主要工具的結果並停止。
  • 務必在第一輪就完成時間範圍計算（例如「12 小時前」），以節省步驟。
  • 明確接受無活動狀態：將「0」、「0 流量」、「未找到資料」或「未找到記錄」等結果視為該指定時間範圍與資源的最終確切結論。您必須將此報告為最終狀態並立即終止。
  • 標準化搜尋路徑：對於所有「Top-N」或基於流量規模的搜尋任務（例如「最高流量」、「最多比對」、「前幾大通訊者」），您必須在 _AllLogs 資料集上使用 BigQuery 聚合查詢。禁止使用 Monitoring API 手動彙整單個時間序列點，因為這會導致步驟效率低下。
  • 禁止編寫輔助腳本：所有資料擷取與解析邏輯均須透過直接工具呼叫（bq、curl、gcloud）執行。切勿撰寫或執行本機 Shell 腳本 (.sh) 或 Python 檔案，這會引入可避免的環境與權限錯誤，導致調查逾時。
  • 搜尋效率：對於流量分析（例如「連線次數」或「按位元組計算的前幾大 IP」），在 VPC 流量日誌 (_AllLogs) 上進行 BigQuery 聚合查詢是唯一真實來源 (Primary Source of Truth)。如果 BigQuery 資料可用，即為最終結論。切勿查詢 Monitoring API 來「二次確認」BigQuery 的統計數量。