Google Cloud(GCP)のCloud Monitoring解説 (基本編)

G-genの杉村です。

Cloud Monitoring (旧称 Stackdriver) を使えば、 Google Cloud (GCP) のリソースモニタリング等を行うことができます。何ができるサービスなのか、基本を見ていきましょう。

Cloud Monitoring

Cloud Monitoring の概要

Cloud Monitoring とは

Cloud Monitoring は Google Cloud (GCP) の オペレーションスイート と呼ばれるサービス群の一つで、各種 Google Cloud サービスからパフォーマンスデータ等を収集して保存・閲覧可能にするサービスです。データ収集元としては Google Cloud の各種サービスのほか、オンプレミスや Amazon Web Services (AWS) 上の仮想サーバなども対象にすることができます。

Cloud Monitoring がデフォルトで収集するデータ (後述の Google Cloud の指標など) に対しては課金されないため、基本機能は無料で使用することができます。

なおオペレーションスイートはかつて Google Stackdriver と呼称されていましたが 2020 年 10 月に改称されました。そのため過去の情報では Cloud Monitoring が Stackdriver と呼ばれていることも多く目にします。

Cloud Monitoring の料金

Cloud Monitoring の料金を解説します。
Google Cloud がデフォルトで収集するメトリクスについては無料です。
ユーザーが Ops Agent で収集する追加メトリクスやカスタムメトリクスは、収集したバイト数あるいはサンプル数に応じて課金されます。

課金対象メトリクスも最初の 150 MB は毎月無料ですがそれ移行は $0.2580/MB が発生します (2022 年 2 月現在) 。
数台〜十数台の VM の Ops Agent 追加指標程度であれば、無料範囲内に収まる可能性があります。
詳細は以下のドキュメントを参照してください。

• Cloud Monitoring pricing summary

後述するアラート機能や稼働時間チェック機能は 無料 です。

リソースモニタリング

Google Cloud の指標

Google Compute Engine (GCE) や Cloud SQL 、 Cloud Storage のバケットなど、あらゆる Google Cloud リソースから 指標 (メトリクス) を収集します。

取得できる指標は、 Google Compute Engine (GCE) や Cloud SQL ならば CPU 使用率やネットワーク IO 、 Cloud Storage ならば API リクエスト数や総使用バイト数などです。

標準的な指標は利用者が 何も設定しなくても、自動的に収集され ます。また、課金は発生しません。
このような自動的に収集されるメトリクス (指標) を Google Cloud の指標 といいます。
指標は、 Cloud Monitoring コンソール画面の Metrics Explorer から見ることができます。

Metrics Explorer 画面

"Google Cloud の指標" で何が収集されるのかは、以下のページを参照してください。

• Google Cloud metrics

Ops エージェントが収集する指標

Google Compute Engine (GCE) の VM に Ops エージェント をインストールすると、 "Google Cloud の指標" の他に追加の指標を収集できます。

実は "Google Cloud の指標" だけですと メモリ使用率 , ディスク使用率 , スワップ利用率 など重要な指標は取れていません。
これは、 Google Cloud の指標は VM のハイパーバイザから取得できる情報 をもとに構成されているからだと考えられます。

Ops エージェントは VM の中の OS 上で稼働し、情報を収集して Cloud Monitoring の API エンドポイントに対してその情報を投げ込みます。
これにより メモリ使用率 , ディスク使用率 , スワップ利用率 など の指標が取得できます。

"Ops エージェントの指標" で何が収集されるのかは、以下のページを参照してください。

• Ops エージェントの指標

なお Ops エージェントの指標は取り込みボリュームに応じて 料金 が発生します。
インスタンス数が数台〜十数台といったレベルでは大した金額にはならないはずですが、数百台レベルのインスタンスを管理する場合は、コストに関する試算も重要になります。

Ops エージェントのセットアップ

セットアップ手順

エージェントのインストール手順等は以下のドキュメントを参照してください。

• Ops エージェントのインストール

要件

Ops エージェントが稼働するインスタンスは以下の条件を全て満たしている必要があることに注意してください。

---

条件1: ネットワーク的に Cloud Monitoring の API エンドポイントに到達できる

• 例1: ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている && VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている && External IP を持っている
• 例2: ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている && VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている && Cloud NAT でインターネットへ出られる
• 例3: 限定公開の Google アクセスで各種 Google API へアクセスできる

(※) 0.0.0.0/0 の代わりに JSON で 公開されている IP アドレス範囲 でも可だが、 IP が変更された際に動的に設定を反映する仕組みが必要

条件2: VM にアタッチされているサービスアカウントがプロジェクトレベルで以下のロールを付与されている

• モニタリング指標の書き込み (roles/monitoring.metricWriter)

条件3: VM の アクセススコープ 設定で Cloud Monitoring への書き込みが許可されている

• "デフォルト" もしくは "全て許可" になっていれば問題ない

---

上記1〜3のどれか一つでも外れていると、エージェントは指標の送信に失敗します。
エージェントが稼働してから数分が経つと Memory Utilization (agent.googleapis.com/memory/percent_used) といった Ops エージェントの指標が表示されますので エージェントのインストール後には正しく指標が送信できているか必ず確認しましょう 。

トラブルシューティング

もしコンソールに指標が表示されない場合は、何らかのエラーが出力されている可能性があります。
Linux インスタンスであれば以下のようなパスにエージェントのログが出力されているので、原因を探りましょう。
/var/log/google-cloud-ops-agent/subagents/logging-module.log

以下はエラーの例です。このときは、ファイアウォールにてインターネットへのアウトバウンドの 443/TCP 通信が拒否されていたため、APIエンドポイントにたどり着けずにエラーになっていました。

[2021/10/14 10:07:46] [error] [upstream] connection #272 to logging.googleapis.com:443 timed out after 10 seconds

なお上記のエラーメッセージで logging.googleapis.com と出ていることからもわかるように、実は Ops エージェントは Cloud Logging にログを送信するエージェントの役割も兼務しています。
かつては Monitoring エージェント と Logging エージェント の2つの異なる役割のエージェントソフトウェアがありましたが、現在はでは Ops エージェントに統合されたのです。

※いったん、本投稿では Cloud Logging の使い方については扱いません。

カスタム指標

ユーザーが独自の指標を収集し Cloud Monitoring に投げ込むこともできます。

"Google Cloudの指標" や "Ops エージェントの指標" は画一的なものであり、アプリケーションの負荷やユーザー体験の状況を正確に反映していない可能性があります。
CPU 使用率やメモリ使用率が上がっているからといって、ユーザーが待たされていることを確実に示しているわけではないですし、逆に CPU 使用率やメモリ使用率に余裕があっても逆のことがありえます。
アプリケーションの実体を示す独自の指標があれば、正確に状況を反映し、スケールアクションなどに繋げることができます。

Cloud Monitoring の Web API に直接データを投げ込む方法とオープンソースのライブラリである OpenCensus を使って Cloud Monitoring に送信する方法があります。
詳細は以下のドキュメントをご参照ください。

• カスタム指標の使用

複数のプロジェクトの指標を表示する

複数のプロジェクトの指標を一つの画面で一覧表示することもできます。

どれか一つのプロジェクトをハブとして、そこに他のプロジェクトを追加することで複数プロジェクトにまたがって指標を確認できます。
このハブとなるプロジェクトを スコーピングプロジェクト (※) と呼びます。
※日本語ドキュメントでは "スコーププロジェクト” と表記されていますが、英語版では "scoping project" となっており意味的には ing が付いていたほうが正しいため、本投稿ではそのように表記します。

スコーピングプロジェクトと権限

Googleは、スコーピングプロジェクトはそれ専用のものを作成し、そこにはリソースを何も作成しないことを推奨しています。
そのほうが権限管理上もシンプルですし、スコーピングプロジェクト自体で指標が生成されないため閲覧上・管理上で優れているためです。

スコーピングプロジェクトを作成して閲覧対象のプロジェクトを追加していくと Metrics Explorer でまとめて閲覧することができます。
閲覧する人のアカウントは、 スコーピングプロジェクトに対してのみ IAM 権限 (モニタリング閲覧者 (roles/monitoring.viewer) 等) を持っていれば、配下のプロジェクトの全ての指標を閲覧できます。

アラート

指標にしきい値を設定し、超過した際にメールを飛ばすなどの アラート設定 ができます。
一つ一つのアラート設定を アラートポリシー といいます。

例えば、 「CPU使用率が」「インスタンスグループ全体で」「5分の間」「80%を超えた場合に」「メールを発報する」 などの設定が可能です。

メール発報の他、以下のアクションが可能です (種類とベータ版表記は 2021/11 現在のもの) 。
このような通知先のことを 通知チャネル (Notification Channel) と言います。

• Cloud Mobile App (Google Cloud のモバイルアプリ)
• PagerDuty Sync (ベータ版)
• Slack (ベータ版)
• Webhook (ベータ版)
• Eメール
• SMS
• Cloud Pub/Sub (ベータ版)

ベータ版と表記されているものは仕様や機能の存続が保証されているわけではない点に十分注意しましょう。

ベータ版ですので本番利用には慎重になる必要がありますが、通知先に Pub/Sub があるので、指標のしきい値超過をトリガに Pub/Sub にメッセージを送信し、 Pub/Sub トリガの Cloud Functions を起動して様々なアクションを実行することも可能でしょう。

アラートポリシーの設定方法は以下を参照ください。

• 指標ベースのアラート ポリシーの管理

アラートの設定画面

稼働時間チェック (Uptime check)

稼働時間チェック 機能 (英名: Private uptime check / Public uptime check) により一般に「URL監視」あるいは「外形監視」などと呼ばれる監視が簡易的に設定できます。

HTTP, HTTPS, TCP (任意ポート) のいずれかのトラフィックを Google から対象リソースに送信し、そのレスポンスを見て、想定状態とことなっていればアラートを発信することができます。

インターネットへ公開しているエンドポイントを対照とする Public uptime check と、閉じた VPC 内のエンドポイント (Private IP) を対照とする Private uptime check の2種類があります。

ターゲットは以下のいずれかで指定可能です。

• Public uptime check の場合
  • URL
  • Kubernetes LoadBalancer Service
  • VM インスタンス
  • App Engine サービス
  • Amazon Web Services（AWS）のロードバランサ
• Private uptime check の場合
  • Service Directory Endpoint (VM や L4 Internal Load Balancer の IP アドレス)

また通知方法はアラートの項で説明した "通知チャネル" から選択できます。

設定時は VPC のファイアウォール等を適切に設定する必要があります。手順の詳細は、以下の公式ドキュメントを御覧ください。

• 公開の稼働時間チェックを作成する
• 非公開稼働時間チェックを作成する

ダッシュボード

指標を見るにはコンソール画面の Metrics Explorer の他、 ダッシュボード という機能を使うこともできます。

ダッシュボードでは Metrics Explorer よりも詳細に表示をカスタマイズでき、グラフの表現も様々です。

• ダッシュボードとグラフ

またダッシュボード定義は JSON 形式でエクスポートできます。

ダッシュボードは運用・監視の要件に合わせて自在に作成が可能ですし、最初からプリセットで構成されているサービスごとのダッシュボードも用意されています。

プリセットのVM用ダッシュボード

Monitoring Query Language (MQL)

コンソールによるグラフィカルな表示のみならず Monitoring Query Language (MQL) というクエリ言語でプログラマブルに指標を取得することもできます。
また関数等を使い計算が可能です。
ドキュメントでは以下のようなユースケースが紹介されています。

• 特定のクラスのレスポンス コードにつながるリクエストの割合を計算
• 現在の値と過去の値の比率を計算
• 事前定義された値ではなく、任意でパーセンタイル値を選択
• 時系列のサンプルをランダムに選択
• 複数の指標タイプの時系列の値に対して任意の算術式を評価
• 正規表現のサブフィールド キャプチャを含む任意の文字列操作を使用して、データを集計する新しいラベルを作成
• 出力データの時間範囲と期間を制御

さらに、前述のアラート発動の条件を MQL で記述することもできます。

MQL は上級者向けですが、ロジックで導出した値に基づいてアラートを発報したり情報を取得したりしたい場合は選択肢として検討しましょう。

杉村 勇馬 (記事一覧) (Facebook)

クラウドソリューション部 部長

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格10冠。

2022年5月現在、ハマっているものはモンスターエナジーウルトラ。

Follow @y_sugi_it