Cloud Monitoring 中的使用者定義指標 (也稱為「自訂指標」) 可讓您擷取內建 Google Cloud 指標未收集的應用程式專屬或用戶端遙測資料。舉例來說，您可以記錄應用程式產生的背景常式數量，然後像內建指標一樣，以圖表呈現、讀取及設定這些指標的快訊。
收集及讀取使用者定義指標的方法
如要檢測程式碼並收集使用者定義的指標，建議使用 OpenTelemetry，但您也可以直接使用 Prometheus 或 Cloud Monitoring API。如要從記錄項目衍生指標，請改為在 Cloud Logging 中建立記錄指標。您可以在 Google Cloud 控制台的「Metrics Management」(指標管理) 頁面中，監控指標擷取作業。
如要瞭解如何建立使用者定義的指標，請參閱下列文件：
收集 OTLP 指標和追蹤記錄說明如何使用 Ops Agent 和代理程式的 OpenTelemetry Protocol (OTLP) 接收器，從使用 OpenTelemetry 檢測並在 Compute Engine 上執行的應用程式收集指標和追蹤記錄。
Google Cloud Managed Service for Prometheus 說明如何從 Google Kubernetes Engine 和 Kubernetes 上執行的應用程式收集 Prometheus 指標。
收集 Prometheus 指標：說明如何使用 Ops Agent，從 Compute Engine 上執行的應用程式收集 Prometheus 指標。
使用 API 建立使用者定義的指標：說明如何使用 Cloud Monitoring API 建立指標，以及如何將指標資料新增至這些指標。本文說明如何使用 Monitoring API，並提供 APIs Explorer、C#、Go、Java、Node.js、PHP、Python 和 Ruby 程式設計語言的範例。
在 Cloud Run 建立自訂指標：說明如何在 Cloud Run 部署作業中，將 OpenTelemetry Collector 做為補充資訊代理程式使用。
就 Cloud Monitoring 而言，您可以使用使用者定義的指標，例如內建指標。您可以繪製圖表、設定快訊、讀取及監控這些指標。如要瞭解如何讀取指標資料，請參閱下列文件：
- 列出指標和資源類型：說明如何列出及檢查使用者定義和內建指標類型。舉例來說，您可以使用該文件中的資訊，列出專案中所有使用者定義的指標描述元。
- 擷取時間序列資料說明如何使用 Monitoring API 從指標擷取時間序列資料。舉例來說，本文說明如何使用 API 取得 Google Cloud 專案中虛擬機器 (VM) 執行個體的 CPU 使用率。
使用者定義指標的指標描述元
每種指標類型都必須有指標描述元，定義指標資料的組織方式。指標描述元也會定義指標的標籤和名稱。例如，指標清單會顯示所有內建指標類型的指標描述元。
Cloud Monitoring 可以使用您寫入的指標資料，為您建立指標描述元，您也可以明確建立指標描述元，然後寫入指標資料。無論是哪種情況，您都必須決定如何整理指標資料。
設計範例
假設您有一個在單一機器上執行的程式，且該程式會呼叫輔助程式 A 和 B。您想計算程式 A 和 B 的呼叫頻率。您也想知道程式 A 每分鐘呼叫超過 10 次，以及程式 B 每分鐘呼叫超過 5 次的時間。最後，假設您有一個 Google Cloud 專案，並打算將資料寫入global受監控資源。
以下範例說明幾種可用於使用者定義指標的不同設計：
您會使用兩項指標：
Metric-type-A會計算對程式A的呼叫，而Metric-type-B會計算對程式B的呼叫。在本例中，Metric-type-A包含 1 個時間序列，Metric-type-B包含 1 個時間序列。您可以建立單一警告政策，並設定兩個條件，也可以建立兩個警告政策，每個政策各設定一個條件。警告政策可支援多個條件，但通知管道只有一項設定。
如果您對受監控活動之間的資料相似度不感興趣，這個模型可能適合您。在本例中，活動是指對程式
A和B的呼叫率。您可以使用單一指標，並使用標籤儲存程式 ID。舉例來說，標籤可能會儲存
A或B值。Monitoring 會為每個不重複的標籤組合建立時間序列。因此，會有一個標籤值為A的時間序列，以及另一個標籤值為B的時間序列。與前一個模型相同，您可以建立單一警告政策或兩項警告政策。不過，警告政策的條件較為複雜。如果要在程式
A的呼叫率超過門檻時產生快訊，條件必須使用篩選器，只納入標籤值為A的資料點。這個模式的優點是容易計算比率。舉例來說，您可以判斷總費用中有多少是撥打
A的費用。您使用單一指標計算呼叫次數，但未使用標籤記錄呼叫的程式。在這個模型中，有一個時間序列結合了兩個程式的資料。不過，由於這兩項程式的資料無法區分，因此您無法建立符合目標的警告政策。
前兩種設計可滿足資料分析需求，但最後一種設計則無法。
詳情請參閱「建立使用者定義指標」。
使用者定義指標的名稱
建立使用者定義指標時，您會定義代表指標類型的字串 ID。這個字串在Google Cloud 專案的使用者定義指標中不得重複，且必須使用前置字元，將指標標示為使用者定義指標。如果是 Monitoring，允許的前置字串為 custom.googleapis.com/、workload.googleapis.com/、external.googleapis.com/user 和 external.googleapis.com/prometheus。前置字元後面會加上名稱，說明您收集的內容。如要進一步瞭解建議的指標命名方式，請參閱「指標命名慣例」。以下是指標類型的兩種 ID 範例：
custom.googleapis.com/cpu_utilization
custom.googleapis.com/instance/cpu/utilization
在上述範例中，前置字串 custom.googleapis.com 表示這兩項指標都是使用者定義的指標。這兩個範例都是用於評估 CPU 使用率的指標，但採用不同的組織模型。如果您預期會有大量使用者定義指標，建議您使用階層式命名結構，例如第二個範例。
所有指標類型都有全域專屬 ID，稱為「資源名稱」。指標類型的資源名稱結構如下：
projects/PROJECT_ID/metricDescriptors/METRIC_TYPE
其中 METRIC_TYPE 是指標類型的字串 ID。如果先前的指標範例是在專案 my-project-id 中建立，則這些指標的資源名稱如下：
projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization
名稱或類型？在指標描述元中，name 欄位會儲存指標類型的資源名稱，type 欄位則會儲存 METRIC_TYPE 字串。
使用者定義指標的受監控資源類型
將資料寫入時間序列時，必須指明資料來源。如要指定資料來源，請選擇代表資料來源的受監控資源類型，然後使用該類型描述特定來源。受監控資源不屬於指標類型。相反地，您寫入資料的時間序列會包含指標類型和受監控資源的參照。指標類型會說明資料，而受監控資源則會說明資料來源。
建立指標描述元前，請先考量受監控資源。您使用的受監控資源類型會影響指標描述元中需要包含的標籤。舉例來說，Compute Engine VM 資源包含專案 ID、執行個體 ID 和執行個體可用區的標籤。因此，如果您打算針對 Compute Engine VM 資源寫入指標，資源標籤會包含執行個體 ID，因此指標描述元中不需要執行個體 ID 的標籤。
指標的每個資料點都必須與受監控資源物件建立關聯。來自不同受監控資源物件的資料點會保留在不同的時間序列中。
您必須搭配使用者定義指標，使用下列其中一種受監控資源類型：
aws_ec2_instance：Amazon EC2 執行個體。dataflow_job：Dataflow 工作。gae_instance：App Engine 執行個體。gce_instance：Compute Engine 執行個體。generic_node：使用者指定的運算節點。generic_task：使用者定義的工作。gke_container：GKE 容器執行個體。global：如果沒有其他適合的資源類型，請使用這項資源。在多數情況下，generic_node或generic_task是比global更好的選擇。k8s_cluster：Kubernetes 叢集。k8s_container：Kubernetes 容器。k8s_node：Kubernetes 節點。k8s_pod：Kubernetes Pod。
常見的做法是使用受監控資源物件，代表執行應用程式程式碼的實體資源。這種做法有幾項優點：
- 相較於使用單一資源類型，您會獲得更好的效能。
- 您可以避免因將多個程序寫入相同時間序列而導致資料變得雜亂無章。
- 您可以將使用者定義指標資料與來自相同資源的其他指標資料分組。
global和一般資源
如果沒有更具體的資源類型適用，generic_task 和 generic_node 資源類型就派得上用場。generic_task 類型適合用於定義應用程式等工作類資源。generic_node 類型適合用於定義虛擬機器等節點式資源。這兩種 generic_* 類型都有多個通用標籤，可用來定義不重複的資源物件，方便您在指標篩選器中使用這些標籤，進行匯總和縮減。
相較之下，global 資源類型只有 project_id 標籤。如果專案中有多個指標來源，使用相同的 global 資源物件可能會導致指標資料發生衝突及遭到覆寫。
支援使用者定義指標的 API 方法
下表列出 Monitoring API 中哪些方法支援使用者定義的指標，哪些方法支援內建指標：
| Monitoring API 方法 | 與 使用者定義指標搭配使用 |
搭配 內建指標使用 |
|---|---|---|
| monitoredResourceDescriptors.get | 是的 | 是的 |
| monitoredResourceDescriptors.list | 是的 | 是的 |
| metricDescriptors.get | 是的 | 是的 |
| metricDescriptors.list | 是的 | 是的 |
| timeSeries.list | 是的 | 是的 |
| timeSeries.create | 是的 | |
| metricDescriptors.create | 是的 | |
| metricDescriptors.delete | 是的 |
限制與延遲時間
如要瞭解使用者定義指標和資料保留的相關限制，請參閱「配額與限制」。
如要在保留期限過後繼續保留指標資料，您必須手動將資料複製到其他位置，例如 Cloud Storage 或 BigQuery。
如要瞭解將資料寫入使用者定義指標的相關延遲時間，請參閱「指標資料的延遲時間」。
後續步驟
- 使用 Google Cloud Managed Service for Prometheus，從 Google Kubernetes Engine 和 Kubernetes 上執行的應用程式收集 Prometheus 指標。
- 從 Compute Engine 上執行的應用程式收集 Prometheus 指標。
- 從使用 OpenTelemetry 檢測並在 Compute Engine 上執行的應用程式收集 OTLP 指標和追蹤記錄。
- 使用 API 建立使用者定義指標
- Cloud Monitoring API 簡介
- 指標、時間序列和資源