指標を表示する

このトピックでは、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`	データ収集ポッドのディスクにあるファイル数のカウント。この値が 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 ヒープのコミットされたメモリ使用量。

Cassandra 指標の操作

Cassandra データベースのモニタリングでは、重要な指標として次のものを使用することをおすすめします。

Cassandra のリクエストレート: この指標を使用して、Cassandra の読み取りと書き込みのリクエストレートをモニタリングします。

指標:	`apigee.googleapis.com/cassandra/clientrequest_latency`
リソースラベル:	`project_id`、`location`、`cluster_name`、`namespace_name`、`pod_name`、`container_name`
指標ラベル:	`scope`、`unit` このラベルは、特定のリソースのフィルタやグループ化に使用します。

Cassandra 読み取りリクエスト率をモニタリングするには、次のフィルタを適用します。

フィルタ: metric.scope == 'Read'
metric.unit == 'OneMinuteRate'

cassandra 書き込みリクエスト率をモニタリングするには、次のフィルタを適用します。

フィルタ: metric.scope == 'Write'
metric.unit == 'OneMinuteRate'

Cassandra のリクエストレイテンシ: この指標を使用して、Cassandra の読み取りおよび書き込みリクエストのレイテンシをモニタリングします。これは、リクエスト率 apigee.googleapis.com/cassandra/clientrequest_latency と同じ指標です（適用されるフィルタは異なります）。
Cassandra 読み取りリクエストのレイテンシをモニタリングするには、次のフィルタを適用します。

フィルタ: metric.scope == 'Read'
metric.unit == '99thPercentile'、'95thPercentile'、または '75thPercentile'

Cassandra 書き込みリクエストのレイテンシをモニタリングするには、次のフィルタを適用します。

フィルタ: metric.scope == 'Write'
metric.unit == '99thPercentile'、'95thPercentile'、または '75thPercentile'

Cassandra Pod の CPU リクエストの使用率

指標:	`kubernetes.io/container/cpu/request_utilization (GKE)` `kubernetes.io/anthos/container/cpu/request_utilization (Anthos)`
リソースラベル:	`project_id`、`location`、`cluster_name`、`namespace_name`、`pod_name`、`container_name` このラベルは、特定のリソースのフィルタやグループ化に使用します。

Cassandra のデータボリュームの使用率

指標:	`kubernetes.io/pod/volume/utilization (GKE)` `kubernetes.io/anthos/pod/volume/utilization (Anthos)`
リソースラベル:	`project_id`、`location`、`cluster_name`、`namespace_name`、`pod_name`
指標ラベル:	`volume_name` このラベルは、特定のリソースのフィルタやグループ化に使用します。

Cassandra クラスタのスケーリングに関する推奨事項

Cassandra クラスタのスケーリングを行う場合、推奨事項として次のガイドラインを参考にしてください。一般に、読み取りリクエストや書き込みリクエストが常に 99 パーセンタイルのレイテンシを示している場合、あるいは、レイテンシが上昇傾向にあり、それに伴い CPU リクエストの急増や、読み取りリクエストまたは書き込みリクエストの急増が見られる場合、Cassandra クラスタは負荷の高い状態とみなすことができます。その場合、クラスタのスケールアップを検討することをおすすめします。詳細については、Cassandra のスケーリングをご覧ください。

指標	しきい値	トリガー期間
`kubernetes.io/pod/volume/utilization`	85%	5 分
`kubernetes.io/container/cpu/request_utilization`	85%	3 分
`Read request Latency 99thPercentile`	5 秒	3 分
`Write request Latency 99thPercentile`	5 秒	3 分