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

Cloud Monitoring の概要
- Cloud Monitoring とは
- Cloud Monitoring の料金
リソースモニタリング
アラート
Uptime check (稼働時間チェック)
ダッシュボード
Monitoring Query Language (MQL)

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 から見ることができます。

"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%を超えた場合に」「E メールを発信する」などの設定が可能です。

通知チャネル

メール発報の他、以下のアクションが可能です。これらのような通知先のことを 通知チャネル (Notification Channel) と言います。

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

通知先に Pub/Sub があるので、指標のしきい値超過をトリガに Pub/Sub にメッセージを送信し、 Pub/Sub トリガの Cloud Functions を起動して様々なアクションを実行することも可能です。

設定方法

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

参考 : 指標ベースのアラートポリシーの管理

また、以下の当社記事もご参照ください。

blog.g-gen.co.jp

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

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 (公開の稼働時間チェック)

Public uptime check (公開の稼働時間チェック) はインターネット公開の HTTP エンドポイントを対象とする uptime check です。

以下をターゲットとして設定できます。

URL
Kubernetes LoadBalancer Service
VM インスタンス
App Engine サービス
Amazon Web Services（AWS）のロードバランサ

設定時は VPC のファイアウォール等を適切に設定する必要があります。 0.0.0.0/0 からの HTTP(S) トラフィックを許可していれば問題ありませんが、 uptime-check の接続元 IP のリストを取得することもできます。

このリストの IP アドレス群を許可することで接続元を絞ることもできますが、こういったクラウドサービスの IP アドレスは変更される可能性もあるため、 変更を自動的にキャッチしてファイアウォールに反映する ような仕組みを用意することが望ましいでしょう。

Public uptime check の設定手順の詳細は、以下の公式ドキュメントを御覧ください。

参考 : 公開の稼働時間チェックを作成する

Private uptime check (非公開の稼働時間チェック)

Private uptime check (非公開の稼働時間チェック) はインターネットに公開されていない、 VPC 内部のリソースが持つ HTTP エンドポイントを対象とする uptime check です。

社内向けサービスをホストする VM や、インターナルで使われる API のエンドポイントを監視する目的で利用できます。

ターゲットとして Service Directory Endpoint と呼ばれるリソースを作成する必要があります。このリソースにより VM や L4 Internal Load Balancer の IP アドレスを抽象化し、 uptime check はそこを目掛けてヘルスチェックを行います。

詳細な設定手順は以下の公式ドキュメントを御覧ください。