このトピックでは、Cloud Operations ダッシュボードで Apigee ハイブリッド指標を表示する方法について説明します。
Cloud Operations について
指標、ダッシュボード、Cloud Operations の詳細については、以下をご覧ください。
ハイブリッド指標を有効にする
ハイブリッド指標を Cloud Operations に送信する前に、指標の収集を有効にする必要があります。手順については、指標の収集を構成するをご覧ください。
ハイブリッド指標の名前とラベルについて
有効にすると、ハイブリッドが Cloud Operations の指標を自動的に入力します。ハイブリッドによって作成される指標のドメイン名接頭辞は次のとおりです。
apigee.googleapis.com/
たとえば、/proxy/request_count 指標には API プロキシが受信したリクエストの合計数が含まれます。Cloud Operations の指標名は次のようになります。
apigee.googleapis.com/proxy/request_count
Cloud Operations では、ラベルに基づいて指標データのフィルタとグループ化を行うことができます。事前定義されたラベルと、ハイブリッドによって明示的に追加されたラベルがあります。以下の利用可能な指標のセクションには、使用可能なすべてのハイブリッド指標と、フィルタリングとグループ化のために使用できる指標に対して追加されたラベルが表示されます。
指標の表示
次の例は、Cloud Operations で指標を表示する方法を示しています。- ブラウザで Monitoring Metrics Explorer を開きます。すでに Cloud Operations コンソールを開いている場合は、[Metrics Explorer] を選択します。
[Find resource type and metric] で、確認する指標を見つけて選択します。[使用可能な指標] に表示されている特定の指標を選択するか、指標を検索します。
- 目的の指標を選択します。
- フィルタの適用各指標のフィルタ選択肢は使用可能な指標に記載されています。
- 選択した指標のグラフが Cloud Operations に表示されます。
- [保存] をクリックします。
ダッシュボードの作成
ダッシュボードを使用して、重要な指標データを表示し、分析できます。Cloud Operations には、使用するリソースとサービス用の事前定義されたダッシュボードが用意されており、カスタム ダッシュボードを作成することもできます。
グラフを使用して、カスタム ダッシュボードに Apigee 指標を表示します。カスタム ダッシュボードでは、表示されるグラフや構成を完全に制御できます。グラフの作成の詳細については、グラフの作成をご覧ください。
次の例は、Cloud Operations でダッシュボードを作成し、指標データが表示されるグラフを追加する方法を示しています。
- ブラウザで Monitoring Metrics Explorer を開き、[ダッシュボード] を選択します。
- [+ ダッシュボードを作成] を選択します。
- ダッシュボードに名前を付けます。例: ハイブリッド プロキシ リクエスト トラフィック
- [Confirm] をクリックします。
ダッシュボードに追加するグラフごとに、次の手順を行います。
- ダッシュボードで、[Add chart] を選択します。
- 上記の指標の表示の説明に従って、目的の指標を選択します。
- ダイアログの項目を入力し、グラフを定義します。
- [保存] をクリックします。選択した指標のデータが Cloud Operations に表示されます。
利用可能な指標
次の表に、プロキシ トラフィックを分析するための指標を示します。各 Apigee 指標の詳細については、Google Cloud の指標をご覧ください。
プロキシ、ターゲット、サーバー トラフィックの指標
Open Telemetry は、プロキシ、ターゲット、サーバー トラフィックの指標を収集して処理します（指標の収集を参照）。
次の表に、Open Telemetry コレクタで使用される指標を示します。
| 指標名 | 使用 |
|---|---|
/proxy/request_count |
最後のサンプルが記録されてからの Apigee プロキシへのリクエストの数。 |
/proxy/response_count |
Apigee API プロキシによって送信されたレスポンスの数。 |
/proxy/latencies |
レイテンシの分布。Apigee プロキシがリクエストを受信してから、レスポンスが Apigee プロキシからクライアントに送信された時点までが計算されます。 |
/proxyv2/request_count |
受信した API プロキシ リクエストの合計数。 |
/proxyv2/response_count |
受信した API プロキシ レスポンスの合計数。 |
/proxyv2/latencies_percentile |
リクエストに対するすべての API ポリシー レスポンスのパーセンタイル。 |
/target/request_count |
最後のサンプルが記録されてから Apigee ターゲットに送信されたリクエストの数。 |
/target/response_count |
最後のサンプルが記録されてから Apigee ターゲットから受信したレスポンスの数。 |
/target/latencies |
レイテンシの分布。リクエストが Apigee ターゲットに送信された時点から、レスポンスが Apigee プロキシによって受信される時点までが計算されます。この時間には Apigee API プロキシのオーバーヘッドは含まれません。 |
/targetv2/request_count |
プロキシのターゲットに送信されたリクエストの合計数。 |
/targetv2/response_count |
プロキシのターゲットから受信したレスポンスの合計数。 |
/server/fault_count |
サーバー アプリケーションの障害の合計数。 たとえば、アプリケーションは |
/server/nio |
これはゲージ指標で、ラベル state でフィルタしてさまざまなラベルの詳細を取得できます。値は、さまざまなシステム オペレーションと I/O オペレーションを表します。accepted、accepted_total、close_failed、close_success、conn_pending、connected、connected_total、max_conn、timeouts などのラベルは、ソケットと接続のオペレーションに関連しています。残りのラベルは、他のシステム オペレーションに関連しています。 |
/server/num_threads |
サーバー内のアクティブな非デーモン スレッドの数。 |
/server/request_count |
サーバー アプリケーションで受信したリクエストの合計数。 たとえば、アプリケーションは |
/server/response_count |
サーバー アプリケーションによって送信されたレスポンスの合計数。 たとえば、アプリケーションは |
/server/latencies |
レイテンシは、サーバー アプリケーションによるミリ秒単位のレイテンシです。 たとえば、アプリケーションは |
/upstream/request_count |
サーバー アプリケーションから上流のアプリケーションに送信されたリクエストの数。 たとえば、 |
/upstream/response_count |
サーバー アプリケーションで上流のアプリケーションから受信したレスポンスの数。 たとえば、 |
/upstream/latencies |
上流のサーバー アプリケーションで発生したレイテンシ（ミリ秒単位）。 たとえば、 |
UDCA の指標
Open Telemetry は、他のハイブリッド サービスと同様に、UDCA サービスの指標を収集して処理します（指標の収集を参照）。
次の表に、Open Telemetry コレクタが UDCA 指標データで使用する指標を示します。
state
state
| 指標名 | 使用 |
|---|---|
/udca/server/local_file_oldest_ts |
データセットにある最も古いファイルの、Unix エポック開始からの経過時間を示すタイムスタンプ（ミリ秒単位）。 これは 60 秒ごとに計算されるもので、リアルタイムの状態を反映しません。UDCA が最新で、この指標の計算時にアップロード待ちのファイルがない場合、この値は 0 になります。 この値が増え続けると、古いファイルがディスクに残ったままになります。 |
/udca/server/local_file_latest_ts |
状態別のディスクにある最新のファイルの、Unix エポック開始からの経過時間を示すタイムスタンプ（ミリ秒単位）。 これは 60 秒ごとに計算されるもので、リアルタイムの状態を反映しません。UDCA が最新で、この指標の計算時にアップロード待ちのファイルがない場合、この値は 0 になります。 |
/udca/server/local_file_count |
データ収集ポッドのディスクにあるファイル数のカウント。 この値が 0 に近づくのが理想的です。値が一貫して高い場合は、ファイルがアップロードされていないか、UDCA が高速でアップロードできていません。 この値は 60 秒ごとに計算されるもので、UDCA の状態をリアルタイムで反映していません。 |
/udca/server/total_latencies |
データファイルの作成とデータファイルの正常なアップロードとの時間間隔（秒単位）。 バケットは 100 ミリ秒、250 ミリ秒、500 ミリ秒、1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、64 秒のいずれかになります。 ファイルの作成時間から正常なアップロード時間までの合計レイテンシのヒストグラム。 |
/udca/server/upload_latencies |
UDCA がデータファイルのアップロードに費やした合計時間（秒単位）。 バケットは 100 ミリ秒、250 ミリ秒、500 ミリ秒、1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、64 秒のいずれかになります。 指標には、すべてのアップストリーム コールを含む、合計アップロード レイテンシのヒストグラムが表示されます。 |
/udca/upstream/http_error_count |
UDCA で発生した HTTP エラーの合計数。この指標は、UDCA 外部依存関係のどの部分が、どのような原因によって失敗しているかを判断するのに役立ちます。 これらのエラーは、さまざまなサービス（
|
/udca/upstream/http_latencies |
サービスのアップストリーム レイテンシ（秒単位）。 バケットは 100 ミリ秒、250 ミリ秒、500 ミリ秒、1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、64 秒のいずれかになります。 アップストリーム サービスからのレイテンシのヒストグラム。 |
/udca/upstream/uploaded_file_sizes |
Apigee サービスにアップロードされるファイルのサイズ（バイト単位）。 バケットは 1 KB、10 KB、100 KB、1 MB、10 MB、100 MB、1 GB のいずれかになります。 データセット、組織、環境ごとのファイルサイズのヒストグラム。 |
/udca/upstream/uploaded_file_count |
UDCA が Apigee サービスにアップロードしたファイルの数。
次のことに注意してください。
|
/udca/disk/used_bytes |
データ収集ポッドのディスク上でデータファイルが占めるスペース（バイト単位）。 時間経過に伴うこの値の増加:
|
/udca/server/pruned_file_count |
有効期間（TTL）が、設定されたしきい値を超えたために、削除されたファイルの数。データセットには API、トレースなどを含めることができ、状態は UPLOADED、FAILED、DISCARDED のいずれかになります。
|
/udca/server/retry_cache_size |
UDCA がアップロードを再試行しているファイル数のカウント（データセットごと）。 各ファイルを 3 回再試行すると、UDCA はファイルを |
Cassandra の指標
Open Telemetry は、他のハイブリッド サービスと同様に、Cassandra の指標を収集して処理します（指標の収集を参照）。
次の表に、Open Telemetry コレクタが Cassandra 指標データで使用する指標を示します。
| 指標名（ドメインを除く） | 使用 |
|---|---|
/cassandra/process_max_fds |
オープン ファイル記述子の最大数。 |
/cassandra/process_open_fds |
ファイル記述子を開きます。 |
/cassandra/jvm_memory_pool_bytes_max |
プールの JVM 最大メモリ使用量。 |
/cassandra/jvm_memory_pool_bytes_init |
プールの JVM 初期メモリ使用量。 |
/cassandra/jvm_memory_bytes_max |
JVM ヒープの最大メモリ使用量。 |
/cassandra/process_cpu_seconds_total |
使用されるユーザーとシステムの CPU 時間（秒単位）。 |
/cassandra/jvm_memory_bytes_used |
JVM ヒープメモリ使用量 |
/cassandra/compaction_pendingtasks |
Cassandra SSTable の未処理の圧縮。詳細については、コンパクションをご覧ください。 |
/cassandra/jvm_memory_bytes_init |
JVM ヒープの初期メモリ使用量。 |
/cassandra/jvm_memory_pool_bytes_used |
JVM プールのメモリ使用量。 |
/cassandra/jvm_memory_pool_bytes_committed |
JVM プールのコミットされたメモリ使用量。 |
/cassandra/clientrequest_latency |
読み取りリクエストのレイテンシの 75 パーセンタイル範囲（マイクロ秒単位）。 |
/cassandra/jvm_memory_bytes_committed |
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 on Google Cloud)
kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)リソースラベル project_id,location,cluster_name,namespace_name,pod_name,container_nameこのラベルは、特定のリソースのフィルタリングやグループ化に使用します。
- Cassandra のデータ ボリュームの使用率
指標: kubernetes.io/pod/volume/utilization (GKE on Google Cloud)
kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)リソースラベル 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 分 |