Google Cloud Platform Japan 公式ブログ: Google Cloud Monitoring: Stackdriver で Google Cloud Platform をモニタリング

Google Cloud Monitoring: Stackdriver で Google Cloud Platform をモニタリング

2015年1月28日水曜日

リクエストのトレースや、パフォーマンスの改善とは別に、他の作業やディスプレイから離れた業務時間外のときに発生する、アプリケーションの停止や性能の低下は、たとえオンプレミスからクラウドへ移行しても引き続き生じる問題です。この問題への対応に、Google Cloud Platform (GCP) を利用している皆さんなら、例えば、昨年 Google App Engine との統合を発表した Datadog や、GCP のテクノロジーパートナーである New Relic といったサービスを使いモニタリングする方法もあるでしょう。同じように AWS を利用している場合、多くのサービスと並んで、8 ヶ月前に、GCP に加わった Stackdriver も候補となるモニタリングサービスの 1 つではないでしょうか。様々な選択肢があるなかで、モニタリングサービスは何を使うべきなのか？回答はシステムに依りますが、まず DevOps の実現という観点から見ていきます。 DevOps による継続的改善によるビジネスゴールの達成、ビジネスの変更に対応するために小さな変更を頻繁に繰り返すオペレーションの中で、システムのガバナンス、オートメーション、CI、オートスケールなど、ツール、手法、プロセスも頻繁に改善し続ける必要があります。このような中でモニタリングサービスに求められるのは、単なるモニタリング機能以外にも、継続的デリバリーの中で事前に全ての変更をテストできるわけではないときに、とにかく速く広範囲に問題を検出できる QA（クオリティアシュアランス）の役割です。それには、より詳細なインサイト、リリースにあわせた迅速なセットアップ、リソースの予測、オートスケールへの対応、対象のクラウドサービスの機能にあわせたモニタリングや、検知に対してアクションを起こすオートメーション、このようなインテリジェンスを持つモニタリングサービスが要求されます。 Stackdriver が、AWS を利用する大規模なサービスで数多く利用されている要因の 1 つには、このインテリジェンスの実現によって、利用者のビジネスゴール達成への関与が挙げられます。

Google は、GCP でも AWS 、あるいは以前紹介した Wix のようにハイブリッドでも利用できる、統一モニタリングソリューションを提供することをゴールとして、まだ Google Cloud Monitoring に含まれていない Stackdriver のテクノロジの統合を進めています。この理由からも Stackdriver の AWS モニタリングの各製品は引き続き利用可能です。

Google Cloud Monitoring は、この Stackdriver を使い GCP のモニタリングを可能にするものです。機能は以下のようにシンプルでありながらも、強力なインサイトを得られます：

簡単なセットアップ：利用を開始すると直ぐに、チャートやアラート機能が使えます。そしてカスタマイズも可能なダッシュボード。

アラートの受信：メール、SMS、PagerDuty、HipChat、他にも多くの手段でアラートを受信できます。アラートは個々のメトリクスや閾値、あるいは、グループの中で集計した値に対して設定できます。

オープンソースソフトウェアの統合：少しの設定で、多くのオープンソースのサーバソフトウェアからのメトリクスを集計できます。例えば Cassandra クラスターや Nginx サーバ、それぞれに固有のトレンドを見つけることができます。

そして Google Cloud Trace に続きベータとなり、GCP を利用する全ての方が、Google App Engine、Google Compute Engine、Pub/Sub、Google Cloud SQL、各サービスのインサイトを得られるようになりました。
利用するには、Google Developers Console からプロジェクトを選択し、左側のナビゲーションから、Monitoring > Dashboards & alerts（監視 > ダッシュボードとアラート）を選択してください。最初に使うときは、Enable Monitoring（監視を有効にする）というラベルのボタンが表示されているので、ボタンを押して有効にします。有効にすると Stackdriver で動く Google Cloud Monitoring のコンソールに移動します（現時点では、app.google.stackdriver.com ドメインで動作します）。ここでは、Google Cloud Monitoring の概要がわかるように、そのコンセプトと主要な機能をスクリーンショットを交え掲載します。 Google Cloud Monitoring コンセプトリソースとグループリソース（Resource）は、GCP のサービスで使われている仮想オブジェクト、例えば GCE であるなら VM インスタンス、Cloud SQL ならデータベースインスタンス、Cloud Pub/Sub ならトピックを指します。グループ（Group）は、リソースの集合。「プロジェクトで Cassandra を実行している全ての VM インスタンス」という言うとき、これがグループとなります。Google Cloud Monitoring は、自動的に関連するリソースを集めてグループ化します。ただし、現在のところ App Engine だけのプロジェクトでは、グループは利用できません。メトリクスサービスメトリクス（Service Metric)、またはプラットフォームメトリクス（Platform Metric）は、特定のサービスやプラットフォーム（GAE など）を使うと計測できるメトリクスです。
カスタムメトリクス（Custom Metrics）は、何らかのシステムの状況を計測して独自に定義できるメトリクスです。例えば、カートのチェックアウトだったり、ユーザーのログイン、あるいはビジネスの KPI。利用するには、そのためのデータを Custom Metrics API を利用して Google Cloud Monitoring に送信する必要があります。
チャートとダッシュボードチャート（Chart）は、1 つ以上のメトリクスをビジュアルで表したものです。1 つ以上のメトリクス、あるいは複数のメトリクスを合計して、時系列のチャートを作成できます。例えば、「VM レイテンシー」という名前で、VM インスタンスのグループの平均 CPU 利用率を表示したチャートを作成するなどが可能です。ダッシュボード（Dashboard）は、複数のチャートからなり、加えてイベントログやインシデントのリストといった別の情報も含まれます。ダッシュボードは、1 ページのビューとして構成されています。システム全体の状況や、システムに悪影響を及ぼす特定要因の状況を表示するダッシュボードを作成することも可能です。ダッシュボードへのチャートの追加や削除はいつでも可能です。
エンドポイントヘルスチェックとイベントエンドポイント（Endpoint）とは、エンドユーザー、オペレーション担当、開発者がクラウドで構成されたシステムを使うときのエントリーポイントです。そのため、エンドポイントには、Web サーバーからストレージサービス、VM インスタンスも該当します。エンドポイントという名前は、Google Cloud Endpoints と混同しやすいですが、Google Cloud Monitoring のエンドポイントとは異なります。エンドポイントヘルスチェック（Endpoint Health Checks）は、Google Cloud Monitoring のサービスです。世界中の様々な場所からエンドポイントにリクエストを送ることで、システムの状態を調べるように設定でき、その結果はアラートポリシーの条件として使うことができます。そのため、結果が悪ければ通知する設定もできます。イベントログ（Event Log）は、アプリケーションや、利用している GCP プラットフォームやサービスに関連するシステムイベントの時系列リストです。イベントには、クラウドインフラストラクチャーのダウンタイム、アラートポリシーに関連した通知、コードのデプロイメントといったものが該当します。また、自分でログにイベントを追加することも可能です。イベントログも、Google Cloud Logging と混同しやすいですが、異なるものです。
アラートと通知とインシデントアラート（Alert）は、アラートポリシーの条件に合致する状況になったとき発生し、Cloud Monitoring Console の Incidents ページに表示されるインシデント（Incident）となります。インシデントは、条件を満たさなくなったら自動で消えますが、手動で取下げることもできます。アラートポリシーには、通知（Notification）を組み合わせことができます。アラートが発生したときに、メールや SMS で、担当者や何らかのサービスに対し通知することができます。

主な機能
Google Cloud Monitoring Console にアクセスすると、最初にシステムの全体状況と、キーメトリクスからなるページが表示されます。

Google Cloud Monitoring Console
アラートポリシーを設定し、設定した条件に合致するときチームに通知するためのアラートを設定できます。アラートは、メール、SMS、PagerDuty、Campfire、HipChat、AWS の Simple Notification Service そして gcp ja night や事例取材の中でも良く出てくる Slack にも通知可能です。また Webhook を利用して、何らかのサービスへ通知を定義することにも対応しています。

レスポンスレイテンシーをメトリクスとしたアラートポリシーの設定
エンドポイントヘルスチェックを設定しておくと、エンドユーザーが、ウェブサーバー、API、その他インターネットから接続可能なリソースが利用できない状況であると、通知を受けられます。

エンドポイントヘルスチェックの状況世界中のロケーションからチェックされています。 Google Cloud Monitoring の特徴として、MySQL や Nginx、Apache、MongoDB、RabbitMQ、その他にも数多くのオープンソースのサーバソフトウェアをネイティブに統合していることが挙げられます。一例として Cassandra プラグインを利用すると、分散 KVS のパフォーマンスを詳細に可視化して調べられます。

Cassandra のパフォーマンスダッシュボード Google Cloud Monitoring はカスタマイズすることもできます。API を使いカスタムメトリクスを送信することで、ダッシュボードにシステムやインフラストラクチャーのメトリクスと一緒に表示させられます。

ダッシュボードにカスタムメトリクスを表示今後の Google Cloud MonitoringGoogle Cloud Monitoring のページ Google Cloud Platform 日本チームでは、皆さんのフィードバックを聞きくのを楽しみにしています。利用した感想やおすすめの使い方、あるいは問題点や不足している機能も含めて、Blog や Qiita などに書いたときは、是非 Google+ や Twitter で教えてください。 #gcpja