BindPlane を使用したオンプレミス リソースのモニタリング

このドキュメントは、Cloud Logging と Cloud Monitoring を拡張してオンプレミスのインフラストラクチャとアプリを含める方法に関する、2 部構成シリーズの一つです。

  • Cloud Logging: Cloud Logging でオンプレミス リソースからのロギングをサポートする方法について説明します。
  • Cloud Monitoring（このドキュメント）: Cloud Monitoring でオンプレミス リソースのモニタリングをサポートする方法について説明します。

オンプレミス リソースのロギングとモニタリングに Logging と Monitoring を使用する理由として、次のことが考えられます。

  • インフラストラクチャを Google Cloud に移行するにあたり、オンプレミス リソースを廃止するまでモニタリングする一時的なソリューションが必要。
  • 複数のクラウドとオンプレミス リソースが含まれる、多様性のあるコンピューティング環境を使用する可能性がある。

いずれの場合も、Logging API、Monitoring API、BindPlane を使用することによって、オンプレミス リソースに対する可視性を得ることができます。このドキュメントは、Google Cloud のリソースと、残存するオンプレミスのインフラストラクチャおよびアプリのリソースのモニタリング戦略に関心のある、DevOps の技術者、管理者、エグゼクティブを対象としています。

Monitoring を使用して指標を取り込む

Monitoring に指標を取り込むには、次の 2 つの方法があります。

  • observIQ の BindPlane ツールを使用して、オンプレミスまたは他のクラウドソースから指標を取り込む
  • OpenCensus を使用して Cloud Monitoring API に書き込む。

BindPlane を使用して指標を取り込む

次の図は、BindPlane で指標を収集する仕組みと、収集された指標が Monitoring に取り込まれる仕組みに関するアーキテクチャを示しています。

Monitoring と BindPlane を使用してオンプレミス リソースをモニタリングする場合のアーキテクチャ。

observIQ には、BindPlane の複数のバージョン（オープンソース（セルフホスト）、SaaS、Enterprise）が用意されています。これらのバージョンの詳細については、BindPlane の比較ページをご覧ください。

メリット:

  • 必要となるのはアプリのインストゥルメンテーションではなく、実装にかかる時間を短縮する構成です。
  • Monitoring の使用料金に含まれています。
  • モニタリング プロダクトによる構成とサポートの対象です。
  • デフォルト構成では提供されない指標を取り込むように拡張できます。

デメリット:

  • observIQ の BindPlane ツールを使用して指標を Monitoring に中継する必要があるため、システム全体が複雑化する可能性があります。

必要な作業量が減ることから、この方法を選択することをおすすめします。このソリューションに必要な作業は開発ではなく、構成です。

OpenCensus を使用して Monitoring API に書き込む

次の図は、OpenCensus で指標を収集する仕組みと、収集された指標が Monitoring に取り込まれる仕組みに関するアーキテクチャを示しています。

Monitoring API を使用してオンプレミス リソースを直接モニタリングする場合のアーキテクチャ

Monitoring API を直接使用する場合は、指標を API に直接送信するために、インストルメンテーション コードをアプリに追加して、API に指標を直接送信する必要があります。それには、直接 Monitoring API を使用して指標を書き込むか、OpenCensus 用の Monitoring エクスポータを使用してアプリのインストルメンテーションを行います。OpenCensus は、トレースと指標に使用する標準データ構造を定義するオープンソース プロジェクトです。OpenCensus を使用すると、Monitoring を含む複数のバックエンドをサポートできるというメリットがあります。また、OpenCensus を使用する場合は、Monitoring API を使用する際の低レベルの技術的詳細も実装されます。

メリット:

  • OpenCensus エクスポータを使用して必要なインストゥルメンテーションを簡単に実装できるため、柔軟性があります。

デメリット:

  • インフラストラクチャ指標を取得する別個のソリューションが必要です。そのために、カスタム エージェントを作成しなければなりません。
  • アプリのインストゥルメンテーションが必要です。したがって、実装コストが高くなる可能性があります。
  • オープンソース ライブラリが必要です。

この方法では作業量が多くなります。また、インフラストラクチャ指標はカバーされないため、この方法を選択することはおすすめできません。

BindPlane を使用する

このドキュメントでは、observIQ の BindPlane ツールを使用して Monitoring に指標を取り込む方法について説明します。BindPlane サービスは一連のソースを定義し、それらのソースから指標を取り込んで、宛先として Monitoring に指標を送信します。BindPlane ではソースとして、Compute Engine、Amazon Elastic Compute Cloud（Amazon EC2）、Linux、Windows、Kubernetes をサポートしています。

ソース、コレクタ、宛先

BindPlane では以下の機能を使用します。

  • ソース: 指標を生成するアイテム。Google Kubernetes Engine（GKE）、Amazon Elastic Container Service for Kubernetes（Amazon EKS）、Microsoft Azure Container Service などです。
  • コレクタ: 環境をリモートからモニタリングして指標データを BindPlane に転送する軽量のプロセス。
  • 宛先: BindPlane が指標を送信するサービス。この場合、宛先は Monitoring API を使用して指標を Monitoring に書き込む BindPlane 上のプロセスです。

ソース、コレクタ、宛先について詳しくは、BindPlane の概要をご覧ください。

使用例

ExampleOrganization という名前の組織を例として考えます。ExampleOrganization には、Google Cloud と Microsoft Azure にデプロイされたリソースと、vSphere を使用してデプロイされたオンプレミス リソースがあります。Google Cloud には、GKE クラスタと、会社のウェブサイトを実行するシンプルなデモアプリがデプロイされています。Microsoft Azure 環境では、Azure Kubernetes Service（AKS）が外部のデベロッパーに REST API エンドポイントを提供し、一連のマイクロサービスを実行しています。vSphere 環境では、MySQL、Oracle、Microsoft SQL Server が一部の会社のアプリをサポートしています。

それぞれの環境にリソースがあるため、ExampleOrganization はコンポーネントがデプロイされている場所に関係なく各コンポーネントをモニタリングしたいと考えています。BindPlane を使用して各環境から指標を Logging と Monitoring に送信すれば、すべての指標を 1 か所にまとめて、モニタリングとアラートを一元化できます。

BindPlane から Monitoring に指標を送信する

BindPlane が設定されて指標の送信を開始すると、Monitoring Workspace に指標が送信されてくるようになります。これにより、Monitoring であらゆる指標や時系列を扱う場合と同じように、表示、構成、アラートや、時系列によるダッシュボードの作成を行うことができます。詳細については、指標、時系列、リソースをご覧ください。

Monitoring で指標を使用する

前の例で、Google Cloud、Microsoft Azure、オンプレミスのソースから指標を送信するように BindPlane を構成しました。次の 3 つの指標が Monitoring に表示されます。

  • GKE クラスタの指標
  • AKS クラスタの指標
  • vSphere オンプレミス データベースの指標

GKE クラスタの指標

GKE クラスタの指標により、Google Kubernetes Engine ページ上の [モニタリング] に、Monitoring Workspace 内で稼働する Kubernetes コンポーネントの 3 つのビューが表示されます。具体的には、インフラストラクチャ ビュー、ワークロード ビュー、サービスビューの 3 つです。クラスタにデプロイされた 4 つのサービスが指標を報告します。

Monitoring でモニタリングされている 4 つのサービスのビュー。

Pod ごとの指標、ログ、構成を確認できます。

特定のサービスの Pod ごとの詳細ビュー。

AKS クラスタの指標

同じ Monitoring 環境で、AKS の指標も収集されます。これらの指標は Monitoring に表示され、Monitoring でダッシュボード、アラート、Metrics Explorer を含むあらゆる目的に使用できます。

Monitoring Metrics Explorer は、指標の検索、フィルタリングや、指標からグラフを構築する手段となります。BindPlane から送信された指標には、指標名に接頭辞 workload.googleapis.com/THIRD_PARTY_APP_NAME が付加されています。

[Resource type] に [Generic Node] が表示された Metrics Explorer。

Metrics Explorer では、指標のグラフを生成できます。

CPU 使用率の指標グラフ。

Monitoring のすべての指標と同じく、これらの指標を使用して、次のスクリーンショットに示すようなダッシュボードを構築できます。このダッシュボードは、AKS で生成されて BindPlane によって収集された指標を表しています。収集された指標は Monitoring に保存されて、ダッシュボード上に表示されます。

4 つのグラフが表示された AKS ダッシュボード。

vSphere オンプレミス クラスタの指標

この例の最後の部分には、vSphere 環境から収集されたデータベースの指標も示されています。vSphere 環境の指標も Monitoring に表示され、Monitoring の他のあらゆる指標と同じように使用できます。次のように、vSphere 環境から取得された Oracle の指標が Metrics Explorer に表示されることを確認できます。

Monitoring での vSphere の指標

Monitoring のすべての指標と同じく、これらの指標を使用して、次のスクリーンショットに示すようなアラートを構築できます。

トリガーに基づくアラートを構築する構成画面。

このアラートは、vSphere 内で稼働する Oracle で生成され、BindPlane によって収集された指標を表しています。収集された指標は Monitoring に保存され、アラートを構成するために使用されます。

アラート ポリシー ウィンドウ。

まとめ

使用中のプラットフォームについて把握できるよう、Monitoring ではダッシュボード、アラート、インシデント対応を使用できます。Monitoring と BindPlane を組み合わせて使用すると、オンプレミス リソースの可視性が高まります。

次のステップ