このトピックでは、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] で、確認する指標を見つけて選択します。[Available metrics] に表示されている特定の指標を選択するか、指標を検索します。
- 目的の指標を選択します。
- フィルタを適用します。各指標で使用可能なフィルタについては、利用可能な指標をご覧ください。
- 選択した指標のグラフが Cloud Operations に表示されます。
- [保存] をクリックします。
ダッシュボードの作成
ダッシュボードを使用して、重要な指標データを表示し、分析できます。Cloud Operations では、使用するリソースとサービスにダッシュボードが事前定義されています。また、カスタム ダッシュボードを作成することもできます。
グラフを使用して、カスタム ダッシュボードに Apigee 指標を表示します。カスタム ダッシュボードでは、表示されるグラフや構成を完全に制御できます。グラフの作成の詳細については、グラフの作成をご覧ください。
次の例は、Cloud Operations でダッシュボードを作成し、指標データが表示されるグラフを追加する方法を示しています。
- ブラウザで Monitoring Metrics Explorer を開き、[ダッシュボード] を選択します。
- [+ CREATE DASHBOARD] を選択します。
- ダッシュボードに名前を付けます。例: ハイブリッド プロキシ リクエスト トラフィック
- [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 |
上流のサーバー アプリケーションで発生したレイテンシ（ミリ秒単位）。 たとえば、 |
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 の指標をご覧ください。
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 の指標をご覧ください。
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 分 |