このトピックでは、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] を選択します。
[Find resource type and metric] で、調べる指標を見つけて選択します。[Available metrics] に表示されている特定の指標を選択するか、指標を検索します。
- 目的の指標を選択します。
- フィルタを適用します。各指標で使用可能なフィルタについては、利用可能な指標をご覧ください。
- 選択した指標のグラフが Cloud Operations に表示されます。
- [Save] をクリックします。
ダッシュボードの作成
ダッシュボードを使用すると、重要な指標データを表示し、分析できます。Cloud Operations では、使用するリソースとサービスにダッシュボードが事前定義されています。また、カスタム ダッシュボードを作成することもできます。
グラフを使用して、カスタム ダッシュボードに Apigee 指標を表示します。カスタム ダッシュボードでは、表示されるグラフや構成を完全に制御できます。グラフの作成の詳細については、グラフの作成をご覧ください。
次の例は、Cloud Operations でダッシュボードを作成し、指標データが表示されるグラフを追加する方法を示しています。
- ブラウザで Monitoring の Metrics Explorer を開き、[Dashboards] を選択します。
- [+ CREATE DASHBOARD] を選択します。
- ダッシュボードに名前を付けます。例: ハイブリッド プロキシ リクエスト トラフィック
- [Confirm] をクリックします。
ダッシュボードに追加するグラフごとに、次の手順を行います。
- ダッシュボードで、[Add chart] を選択します。
- 上記の指標の表示の説明に従って、目的の指標を選択します。
- ダイアログの項目を入力し、グラフを定義します。
- [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
|
プロキシのターゲットに送信されたリクエストの合計数。 |
/targetv2/response_count |
method
|
プロキシのターゲットから受信したレスポンスの合計数。 |
/server/fault_count |
source |
サーバー アプリケーションの障害の合計数。 たとえば、アプリケーションは |
/server/nio |
state |
開いているソケットの数。 |
/server/num_threads |
サーバーでアクティブなデーモン以外のスレッドの数。 | |
/server/request_count |
method
|
サーバー アプリケーションで受信したリクエストの合計数。 たとえば、アプリケーションは |
/server/response_count |
method
|
サーバー アプリケーションによって送信されたレスポンスの合計数。 たとえば、アプリケーションは |
/server/latencies |
method
|
レイテンシは、サーバー アプリケーションによるミリ秒単位のレイテンシです。 たとえば、アプリケーションは |
/upstream/request_count |
method
|
サーバー アプリケーションから上流のアプリケーションに送信されたリクエストの数。 たとえば、 |
/upstream/response_count |
method
|
サーバー アプリケーションで上流のアプリケーションから受信したレスポンスの数。 たとえば、 |
/upstream/latencies |
method
|
上流のサーバー アプリケーションで発生したレイテンシ（ミリ秒単位）。 たとえば、 |
UDCA の指標
Prometheus サービスは、他のハイブリッド サービスと同様に、UDCA サービスの指標を収集して処理します（指標の収集を参照）。
次の表に、Prometheus で使用される UDCA の指標データの指標とラベルを示します。これらのラベルは、指標のログエントリで使用されます。
| 指標名 | ラベル | 用途 |
|---|---|---|
/udca/server/local_file_oldest_ts |
dataset
|
データセットにある最も古いファイルのタイムスタンプ（ミリ秒単位）。これは Unix エポック開始からの経過時間を表します。 これは 60 秒ごとに計算されるもので、リアルタイムの状態を反映しません。UDCA が最新で、この指標の計算時にアップロード待ちのファイルがない場合、この値は 0 になります。 この値が増え続けると、古いファイルがディスクに残ったままになります。 |
/udca/server/local_file_latest_ts |
dataset
|
ディスクにある最新のファイルのタイムスタンプ（ミリ秒単位）。これは Unix エポック開始からの経過時間を表します。ディスクの状態別に表示されます。 これは 60 秒ごとに計算されるもので、リアルタイムの状態を反映しません。UDCA が最新で、この指標の計算時にアップロード待ちのファイルがない場合、この値は 0 になります。 |
/udca/server/local_file_count |
dataset
|
データ収集 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
|
UDCA で発生した HTTP エラーの合計数。この指標は、UDCA 外部依存関係のどの部分が、どのような原因によって失敗しているかを判断するのに役立ちます。 これらのエラーは、さまざまなサービス（
|
/udca/upstream/http_latencies |
service
|
サービスのアップストリーム レイテンシ（秒単位）。 バケットは 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 サービスにアップロードしたファイルの数。 次のことに注意してください。
|
/udca/disk/used_bytes |
dataset
|
データ収集 Pod のディスク上でデータファイルが占めるスペース（バイト単位）。 時間経過に伴うこの値の増加:
|
/udca/server/pruned_file_count |
dataset
|
有効期間（TTL）が設定済みのしきい値を超えたために削除されたファイルの数。データセットには API、トレースなどが含まれている場合があります。状態は UPLOADED、FAILED、DISCARDED のいずれかになります。 |
/udca/server/retry_cache_size |
dataset |
UDCA がアップロードを再試行しているファイル数（データセットごと）。 各ファイルを 3 回再試行すると、UDCA はファイルを |
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
|
読み取りリクエストのレイテンシの 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リソースラベル: project_id、location、cluster_name、namespace_name、pod_name、container_nameこのラベルは、特定のリソースのフィルタやグループ化に使用します。
- Cassandra のデータ ボリュームの使用率
指標: kubernetes.io/pod/volume/utilizationリソースラベル: 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 分 |