指標を表示する

このトピックでは、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 で指標を表示する方法を示しています。
  1. ブラウザで Monitoring の Metrics Explorer を開きます。すでに Cloud Operations コンソールを開いている場合は、[Metrics Explorer] を選択します。
  2. [リソースタイプと指標を探す] で、調べる指標を見つけて選択します。[Available metrics] に表示されている特定の指標を選択するか、指標を検索します。

  3. 目的の指標を選択します。
  4. フィルタを適用します。各指標で使用可能なフィルタについては、利用可能な指標をご覧ください。
  5. 選択した指標のグラフが Cloud Operations に表示されます。
  6. [Save] をクリックします。

ダッシュボードの作成

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

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

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

  1. ブラウザで Monitoring の Metrics Explorer を開き、[Dashboards] を選択します。
  2. [+ CREATE DASHBOARD] を選択します。
  3. ダッシュボードに名前を付けます。例: ハイブリッド プロキシ リクエスト トラフィック
  4. [Confirm] をクリックします。
  5. ダッシュボードに追加するグラフごとに、次の手順を行います。

    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-synchronizerapigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。

/server/nio state 開いているソケットの数。
/server/num_threads サーバーでアクティブなデーモン以外のスレッドの数。
/server/request_count method

type

サーバー アプリケーションで受信したリクエストの合計数。

たとえば、アプリケーションは apigee-runtime apigee-synchronizerapigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。

/server/response_count method

response_code
type

サーバー アプリケーションによって送信されたレスポンスの合計数。

たとえば、アプリケーションは apigee-runtime apigee-synchronizerapigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。

/server/latencies method

response_code
type

レイテンシは、サーバー アプリケーションによるミリ秒単位のレイテンシです。

たとえば、アプリケーションは apigee-runtime apigee-synchronizerapigee-udca のいずれかになります。pod_name ラベルを使用して、アプリケーションで結果をフィルタリングします。

/upstream/request_count method

type

サーバー アプリケーションから上流のアプリケーションに送信されたリクエストの数。

たとえば、 apigee-synchronizer の場合、コントロール プレーンは上流です。apigee-synchronizerupstream/request_count は、apigee-synchronizer によってコントロール プレーンに対して行われたリクエストを示す指標です。

/upstream/response_count method

response_code

type

サーバー アプリケーションで上流のアプリケーションから受信したレスポンスの数。

たとえば、apigee-synchronizer の場合、コントロール プレーンは上流です。apigee-synchronizerupstream/response_count は、apigee-synchronizer がコントロール プレーンから受信したリクエストを示す指標です。

/upstream/latencies method

response_code
type

上流のサーバー アプリケーションで発生したレイテンシ(ミリ秒単位)。

たとえば、apigee-synchronizer の場合、コントロール プレーンは上流です。apigee-synchronizerupstream/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 外部依存関係のどの部分が、どのような原因によって失敗しているかを判断するのに役立ちます。

これらのエラーは、さまざまなサービス(getDataLocationCloud storageToken generator)やデータセット(apitrace など)で発生する可能性があります。また、レスポンス コードもさまざまです。

/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、トレースなどが含まれている場合があります。状態は UPLOADEDFAILEDDISCARDED のいずれかになります。
/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_idlocationcluster_namenamespace_namepod_namecontainer_name
    指標ラベル: scopeunit

    このラベルは、特定のリソースのフィルタやグループ化に使用します。

    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_idlocationcluster_namenamespace_namepod_namecontainer_name

    このラベルは、特定のリソースのフィルタやグループ化に使用します。

  • Cassandra のデータ ボリュームの使用率
    指標: kubernetes.io/pod/volume/utilization
    リソースラベル: project_idlocationcluster_namenamespace_namepod_name
    指標ラベル: volume_name

    このラベルは、特定のリソースのフィルタやグループ化に使用します。

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

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

指標しきい値トリガー期間
kubernetes.io/pod/volume/utilization85%5 分
kubernetes.io/container/cpu/request_utilization85%3 分
Read request Latency 99thPercentile5 秒3 分
Write request Latency 99thPercentile5 秒3 分