G-genの杉村です。
Cloud Monitoring を使えば、 Google Cloud (GCP) の各種リソースのリソースモニタリングや監視が無料 (タダ) で監視できてしまいます。
Cloud Monitoring でできることを、順を追って見ていきましょう。
Cloud Monitoring とは
Cloud Monitoring は Google Cloud (GCP) の オペレーションスイート と呼ばれるサービス群の一つで、各種 Google Cloud サービスからパフォーマンスデータ等を収集して保存・閲覧可能にするサービスです。データ収集元としては Google Cloud の各種サービスのほか、オンプレミスや Amazon Web Services (AWS) 上の仮想サーバなども対象にすることができます。
Cloud Monitoring がデフォルトで収集するデータ (後述の Google Cloud の指標など) に対しては課金されないため、基本機能は無料で使用することができます。
次項からは Cloud Monitoring が持っている機能を解説します。
リソースモニタリング
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 の指標" で何が収集されるのかは、以下のページを参照してください。
Ops エージェントが収集する指標
Google Compute Engine (GCE) の VM に Ops エージェント をインストールすると、 "Google Cloud の指標" の他に追加の指標を収集できます。
実は "Google Cloud の指標" だけですと メモリ使用率 , ディスク使用率 , スワップ利用率 など重要な指標は取れていません。
これは、 Google Cloud の指標は VM のハイパーバイザから取得できる情報 をもとに構成されているからだと考えられます。
Ops エージェントは VM の中の OS 上で稼働し、情報を収集して Cloud Monitoring の API エンドポイントに対してその情報を投げ込みます。
これにより メモリ使用率 , ディスク使用率 , スワップ利用率 など の指標が取得できます。
"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 を起動して様々なアクションを実行することも可能でしょう。
アラートポリシーの設定方法は以下を参照ください。
稼働時間チェック
稼働時間チェック 機能により一般に「URL監視」あるいは「外形監視」などと呼ばれる監視が簡易的に設定できます。
HTTP, HTTPS, TCP (任意ポート) のいずれかのトラフィックを Google から対象リソースに送信し、そのレスポンスを見て、想定状態とことなっていればアラートを発信することができます。
ターゲットは以下の方法のいずれかで指定可能です。
- URL
- Kubernetes LoadBalancer Service
- VM インスタンス
- App Engine サービス
- Amazon Web Services（AWS）のロードバランサ
また通知方法はアラートの項で説明した "通知チャネル" から選択できます。
大事なのは、稼働時間チェックの ヘルスチェックは Public IP から送信されてくる ことです。そのため VPC のファイアウォール等で インターネットからのトラフィックが許可 されている必要があります。
また対象が VM やロードバランサーの場合、 External IP が必要 です。
なお、先ほど インターネットからのトラフィックが許可 と書きましたが実は必ずしも 0.0.0.0/0 である必要はありません。
以下の方法に従い、稼働時間チェックの接続元 IP を取得できます。
しかしながらこの IP アドレスリストは、頻度は少ないながらも変更される可能性があります。
この IP リストを利用する場合は、自動的・定期的に IP アドレスを取得して自動的にファイアウォール等の設定を変更するプログラムを組む必要があるでしょう。
ダッシュボード
指標を見るにはコンソール画面の Metrics Explorer の他、 ダッシュボード という機能を使うこともできます。
ダッシュボードでは Metrics Explorer よりも詳細に表示をカスタマイズでき、グラフの表現も様々です。
またダッシュボード定義は JSON 形式でエクスポートできます。
ダッシュボードは運用・監視の要件に合わせて自在に作成が可能ですし、最初からプリセットで構成されているサービスごとのダッシュボードも用意されています。
Monitoring Query Language (MQL)
コンソールによるグラフィカルな表示のみならず Monitoring Query Language (MQL) というクエリ言語でプログラマブルに指標を取得することもできます。
また関数等を使い計算が可能です。
ドキュメントでは以下のようなユースケースが紹介されています。
- 特定のクラスのレスポンス コードにつながるリクエストの割合を計算
- 現在の値と過去の値の比率を計算
- 事前定義された値ではなく、任意でパーセンタイル値を選択
- 時系列のサンプルをランダムに選択
- 複数の指標タイプの時系列の値に対して任意の算術式を評価
- 正規表現のサブフィールド キャプチャを含む任意の文字列操作を使用して、データを集計する新しいラベルを作成
- 出力データの時間範囲と期間を制御
さらに、前述のアラート発動の条件を MQL で記述することもできます。
MQL は上級者向けですが、ロジックで導出した値に基づいてアラートを発報したり情報を取得したりしたい場合は選択肢として検討しましょう。
杉村 勇馬 (記事一覧)
クラウドソリューション部 部長
クラウド管理運用やネットワークに知見あり。AWSの全12資格をコンプリートしたので、次はGoogle Cloudの認定資格を狙っている。現在、Google Cloud認定資格は3冠。
2021年12月現在、ハマっているものはマーベル (遅い)