様々な選択肢があるなかで、モニタリングサービスは何を使うべきなのか？ 回答はシステムに依りますが、まず 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 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 だけのプロジェクトでは、グループは利用できません。
メトリクス
メトリクス（Metric）は、システムを評価するための、計測可能な値です。GCP におけるメトリクスには、CPU 利用率、リクエスト処理のレイテンシー、ストレージの利用量などがあります。メトリクスが継続して計測されると、時系列のデータとなります。
サービス メトリクス（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 Policy）は、リソースやグループが平常稼働しているかを定義するルールです。ルールはロジカルな条件であり、メトリクスの閾値やエンドポイント ヘルスチェックを使い定義します。ルールは例えば、2 分間隔でウェブ サイトの平均レスポンス レイテンシーを調べ 5 秒を超えてはならない、といった内容になります。
アラート（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 Monitoring
現在 Google では、問題の根本原因を容易に調査できるように、Google Cloud Monitoring と Google Cloud Logging のさらなる統合を進めています。Google Cloud Monitoring のより詳細な情報が必要なときは、
Google Cloud Monitoring のページ （英）をご覧ください。
Google Cloud Platform 日本チームでは、皆さんのフィードバックを聞きくのを楽しみにしています。利用した感想やおすすめの使い方、あるいは問題点や不足している機能も含めて、Blog や
Qiita などに書いたときは、是非
Google+ や
Twitter で教えてください。 #gcpja
様々な選択肢があるなかで、モニタリングサービスは何を使うべきなのか？ 回答はシステムに依りますが、まず 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 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 だけのプロジェクトでは、グループは利用できません。
メトリクス
メトリクス（Metric）は、システムを評価するための、計測可能な値です。GCP におけるメトリクスには、CPU 利用率、リクエスト処理のレイテンシー、ストレージの利用量などがあります。メトリクスが継続して計測されると、時系列のデータとなります。
サービス メトリクス（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 Policy）は、リソースやグループが平常稼働しているかを定義するルールです。ルールはロジカルな条件であり、メトリクスの閾値やエンドポイント ヘルスチェックを使い定義します。ルールは例えば、2 分間隔でウェブ サイトの平均レスポンス レイテンシーを調べ 5 秒を超えてはならない、といった内容になります。
アラート（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 Monitoring
現在 Google では、問題の根本原因を容易に調査できるように、Google Cloud Monitoring と Google Cloud Logging のさらなる統合を進めています。Google Cloud Monitoring のより詳細な情報が必要なときは、Google Cloud Monitoring のページ （英）をご覧ください。
Google Cloud Platform 日本チームでは、皆さんのフィードバックを聞きくのを楽しみにしています。利用した感想やおすすめの使い方、あるいは問題点や不足している機能も含めて、Blog や
Qiita などに書いたときは、是非
Google+ や
Twitter で教えてください。 #gcpja
皆さん、こんにちは。そして、新しい連載へようこそ。この連載では、現代コンピューティングの最も重要なイノベーションの 1 つであるコンテナリゼーション（Containerization）についてお伝えしていきます。
