WEB問題集
正解：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 で十分実現できる要件をオーバーエンジニアリングしています。
正解：C
正解の根拠
ビジネス KPI を継続的に観測しアラートと SLO で参照するには、Cloud Monitoring に Custom Metric として送信するのが王道です。Cloud Run のような GA サービスでは OpenTelemetry の Metrics SDK と GCP Exporter を組み合わせると、追加のサイドカー無しで集計済みカウンタやヒストグラムを送信できます。送信後は MQL や PromQL で時系列クエリを書き、同じ指標を Alert ポリシーと Service Monitoring の SLI 双方で参照可能です。
送信方式の比較
| 方式 | 遅延 | SLO 連携 | 運用負荷 |
|---|---|---|---|
| OpenTelemetry Custom Metric | 低 | 直接 SLI 化可能 | 低 |
| ログ集計のみ | 中 | log-based metric が別途必要 | 中 |
| Trace span 数代替 | 低 | サンプリングで欠損 | 不安定 |
サンプル送信コード
from opentelemetry import metrics
meter = metrics.get_meter("orders")
order_counter = meter.create_counter("orders_completed_total")
order_counter.add(1, {"region": "asia-northeast1"})不正解の理由
- A: 手動 CSV 集計は自動化と SLO 連携の要件を満たせず、アラートのリアルタイム性も確保できません。
- B: Trace は通常サンプリングが効くため、件数の正確な計測には設計上向いていません。
- D: Cloud Storage 経由のバッチ集計は遅延が大きく、Monitoring と SLO API への直接連携も別途必要となります。
正解：C
正解の根拠
MQL は時系列に対する関数型クエリ言語であり、align(集計粒度の正規化) と group_by(ラベル単位の集約) を組み合わせて任意の比率を算出できます。直近と過去を比較する場合は align rate に対し時間オフセットを取った同種クエリを join し、比率の閾値で alert を発火させます。これは Cloud Monitoring が公式に推奨するパターンです。
MQL サンプル
fetch cloud_run_revision
| metric 'run.googleapis.com/request_count'
| filter metric.response_code_class = '5xx'
| align rate(5m)
| every 1m
| { ident
; ident | group_by [], mean | window 1h | shift 5m }
| ratio
| condition val() > 3方式の比較
| 方式 | リアルタイム性 | 運用容易性 |
|---|---|---|
| MQL ratio | 1 分粒度で発火 | Alert ポリシーから直接利用 |
| Logs Explorer + 手動 Excel | 分単位以上 | 属人化しやすい |
| Billing 連動 | 時間単位 | 因果関係が間接的 |
不正解の理由
- A: Billing データの粒度は時間単位で、5 分粒度の異常検知には粒度と意味の両面で合いません。
- B: 手動エクスポートはアラート連携できず、自動的な閾値判定の仕組みとしては成立しません。
- D: Trace の目視確認は属人的でアラート化できず、SLO や PagerDuty 連携の要件も満たせません。
正解：D
正解の根拠
Google Cloud Managed Service for Prometheus は、収集したメトリクスを Cloud Monitoring のバックエンドに保存します。クエリ側は PromQL に対応しており、Cloud Monitoring の Metrics Explorer、Grafana data source、Alert ポリシーのいずれからも PromQL を発行できます。これにより既存の OSS 資産をほぼそのまま再利用可能です。
クエリ言語の使い分け
| 言語 | 対象データ | 主な用途 |
|---|---|---|
| PromQL | Managed Prometheus 取り込み | K8s メトリクスの解析 |
| MQL | Cloud Monitoring 全般 | GCP ネイティブ指標の比率算出 |
| LogQL 風フィルタ | Cloud Logging | ログ検索 / log-based metric 定義 |
PromQL 例
sum by (pod)(
rate(container_cpu_usage_seconds_total{namespace="shop"}[5m])
)不正解の理由
- A: BigQuery SQL は分析用途であり、Monitoring の Alert ポリシーから直接呼び出す経路としては設計されていません。
- B: Looker Studio は可視化レイヤーで、PromQL の代替となるクエリ言語を提供していません。
- C: Cloud Logging のフィルタ言語はログ用途で、Prometheus メトリクスの時系列クエリには対応していません。
（2つ選択）
正解：A, C
正解の根拠
Alert ポリシーの誤検知抑制と取り逃し防止は、duration(継続時間)・auto-close・対象フィルタ・アグリゲーション粒度の 4 つで決まります。継続時間を短くしすぎるとスパイクで誤発報し、長すぎると重大障害の検知が遅れます。フィルタとアグリゲーションは、対象を「サービス × リージョン」など業務単位にそろえることで、ノイズと信号を分離します。
主要設定の意義
| 設定 | 役割 | 典型値 |
|---|---|---|
| duration | 瞬間スパイク除去 | 3〜10 分 |
| auto-close | 復旧後の自動クローズ | 30 分〜24 時間 |
| filter | 対象リソースの限定 | service / namespace |
| aggregation | 系列の集約粒度 | per service per region |
運用 Tips
- SLO に紐づくバーンレートアラートは duration を短め、長期予算アラートは長めに分けて設定します
- 通知チャネルは PagerDuty と Email を併用し、片側障害でも届くよう冗長化します
- incident の auto-close は障害復旧の検出ロジックと併せて調整します
不正解の理由
- B: 通知経路を 1 つに絞ると、その経路自体の障害時に重大インシデントを取り逃すリスクが高まります。
- D: ダッシュボードの装飾は人の視認性に依存するため、自動的なアラート品質改善には寄与しません。