Cloud Monitoring 的監控資料模型由三個主要概念構成:
- 受監控資源類型
- 指標類型
- 時間序列
如要瞭解這些 Cloud Monitoring 概念,請參閱指標模型文件。如果您不熟悉這些概念,請先閱讀該頁面。
本頁面將更詳細地說明指標類型、受監控資源和時間序列,以及一些相關概念。這些概念是所有監控指標的基礎。
如果您想執行下列任一操作,請務必瞭解這個頁面的資訊:使用 Metrics Explorer 檢查指標資料。
建立快訊政策,即可在值超出正常範圍時收到通知,詳情請參閱「使用快訊政策」。
使用 Monitoring API 擷取原始或匯總的監控資料,如「擷取時間序列資料」一文所述。
如要建立自己的指標類型,請參閱「使用者定義指標總覽」。
關於標籤
受監控資源類型和指標類型都支援標籤,可在分析期間分類資料。例如:
- 虛擬機器的受監控資源類型可能包含機器位置和與機器相關聯的專案 ID 的標籤。記錄受監控資源的相關資訊時,資訊會包含標籤的值。除了為受監控資源類型定義的標籤外,受監控資源也可能具有系統或使用者提供的中繼資料標籤。
- 計算 API 要求的指標類型可能會有標籤,用於記錄呼叫的方法名稱和要求狀態。
如要進一步瞭解如何使用標籤,請參閱「標籤」一文。
受監控資源類型
「受監控資源」是指系統擷取指標資料的資源。Cloud Monitoring 支援約 270 種受監控資源類型。
受監控的資源類型包括一般節點和工作、Google Kubernetes Engine 中的架構元件、Bigtable 中的資料表、各種 AWS 資源等等。每種受監控資源類型都會在稱為「受監控資源描述元」的資料結構中正式說明。詳情請參閱「受監控資源描述元」。
受監控資源清單中列出所有支援的受監控資源類型。清單中的項目是根據受監控資源描述元建立。本節說明監控資源描述元中擷取的資訊,以及這些資訊在清單中的顯示方式。
受控資源類型範例
下圖顯示 Cloud Storage 值區的清單項目:
清單中的所有項目都包含下列資訊:
- 類型:項目中的標頭會列出受監控的資源類型;
gcs_bucket在這個範例中。 - 顯示名稱:受監控資源的簡短說明。
- 說明:受監控資源的詳細說明。
- 標籤:用於分類資料的一組維度。詳情請參閱「標籤」。
指標類型
「指標類型」是指可從受監控資源收集的測量值。指標類型包括所測量的項目說明,以及如何解讀測量結果。Cloud Monitoring 支援約 6,500 種指標類型,並可讓您定義新的類型。指標類型包括 API 呼叫次數、磁碟使用統計資料、儲存空間用量等等。
每種指標類型都會在稱為指標描述元的資料結構中正式說明。詳情請參閱指標描述元。
每個內建指標類型在「指標清單」頁面中都有一個項目。這些資料表中的項目是根據指標描述元建立。本節說明指標類型中擷取的資訊,並顯示參考資料中的呈現方式。
指標類型範例
下圖顯示 Cloud Storage 指標類型的項目:
指標類型會顯示在表格中,表格標題則會說明資訊的版面配置。本節以一個項目為例,但所有表格都採用相同格式。
Cloud Storage 資料表項目範例提供下列有關一個指標類型的資訊:
指標類型:指標類型的 ID,例如範例中的
storage.googleapis.com/api/request_count。前置字串
storage.googleapis.com可做為 Cloud Storage 的命名空間。與特定受監控資源類型相關聯的所有指標類型,都會使用相同的命名空間。資料表中的項目會省略命名空間。
與 Cloud Storage 相關的所有指標類型都會列在 Cloud Storage 指標表格中。
推出階段:彩色方塊,表示指標類型的推出階段,例如 Alpha、Beta 和 GA。
顯示名稱:簡要說明指標類型的字串,例如「要求數」。
種類、類型、單位:這行提供解讀資料值的資訊。範例顯示以 64 位元整數記錄的差異指標,沒有單位 (即
1值)。受控資源:可使用這個指標類型的受控資源。這裡的值與「受監控資源類型」一文所述相同。
說明:詳細說明記錄內容和方式。 以斜體顯示,與標籤區別。
標籤:用於分類資料的一組維度。詳情請參閱「標籤」。
透過 Cloud Monitoring API 存取監控資料時,請在 API 呼叫中加入 Google Cloud 專案。您只能擷取該 Google Cloud 專案可見的資料。舉例來說,如果您要求專案中 storage.googleapis.com/api/request_count 指標類型的資料,則只會看到專案中 Cloud Storage 值區的 API 計數。如果專案未使用任何 Cloud Storage 值區,系統就不會傳回任何指標資料。
內建指標類型
內建指標類型是由 Google Cloud 服務定義,包括 Cloud Monitoring。這些指標類型說明各種常見基礎架構的標準測量方式,任何人都可使用。
「指標清單」會顯示整組內建指標類型。 「外部指標清單」頁面列出的指標是內建指標的特殊子集,由 Cloud Monitoring 與開放原始碼專案或第三方供應商合作定義。一般來說,這些指標的前置字元為external.googleapis.com。
自訂指標
建構應用程式時,您可能想評估某些屬性,但 Cloud Monitoring 並未內建這些屬性的指標。您可以使用 Cloud Monitoring 定義自己的指標類型,或從外部來源匯入指標類型。這些指標類型稱為自訂指標。如果指標的前置字串為 custom.googleapis.com 或 prometheus.googleapis.com,則為自訂指標。後者通常來自 Google Cloud Managed Service for Prometheus。
舉例來說,如要追蹤商店銷售的小工具數量,就必須使用自訂指標。詳情請參閱「使用者定義指標總覽」。
標籤
標籤是鍵/值組合,可用來提供資料值的相關資訊。
指標和受監控資源標籤
指標和受監控資源類型的定義都包含標籤。標籤是所收集資料的分類器,可協助分類資料,以進行深入分析。例如:
- Cloud Storage 指標類型
storage.googleapis.com/api/request_count有兩個標籤,分別是response_code和method。 - Cloud Storage 監控資源類型
gcs_bucket有三個標籤:project_id、bucket_name和location。標籤會識別資源類型的特定例項。
因此,系統會根據呼叫的方法、呼叫的回應代碼,以及所涉值區的名稱、位置和專案,對從 Cloud Storage 值區收集的 API 要求資料進行分類。標籤組合會因指標或受控資源類型而異;如要瞭解可用的標籤,請參閱「指標清單」和「受控資源清單」頁面。
在計算 API 呼叫次數時,追蹤回應代碼、方法名稱和位置,即可擷取特定 API 方法的呼叫次數、任何方法的失敗呼叫次數,或特定位置中特定方法的失敗呼叫次數。
標籤數量和每個標籤可假設的值數量稱為基數。基數是指一組指標和受監控資源類型可能收集的時間序列數量,每個標籤值組合都會產生一個時間序列。詳情請參閱「基數:時間序列和標籤」。
資源中繼資料標籤
除了指標和受監控資源類型中定義的標籤,Monitoring 內部也會收集受監控資源的其他資訊,並將這些資訊儲存在系統中繼資料標籤中。使用者只能以唯讀值形式查看這些系統中繼資料標籤。 此外,使用者在 Google Cloud 控制台中設定 VM 執行個體等資源時,也可以建立自己的資源中繼資料標籤。
系統和使用者中繼資料標籤統稱為「資源中繼資料標籤」。您可以在時間序列篩選器中使用這些標籤,就像使用指標和受監控資源類型中定義的標籤一樣。
只有明確依資源中繼資料標籤彙整時,查詢結果才會顯示這些標籤。
如要進一步瞭解篩選功能,請參閱「監控篩選器」。
時間序列:受控資源的資料
本節將說明監控資料的內容,以及如何以時間序列的形式整理資料。指標模型的概念元件會在此成為具體構件。
Cloud Monitoring 會儲存指標和受監控資源類型配對的定期測量結果。系統會將測量結果收集到時間序列中,每個時間序列包含下列項目:
時間序列所屬的指標類型名稱,以及指標標籤的一組值。
一系列 (timestamp, value) 配對。值是測量結果,時間戳記則是測量時間。
做為時間序列資料來源的受監控資源,以及資源標籤的一組值。
系統會為每個產生資料的指標和資源標籤組合建立時間序列。
樣式化範例:指標類型 storage.googleapis.com/api/request_count 可能會為專案的 Cloud Storage 值區提供許多時間序列。下表顯示一些可能的時間序列。
在表格中,bucket: xyz 代表受監控資源類型中 bucket_name 標籤的值,而 response_code 和 method 則是指標類型中的標籤。資源和指標標籤中的每個值組合都有一個時間序列;下表顯示其中一些:
| 受監控 資源標籤 |
指標標籤 | 指標資料 |
|---|---|---|
bucket: 1234 |
response_code: OK, |
{ |
bucket: 1234 |
response_code: OK, |
{ |
bucket: 1234 |
response_code: FAIL, |
{ |
bucket: 9876 |
response_code: OK, |
{ |
Cloud Monitoring 不會記錄「空白」時間序列。在 Cloud Storage 值區範例中,如果您未使用特定值區或從未呼叫特定 API 方法,系統就不會收集該標籤的資料,也不會提及任何時間序列。也就是說,如果專案完全沒有特定指標的資料,您就不會看到該指標類型。
指標類型不會指出指標時間序列中受控資源的類型。Cloud Storage 只有一種受監控資源類型:gcs_bucket。部分指標類型會與多個受監控資源配對。
實際範例:如果您有 Google Cloud 專案,可以試用 Monitoring API 中 timeSeries.list 方法參考頁面上的 APIs Explorer 小工具。
開啟
timeSeries.list參考頁面。在標示為「Try this method」的窗格中,輸入下列內容:
- name:
projects/PROJECT_ID將PROJECT_ID替換為專案 ID。 Google Cloud - filter:
metric.type="logging.googleapis.com/log_entry_count" resource.type="gce_instance" - interval.start_time:輸入開始時間,並確保開始時間比結束時間早 20 分鐘。
- interval.end_time:輸入結束時間。
- name:
如果要求成功,系統會傳回符合要求的時間序列資料。看起來會像下列程式碼片段:
{
"timeSeries": [
{
"metric": {
"labels": {
"severity": "INFO",
"log": "compute.googleapis.com/activity_log"
},
"type": "logging.googleapis.com/log_entry_count"
},
"resource": {
"type": "gce_instance",
"labels": {
"instance_id": "0",
"zone": "us-central1",
"project_id": "your-project-id"
}
},
"metricKind": "DELTA",
"valueType": "INT64",
"points": [
{
"interval": {
"startTime": "2024-03-29T13:53:00Z",
"endTime": "2024-03-29T13:54:00Z"
},
"value": {
"int64Value": "0"
}
},
...
]
},
...
]
}
如要進一步瞭解如何使用 APIs Explorer 小工具,包括如何排解問題,請參閱「APIs Explorer」。
基數:時間序列和標籤
每個時間序列都與一組特定的指標和受監控資源類型相關聯。指標和受監控資源類型都會提供一些標籤。在 Cloud Monitoring 中,一組標籤的唯一值組合數量,就是指標類型或受監控資源類型的基數。這些值稱為「指標基數」和「資源基數」,可決定可能產生多少時間序列,也就是「總基數」。
指標、資源和總基數
假設您有指定兩個標籤的指標類型,
color 和 zone。指標基數取決於這些標籤可能的值數:
- 如果只有三種可能的顏色:「紅」、「綠」和「藍」,則
color標籤最多可以有三個不同的值。 - 如果只有「east」和「west」兩個可能區域,則
zone標籤最多可有兩個不同的值。
這項指標的基數為 6 (3×2)。如果 color 標籤有 1,000 個可能值,且每個顏色都可能出現在每個區域,則指標基數為 2,000 (1,000×2)。如果這些是受控資源類型而非指標類型的標籤,則適用相同的計算方式。
這個基數值是根據可能的標籤值組合數計算出的最大值。如果標籤值的所有組合實際上並未發生,實際有效值可能會大幅降低。舉例來說,如果每個顏色只出現在一個區域,而非兩個區域,則執行中系統中顯示的時間序列數量上限為 1,000 個。不過,有效基數的實用性取決於特定組合未顯示的原因,以及這些組合是否可能在未來顯示。

寫入時間序列資料時,系統會依指標和受監控資源類型分類。對於任何指標和資源類型組合,總基數是指標基數和資源基數的乘積。如果指標的基數為 1,000,資源的基數為 100,且每個標籤值都會顯示,則您會有 100,000 個時間序列 (1,000×100)。
設計專屬指標時,請確保任何標籤的可能值集受到限制。建議使用一小組離散值 (例如「紅色」、「綠色」和「藍色」)。舉例來說,如果您使用 8 位元 RGB 值做為color 標籤,則可使用超過 1,600 萬個不同的值。請勿使用高解析度值做為指標標籤,例如時間戳記、任何類型的專屬 ID、使用者 ID、IP 位址、未參數化的網址等。
查詢效能和基數
發出資料查詢時,查詢效能的最大影響因素是您要求的資料量:一般來說,查詢一小時的資料會比查詢六個月的資料更快。不過,要求傳回的資料量也會受到要求中時間序列數量的影響。如果查詢擷取低基數指標的兩個月資料,速度可能會比擷取高基數指標的兩個月資料快,因為擷取的資料量較少。
基數主要取決於標籤可擁有的值數量,而非標籤數量。一般來說,您無法控管資源的基數,因為 Pod 或 VM 的數量會根據業務需求而異。不過,將指標擷取至 Cloud Monitoring 時,您通常可以控制指標基數,而不是使用系統指標。舉例來說,您可以透過使用者定義的自訂指標,決定標籤和可能的值。如果您要擷取 Prometheus 指標,可以使用重新標籤功能修改標籤集,並捨棄不想擷取的時間序列。
您可以使用 Cloud Monitoring 的「指標管理」頁面,找出可能出現基數問題的指標。如要查看「指標管理」頁面,請按照下列步驟操作:
-
前往 Google Cloud 控制台的 「指標管理」頁面:
如果您是使用搜尋列尋找這個頁面,請選取子標題為「Monitoring」的結果。
- 在工具列中選取時間範圍。根據預設,「指標管理」頁面會顯示前一天收集的指標資訊。
如要進一步瞭解「指標管理」頁面,請參閱「查看及管理指標用量」。
如要瞭解 Cloud Monitoring 儲存及擷取時間序列資料的技術背景,請參閱「Monarch:Google 的全球規模記憶體內時間序列資料庫」。
如要瞭解 Cloud Monitoring 中使用者定義指標的限制,請參閱「使用者定義指標」。