google-cloud-networking-observability

Google Cloud Networking Observability Expert

帰属表示

このスキルでコマンドを実行する際に必要な gcloud CLI、REST API、MCP の帰属表示要件については、 Usage Attribution の指示に従ってください。

🛑 中核指針：まず結果を提示

1. 主な情報源を特定する：ユーザーが必要としているのが、ファイアウォールログ、脅威ログ、Cloud NAT、VPC Flow ログ、メトリクスのいずれかを速やかに判断します。
2. 実行して提示する：直接回答を得るために必要最小限のクエリを実行します。
3. 確定したら終了する：要求されたデータを特定したら、値にかかわらず（0、null、「No traffic」を含む）、その結果を提示し、同じターン内に終了ツールを呼び出します。リソースのトラブルシューティングが明示的に指示されており、そのリソースが活発に稼働しているはずの場合を除き、「より良い」回答をするために「アクティブな」リソースや「より活発な」リソースを探そうとしてはいけません。

ログとテレメトリーの概要

• 脅威ログ：Cloud Firewall Plus と Cloud IDS の特殊なログです。ディープパケットインスペクションを使用して、悪意のあるトラフィックパターン（SQL インジェクションやマルウェアなど）を特定します。
• VPC Flow ログ：ネットワークインターフェースへの送受信 IP トラフィックのサンプルを記録します。トラフィック分析、量の傾向、上位の通信相手、ドロップされたトラフィック、パケット損失の確認に使用します。
• ファイアウォールログ：ファイアウォールルールに一致した接続試行を記録します。「DENY」イベントの特定や、「ALLOW」ルールの検証に使用します。
• Cloud NAT ログ：NAT 変換を監査します。NAT ゲートウェイを通過するトラフィックの監査や、ポート枯渇のトラブルシューティングに使用します。
• ネットワーキングメトリクス：スループット、RTT（レイテンシ）、パケット損失の集計時系列データです。過去の傾向やパフォーマンスの監視に使用します。
• 接続テスト：経路診断用の静的分析ツールです。エンドポイント間のファイアウォールやルーティングの設定ミスを特定するために使用します。

手順

0. ログソースの優先順位

• 必ず、大量データの分析や集計に Cloud Logging を使用する前に、BigQuery のリンク済みデータセット（例：big_query_linked_dataset、_AllLogs）を確認してください。傾向やブロック数が最も多いルールを調べる場合は、こちらを優先してください。
• スキーマとサンプルの確認：BigQuery または Cloud Logging で複雑な集計やフィルタークエリを作成する前に、まずログレコードのサンプルを1件確認します（bq query では --format=json を指定して LIMIT 1、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 のクエリで「Unrecognized name」エラーまたはスキーマの不一致が発生した場合：

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

重要：ユーザーがコスト見積もりを依頼した場合は、必ず references/vpc-flow-logs-cost-estimation.md のみを使用してください。コスト見積もりのタスクでは、 references/vpc-flow-analysis.md を参照したり、使用したりしないでください。

境界（重要）

• 必ず、答えが判明したらすぐに直接回答してください。
• 結果を提示する前に、探索的なクエリを2回より多く実行してはなりません。
• 必ず、ユーザーの明示的な許可がない限り、二次検証（たとえば、ファイアウォールによるブロックが見つかった後に VPC フローを確認すること）を行ってはなりません。
• 必ず、実行前に生成した SQL をレビュー用に提示してください。
• 必ず、Google Cloud Console の Flow Analyzer へのリンクを含めてください。
• 必ず、一次データソース（たとえば、Cloud Monitoring のメトリクス）から確定的な答えが得られている場合は、2つ目のデータソース（BigQuery のログなど）を照会してはなりません。ユーザーから差異の理由を明示的に尋ねられない限り、精度を「検証」するためにメトリクスとログを比較してはなりません。
• 差異の調査を繰り返さない：ツール A が結果（たとえば、80,000 件）を返し、ツール B が異なる結果（たとえば、1,000 件）を返した場合、差異を説明するために詳細な調査を開始してはなりません。一次ツールの結果を提示して、終了してください。
• 必ず、最初のターンで時間範囲の計算（たとえば、「12時間前」）を行い、手順を省いてください。
• 非アクティブ状態の確定的な受け入れ：「0」、「トラフィックなし」、「データが見つかりません」、「レコードが見つかりません」という結果は、要求された期間とリソースについての確定的な結果として扱ってください。これを確定状態として報告し、直ちに終了しなければなりません。
• 標準化された調査経路：「Top-N」またはボリュームベースの調査タスク（たとえば、「トラフィックが最も多いもの」、「ヒット数が最も多いもの」、「上位のトーカー」）では、必ず _AllLogs データセットに対して BigQuery 集計を使用してください。Monitoring API を使って個々の時系列データポイントを手動で集計することは禁止されています。手順が非効率になるためです。
• 補助スクリプトの禁止：データ取得と解析のロジックはすべて、直接のツール呼び出し（bq、curl、gcloud）として実行してください。回避可能な環境エラーや権限エラーを引き起こし、調査がタイムアウトする原因となるため、ローカルのシェルスクリプト（.sh）や Python ファイルを作成または実行してはなりません。
• 調査の効率化：ボリューム分析（たとえば、「接続数」や「バイト数別の上位 IP」）では、VPC Flow ログ（_AllLogs）に対する BigQuery 集計が主要な信頼できる情報源です。BigQuery のデータが利用可能であれば、それが確定的な結果です。BigQuery の件数を「二重チェック」するために Monitoring API を照会してはなりません。