PCD#451(managing)
GKE と Cloud Run を併用するマイクロサービス基盤で、複数プロジェクトのリソースを 1 つの Cloud Monitoring 画面から横断的に観察したいです。最小工数で実現するには、どの構成が最も適切でしょうか。
正解：D
正解の根拠
Cloud Monitoring の metrics scope は、1 つのスコーピングプロジェクトに対して複数の被監視プロジェクトをぶら下げる仕組みです。これにより、各プロジェクトのメトリクスを単一のダッシュボードやアラートポリシーから参照できます。設定はコンソールまたは Terraform で完結し、追加のデータパイプラインは不要です。
主要な集約方式の比較
| 方式 | 運用工数 | 遅延 | 適性 |
|---|---|---|---|
| metrics scope | 低 | ほぼリアルタイム | マルチプロジェクト監視に最適 |
| BigQuery 集約 + Looker Studio | 高 | 分単位 | 分析向け、運用監視には冗長 |
| ダッシュボード複製 | 中 | 手動操作依存 | 恒常運用には不向き |
設定手順
- スコーピングプロジェクトで Monitoring API を有効化します
- 「Metrics scope の管理」から被監視プロジェクトを追加します
- 追加後はリソースタイプ別にダッシュボードと Alert ポリシーを構成します
gcloud monitoring metrics-scopes add-monitored-project
--project=scoping-project
--monitored-project=workload-project不正解の理由
- A: Logs Explorer はログ閲覧用のため、メトリクスの横断ダッシュボードには利用できず、目的に対して手段が一致しません。
- B: ダッシュボード複製は metrics scope の機能を再発明する形となり、保守負担が継続的に増えてしまいます。
- C: BigQuery 集約はコストと遅延を増やすうえ、metrics scope で十分実現できる要件をオーバーエンジニアリングしています。
コメント