Harmonic Society
オンライン予約 お問い合わせ
プログラミング

Google Cloud Monitoringの実践ガイド｜メトリクス・アラート・ダッシュボード設定

kento_morota 18分で読めます

「サーバーが落ちてからしか気づけない」「リソース使用率がいつの間にか上限に達していた」――こうした運用トラブルは、適切な監視体制を構築することで未然に防げます。

Google Cloud Monitoring（旧Stackdriver Monitoring）は、GCP上のリソースを包括的に監視するためのマネージドサービスです。この記事では、メトリクスの基本からアラートポリシーの設計、実用的なダッシュボードの作成まで、本番運用に必要な監視設定をステップごとに解説します。

Cloud Monitoringとは？GCP監視の全体像を把握する

Cloud Monitoringは、Google Cloud Operationsスイートの中核を成すメトリクス収集・可視化・アラート通知サービスです。Compute Engine、Cloud Run、Cloud SQL、BigQueryなど、ほぼすべてのGCPサービスのメトリクスを自動的に収集します。

Cloud Monitoringの主要機能

Cloud Monitoringが提供する機能は、大きく4つに分類できます。

  • メトリクス収集：CPU使用率、メモリ使用量、ディスクI/O、ネットワークトラフィックなどのリソースメトリクスを自動収集
  • アラート通知：メトリクスが閾値を超えた場合にメール、Slack、PagerDutyなどで通知
  • ダッシュボード：メトリクスをグラフやチャートで可視化し、システムの状態を一覧で把握
  • アップタイムチェック：外部からHTTP/HTTPSエンドポイントの可用性を定期的に確認

料金体系の基本

Cloud Monitoringの料金は、取り込むメトリクスの量に基づきます。

  • GCPサービスのメトリクス：無料（Compute Engine、Cloud SQLなどの標準メトリクス）
  • カスタムメトリクス：最初の150MBまで無料、以降は$0.258/MB
  • アップタイムチェック：月100万回の実行まで無料

中小規模のシステムであれば、多くの場合は無料枠内で運用可能です。GCPのコスト管理と合わせて、監視コストも適切に把握しておきましょう。

メトリクスの基礎知識と主要なメトリクス

効果的な監視を行うには、まず収集するメトリクスの意味と重要度を理解する必要があります。

メトリクスの種類

GCPのメトリクスは以下の3種類に分類されます。

1. システムメトリクス（自動収集）
GCPサービスが自動的に出力するメトリクスです。追加設定なしで利用できます。

  • compute.googleapis.com/instance/cpu/utilization：VM CPU使用率
  • compute.googleapis.com/instance/disk/read_bytes_count：ディスク読み取りバイト数
  • cloudsql.googleapis.com/database/cpu/utilization：Cloud SQL CPU使用率
  • run.googleapis.com/request_count：Cloud Runリクエスト数

2. エージェントメトリクス
Compute EngineのVMにOps Agentをインストールすることで、OS レベルの詳細なメトリクスを収集します。

# Ops Agentのインストール（Debian/Ubuntu）
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

# ステータスの確認
sudo systemctl status google-cloud-ops-agent

Ops Agentを導入すると、メモリ使用率、プロセスごとのCPU使用率、ディスクの空き容量などが取得可能になります。

3. カスタムメトリクス
アプリケーション固有のメトリクスを自前で送信します。たとえば「アクティブユーザー数」「注文処理時間」「キューの待機件数」などが該当します。

Compute Engineで監視すべき主要メトリクス

VMを運用する場合、以下のメトリクスは最低限監視してください。

  • CPU使用率：80%超が持続する場合はスケールアップまたはスケールアウトを検討
  • メモリ使用率（Ops Agent必要）：90%超はOOMKillのリスクがある
  • ディスク使用率（Ops Agent必要）：85%超で増設を計画
  • ネットワーク受信・送信バイト数：異常なトラフィック増加を検知

アラートポリシーの設計と作成

メトリクスを収集するだけでは、障害を防ぐことはできません。適切なアラートポリシーを設定し、問題が発生する前に通知を受け取る仕組みを作ることが重要です。

アラート設計のベストプラクティス

効果的なアラートを設計するためのポイントを紹介します。

アラート疲れを防ぐ
頻繁に鳴るアラートは無視されるようになります。本当に対応が必要な状況だけを通知するよう、閾値を慎重に設定してください。

段階的な閾値を設定する
Warning（注意）とCritical（緊急）の2段階を用意し、通知先を分けると効果的です。

  • Warning（CPU 70%超 5分間継続）→ Slackチャンネルに通知
  • Critical（CPU 90%超 3分間継続）→ PagerDutyでオンコール担当に通知

gcloudでアラートポリシーを作成する

以下は、Compute EngineのCPU使用率に対するアラートポリシーの作成例です。

# アラートポリシーをJSONで定義
cat << 'EOF' > cpu-alert-policy.json
{
  "displayName": "VM CPU使用率 - Critical",
  "conditions": [
    {
      "displayName": "CPU使用率が90%を超過",
      "conditionThreshold": {
        "filter": "metric.type=\"compute.googleapis.com/instance/cpu/utilization\" AND resource.type=\"gce_instance\"",
        "comparison": "COMPARISON_GT",
        "thresholdValue": 0.9,
        "duration": "180s",
        "aggregations": [
          {
            "alignmentPeriod": "60s",
            "perSeriesAligner": "ALIGN_MEAN"
          }
        ]
      }
    }
  ],
  "notificationChannels": ["projects/PROJECT_ID/notificationChannels/CHANNEL_ID"],
  "alertStrategy": {
    "autoClose": "604800s"
  }
}
EOF

# アラートポリシーの作成
gcloud alpha monitoring policies create --policy-from-file=cpu-alert-policy.json

通知チャンネルの設定

アラートの通知先を設定します。メールとSlackの設定例です。

# メール通知チャンネルの作成
gcloud alpha monitoring channels create \
  --display-name="運用チーム メール" \
  --type=email \
  --channel-labels=email_address=ops-team@example.com

# Slack通知チャンネルの作成（事前にSlack連携設定が必要）
gcloud alpha monitoring channels create \
  --display-name="運用チーム Slack" \
  --type=slack \
  --channel-labels=channel_name=#gcp-alerts

推奨するアラートポリシー一覧

本番環境で最低限設定すべきアラートポリシーの推奨例です。

  • VM CPU使用率：90%超が3分間継続
  • VMメモリ使用率：90%超が5分間継続
  • ディスク使用率：85%超
  • Cloud SQL CPU使用率：80%超が5分間継続
  • Cloud SQLストレージ使用率：80%超
  • Cloud Runエラーレート：5xx応答が5%超
  • Cloud Runレイテンシ：p99が3秒超
  • アップタイムチェック失敗：2リージョン以上で失敗

アップタイムチェックの設定

アップタイムチェックは、世界中のGoogleデータセンターから定期的にエンドポイントにアクセスし、サービスの可用性を外部から監視する機能です。

HTTPアップタイムチェックの作成

# アップタイムチェックの作成
gcloud monitoring uptime create my-web-check \
  --display-name="Webサイト可用性チェック" \
  --resource-type=uptime-url \
  --monitored-resource="host=www.example.com" \
  --protocol=HTTPS \
  --path=/ \
  --period=300 \
  --timeout=10 \
  --content-match-content="OK" \
  --regions=ASIA_PACIFIC,USA,EUROPE

設定のポイントは以下の通りです。

  • チェック間隔：本番環境では1〜5分間隔を推奨
  • タイムアウト：通常のレスポンス時間の2〜3倍に設定
  • コンテンツマッチ：ステータスコードだけでなく、レスポンスボディの内容もチェックすると、アプリケーションレベルの異常を検知できる
  • チェックリージョン：複数リージョンからチェックし、2つ以上で失敗した場合にアラートを発報する設定が推奨

ヘルスチェック用エンドポイントの設計

アップタイムチェック用に専用のヘルスチェックエンドポイントを用意すると、より正確な監視が可能です。

# ヘルスチェックエンドポイントの例（Node.js）
app.get('/health', async (req, res) => {
  try {
    // データベース接続チェック
    await db.query('SELECT 1');
    // 外部APIの接続チェック
    await fetch('https://api.example.com/status');
    res.status(200).json({ status: 'healthy' });
  } catch (error) {
    res.status(503).json({ status: 'unhealthy', error: error.message });
  }
});

この方式により、サーバーは動いているがデータベース接続が切れているといった、内部的な異常も検知できます。

ダッシュボードの作成と活用

ダッシュボードは、システムの健全性を一目で把握するための重要なツールです。適切に設計されたダッシュボードは、障害対応の初動を早めます。

ダッシュボードの設計原則

効果的なダッシュボードを作るための原則です。

1. 目的別にダッシュボードを分ける

  • 概要ダッシュボード：全サービスの稼働状況を俯瞰するもの。日常の確認用
  • サービス別ダッシュボード：特定サービスの詳細メトリクス。障害調査用
  • ビジネスメトリクスダッシュボード：リクエスト数、エラーレート、レイテンシの推移

2. RED メソッドを活用する
サービスの健全性を測る指標として「RED」が定番です。

  • Rate（リクエストレート）：1秒あたりのリクエスト数
  • Errors（エラーレート）：エラー応答の割合
  • Duration（レイテンシ）：リクエスト処理にかかる時間

gcloudでダッシュボードを作成する

# ダッシュボード定義をJSONで作成
cat << 'EOF' > dashboard.json
{
  "displayName": "本番環境 概要ダッシュボード",
  "gridLayout": {
    "columns": 2,
    "widgets": [
      {
        "title": "VM CPU使用率",
        "xyChart": {
          "dataSets": [
            {
              "timeSeriesQuery": {
                "timeSeriesFilter": {
                  "filter": "metric.type=\"compute.googleapis.com/instance/cpu/utilization\" AND resource.type=\"gce_instance\"",
                  "aggregation": {
                    "alignmentPeriod": "300s",
                    "perSeriesAligner": "ALIGN_MEAN"
                  }
                }
              }
            }
          ]
        }
      },
      {
        "title": "Cloud SQL CPU使用率",
        "xyChart": {
          "dataSets": [
            {
              "timeSeriesQuery": {
                "timeSeriesFilter": {
                  "filter": "metric.type=\"cloudsql.googleapis.com/database/cpu/utilization\"",
                  "aggregation": {
                    "alignmentPeriod": "300s",
                    "perSeriesAligner": "ALIGN_MEAN"
                  }
                }
              }
            }
          ]
        }
      }
    ]
  }
}
EOF

# ダッシュボードの作成
gcloud monitoring dashboards create --config-from-file=dashboard.json

MQL（Monitoring Query Language）の活用

複雑なメトリクスの集計やフィルタリングには、MQLが便利です。

# Cloud Runのp95レイテンシを取得するMQL
fetch cloud_run_revision
| metric 'run.googleapis.com/request_latencies'
| align delta(1m)
| every 1m
| group_by [resource.service_name],
    [value_request_latencies_percentile: percentile(value.request_latencies, 95)]

# エラーレートを計算するMQL
fetch cloud_run_revision
| metric 'run.googleapis.com/request_count'
| filter metric.response_code_class = '5xx'
| align rate(1m)
| every 1m
| group_by [resource.service_name], [error_count: sum(value.request_count)]

カスタムメトリクスの送信

GCPの標準メトリクスでは取得できない、アプリケーション固有の指標を監視するために、カスタムメトリクスを活用します。

OpenTelemetryを使ったカスタムメトリクス送信

GCPはOpenTelemetryを公式にサポートしています。以下はPythonでカスタムメトリクスを送信する例です。

# 必要なパッケージのインストール
# pip install opentelemetry-api opentelemetry-sdk \
#   opentelemetry-exporter-gcp-monitoring

from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.cloud_monitoring import CloudMonitoringMetricsExporter
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader

# メトリクスエクスポーターの設定
exporter = CloudMonitoringMetricsExporter()
reader = PeriodicExportingMetricReader(exporter, export_interval_millis=60000)
provider = MeterProvider(metric_readers=[reader])
metrics.set_meter_provider(provider)

meter = metrics.get_meter("my-application")

# カスタムメトリクスの定義
order_counter = meter.create_counter(
    name="orders_processed",
    description="処理済み注文数",
    unit="1"
)

processing_time = meter.create_histogram(
    name="order_processing_time",
    description="注文処理時間",
    unit="ms"
)

# メトリクスの記録
order_counter.add(1, {"status": "success", "region": "tokyo"})
processing_time.record(245, {"order_type": "standard"})

カスタムメトリクスの命名規則

カスタムメトリクスは一貫した命名規則を適用すると、管理が容易になります。

  • 形式：custom.googleapis.com/[サービス名]/[メトリクス名]
  • 例：custom.googleapis.com/order-service/processing_time
  • ラベル：環境（production/staging）、リージョン、サービスバージョンなどをラベルで付与

ログベースメトリクスとCloud Loggingとの連携

Cloud Monitoringは、Cloud Loggingと密接に連携しています。ログからメトリクスを自動生成するログベースメトリクスを活用すると、アプリケーションの振る舞いを効率的に監視できます。

ログベースメトリクスの作成

# エラーログの発生回数をカウントするメトリクス
gcloud logging metrics create error-count \
  --description="アプリケーションエラーの発生回数" \
  --log-filter='resource.type="cloud_run_revision" AND severity>=ERROR'

# 特定のログメッセージをカウント
gcloud logging metrics create payment-failures \
  --description="決済失敗の回数" \
  --log-filter='resource.type="cloud_run_revision" AND jsonPayload.event="payment_failed"'

作成したログベースメトリクスは、通常のメトリクスと同様にアラートポリシーやダッシュボードで使用できます。「決済失敗が5分間で10件以上」のような業務ロジックに基づいたアラートを設定できる点が大きなメリットです。

Cloud Loggingのログエクスプローラーとの連携

ダッシュボードでメトリクスの異常を発見したら、Cloud Loggingのログエクスプローラーで原因を調査する流れが一般的です。メトリクスのグラフからワンクリックで対応するログにジャンプできるため、障害対応の効率が大幅に向上します。

まとめ：効果的な監視体制で安定運用を実現する

Google Cloud Monitoringを活用した監視体制の構築方法を解説しました。要点を整理します。

  • メトリクス：標準メトリクスに加え、Ops Agentとカスタムメトリクスで監視範囲を拡大する
  • アラート：段階的な閾値で「アラート疲れ」を防ぎ、本当に重要な通知のみ送る
  • アップタイムチェック：外部からの可用性監視で、ユーザー視点の障害を検知する
  • ダッシュボード：目的別に作成し、REDメソッドでサービスの健全性を可視化する
  • ログベースメトリクス：ログから自動的にメトリクスを生成し、業務ロジックに基づいた監視を実現する

まずは主要なリソースのアラートポリシーと概要ダッシュボードの作成から始めてください。VPCネットワークのFlow Logsや、Cloud Runのリクエストメトリクスなど、各サービスの監視項目は運用しながら段階的に拡充していくのが現実的です。また、Cloud BuildによるCI/CDパイプラインのビルド成功率・失敗率もダッシュボードに追加しておくと、開発プロセス全体の可視化に役立ちます。

#GCP#Cloud Monitoring#監視
共有:
無料メルマガ

週1回、最新の技術記事をお届け

AI・クラウド・開発の最新記事を毎週月曜にメールでお届けします。登録は無料、いつでも解除できます。

※ プライバシーポリシーに基づき管理します

関連記事

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説
AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド

AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド
AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化

AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化
AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術

AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術
AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド

AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド
AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法

AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法
AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング

AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング
AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践

AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践
AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AI活用のヒントをお探しですか？お気軽にご相談ください。

まずは話だけ聞いてもらう