カスタム指標を使用すると、アプリケーション固有のデータやクライアント側のシステムデータを取得できます。Cloud Monitoring によって収集された組み込み指標では、バックエンドのレイテンシやディスク使用量に関する情報は得ることができますが、アプリケーションが生成したバックグラウンド ルーチンの数などは確認できません。指標は、ログエントリの内容に基づくものを作成することもできます。そうした種類のカスタム指標については、ログベースの指標の概要をご覧ください。
カスタム指標（アプリケーション固有の指標）を使用すると、Cloud Monitoring の組み込み指標では定義できない情報を定義して収集できます。ユーザーはこれらの指標を、コードを設定するためにライブラリによって提供されている API を使用して取得し、Cloud Monitoring などのバックエンド アプリケーションに送信します。
カスタム指標は、Cloud Monitoring API を直接使用して作成できます。ただし、OpenCensus を使用することをおすすめします。カスタム指標の作成方法については、次のドキュメントをご覧ください。
OpenCensus を使用してカスタム指標を作成するでは、オープンソースのモニタリングとトレースのライブラリである OpenCensus の使用方法が説明されています。このライブラリを使用すると、カスタム指標を作成し、それらの指標に指標データを追加して、その指標データを Cloud Monitoring にエクスポートできます。
API でカスタム指標を作成するでは、Cloud Monitoring API を使用してカスタム指標を作成する方法と、その指標に指標データを追加する方法が説明されています。このドキュメントでは、API Explorer、C#、Go、Java、Node.js、PHP、Python、Ruby の各プログラミング言語を使用し、Monitoring API を使用する方法が例を使って説明されています。
Cloud Monitoring に関する限り、組み込み指標などのカスタム指標を使用できます。これらの指標は、グラフ化、アラートの設定、読み取りが可能です。 指標データの読み取りについては、次のドキュメントをご覧ください。
- 指標タイプとリソースタイプの閲覧では、カスタム指標と組み込み指標タイプを一覧表示し、調査する方法が説明されています。たとえば、このドキュメントの内容を使用して、プロジェクト内のすべてのカスタム指標記述子を一覧表示できます。
- 指標データの読み取りでは、Monitoring API を使用してカスタム指標や組み込み指標から時系列データを取得する方法が説明されています。たとえば、このドキュメントでは、API を使用して Google Cloud プロジェクトの仮想マシン（VM）インスタンスの CPU 使用率を取得する方法が説明されています。
Google Cloud コンソールには、カスタム指標の使用状況を表示する専用のページがあります。このページの内容については、指標診断の表示をご覧ください。
カスタム指標の指標記述子
各指標タイプには、指標データの整理方法を定義する指標記述子が必要です。指標記述子は、指標のラベルと指標の名前も定義します。たとえば、指標リストには、すべての組み込み指標タイプの指標記述子が表示されます。
カスタム指標を使用する場合、Cloud Monitoring は、書き込んだ指標データを使用して、指標記述子を作成できます。あるいは、指標記述子を明示的に作成して、指標データを書き込むこともできます。いずれの場合も、指標データの整理方法を決定する必要があります。
設計例
単一のマシンで実行されているプログラムがあり、このプログラムが補助プログラム A と B を呼び出すとします。ここで、プログラム A と B が何回呼び出されるかカウントする必要があるとします。また、プログラム A が 1 分あたり 10 回以上呼び出された時刻と、プログラム B が 1 分あたり 5 回以上呼び出された時刻も知りたいとします。最後に、Google Cloud プロジェクトは 1 つで、global モニタリング対象リソースにデータを書き込むものとします。
ここでは、カスタム指標に使用できる異なる設計例をいくつか説明します。
2 つのカスタム指標を使用する。
Metric-type-AはプログラムAへの呼び出しを計上します。Metric-type-BはプログラムBへの呼び出しを計上します。この場合、Metric-type-AとMetric-type-Bにはそれぞれ 1 つの時系列が含まれます。2 つの条件を含むアラート ポリシーを 1 つ作成することも、このデータモードを使用して 1 つの条件で 2 つのアラート ポリシーを作成することもできます。アラート ポリシーは複数の条件をサポートできますが、通知チャネルの構成は 1 つです。
このモデルは、モニタリング対象のアクティビティ間のデータの類似性に関心がない場合に適しています。この例では、アクティビティとはプログラム
AとBの呼び出し率です。1 つのカスタム指標を使用し、ラベルを使用してプログラム ID を保存します。たとえば、そのラベルでは
AやBの値を保存できます。Monitoring は、ラベルの一意の組み合わせごとに時系列を作成します。したがって、ラベル値がAの時系列と、ラベル値がBの時系列があります。前のモデルと同様に、アラート ポリシーを 1 つまたは 2 つ作成できます。ただし、アラート ポリシーの条件はより複雑です。プログラム
Aの呼び出し率がしきい値を超えた場合にインシデントを生成する条件では、ラベル値がAであるデータポイントのみを含むフィルタを使用する必要があります。このモデルのメリットの 1 つは、比率を簡単に計算できることです。たとえば、合計のうち、
Aの呼び出しによるものどれくらいかを判断できます。1 つのカスタム指標を使用して呼び出し数を計上しますが、どのプログラムが呼び出しを行ったかを記録するのにラベルは使用しません。このモデルでは、2 つのプログラムのデータを結合する単一の時系列があります。ただし、2 つのプログラムのデータを分離することはできないため、目的に合ったアラート ポリシーを作成することはできません。
最初の 2 つの設計では、データ分析の要件を満たすことができますが、最後の設計では満たせません。
指標記述子の作成方法については、指標記述子の作成をご覧ください。
カスタム指標の名前
カスタム指標を作成するときは、指標タイプを表す文字列識別子を定義します。この文字列は、Google Cloud プロジェクトのカスタム指標間で一意である必要があり、指標をユーザー定義の指標として指定する接頭辞を使用する必要があります。Monitoring の場合、使用できるプレフィックスは custom.googleapis.com/、external.googleapis.com/user、external.googleapis.com/prometheus です。接頭辞の後には、収集内容を示す名前が続きます。カスタム指標の命名方法の詳細については、指標の命名規則をご覧ください。次に、指標タイプの 2 種類の識別子の例を示します。
custom.googleapis.com/cpu_utilization
custom.googleapis.com/instance/cpu/utilization
上記の例での接頭辞 custom.googleapis.com は、両方の指標がカスタム指標であることを示します。どちらの例も CPU 使用率を測定する指標用ですが、組織モデルが異なります。カスタム指標が多くなることが予想される場合は、2 番目の例で使用されているような階層的な命名規則を使用することをおすすめします。
すべての指標タイプには、リソース名というグローバル一意識別子があります。指標タイプのリソース名の構成は以下のとおりです。
projects/PROJECT_ID/metricDescriptors/METRIC_TYPE
ここで、METRIC_TYPE は指標タイプの文字列識別子です。上の指標の例をプロジェクト my-project-id に作成した場合、これらの指標のリソース名は次のようになります。
projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization
名前かタイプか:指標記述子では、name フィールドに指標タイプのリソース名が格納され、type フィールドに METRIC_TYPE 文字列が格納されます。
カスタム指標のモニタリング対象リソースタイプ
データを時系列に書き込むときには、データの取得元を示す必要があります。データのソースを指定するには、データの取得元を示すモニタリング対象リソースタイプを選択し、それを使用して具体的な取得元を記述します。モニタリング対象リソースは、指標タイプの一部にはなりません。代わりに、データを書き込む時系列に、指標タイプへの参照とモニタリング対象リソースへの参照が含まれます。指標タイプはデータを表し、モニタリング対象リソースはデータが発信された場所を表します。
モニタリング対象リソースは、指標記述子を作成する前に検討してください。指標記述子に含める必要があるラベルは、使用するモニタリング対象リソースのタイプによって影響されます。たとえば、Compute Engine VM リソースには、プロジェクト ID、インスタンス ID、インスタンス ゾーンのラベルが含まれます。そのため、Compute Engine VM リソースに対してカスタム指標を記述する場合は、リソースラベルがインスタンス ID を含み、指標記述子にインスタンス ID のラベルは必要ありません。
指標の各データポイントは、モニタリング対象リソース オブジェクトと関連付ける必要があります。異なるモニタリング対象リソース オブジェクトからのポイントは、異なる時系列で保持されます。
カスタム指標では、次のモニタリング対象リソースタイプのいずれかを使用する必要があります。
aws_ec2_instance: Amazon EC2 インスタンス。dataflow_job: Dataflow ジョブ。gae_instance: App Engine インスタンス。gce_instance: Compute Engine インスタンス。generic_node: ユーザー指定のコンピューティング ノード。generic_task: ユーザー定義のタスク。gke_container: GKE コンテナ インスタンス。global: 他に適切なリソースタイプがない場合はこのリソースを使用します。ほとんどのケースでは、generic_nodeやgeneric_taskの方がglobalより適切です。k8s_cluster: Kubernetes クラスタ。k8s_container: Kubernetes コンテナ。k8s_node: Kubernetes ノード。k8s_pod: Kubernetes Pod。
通常は、アプリケーション コードが実行されている物理リソースを表すモニタリング対象リソース オブジェクトを使用します。 このアプローチにはいくつかのメリットがあります。
- 単一のリソースタイプを使用する場合に比べてパフォーマンスが向上します。
- 複数のプロセスが同じ時系列に書き込むことに起因する順不同データを回避します。
- カスタム指標データは、同じリソースからの他の指標データとグループ化できます。
global と汎用リソース
generic_task と generic_node のリソースタイプは、より個別な内容を扱う他のリソースタイプが適当でない場合に役立ちます。generic_task はタスクのようなリソース（たとえばアプリケーションなど）を定義する際、generic_node はノードのようなリソース（たとえば仮想マシンなど）を定義する際に便利です。 どちらの generic_* タイプにも共通のラベルが用意されており、独自のリソース オブジェクトを定義できます。共通ラベルを指標フィルタに使うことで、集約や単純化が簡単に行えます。
一方、global リソースタイプには project_id ラベルと location ラベルしかありません。プロジェクト内に指標のソースが複数ある場合、同じ global リソース オブジェクトを使うと、指標データの競合や上書きが発生する可能性があります。
カスタム指標をサポートする API メソッド
次の表では、Monitoring API のカスタム指標をサポートするメソッドと組み込み指標をサポートするメソッドを示します。
| Monitoring API メソッド | カスタム指標 で使用 |
組み込み指標 で使用 |
|---|---|---|
| monitoredResourceDescriptors.get | ○ | ○ |
| monitoredResourceDescriptors.list | ○ | ○ |
| metricDescriptors.get | ○ | ○ |
| metricDescriptors.list | ○ | ○ |
| timeSeries.list | ○ | ○ |
| timeSeries.create | ○ | |
| metricDescriptors.create | ○ | |
| metricDescriptors.delete | ○ |
制限とレイテンシ
カスタム指標とデータ保持に関連する上限については、割り当てと上限をご覧ください。
保存期間を超えて指標データを保持するには、Cloud Storage や BigQuery のような別の場所にデータを手動でコピーする必要があります。
カスタム指標へのデータの書き込みに伴うレイテンシについて詳しくは、指標データのレイテンシをご覧ください。