Zenn
👻

Cloud Monitoringの機能をざっくり理解したい

2024/06/17に公開
Google Cloud
Cloud Monitoring
tech

初めに

こんにちは。hikaruです。
今回は、Cloud Monitoringのハンズオンで検証したこと、現在勉強中のProfessional Cloud DevOps Engineerの資格勉強ではまったところを中心まとめます。

Cloud Monitoringとは

Cloud Monitoringは、

  • アプリケーションの健全性
  • パフォーマンス
  • リソース状況

等の情報をユーザに提供してくれるサービスになります。Google Cloudサービスによって生成されたシステム指標は、Cloud Monitoringによってある程度自動的に収集されます。追加のシステム情報を収集したい場合は、Opsエージェントをインストールするなど追加の対応が必要になります。
Metrics Explorerから各Google Cloudリソースのメトリクス情報を可視化することができます。また、カスタムでダッシュボードを作成し、任意の指標のみを閲覧させることが可能です。
また、その他の機能としては以下があります。

  • アラートと通知
  • 稼働時間チェック
  • 合成モニタリング
  • SLO監視
  • PromQLやMQL等のクエリでの指標の検索
  • 複数プロジェクトの指標のモニタリング

値の型と指標の種類

Cloud Monitoringでの指標タイプについて以下にまとめます。
こちらは、Professional Cloud DevOps Engineerの資格勉強中にわからなかった点になります。

値の型

測定値のデータ型を表し、Cloud Monitoringでは、ValueTypeと表記されます。

型 説明
BOOL 真偽値型
INT64 64ビット整数型
DOUBLE 浮動小数点型
STRING 文字列型
DISTRIBUTION 分布測定型（値のグループを表す）

指標の種類

各時系列には、そのデータポイントの指標の種類が含まれます。Cloud Monitoringでは、MetricKindと表記されます。

種類 説明 用途
GAUGE 特定の時刻を測定するための指標 CPU使用率
DELTA 時間間隔の変化を測定するための指標 リクエスト数
CULUMATIVE 累積指標を測定するための指標 ネットワーク送信・受信バイト数

リソースグループ

Cloud Monitoringでは、各リソースをグループに所属させる形で定義することができます。
グループを作成することで、そのグループごとにアラートポリシーや、グラフ、ダッシュボードを設定することができます。

メンバー条件

グループに所属させるための条件を定義することができます。メンバー条件には以下の条件を利用することができます。

  • ラベル
  • リージョン
  • アプリケーション
  • etc...

メンバー条件に一致するリソースは自動的に、一致するグループに追加されるため、変化する環境のモニタリングに役立ちます。

グループの作成

実際にリソースグループを作成してみます。
CloudMonitoringのコンソール画面からグループを選択します。
CREATE GROUPを選択します。

グループを作成するにあたり必要なメンバー条件を入力します。
東京リージョンに存在するすべてのGCEをグループに所属させたいので、以下のメンバー条件を指定します。

  • Name : vm-instance-asia-northeast1
  • Criteria : Resource Type equals gce_instance
  • Criteria : Region equals asia-northeast1
  • Combine criteria operator : AND

CREATEボタンをクリックすると、グループが作成されます。

作成されたグループに、既に東京リージョンに作成済みのtest-instanceがVM Instancesに記載されていることがわかります。
また、CPU使用率や、受信バイト数などのメトリクスも閲覧できています。

追加で、東京リージョンにVM名：instance-20240615-000613を構築してみます。
グループのメンバー条件である

  • Resource Type equals gce_instance
  • Region equals asia-northeast1
    と一致することから、GCEインスタンスを作成後、しばらくするとグループにinstance-20240615-000613が追加されていることが確認できました。

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

複数プロジェクトの指標を集約して1つのモニタリング専用プロジェクトで閲覧することができます。
Google Cloudの公式ドキュメントでは、モニタリング専用プロジェクトを作成し、モニタリング専用プロジェクトには、その他のリソースは作成しないことが推奨されています。
モニタリング専用プロジェクトで、指標を閲覧するためには、Monitoring閲覧者（roles/monitoring.viewer）ロールが必要です。

リソースコンテナ

Google Cloudのモニタリング対象プロジェクトのことを言います。

指標スコープ

プロジェクトでグラフ化およびモニタリングできる時系列データを持つセットのリソースコンテナ（モニタリング対象プロジェクト）を定義します。デフォルトでは、Google Cloudプロジェクトの指標スコープには自身のプロジェクトのみが含まれます。

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

複数プロジェクトを集約して閲覧することのできるプロジェクトのことをスコーピングプロジェクトと言います。ハブのような役割を果たします。

複数プロジェクトの指標を表示してみる

モニタリング専用プロジェクトを用意し、Cloud Monitoringの画面からMonitoringの設定をクリックします。
コンソール下部のGCPプロジェクトの追加をクリックします。

プロジェクトを選択をクリックして、モニタリング対象プロジェクトを選択していきます。

選択後、ADD PROJECTSをクリックします。

以上で、複数プロジェクトの指標を表示する設定が完了しました。
モニタリング専用プロジェクト（いわゆるスコーピングプロジェクト）は、プロジェクトの役割にScoping Projectと表示され、モニタリング対象プロジェクト（いわゆるリソースコンテナ）は、プロジェクトの役割にMonitored Projectと表示されています。
その後は、Metrics Explorerから閲覧したい指標を指定することで、モニタリング対象プロジェクトの指標を閲覧することができます。

稼働時間チェック

HTTP、HTTPS、TCP のリクエストに応答するアプリケーションに対して定期的にリクエストを送信することができます。稼働時間チェックでは、パブリックエンドポイント:公開稼働時間チェックまたはプライベートエンドポイント:非公開稼働時間チェックに対してリクエストを送信することができ、レスポンスデータを検証することもできます。
稼働時間チェックには、稼働時間チェックのステータスや、レイテンシ等の詳細なデータを確認することができます。
また、何らかの理由で稼働時間チェックが失敗した場合は、アラートポリシーを設定することでslackやE-mailに失敗を通知することも可能です。

公開稼働時間チェック

公開稼働時間チェックは、一般公開されているURLまたは、Google Cloudリソースにリクエストを送信し、正常なレスポンスが返却されるかどうかを確認する機能になります。
以下の公開稼働時間チェックが可能です。

  • 稼働時間チェックURL
  • VMインスタンス
  • App Engineアプリケーション
  • Kubernetesサービス
  • AWS EC2インスタンス
  • AWS ELB
  • Cloud Runリビジョン

公開稼働時間チェックの作成

公開稼働時間チェックを作成するにあたって、監視対象のリソース（ロードバランサの背後にインスタンスグループに所属しているNginx VM）を用意しました。

今回は、こちらのリソースのエンドポイントに向けて公開稼働時間チェックを用意していこうと思います。
VMインスタンスに公開稼働時間チェックを送信する場合は、稼働時間チェックサーバーによって使用されるIPアドレスを許可する必要があるので、IPアドレスの一覧を許可してください。
https://cloud.google.com/monitoring/uptime-checks/using-uptime-checks?hl=ja

Cloud Monitoringのコンソール画面から稼働時間チェックに遷移し、稼働時間チェックを作成をクリックします。

ターゲットの項目から必要情報を入力します
今回は、ドメイン・証明書の用意はしていないのでHTTP、IPアドレスベースでの公開稼働時間チェックとします
本番で利用される場合はHTTPS/ホスト名での公開稼働時間チェックが推奨です。

  • Protocol : HTTP
  • リソースの種類 : URL
  • Hostname : 払い出されたロードバランサのIPアドレス
  • Path : /
  • Check Frequency : 1minute
  • 他のオプション : デフォルト

レスポンスの検証の項目から必要情報を入力します
今回は、デフォルト値をそのまま利用するためスキップします。
ステータスコードや、タイムアウト値をカスタマイズしたい場合は、設定してください。
https://cloud.google.com/monitoring/uptime-checks/response-validation?hl=ja

アラートと通知の項目から必要情報を入力します
今回は、自身のメールアドレス宛にアラートを送信したいので設定していきます。

  • Name : 任意のアラートポリシー名
  • Duration : 1 minute
  • Notifications : 自身のメールアドレス

確認の項目から必要情報を入力します
稼働時間チェックを作成する前に、テストを実施することができます。
今回はステータスコード:200が返却されればOKなので、テストが成功しています。また、レイテンシも表示されています。

  • Title : nginx-uptime-check

作成された稼働時間チェックを確認すると、以下の情報を確認することができます。

  • Percent Uptime
  • Uptime Latency
  • Passed Checks
  • Uptime Check Latency
  • Current Status
  • Configuration
  • Alert Policies

Nginxのプロセスを停止してみて、稼働時間チェックをエラーにしてみました。
稼働時間チェックの詳細を確認すると、Current Statusはすべて赤い表示に代わっており、Passed Checksも1から0に代わっています。

また、Nginxのプロセスを停止してしばらくすると自身のメールアドレスに対して、アラート通知が送られてくることも確認できました。

Nginxのプロセスを復旧させて、しばらくすると自身のメールアドレスに対して、復旧のアラート通知が送られてくることも確認できました。

非公開稼働時間チェック

非公開稼働時間チェックは、Google Cloudリソースの内部 IP アドレスに対してリクエストを送信することができます。非公開稼働時間チェックでは、仮想マシン（VM）や L4 内部ロードバランサ（ILB）などのリソースにプライベートネットワーク経由でリクエストを送信するできます。
非公開稼働時間チェックを使用するには、Service Directory を利用してプライベートネットワークアクセスを構成する必要があります。

非公開稼働時間チェックの作成

非公開稼働時間チェックを作成するにあたっては、監視対象のリソースとして公開稼働時間チェックで作成したNginx VMをそのまま利用します。

Nginx VMのプライベートIPアドレスエンドポイントに向けて非公開稼働時間チェックを用意していこうと思います。

非公開稼働時間チェックを作成するためには事前に以下のAPIを有効化する必要があります。

  • Cloud Monitoring API: monitoring.googleapis.com
  • Service Directory API: servicedirectory.googleapis.com
  • Service Networking API: servicenetworking.googleapis.com
  • Compute Engine API: compute.googleapis.com

ターゲットの項目から必要情報を入力します

  • Protocol : HTTP
  • リソースの種類 : Internal IP

プライベート稼働時間チェックの注釈のVIEWをクリックすると、右側にプライベート稼働時間チェックの前提条件のリストが表示されますので、指示に従って設定していきます。

  • サービスアカウントの作成
    • Cloud Monitoringが所有するサービスアカウントを使用して、Service Directory サービスとのやり取りする必要があります。
  • サービスの登録
    • Service Directoryを利用して、VMインスタンスの内部IPアドレス、ポートに対応するエンドポイント、名前空間を用意する必要があります。
  • ファイアウォールルールの作成
    • 35.199.192.0/19 からの受信 TCP トラフィックを有効にするファイアウォール ルールを作成する必要があります。

必要情報を入力し、レスポンスの検証、アラートと通知、確認はデフォルト値を入力し作成します。

公開稼働時間チェックと同様に、以下の情報を確認することができます。

  • Percent Uptime
  • Uptime Latency
  • Passed Checks
  • Uptime Check Latency
  • Current Status
  • Configuration
  • Alert Policies

最後に

今回は、Cloud Monitoringのハンズオンで検証したことや、Professional Cloud DevOps Engineerの資格勉強ではまったところを中心まとめました。Cloud MonitoringはPromQLや、MQLが上級者向けで合ったり、ユーザにわかりやすいようなダッシュボードを作成する必要があったりと奥が深いサービスになっているので運用で利用した知見を今後もまとめていきたいと思います。
最後までご覧いただきありがとうございました。

GitHubで編集を提案

Discussion