指標を表示する

このトピックでは、Stackdriver ダッシュボードで Apigee ハイブリッド指標を表示する方法について説明します。

Stackdriver について

指標、ダッシュボード、Stackdriver の詳細については、以下をご覧ください。

ハイブリッド指標の有効化

ハイブリッド指標を Stackdriver に送信するには、まず指標の収集を有効にする必要があります。この手順については、指標の収集を構成するをご覧ください。

ハイブリッド指標の名前とラベルについて

有効にすると、ハイブリッドで Stackdriver の指標が自動的に入力されます。ハイブリッドによって作成される指標のドメイン名接頭辞は次のとおりです。

apigee.googleapis.com/

たとえば、/proxy/request_count 指標には API プロキシが受信したリクエストの合計数が含まれます。したがって、Stackdriver の指標名は次のようになります。

apigee.googleapis.com/proxy/request_count

Stackdriver では、ラベルに基づく指標データのフィルタリングとグループ化が可能です。事前定義されたラベルと、ハイブリッドによって明示的に追加されたラベルがあります。以下の利用可能な指標のセクションには、使用可能なすべてのハイブリッド指標と、フィルタリングとグループ化のために使用できる指標に対して追加されたラベルが表示されます。

指標の表示

次の例は、Stackdriver で指標を表示する方法を示しています。
  1. Stackdriver Metrics Explorer をブラウザで開きます。または、すでに Stackdriver コンソールを開いている場合は、[Metrics Explorer] を選択します。

  2. [Find resource type and metric] で、調べる指標を見つけて選択します。[Available metrics] に一覧表示されている特定の指標を選択するか、指標を検索します。たとえば、proxy/latencies を検索します。

    指標を入力する

  3. 目的の指標を選択します。
  4. フィルタを適用します。各指標のフィルタ選択肢は使用可能な指標に記載されています。たとえば、proxy_latencies 指標のフィルタの選択肢は org=org_name です。
  5. 選択した指標のグラフが表示されます。
  6. [Save] をクリックします。

ダッシュボードの作成

ダッシュボードを使用して、重要な指標データを表示し、分析できます。Stackdriver には、使用するリソースとサービス用の事前定義されたダッシュボードが用意されており、カスタム ダッシュボードを作成することもできます。

グラフを使用して、カスタム ダッシュボードに Apigee 指標を表示します。カスタム ダッシュボードでは、表示されるグラフや構成を完全に制御できます。グラフの作成の詳細については、グラフの作成をご覧ください。

次の例は、Stackdriver でダッシュボードを作成し、指標データが表示されるグラフを追加する方法を示しています。

  1. ブラウザで Stackdriver Metrics Explorer を開き、[Dashboards] を選択します。
  2. [+ Create Dashboard] を選択します。
  3. ダッシュボードに名前を付けます。例: ハイブリッド プロキシ リクエスト トラフィック
  4. [Confirm] をクリックします。

  5. ダッシュボードに追加するグラフごとに、次の手順を行います。

    1. ダッシュボードで、[Add chart] を選択します。
    2. 上記の指標の表示の説明に従って、目的の指標を選択します。
    3. ダイアログの項目を入力し、グラフを定義します。
    4. [Save] をクリックします。選択した指標のデータが Stackdriver に表示されます。

利用可能な指標

次の表に、プロキシ トラフィックを分析するための指標を一覧表示します。

プロキシ、ターゲット、サーバーのトラフィック指標

Prometheus サービスは、プロキシ、ターゲット、サーバー トラフィックの指標を収集して処理します（指標の収集を参照）。

次の表に、Prometheus で使用される指標とラベルを示します。これらのラベルは指標のログエントリで使用されます。

指標名 ラベル 用途
/proxy/request_count method 受信した API プロキシ リクエストの合計数。
/proxy/response_count method response_code 受信した API プロキシ レスポンスの合計数。
/proxy/latencies method 呼び出しに応答するのにかかった時間（ミリ秒）の合計。この時間には、Apigee API プロキシのオーバーヘッドとターゲット サーバーでの時間が含まれています。
/target/request_count method

target_type

target_endpoint

 プロキシのターゲットに送信されたリクエストの総数。
/target/response_count method

response_code

target_type

target_endpoint

 プロキシのターゲットから受信したレスポンスの総数。
/target/latencies method

response_code

target_type

target_endpoint

 呼び出しに応答するのにかかった時間（ミリ秒）の合計。この時間には Apigee API プロキシのオーバーヘッドは含まれません。
/policy/latencies policy_name この名前付きポリシーの実行にかかった合計時間（ミリ秒）。
/server/fault_count source

サーバー アプリケーションの障害の合計数。

たとえば、アプリケーションは apigee-runtime、 apigee-synchronizer、apigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。
/server/nio state 開いているソケットの数。
/server/num_threads サーバー内のアクティブな非デーモン スレッドの数。
/server/request_count method

type

サーバー アプリケーションで受信したリクエストの合計数。

たとえば、アプリケーションは apigee-runtime、 apigee-synchronizer、apigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。
/server/response_count method

response_code
type

サーバー アプリケーションによって送信されたレスポンスの合計数。

たとえば、アプリケーションは apigee-runtime、 apigee-synchronizer、apigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。
/server/latencies method

response_code
type

レイテンシは、サーバー アプリケーションによるミリ秒単位のレイテンシです。

たとえば、アプリケーションは apigee-runtime、 apigee-synchronizer、apigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。
/upstream/request_count method

type

サーバー アプリケーションから上流のアプリケーションに送信されたリクエストの数。

たとえば、 apigee-synchronizer の場合、コントロール プレーンは上流です。したがって、apigee-synchronizer の upstream/request_count は、apigee-synchronizer によってコントロール プレーンに対して行われたリクエストを示す指標です。
/upstream/response_count method

response_code

type

サーバー アプリケーションで上流のアプリケーションから受信したレスポンスの数。

たとえば、apigee-synchronizer の場合、コントロール プレーンは上流です。したがって、apigee-synchronizer の upstream/response_count は、apigee-synchronizer でコントロール プレーンから受信したリクエストを示す指標です。
/upstream/latencies method

response_code
type

上流のサーバー アプリケーションで発生したレイテンシ（ミリ秒単位）。

たとえば、apigee-synchronizer の場合、コントロール プレーンは上流です。したがって、apigee-synchronizer の upstream/latencies は、コントロール プレーンからのレイテンシを示す指標です。

UDCA の指標

Prometheus サービスは、他のハイブリッド サービスと同様に、UDCA サービスの指標を収集して処理します（指標の収集を参照）。

次の表に、Prometheus で使用される UDCA 指標データの指標とラベルを示します。これらのラベルは指標のログエントリで使用されます。

指標名 ラベル 用途
/udca/server/local_file_oldest_ts dataset

state

データセットにある最も古いファイルの、Unix エポック開始からの経過時間を示すタイムスタンプ（ミリ秒単位）。

これは 60 秒ごとに計算されるもので、リアルタイムの状態を反映しません。UDCA が最新で、この指標の計算時にアップロード待ちのファイルがない場合、この値は 0 になります。

この値が増え続けると、古いファイルがディスクに残ったままになります。
/udca/server/local_file_latest_ts dataset

state

状態別のディスクにある最新のファイルの、Unix エポック開始からの経過時間を示すタイムスタンプ（ミリ秒単位）。

これは 60 秒ごとに計算されるもので、リアルタイムの状態を反映しません。UDCA が最新で、この指標の計算時にアップロード待ちのファイルがない場合、この値は 0 になります。
/udca/server/local_file_count dataset

state

データ収集ポッドのディスクにあるファイル数のカウント。

この値が 0 に近づくのが理想的です。値が一貫して高い場合は、ファイルがアップロードされていないか、UDCA が高速でアップロードできていません。

この値は 60 秒ごとに計算されるもので、UDCA の状態をリアルタイムで反映していません。
/udca/server/total_latencies dataset

データファイルの作成とデータファイルの正常なアップロードとの時間間隔（秒単位）。

バケットは 100 ミリ秒、250 ミリ秒、500 ミリ秒、1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、64 秒のいずれかになります。

ファイルの作成時間から正常なアップロード時間までの合計レイテンシのヒストグラム。
/udca/server/upload_latencies dataset

UDCA がデータファイルのアップロードに費やした合計時間（秒単位）。

バケットは 100 ミリ秒、250 ミリ秒、500 ミリ秒、1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、64 秒のいずれかになります。

指標には、すべてのアップストリーム コールを含む、合計アップロード レイテンシのヒストグラムが表示されます。
/udca/upstream/http_error_count service

dataset

response_code

UDCA で発生した HTTP エラーの合計数。この指標は、UDCA 外部依存関係のどの部分が、どのような原因によって失敗しているかを判断するのに役立ちます。

これらのエラーは、さまざまなサービス（getDataLocation、Cloud storage、Token generator）や、さまざまなレスポンス コードを持つさまざまなデータセット（api や trace など）で発生する可能性があります。
/udca/upstream/http_latencies service

dataset

サービスのアップストリーム レイテンシ（秒単位）。

バケットは 100 ミリ秒、250 ミリ秒、500 ミリ秒、1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、64 秒のいずれかになります。

アップストリーム サービスからのレイテンシのヒストグラム。
/udca/upstream/uploaded_file_sizes dataset

Apigee サービスにアップロードされるファイルのサイズ（バイト単位）。

バケットは 1 KB、10 KB、100 KB、1 MB、10 MB、100 MB、1 GB のいずれかになります。

データセット、組織、環境ごとのファイルサイズのヒストグラム。
/udca/upstream/uploaded_file_count dataset UDCA が Apigee サービスにアップロードしたファイルの数。

次のことに注意してください。

  • event データセットの値は増え続けます。
  • org/env に一定のトラフィックがある場合、api データセット値は増え続けます。
  • Apigee トレースツールを使用してリクエストをデバッグまたは検査すると、trace データセットの値は増えます。
/udca/disk/used_bytes dataset

state

データ収集ポッドのディスク上でデータファイルが占めるスペース（バイト単位）。

時間経過に伴うこの値の増加:

  • ready_to_upload はエージェントが遅れていることを意味します。
  • failed はファイルがディスク上に蓄積されていて、アップロードされていないことを示します。この値は 60 秒ごとに計算されます。
/udca/server/pruned_file_count dataset

state

 有効期間（TTL）が、設定されたしきい値を超えたために、削除されたファイルの数。データセットには API、トレースなどを含めることができ、状態は UPLOADED、FAILED、DISCARDED のいずれかになります。
/udca/server/retry_cache_size dataset

UDCA がアップロードを再試行しているファイル数のカウント（データセットごと）。

各ファイルを 3 回再試行すると、UDCA はファイルを /failed サブディレクトリに移動し、このキャッシュから削除します。時間の経過に伴ってこの値が増大する場合は、キャッシュがクリアされていません。これは、3 回の再試行後にファイルが /failed サブディレクトリに移動されたときに発生します。

Cassandra の指標

Prometheus サービスは、他の Hybrid サービスと同様に、Cassandra の指標を収集して処理します（指標の収集を参照）。

次の表に、Prometheus で使用される Cassandra 指標データの指標とラベルを示します。これらのラベルは指標のログエントリで使用されます。

指標名（ドメインを除く） ラベル 用途
/cassandra/process_max_fds オープン ファイル記述子の最大数。
/cassandra/process_open_fds ファイル記述子を開きます。
/cassandra/jvm_memory_pool_bytes_max pool プールの JVM 最大メモリ使用量。
/cassandra/jvm_memory_pool_bytes_init pol プールの JVM 初期メモリ使用量。
/cassandra/jvm_memory_bytes_max area JVM ヒープの最大メモリ使用量。
/cassandra/process_cpu_seconds_total 使用されるユーザーとシステムの CPU 時間（秒単位）。
/cassandra/jvm_memory_bytes_used area JVM ヒープメモリ使用量。
/cassandra/compaction_pendingtasks unit Cassandra SSTables の優れたコンパクション。詳細については、コンパクションをご覧ください。
/cassandra/jvm_memory_bytes_init area JVM ヒープの初期メモリ使用量。
/cassandra/jvm_memory_pool_bytes_used pool JVM プールのメモリ使用量。
/cassandra/jvm_memory_pool_bytes_committed pool JVM プールのコミットされたメモリ使用量。
/cassandra/clientrequest_latency scope

unit

 読み取りリクエストのレイテンシの 75 パーセンタイル範囲（マイクロ秒単位）。
/cassandra/jvm_memory_bytes_committed area JVM ヒープのコミットされたメモリ使用量。