【GCP入門編・第16回】アプリのパフォーマンスを視覚的に確認できる Stackdriver Monitoring を紹介！

Stackdriver は、2014年に Google が買収し、2016年に GCP のサービスの一部として統合した統合監視サービスです。 Monitoring 、 Error Reporting 、 Trace 、 Logging 、 Debugger の5つのサービスによって構成され、 GCP と AWS をサポートしています。
元々が GCP 固有のサービスとして作られていた訳ではないため、汎用的な作りになっていますが、 買収を経て統合されたことにより、 Compute Engine や App Engine 、 Kubernetes Engine 、 Cloud SQL 、 Datastore など様々な GCP のサービスを簡単に監視できるように機能が強化されています。
この記事では、 Stackdriver のサービスの中でも、 Logging と並んでメインのサービスとなる Stackdriver Monitoring について解説します。

この記事の目的

• Stackdriver Monitoring とは何かを知ろう。
• Stackdriver Monitoring でできることを学ぼう。

Stackdriver Monitoring でできること

Stackdriver Monitoring では、サービスを稼働させるインスタンスの CPU 使用率やメモリ使用率、またはそのインスタンス上で動作するアプリケーションの各種使用率等といったメトリクスを集めるメトリクス収集機能と、収集したメトリクスを用いたアラートの通知を行うことができます。
下の画面は Stackdriver Monitoring のダッシュボード画面です。

こうしたメトリクスの収集に使われるツールには MUNIN や Cacti といったものがありますが、 Stackdriver Monitoring では agent を対象のインスタンスにインストールしなくても GCP や AWS の基本的なメトリクスをほぼ無設定で収集することができます。
より詳細なメトリクスを収集したい場合には agent をインストールすることも可能で、 agent は collectd ベースのものが提供されています。 agent をインストールすることで後述するアプリケーションのメトリクス収集や、インスタンスのより詳細なメトリクスを収集することが可能になります。
また、 Stackdriver Monitoring では Web アプリケーションが正常に稼働しているかどうかを監視することも可能です。こちらは単純に URL を指定することで利用できるため、簡単に運用中のサービスが停止していないかどうか監視し続けることができます。
こうして収集したメトリクスを基準にして、アラートを送信することが可能です。 Stackdriver Monitoring ではメールによる通知の他に Slack や HipChat といったチャットツールに対して簡単に通知を設定することもできます。
アラートを送信する閾値は複数の条件を指定することもできますので、重要なアラートが埋もれてしまい、大きな障害の兆候を見逃してしまう、といったことも防げるでしょう。
また、 Stackdriver のアカウントは複数の GCP のプロジェクトと紐付けることが可能です。このため、同じチームで複数の異なるサービスを運用していた場合でも、監視は一箇所で行うことができる、というメリットがあります。

収集できる基本的なメトリクス

Stackdriver Monitoring で監視することのできるメトリクスには、大きく分けて Built-in metrics と Custom metrics の2種類があります。 Custom metrics は Stackdriver の提供する API を通じて、メトリクスを自分で設定することができます。Built-in metrics はデフォルトで提供されているメトリクスとなります。
Built-in metrics は Agent metrics 、 AWS metrics 、 GCP metrics に大きく分けられます。 Agent metrics は主にインスタンス上で動作するアプリケーションを対象としたもので、 Stackdriver agent を使用して収集します。 AWS metrics 、 GCP metrics は AWS であれば EC2 、 ELB 、 RDS など AWS が提供するサービスのメトリクスを、 GCP であれば App Engine や Compute Engine 、 BigQuery や Cloud SQL 、 Cloud Storage といった様々なサービスのメトリクスを収集することができます。

上の画像は Cloud Storage のバケットのメトリクス監視画面です。このように、バケットに対するリクエスト数やトラフィックといったメトリクスは Built-in metrics として用意されているので、特に設定をしなくても監視することができます。
非常に多くのメトリクスを利用することができるようになっており、すべての Built-in metrics はこちらで閲覧することが可能です。

アプリケーションのメトリクスを収集する

Stackdriver agent を利用することで、 Compute Engine のインスタンス上で動作するアプリケーションのメトリクスの収集が可能です。デフォルトで Stackdriver agent がメトリクスを収集できるアプリケーションには、 Apache 、 Nginx といったウェブサーバー、 MySQL や PostgreSQL といったリレーショナルデータベース、 Redis や Memcached といった KVS が含まれていますので、 Web アプリケーションの運用を行う際に使われる代表的なアプリケーションの監視はすぐに行うことが可能です。
これらのアプリケーションのメトリクス収集は Stackdriver agent のプラグインをインストールすることで行われます。プラグインの一覧は公式ページのサードパーティ製アプリケーションのモニタリングにあります。

アラートのポリシー

Stackdriver Monitoring では、メトリクスに対して Alerting Policy を設定することで、アラートの通知が可能になります。例えば、ディスクの使用率が90%を超えた場合、 CPU の使用率が90%を超えた場合…といった具合です。このような “…の場合” を Stackdriver Monitoring では “Condition” と呼んでおり、メトリクスが設定した Condition を満たした場合に “Incident” が発生してアラートが送信されます。対象のメトリクスと Condition 、通知先を組み合わせた設定が Alerting Policy となります。

Alerting Policy は上の画像に表示されている、 Stackdriver のコンソールから設定することが可能です。上の画像では “Threshold-user/test-log-critical” 、 “5XX check” という2つのアラートが設定されており、両方のアラートがオンとなっています。

価格設定について

現在、 Stackdriver には2つの価格設定があります。1つは Basic Tier で、こちらは無料で使用が可能です。もう1つは Premium Tier で、こちらは月単位で課金がなされます。詳細な価格等については公式ページをご確認ください。
Basic Tier では GCP metrics のみが使用できますので、 Stackdriver agent を利用したアプリケーションのメトリクス収集や AWS 上で動作するインスタンスのメトリクス収集を行いたい場合は、 Premium Tier を選択する必要があります。また、 Basic Tier ではアラートの送信先がメールと Cloud Console モバイルアプリのみとなっていますので、 Slack や HipChat を利用する場合は Premium Tier を選択しましょう。

おわりに

いかがでしたか。 Stackdriver Monitoring は多様化するアプリケーションの運用環境をうまくカバーし、アプリケーションの監視という非常に重要ではあるけれども厄介な問題をうまく解決するためのサービスです。アプリケーションの監視は MUNIN のようなオープンソースのツールを組み合わせて行うことももちろん可能ですが、監視ツールの設定やエージェントのインストール、さらに収集したメトリクスやログファイルの増加など、監視ツールを運用するための努力も必要になってきます。 Stackdriver Monitoring を使用することで、こうした監視ツールそのものの運用に気を使うことなく、本当に行いたい監視のみを行うことが可能となります。