Cloud Monitoring / Logging

解決する課題

物理サーバーやエージェントを自前で組まずに、Google Cloud 全体の状態を一元的に把握できます。

• システムが 今どんな状態か（メトリクス）を知りたい
• 異常を 自動で検知して通知/対処したい（アラートポリシー → 通知チャネル）
• ログを 一元的に集めて調べたい（Logging とログクエリ）
• 「99.9% で応答する」といった SLO を定義して継続監視したい

主要概念と用語

Cloud Monitoring / Logging は、もともと買収した Stackdriver が前身で、現在は Google Cloud Observability の一部として統合されています。

• 指標（メトリクス）: 時系列の数値。compute.googleapis.com/instance/cpu/utilization のように メトリクスタイプ で識別。Google 提供の指標と、ユーザー定義（カスタム）指標がある
• モニタリング対象リソース（Monitored Resource）: 指標がどのリソースに紐づくか（gce_instance、k8s_container など）。AWS の名前空間＋ディメンションに近い概念
• 指標スコープ（Metrics Scope）: 1 つのスコーピングプロジェクトから複数プロジェクトの指標をまとめて閲覧する仕組み（マルチプロジェクト監視）
• アラートポリシー / 条件（Condition）: しきい値超過などで発火し、通知チャネル（メール、Slack、PagerDuty、Pub/Sub、Webhook、SMS）へ通知
• アップタイムチェック（Uptime Check）: 外形監視。世界各地のロケーションから HTTP/HTTPS/TCP の死活を確認
• ダッシュボード: 可視化。MQL（Monitoring Query Language）/ PromQL での柔軟なクエリにも対応
• ログ（Logging）: ログエントリ を ログバケット に保存。ログシンク で BigQuery / Cloud Storage / Pub/Sub へエクスポート
• ログベースの指標（Log-based Metrics）: ログのパターン一致やフィールド抽出から指標を生成し、アラートに使える
• Ops エージェント（Ops Agent）: VM 内部の指標（メモリ等）やアプリログを送る統合エージェント。旧来の Monitoring Agent / Logging Agent の後継

仕様・制限・クォータ

• 多くの Google Cloud 指標は 60 秒（1 分）粒度で自動収集。カスタム指標は任意の粒度で送信可
• アラートポリシー はプロジェクトあたりの上限（例: 既定 500 件、条件数の上限あり）がある。引き上げは制限の調整から申請
• ログルーター（Log Router） が全ログエントリを受け取り、_Default / _Required バケットなどへルーティング
• ログバケットの 保持期間 は設定可能（_Required は 400 日固定、_Default は既定 30 日、ユーザー定義は 1〜3650 日）
• カスタム指標・ログベース指標には命名やラベル基数（cardinality）の制限がある

内部の仕組み

各 Google Cloud サービスが指標を自動で時系列データベースに送信し、Monitoring が保持します。アラートポリシーは一定期間にわたり条件を評価し、合致するとインシデント（incident）を生成して通知チャネルへ送ります。

ログは ログルーター にいったん集約され、シンクのフィルタに従って各バケットや外部宛先へ分配されます。_Required バケットの監査ログは課金されず削除もできない一方、_Default バケットは課金対象です。

設計パターン / ベストプラクティス

• アラートポリシー → 通知チャネル（PagerDuty/Slack）で人へ、Pub/Sub 通知から Cloud Functions で自動対処へ
• ログを ログシンク で BigQuery に集約し、SQL で横断分析。長期保管は Cloud Storage
• SLO（サービスレベル目標） と エラーバジェット を Monitoring で定義し、バーンレートアラートで早期検知
• VM には Ops エージェント を標準導入し、メモリ・ディスク・アプリログを取りこぼさない
• マルチプロジェクトは 指標スコープでスコーピングプロジェクトに集約して横断監視

運用・監視

• 監視対象の取りこぼし → Ops エージェントの導入・設定と、サービスアカウントの IAM 権限（roles/monitoring.metricWriter など）を確認
• アラートが発火しない → 条件の評価期間・整列（alignment）・データ欠損時の挙動（evaluationMissingData）を確認
• ログが見えない → ログルーターのシンク/除外（exclusion）フィルタと、_Default 以外への振り分けを確認
• コスト増 → 取り込みログ量・カスタム指標数・ログ保持期間の使い過ぎを点検

コスト

課金は主に 取り込みログ量（GiB）、カスタム/外部指標、監視 API 呼び出し、アップタイムチェック実行数 で決まります。Google Cloud の標準指標と _Required バケットの監査ログは無料です。

セキュリティ

• ログの保存先バケットは CMEK（顧客管理鍵 / Cloud KMS） で暗号化でき、アクセスは IAM で制御
• 監視/ログの権限は IAM ロール で最小化（閲覧は roles/monitoring.viewer / roles/logging.viewer、書き込みは metricWriter / logWriter）
• 機微情報のログ流出を防ぐため、シンクの除外フィルタや Sensitive Data Protection（旧 DLP） で秘匿化
• 改ざん防止が必要な監査要件には、ログバケットのロック（保持の固定） を利用

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 通知チャネル（メール）を作成し、チャネル名（ID）を取得
gcloud beta monitoring channels create \
  --display-name="oncall-email" \
  --type=email \
  --channel-labels=email_address=oncall@example.com

# CPU 使用率が 80% を超えたら通知するアラートポリシーを作成
# （--condition-filter は MQL ではなくフィルタ式。閾値はパーセンテージ換算で 0.8）
gcloud alpha monitoring policies create \
  --display-name="high-cpu" \
  --notification-channels="projects/PROJECT_ID/notificationChannels/CHANNEL_ID" \
  --condition-display-name="cpu>80%" \
  --condition-filter='resource.type="gce_instance" AND metric.type="compute.googleapis.com/instance/cpu/utilization"' \
  --condition-threshold-value=0.8 \
  --condition-threshold-comparison=COMPARISON_GT \
  --condition-threshold-duration=300s \
  --aggregation='{"alignmentPeriod":"60s","perSeriesAligner":"ALIGN_MEAN"}'

# ログをフィルタして直近のエラーを確認
gcloud logging read \
  'resource.type="cloud_run_revision" AND severity>=ERROR' \
  --limit=20 --freshness=1h --format="table(timestamp, severity, textPayload)"

# ログシンクを作成し、エラー以上のログを BigQuery へエクスポート
gcloud logging sinks create errors-to-bq \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/app_logs \
  --log-filter='severity>=ERROR'