Google Cloud Monitoring の基本: 指標の種類について

※この投稿は米国時間 2021 年 10 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションをクラウドに移行する場合でも、Kubernetes を使用してモダナイズする場合でも、クラウドベースのワークロードの観察は従来型のデプロイメントの観察より困難です。オンプレミスのモノリスをモニタリングするとき、運用チームはスタック全体を完全に可視化し、どのテレメトリー データ（インフラストラクチャからプラットフォームやアプリケーションのデータまで）をどのように収集するかを完全にコントロールできました。クラウドベースのアプリケーションでは、テレメトリーを集約、統合、分析して完全な可視化を実現するのは、次の理由からより難しくなります。   

1. データの発生するソースが多くなります。アプリケーションやワークロードのコンポーネントから得られるテレメトリー データに加えて、クラウド インフラストラクチャ（VM、ロードバランサなど）、クラウド プラットフォーム（Kubernetes、Docker など）、およびクラウド サービス（ストレージ、データベースなど）からのテレメトリー データを統合する必要があります。

2. システムによって可視性のレベルは異なります。テレメトリー データの収集元である各種のソースは、それぞれデータ収集のためのメカニズムが異なっています。一部のソースは API でデータを公開するのに対し、別のソースではユーザーがエージェントをインストールする必要があります。一部のサービスはデータをエンドポイントに push しますが、他のサービスではユーザーがエンドポイントからデータを pull する必要があります。  

3. データの収集、保持、集約の粒度も異なる可能性があります。一部のソースでは細かい粒度（秒単位）でデータを収集できるのに対して、他のソースではより粗い粒度（分単位）でしかデータが公開されないことも考えられます。短い期間（数日）だけ保持されるテレメトリー データもあれば、はるかに長い期間（数年）保持されるテレメトリー データもあります。

これらの技術的な相違に加えて、オブザーバビリティ ソリューションを実行するコストも問題になる可能性があります。収集可能な指標データの一部だけをコントロールできると仮定して、「どのテレメトリー データは有料で購入する必要があり、どのテレメトリー データは使用しているサービスの一部として無料で入手可能か？」と自問するかもしれません。

オブザーバビリティという言葉は、指標、イベント、トレース、ログなど各種のシグナルを網羅していますが、このブログでは Google Cloud での指標の収集について解説します。このブログでは、Google Cloud での指標の収集について、3 つの観点で説明します。

1. 収集される指標の種類のバリエーション

2. 各種の指標が収集される方法

3. どの指標が有料で、どの指標が無料か

ここでは、Google Compute Engine（GCE）、Google Kubernetes Engine（GKE）、Google BigQuery（BQ）の 3 つのサービスについて、これらの側面を探求します。これら 3 つの例は、ユーザーが Google Cloud サービスに対してどの程度の可視性を持てるかという点について、それぞれコントロールのレベルが異なります。  

1. GCE: 指標を収集するエージェントのデプロイについて、ほぼ完全なコントロール

2. GKE: 指標を収集するエージェントのデプロイについて、多少のコントロール

3. BQ: 指標を収集するエージェントのデプロイをコントロール不能

指標のタイプ

これら 3 つのクラスのサービスにわたり、多くの種類の指標が収集されますが、システム指標、エージェント指標、ユーザー定義指標、ログベースの指標の 4 つに大きくグループ化できます。

1. システム指標

システム指標は Google Cloud によって計測および収集され、プラットフォームのマネージド サービスがどのように動作しているかを可視化できます。これらの指標を収集するためにエージェントをデプロイする必要はなく、これらの指標は Google Cloud Monitoring へ自動的に送信されます。

これらの指標は使用されるコンテキストによって呼び方が変わる可能性がありますが、一般的にはすべてシステム指標のグループになります。システム指標は Google Cloud 指標、GCP 指標、「組み込み」指標、システム定義指標、プラットフォーム指標、インフラストラクチャ指標とも一般的に呼ばれます。サービスの種類によって用語が異なる場合もあります。

• Infrastructure as a service（IaaS）ユーザーは、これらをインフラストラクチャ指標と呼ぶことがあります。

• Platform as a service（PaaS）/ Containers as a service（CaaS）ユーザーは、これらをプラットフォーム指標と呼ぶことがあります。

• Software as a service（SaaS）ユーザーは、これらをサービス指標と呼ぶことがあります。

使用のコンテキストにかかわらず、これらはすべて「組み込み指標」です。特定の Google Cloud サービスの使用コンテキストでは、次のような呼び方をすることもあります。

• Kubernetes 指標: GKE から収集されます。GKE の以前のバージョンでは、コンテナ指標と呼ばれていました。このタイプの指標は、名前の先頭に kubernetes.io が付いています。これらは Kubernetes クラスタ内のコンテナ、Pod、ノードのリソース指標です。

• Anthos 指標: オンプレミスの Anthos と、ベアメタルの Anthos から収集されます。このタイプの指標は、名前の先頭に kubernetes.io/anthos が付いています。

• Istio 指標: Google Kubernetes Engine の Istio から収集されます。このタイプの指標は、名前の先頭に istio.io が付いています。

• Knative 指標: Google Kubernetes Engine の Knative から収集されます。このタイプの指標は、名前の先頭に knative.dev が付いています。

2. エージェント指標

エージェント指標には、広範なタイプの指標が含まれます。名前が示すように、エージェント指標では指標を収集するためにエージェント（Cloud Monitoring エージェントか、統一 Ops エージェント）をインストールする必要があります。エージェントベースの指標では、アプリケーション開発者が指標を設定する必要はなく、エージェントで構成が必要なパッケージ済みのレシーバー / コレクタとして使用できます。ユーザーのインストールしたエージェントは、次のタイプの指標を収集します。

• リソース指標: リソースについての指標で、仮想マシン（VM）のコンピューティング、ネットワーク、ストレージを含みます。これらのリソースには、Google Cloud が管理するもの（GCE VM など）、お客様が管理するもの（オンプレミスのホストなど）、別のクラウドのリソースであるもの（AWS VM）があります。

• プロセス指標: リソース指標は高レベル、たとえば VM レベルの可視性を提供します。プロセス指標はより粒度が細かく、VM 内で実行されている特定のプロセス（たとえば、データのバックアップ プロセス）に関する、CPU、メモリ、I/O、スレッド数などの測定値が含まれます。

• サードパーティ指標: VM（GCE や他の場所）またはコンテナ（Nginx、Kafka、MySQL など）で実行されるサードパーティ ソフトウェアやオープンソースのソフトウェアについての指標。これらの指標により、それらのソフトウェア コンポーネントの内部動作について、特定目的に合わせた可視性を得ることができます。

注: Ops エージェントは自分自身についての指標も収集できます。この場合、名前の先頭に agent.googleapis.com/agent が付きます。エージェントにより収集された、他のソフトウェア コンポーネントについての指標は、名前の先頭に agent.googleapis.com/<コンポーネント名> が付きます。

3. ユーザー定義指標

ユーザー定義指標は、デプロイ済みのアプリケーションやワークロードへの可視性を提供するもので、ユーザーが定義して設定します。ユーザー定義指標には次のものが含まれます。

• カスタム指標: カスタム指標はクライアント ライブラリか Cloud Monitoring API を使用して取り込む、または Ops エージェントをデプロイして指標を収集してから、Cloud Monitoring に取り込むことができます。これらの指標の名前は、先頭に custom.googleapis.com が付きます。

• ワークロード指標: ワークロード指標には、リソースで実行されるアプリケーションで生成される広範なデータが含まれます。これらのアプリケーションがモノリス、コンテナ、データ処理 ETL ジョブのどれでも、コードを組み込んで、対象のタスクに特に関連する指標を生成する必要があります。これらの指標は、そのワークロードが使用しているリソースについての情報（例: アプリケーション オブジェクトによるメモリ消費や、SPARC ジョブにより処理されるデータレコードの数）や、場合によってはいくつかのビジネス指標（発注を行ったユーザーの数や、処理された合計金額）を捕捉します。ワークロード指標は、名前の先頭に workload.googleapis.com が付きます。ここでも、コンテキストによってはワークロード指標のことを「アプリケーション指標」や「ジョブ指標」と呼ぶことがあります。

• 外部指標: オープンソースまたはサードパーティのアプリケーションから収集されます。Google Cloud プロジェクトに送信される指標で、指標タイプが external.googleapis.com で始まるものは、外部指標と呼ばれます。

• Prometheus 指標: 一部の Kubernetes ユーザーは、自分の Kubernetes 環境をモニタリングするために Prometheus を使用します。さらに、これらのユーザーは Prometheus 指標を Google Cloud Monitoring に伝搬し、その豊富な機能を活用します。Prometheus は、Cloud Monitoring で構成できます。この場合、Prometheus によりエクスポートされた指標は Cloud Monitoring の指標タイプに変換されます。

4. ログベースの指標

ログベースの指標は、Cloud Logging に取り込まれたログから生成されます。これらの指標は、特定のパターンに一致するログイベントをカウントする、または特定のログイベントのフィールドを抽出して集約することで作成できます。その後で、ログベースの指標は Cloud Monitoring に書き込まれ、アラート、チャート、ダッシュボードに使用できます。ログベースの指標には 2 種類あります。ユーザー定義（ユーザーが定義を作成するもの）とシステム定義（定義が最初から使用でき、ユーザーには変更できないもの）です。

指標の収集

指標は、Google サービスと、Google サービス上で実行されているアプリケーションから、いくつかの方法で収集されます。ここでは、各指標についての説明は省略しつつ、それぞれの収集メカニズムについて解説します。

1. GCE から指標を収集する

GCE の指標は、2 つの異なるメカニズムを使用して収集されます。

1. すでに述べたように、GCE のシステム指標（またはインフラストラクチャ指標）は、指標を収集するエージェントをインストールする必要がありません。Google はこれらの指標を自動的に収集し、プロジェクトに push します（図 1 を参照）。システム指標は一般に、Cloud Monitoring への取り込み前にバッチ処理されます。

2. GCE 指標を収集する 2 番目のメカニズムは、Ops エージェントや従来型のモニタリング エージェントをインストールすることです。エージェントをインストールすると、2 つの部分で利点があります。

• システム指標を非常に細かい粒度（1 分以内）で収集でき、個別の Linux や Windows プロセスのプロセス指標にアクセスできます。

• 開発者がアプリケーションを GCE VM にデプロイする際に、アプリケーション指標も生成できます。エージェントはほぼ瞬間的に指標を収集してプロジェクトに読み込むため、分析、アラート、ダッシュボードを迅速に行えます。

2. GKE から指標を収集する（Prometheus 不使用）

Prometheus を使用しない場合も、2 種類のメカニズムで GKE 指標を収集できます。GKE クラスタでは一部のノードがユーザー管理で、コントロール プレーン ノードなど他のノードは Google で管理されるため、指標収集のシナリオは多少複雑になります。GCE 環境の場合と同様に、システム指標はエージェントのデプロイなしで収集されます。

お客様が管理する GKE ノードについては、各種のリソースとワークロードについて指標を収集できます。GCE VM（Kubernetes ノードの基盤）については、Google コレクタでシステム指標がキャプチャされ、Cloud プロジェクトに送られます。プラットフォーム指標を収集するため、Kubernetes クラスタが作成される際に、GKE のお客様が管理するノードに Google コレクタが自動的にデプロイされます。これらのコレクタは Kubelet 経由で Kubernetes 指標を収集し、プロジェクトに公開します。

GKE コントロール プレーンでは、ノードは Google により管理され、これらのノードからの指標は Cloud Monitoring に公開されません。ただし、これらの指標は自動的に収集され、Kubernetes スケジューラにより、スケーリングやリソース管理の決定に使用されます。ここでも、これらの指標を収集するためにユーザーがエージェント ソフトウェアをデプロイする必要はありません。これらの Google コレクタは、クラスタが作成される際に Google により展開され、管理されます。

最後に、開発者はワークロードから出力された Prometheus 互換の指標、たとえば CronJobs や Deployments などを GKE クラスタ上で、フルマネージドの構成可能なパイプラインを使用して Cloud Monitoring から収集できます。開発者がどの指標を収集するかを構成すれば、他の動作はすべて GKE が行います。  

3. GKE から指標を収集する（Prometheus 使用）

Prometheus は、Kubernetes 環境をモニタリングするための一般的な選択肢です。GKE にアプリケーションをデプロイしているお客様は、モニタリングに Prometheus を引き続き使用できます。Prometheus の表示形式を使用するサービスによって生成された指標は、クラスタからエクスポートし、Cloud Monitoring で表示できます。

このユースケースでコントロール プレーン ノードから指標を収集する動作は、Prometheus を使用しないユースケースとほぼ同じです。しかし、ワーカーノードからの指標収集は異なります。Prometheus は Kubernetes ワーカーノードの 1 つにデプロイされ（図 3）、Pod から、および Kubelet API 経由で指標をスクレイピングします。アダプタが Prometheus から指標を収集し、Cloud Monitoring にアップロードします。

有料の指標と無料の指標

運用チームは常に IT の経費について考えており、モニタリング、ロギング、診断、トラブルシューティングのツールのうちどれが有料で、どれが無料なのかを一般的に明確化することを必要としています。何が有料で何が無料なのか、消費量アラートのしきい値の設定、その他の情報に関する明確な最新のガイドについては、Google Cloud のオペレーション スイートの料金ページをご覧ください。ここで説明した 4 つの大きなカテゴリの中で、システム指標は無料です。他のカテゴリの指標はすべて有料です。この一般的な説明には例外が 2 つあります。エージェントが収集した指標は有料ですが、エージェント自体についての指標（agent.googleapis.com/agent 名前空間に含まれるもの）は無料です。同様に、ログベースの指標は有料ですが、システム定義のログベースの指標は無料です。

さらに詳細な情報と、最新情報については、料金ページをご覧ください。

まとめ

クラウドベースのサービスとワークロードのオブザーバビリティのためには、収集と分析を必要とする多様な指標を理解する必要があります。これらの指標はシステム指標、エージェント指標、ユーザー定義指標、ログベースの指標に分類されます。このブログでは、指標のタイプ、これらの指標を収集するため使用される一般的なアーキテクチャ、および Google Cloud Monitoring を使用するときに、どの指標が有料で、どの指標が無料かについて解説しました。

ご不明な点やフィードバックがございましたら、Google Cloud コミュニティのオペレーション スイートのセクションでお知らせください。

- アウトバウンド プロダクト管理担当ディレクター Rakesh Dhoopar