Cloud Monitoringで始めるサービス監視

メタサイトエンジニアのYKです。

先日、業務の一環でGCP上に開発用のサーバを立ち上げる機会があり、ドメインの設定やデプロイ作業をしていたのですが、監視はどうするか？という課題がありました。

監視の重要性は理解していますが開発用のサーバということもあり、設定の手間や費用の面で監視をどうするか検討していたところ、Google Cloud Monitoring（以下、Cloud Monitoring）はサーバ側で追加の設定不要、基本無料で利用できるということでCloud Monitoringを導入しました。

Cloud Monitoringは設定項目も少なく簡単に導入できる一方で、公式ドキュメントを見ないとわかりにくい箇所もいくつかありましたので、今回は具体的な設定手順も含めてCloud Monitoringについて紹介したいと思います。

Cloud Monitoringとは

Cloud Monitoringとは、Google社が提供するオペレーションスイート（旧称 Stackdriver）という監視サービス群の一つで、Google CloudサービスやAWS、オープンソースアプリケーション、サードパーティアプリケーションから様々な指標、イベント、メタデータを収集できます。

収集したデータはダッシュボード上でグラフとして可視化される他、収集した指標が事前に設定した条件を満たした場合に通知する設定もできます。

Cloud Monitoringの料金

以下の内容は本記事執筆時点の内容です。最新の料金については、料金ページをご確認ください。

Cloud Monitoringの導入にあたり料金はどの程度かかるのかは気になると思いますので、簡単に利用料金について触れておきます。

Cloud Monitoringは取り込んだ指標データ量に応じて料金が発生する従量課金制のサービスになっています。

ただし、Google Cloud、Anthos、Knative から取得した指標データは課金対象外（無料）に設定されている他、請求先アカウントごとに最初の 150 MiBが毎月の無料割り当て量として設定されています。

そのため、デフォルトで使用できる指標については無料で使用できますが、Ops Agentを使用して追加の指標データを収集する場合に料金が発生します。

なお、追加の指標データ収集時に発生する料金は一部の指標を除いて以下の料金設定になっています。

取り込みデータ量	料金
0 ～ 100,000 MiB	$0.2580/MiB
100,001 ～ 250,000 MiB	$0.1510/MiB
250,001 MiB ～	$0.0610/MiB

取り込みデータ量が251,000 MiBの場合の料金計算

$0.2580 × 100,000 MiB ＋ $0.1510 × 150,000 MiB ＋$0.0610 × 1,000 MiB ＝ $48,511

取り込みデータ量に応じた料金の推移 CloudMonitoring料金推移

なぜCloud Monitoringを選択したか？

サービス監視には様々なサービス・ツールがありますが、Cloud Monitoringを選定したポイントは以下の3点でした。

手軽に始められる（導入が簡単）
デフォルトで使用できる指標であれば無料で利用できる
Cloud FunctionsやCloud Runといったサーバレスアーキテクチャの指標も収集できる

デフォルトで使用できる指標は無料なので、GCPを利用しているのであればとりあえずCloud Monitoringを使ってみてから他のサービス・ツールを検討する、というのも良いかもしれません。

Cloud Monitoringの導入方法

Google Compute Engine 仮想マシン（VM）インスタンスのCPU使用率が90%を超えた場合に監視用メーリングリストにアラートメールを通知する、というケースを想定してCloud Monitoringの導入方法を紹介します。

通知先メールアドレスを登録する
1. メニュー > オペレーション > Monitoring > アラート
2. EDIT NOTIFICATION CHANNELS
3. Email > ADD NEW
  
  通知チャネルには以下の8種類が使用できます。今回はメールに通知するためEmailを使用します。
  - Mobile Devices
  - PagerDuty Services
  - PagerDuty Sync（ベータ版）
  - Slack
  - Webhooks
  - Email
  - SMS
  - Pub/Sub
4. メールアドレス / 表示名を入力して SAVE

アラートを登録する

メニュー > オペレーション > Monitoring > アラート
ポリシーを作成する

Create policy
監視指標を設定する

指標を選択 > VM Instance > Instance > CPU utilization を選択して適用 CPU使用率の指標であるCPU utilizationを選択します。CPU usageはCPU使用量の指標で間違いやすいため注意が必要です。

なお、その他の指標は指標の一覧をご確認ください。
【任意】対象のVMインスタンスを限定する

ADD FILTERを選択してアラートを適用するVMインスタンスを絞り込む画面右側のグラフに表示されているVMインスタンスがアラートの対象になります。

GCPプロジェクト内に複数のVMインスタンスがあり、アラート対象を限定したい場合は任意の条件でフィルタを追加してください。

監視条件を設定する

ローリングウィンドウ（監視間隔）

ローリングウィンドウ関数（監視間隔中の指標データに適用される関数）

ローリングウィンドウ関数	変換後データ
interpolate	前後の監視間隔の補間値 0→0→100の場合は0→50→100に補間される。
next older	監視間隔中の最新値
min	監視間隔中の最小値
max	監視間隔中の最大値
mean	監視間隔中の平均値
count	監視間隔中の指標データの数
sum	監視間隔中の合計値
std. dev.	監視間隔中の標準偏差
percent change	前回収集値からの変化率 ((現在値 - 前回値) / 前回値) * 100で算出される値。

瞬間的なCPU使用率上昇はアラート対象外にするために、今回は5分間の平均値にしてみます。 CloudMonitoring導入手順 2 5 設定内容に問題がなければNEXTをクリックして次の設定に進みます。

アラート条件を設定する
- Condition type（監視条件の種類）
  - Threshold（しきい値条件）
    
    監視間隔中に指標データが基準値の範囲外になった場合をアラートトリガーとする場合に使用します。こちらを使用する場合はアラートトリガー、しきい値の位置、しきい値を設定します。オプション設定として、アラートの再テストについての設定もできます。
  - Metric absence（不在条件）
    
    監視間隔中に指標データが無い場合をアラートトリガーとする場合に使用します。こちらを使用する場合はアラートトリガー、指標データの不在時間を設定します。
- 条件名
  
  アラート条件に任意の名前を設定できます。
CPU使用率90%以上の場合にアラート通知をするために、以下の設定とします。
アラート通知を設定する
- Configure notifications（通知設定）
  - 通知チャンネルを使用
    
    登録された通知チャンネルにアラートを通知する場合はONにして通知チャンネルを選択します。
  - Notify on incident closure（インシデントクローズ時の通知）
    
    Cloud Monitoringでは、指標データが基準値の範囲外になった場合に自動でインシデントをオープンし、基準値の範囲内に戻ったらクローズする機能があります。
    
    インシデントは発生時の指標データが可視化され閲覧できるため、いつ、何が起きたのかを後から確認するのに便利です。
    
    ここでは、インシデントがクローズした際に通知するかどうかを設定できます。
  - インシデントの自動クローズ期間
    
    アラート条件を満たした場合に、Cloud Monitoringが自動でインシデントをクローズする期間を設定します。
- 【任意】Policy user labels（アラートのラベル付け）
  
  アラートに任意のラベルを付けることができます。例としてアラートポリシーに重大度レベルを追加する方法が紹介されていますので、ラベルを設定する場合はこちらをご確認ください。
- 【任意】Documentation（ドキュメントテンプレートの設定）
  
  アラート内容をカスタムしたい場合に設定します。テキストの他、マークダウン、変数、チャンネルコントロール¹を使用できます。
- Name the alert policy（ポリシーの名前）
設定内容に問題がなければNEXTをクリックして次の設定に進みます。
ポリシーの設定内容を確認する

設定したポリシーの内容を確認して問題が無ければポリシーを作成をクリックしてアラート通知の作成は完了です。

【任意】アラートを確認する

最後に、作成したアラートが動作するか確認してみましょう。

本番環境の場合はApache Bench等で負荷を掛けることはできないと思いますので、一時的にアラート条件をCPU使用率が1%を超えた場合に変更して確認してみます。

メール通知

インシデントの詳細

無事にメール通知されました。メール内のリンクからインシデントの詳細も確認できます。