指標を表示する

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

Cloud Operations について

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

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

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

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

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

apigee.googleapis.com/

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

apigee.googleapis.com/proxyv2/request_count

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

指標の表示

次の例は、Cloud Operations で指標を表示する方法を示しています。

ブラウザで Monitoring の Metrics Explorer を開きます。すでに Cloud Operations コンソールを開いている場合は、[Metrics Explorer] を選択します。
[リソースタイプと指標を探す] で、調べる指標を見つけて選択します。[Available metrics] に表示されている特定の指標を選択するか、指標を検索します。
目的の指標を選択します。
フィルタを適用します。各指標で使用可能なフィルタについては、利用可能な指標をご覧ください。
選択した指標のグラフが Cloud Operations に表示されます。
[Save] をクリックします。

ダッシュボードの作成

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

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

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

ブラウザで Monitoring の Metrics Explorer を開き、[Dashboards] を選択します。
[+ CREATE DASHBOARD] を選択します。
ダッシュボードに名前を付けます。例: ハイブリッドプロキシリクエストトラフィック
[Confirm] をクリックします。
ダッシュボードに追加するグラフごとに、次の手順を行います。
1. ダッシュボードで、[Add chart] を選択します。
2. 上記の指標の表示の説明に従って、目的の指標を選択します。
3. ダイアログの項目を入力し、グラフを定義します。
4. [Save] をクリックします。選択した指標のデータが Cloud Operations に表示されます。

利用可能な指標

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

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

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

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

指標名	ラベル	用途
`/proxyv2/request_count`	`method`	受信した API プロキシリクエストの合計数。
`/proxyv2/response_count`	`method` `response_code`	受信した API プロキシレスポンスの合計数。
`/proxyv2/latencies_percentile`	`method`	リクエストに対するすべての API ポリシーレスポンスのパーセンタイル。
`/targetv2/request_count`	`method` `target_type` `target_endpoint`	プロキシのターゲットに送信されたリクエストの合計数。
`/targetv2/response_count`	`method` `response_code` `target_type` `target_endpoint`	プロキシのターゲットから受信したレスポンスの合計数。
`/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`	データ収集 Pod のディスク上にあるファイル数。この値が 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`	データ収集 Pod のディスク上でデータファイルが占めるスペース（バイト単位）。時間経過に伴うこの値の増加: `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 サービスは、他のハイブリッドサービスと同様に、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 SSTable の未処理の圧縮。詳細については、圧縮をご覧ください。
`/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 ヒープのコミットされたメモリ使用量。