查看指標

本主題說明如何在 Cloud Operations 資訊主頁中查看 Apigee 混合指標。

關於 Cloud 作業套件

如要進一步瞭解指標、資訊主頁和 Cloud Operations，請參閱：

啟用混合指標

您必須先啟用指標收集功能，才能將混合指標傳送至 Cloud Operations。如需這項程序的相關說明，請參閱「設定指標收集」。

關於混合指標名稱和標籤

啟用混合型後，系統會自動填入 Cloud Operations 指標。由混合型建立的評估指標網域名稱前置字串為：

apigee.googleapis.com/

舉例來說，/proxyv2/request_count 指標包含 API Proxy 收到的要求總數。因此，Cloud 作業套件中的指標名稱如下：

apigee.googleapis.com/proxyv2/request_count

Cloud Operations 可讓您根據標籤篩選和分組指標資料。有些標籤是預先定義的，其他則是由混合型服務明確新增。下方的「可用指標」部分會列出所有可用的混合指標，以及專門用於篩選和分組的指標標籤。

查看指標

以下範例說明如何在 Cloud Operations 中查看指標：
  1. 在瀏覽器中開啟 Monitoring Metrics Explorer。或者，如果您已在 Cloud Operations 控制台中，請選取「Metrics Explorer」。

  2. 在「Find resource type and metric」(尋找資源類型和指標) 中，找出並選取要檢查的指標。選擇「可用指標」中列出的特定指標，或搜尋指標。

  3. 選取所需指標。
  4. 套用篩選器。每個指標的篩選器選項會列在「可用指標」中。
  5. Cloud Operations 會顯示所選指標的圖表。
  6. 按一下 [儲存]。

建立資訊主頁

資訊主頁是檢視並分析重要指標資料的方法之一，Cloud 作業套件會針對您使用的資源和服務提供預先定義的資訊主頁，您也可以建立自訂資訊主頁。

您可以使用圖表在自訂資訊主頁中顯示 Apigee 指標。您可以透過自訂資訊主頁，完全控管要顯示的圖表及其設定。如要進一步瞭解如何建立圖表，請參閱「建立圖表」一文。

以下範例說明如何在 Cloud Operations 中建立資訊主頁，然後新增圖表來查看指標資料：

  1. 在瀏覽器中開啟 Monitoring Metrics Explorer，然後選取「Dashboard」。
  2. 選取「+ 建立資訊主頁」。
  3. 為資訊主頁命名。例如：Hybrid Proxy Request Traffic
  4. 按一下「確認」。

  5. 針對要加進資訊主頁的每張圖表，請按照下列步驟操作：

    1. 在資訊主頁中選取「新增圖表」。
    2. 如上文「查看指標」一節所述，選取所需指標。
    3. 完成對話方塊，定義圖表。
    4. 按一下 [儲存]。Cloud Operations 會顯示所選指標的資料。

可用的指標

下表列出用於分析 Proxy 流量的指標。

Proxy、目標和伺服器流量指標

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

 傳送至 Proxy 目標的請求總數。
/targetv2/response_count method

response_code

target_type

target_endpoint

 從 Proxy 目標收到的回應總數。
/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 Epoch 開始算起的毫秒數為單位。

系統會每 60 秒計算一次，但不會即時反映狀態。如果 UDCA 為最新版本，且計算這個指標時沒有檔案等待上傳，則這個值會是 0。

如果這個值持續增加，表示磁碟上仍有舊檔案。
/udca/server/local_file_latest_ts dataset

state

磁碟上最新檔案的時間戳記 (以自 Unix Epoch 紀元時間起算的毫秒數)，依狀態排序。

系統會每 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 外部依附元件的哪個部分發生錯誤，以及原因。

這些錯誤可能會發生在各種服務 (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 資料表的未完成壓縮作業。詳情請參閱「壓縮」一節。
/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 堆積已提交的記憶體用量。