本頁面由 Cloud Translation API 翻譯而成。

為事件加上標籤

本文說明如何為事件加上使用者定義的標籤，藉此整理事件並排定優先順序。這些標籤是在快訊政策中設定，並列於快訊政策和事件中。視設定而定，標籤也會顯示在特定通知中。

關於標籤

標籤是鍵/值組合，可用於將資訊附加至時間序列、快訊政策、事件或通知。舉例來說，時間序列的標籤可能會指出收集資料的特定虛擬機器 (VM) 執行個體。標籤可以是使用者定義或預先定義。

使用者定義的標籤

使用者定義的標籤包含您指定的資訊。這些標籤可以有靜態或動態值：

靜態使用者定義標籤的值無法變更。使用 Google Cloud 控制台或 Cloud Monitoring API 設定快訊政策時，您可以建立靜態使用者定義標籤。如需詳細資訊，請參閱下列文件：
- 建立指標閾值快訊政策。
- 透過 API 建立快訊政策。
動態使用者定義標籤的值可能會根據時間序列資料的值而變更。使用 PromQL 設定快訊政策的條件時，可以建立動態使用者定義標籤。如需範例，請參閱「範例：新增含有動態值的自訂標籤」。

標籤鍵開頭必須為小寫字母。標籤鍵和標籤值只能包含小寫字母、數字、底線和破折號。

預先定義的標籤

資源描述元中包含預先定義的標籤，寫入時間序列資料時必須填入這些標籤。這些標籤會顯示所收集指標的相關資訊，或是指標寫入的資源。舉例來說，時間序列的標籤可能會識別虛擬機器 (VM)、區域、 Google Cloud 專案和裝置類型。當 Monitoring 根據該時間序列建立事件時，事件會沿用這些標籤。

App Hub 標籤

App Hub 會將標籤附加至應用程式及其服務和工作負載產生的記錄、指標和追蹤資料。這些標籤可讓基礎架構建立 Google Cloud 應用程式、服務和工作負載資訊主頁，顯示指標和記錄資料。詳情請參閱下列文件：

Google Cloud 控制台：將快訊政策與 App Hub 應用程式建立關聯。
Cloud Monitoring API：將快訊政策與 App Hub 應用程式建立關聯。

如何查看標籤

您可以在事件詳細資料頁面、快訊政策詳細資料頁面，以及部分通知中，查看快訊政策或事件的標籤。

快訊政策：使用者定義的靜態標籤會列在「使用者標籤」部分。動態使用者定義標籤和預先定義標籤不會顯示。
事件：靜態使用者定義標籤會列在「政策標籤」部分，動態使用者定義標籤則會列在「指標標籤」部分。預先定義的標籤會列在「受監控資源標籤」和「指標標籤」部分。
通知：預先定義的標籤和使用者定義的標籤會列在下列通知類型中：
- 電子郵件
- Google Chat
- PagerDuty
- Pub/Sub
- Webhook

範例：新增含有動態值的使用者定義標籤

您可以使用 PromQL 設定標籤，根據時間序列資料動態變更標籤值。舉例來說，您希望事件具有 criticality 標籤，其值會根據監控的 CPU 使用率指標值而變更：

  label_replace(
    avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.9,
    "criticality", "CRITICAL", "", ""
  )
or ignoring (criticality)
  label_replace(
    avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.8,
    "criticality", "WARNING", "", ""
  )
or ignoring (criticality)
  label_replace(
    avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.7,
    "criticality", "INFO", "", ""
  )
or ignoring (criticality)
  label_replace(
    avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]),
    "criticality", "GOOD", "", ""
  )

下圖說明使用 PromQL 查詢的快訊政策如何處理監控的時間序列資料：

插圖：快訊政策如何處理監控的時間序列。

政策處理常式會處理 CPU 使用率資料，並輸出時間序列，指出何時符合條件。在先前的範例中，CPU 使用率至少達到 70% 時，即符合條件。對於每個輸入時間序列，政策處理常式可以產生下列四個時間序列之一：

輸出時間序列名稱	符合條件	說明
「GOOD」	否	這個時間序列與輸入時間序列的標籤相同。沒有嚴重程度標籤。
「CRITICAL」	是	CPU 使用率至少為 90%。輸出時間序列的標籤與「良好」時間序列相同，但多了一個值為「重大」的嚴重程度標籤。
「WARNING」	是	CPU 使用率至少為 80%，但低於 90%。輸出時間序列的標籤與「良好」時間序列相同，但嚴重程度標籤的值為「警告」。
「INFO」	是	CPU 使用率至少為 70%，但低於 80%。輸出時間序列的標籤與「良好」時間序列相同，但多了一個值為「INFO」的嚴重程度標籤。

政策處理常式產生的時間序列資料會輸入事件管理員，後者會決定事件的建立和關閉時間。事件管理員會使用 duration、evaluationMissingData 和 autoClose 欄位的值，判斷何時應關閉事件。

最佳做法

如要驗證建立標籤時，一次最多只能開啟一個事件 (標籤值是動態設定)，請執行下列操作：

在 MetricThreshold 物件中，覆寫下列欄位的預設值：
- duration 欄位：設為非零值。
- evaluationMissingData 欄位：設定為在資料停止傳送時關閉事件。使用 Cloud Monitoring API 時，請將這個欄位設為 EVALUATION_MISSING_DATA_INACTIVE。使用 Google Cloud 控制台時，請將欄位設為「Missing data points treated as values that don't violate the policy condition」(將缺少資料點視為不違反政策條件的值)。
在 AlertStrategy 物件中，將 autoClose 欄位設為最小值 30 分鐘。使用 Cloud Monitoring API 時，請將這個欄位設為 30m。

詳情請參閱「部分指標資料」。

事件流程

假設建立快訊政策時，CPU 使用率測量值低於 70%。以下順序說明事件的開啟和關閉方式：

由於 CPU 使用率測量結果低於 70%，政策處理常式會產生「良好」時間序列，且不會開啟任何事件。
接著，假設 CPU 使用率升至 93%。政策處理常式會停止產生「良好」時間序列資料，並開始產生「嚴重」時間序列的資料。

事件管理員會看到符合條件的新「重大」時間序列，然後開啟事件。通知包含嚴重程度標籤，值為 CRITICAL。
假設 CPU 使用率降至 75%。政策處理常式會停止產生「重大」時間序列，並開始產生「資訊」時間序列。

事件管理員會看到符合條件的新「INFO」時間序列，然後開啟事件。通知會包含嚴重程度標籤，值為 INFO。

事件管理員發現「重大」時間序列沒有任何資料傳入，且該時間序列的事件處於開啟狀態。由於政策設定為在資料停止傳送時關閉事件，事件管理員會關閉與「重大」時間序列相關聯的事件。因此，只有嚴重程度標籤值為 INFO 的事件會保持開啟狀態。
最後，假設 CPU 使用率降至 45%。這個值低於所有門檻，因此政策處理常式會停止產生「INFO」時間序列，並開始產生「GOOD」時間序列。

事件管理員發現「INFO」時間序列沒有任何資料傳送，且該時間序列的事件已開啟。由於政策使用建議設定，因此事件已結案。

如果沒有為 evaluationMissingData 欄位使用建議值，資料停止傳送時，系統不會立即關閉未結案件。因此，您可能會看到多個針對相同輸入時間序列開啟的事件。詳情請參閱「部分指標資料」。