以指標為準的快訊政策行為

Cloud Monitoring 中的指標型警告政策可讓您監控時間序列資料、建立警告及傳送通知。您可以設定對齊週期、重新測試時間範圍和多條件規則，控管警告政策建立警告和傳送通知的時間。瞭解警告政策如何處理遺漏資料、警告和通知的限制，以及通知延遲，有助於減少偽陽性，並調整警告回應速度。

這項內容不適用於以記錄檔為準的警告政策。如要瞭解以記錄為基礎的警告政策，請參閱「監控記錄」。

校正週期和重新測試時間

Cloud Monitoring 會評估對齊週期和重新測試時間範圍，判斷是否符合警告政策的條件。

校正週期

警告政策監控時間序列資料前，必須先將資料正規化，警告政策才能評估間隔規律的資料。正規化程序稱為「校驗」。

對齊作業包含兩個步驟：

• 將時間序列劃分為固定時間間隔，也稱為將資料分組。間隔即為對齊週期。

• 計算校正期間內各點的單一值。您可以選擇如何計算該單一資料點，例如加總所有值、計算平均值或使用最大值。結合資料點的函式稱為「對齊器」。組合結果稱為「對齊值」。

  如要進一步瞭解對齊方式，請參閱「對齊：序列內正規化」。

舉例來說，如果對齊時間間隔為五分鐘，下午 1 點的對齊時間間隔就會包含下午 12:55 到下午 1:00 之間收到的樣本。下午 1:01，對齊時間間隔會滑動一分鐘，並包含下午 12:56 到下午 1:01 之間收到的樣本。

監控功能會依下列方式設定對齊期間：

Google Cloud 控制台

如要設定對齊週期，請在「警告觸發條件」頁面中，為下列欄位選擇值：

• 滾動週期：指定要評估的時間範圍。
• 滾動週期函式：指定要對資料點視窗執行的數學函式。

如要進一步瞭解可用函式，請參閱 API 參考資料中的 Aligner。部分對齊器函式會對齊資料，並將資料從一種指標類型轉換為另一種。如需詳細說明，請參閱「種類、類型和轉換」。

API

如要設定對齊週期，請在 MetricThreshold 和 MetricAbsence 結構體中設定 aggregations.alignmentPeriod 和 aggregations.perSeriesAligner 欄位。

如要進一步瞭解可用函式，請參閱 API 參考資料中的 Aligner。部分對齊器函式會對齊資料，並將資料從一種指標類型轉換為另一種。如需詳細說明，請參閱「種類、類型和轉換」。

為說明對齊週期對快訊政策中條件的影響，請考慮指標門檻條件，該條件會監控取樣週期為一分鐘的指標。假設對齊週期設為五分鐘，且對齊器設為 sum。此外，假設時間序列的對應值大於 2 至少三分鐘時，即符合條件，且每分鐘都會評估條件。在本例中，重測時間範圍 (下一節會說明) 為三分鐘。下圖說明條件的幾個連續評估：

圖中的每一列都說明條件的單一評估結果。系統會顯示時間序列資料。對齊期間的點會以藍點顯示，較舊的點則為黑點。每一列都會顯示對齊的值，以及這個值是否大於門檻值 2。在標示為 start 的資料列中，對齊值計算結果為 1，低於門檻。在下一次評估時，對齊期間的樣本總和為 2。第三次評估時，總和為 3，由於這個值大於門檻，系統會啟動重測時間範圍的計時器。

重新測試週期

警告政策的條件設有重新測試時間範圍，可避免條件因單一測量結果或預測而達成。舉例來說，假設條件的重新測試時間範圍設為 15 分鐘。以下說明條件的行為，具體取決於條件類型：

• 如果單一時間序列中，15 分鐘間隔內的所有對應測量值都違反門檻，即符合指標門檻條件。
• 如果時間序列在 15 分鐘間隔內沒有任何資料送達，即符合指標缺席條件。
• 如果 15 分鐘內的所有預測都指出時間序列會在預測時間範圍內違反門檻，即符合預測條件。

如果政策只有一個條件，當符合該條件時，系統就會開啟快訊並傳送通知。只要條件持續符合，這些快訊就會保持開啟狀態。

Google Cloud 控制台

您可以在「設定警告觸發條件」步驟中，使用「重新測試時間範圍」欄位設定重新測試時間範圍。

API

如要設定重新測試時間範圍，請在 MetricThreshold 和 MetricAbsence 結構中設定名為 duration 的欄位。

上圖說明瞭指標閾值條件的三種評估方式。在 start + 2 minutes 時，對齊值大於門檻；不過，由於重新測試時間間隔設為三分鐘，因此不符合條件。下圖說明條件的後續評估結果：

即使在時間 start + 2 minutes 時，對齊值大於門檻，但對齊值必須大於門檻三分鐘，條件才會成立。該事件發生於時間 start + 5 minutes。

如果評估或預測結果不符合條件，條件就會重設重新測試的時段。因此，請將重新測試時間範圍設為足夠長，以盡量減少偽陽性，但也要夠短，確保系統能及時開啟警報。如以下範例所示：

範例

這項警告政策包含一個指標門檻條件，指定五分鐘的重新測試時間範圍。

如果 HTTP 回應延遲時間超過兩秒，
且延遲時間超過閾值五分鐘，
則開啟快訊並傳送電子郵件給支援團隊。

以下序列說明重新測試時間範圍如何影響條件的評估：

1. HTTP 延遲時間少於兩秒。
2. 接下來連續三分鐘，HTTP 延遲時間超過兩秒。
3. 在下一次測量中，延遲時間少於兩秒，因此條件會重設重新測試視窗。

4. 接下來連續五分鐘，HTTP 延遲時間都超過兩秒，因此符合條件。

   由於警告政策只有一個條件，因此 Monitoring 會在符合條件時傳送通知。

設定比對期和重新測試回溯期的最佳做法

校正週期會決定校正器合併的樣本數量。取樣間隔、擷取延遲和要合併的樣本數會影響對齊週期設定：

• 對齊期間不得超過 24 小時，扣除擷取延遲時間後亦然。

• 建議您將對齊週期設為至少與擷取延遲時間一樣長。不過，對齊週期一律應至少與取樣間隔一樣長。

• 如果是指標門檻條件，對齊週期的典型最大值為 25 小時，減去指標類型的擷取延遲時間。舉例來說，如果指標的擷取延遲時間為 6 小時，則對齊週期的最大值為 19 小時。您可以使用 PromQL，針對超過 25 小時的舊資料發出快訊。詳情請參閱「使用 PromQL 建立警告政策」。

舉例來說，如果某種指標類型的擷取延遲時間為 6 小時，建議您使用 6 到 18 小時的對齊週期。假設取樣間隔為 60 秒。如果將對齊週期設為 6 小時 5 分鐘，對齊器平均會合併 5 個樣本。

如果指標類型有很長的擷取延遲時間 (例如 18 小時)，請將對齊週期設為至少與取樣間隔一樣長，但最多為 24 小時減去擷取延遲時間。

使用重新測試時間範圍指定快訊的反應速度。舉例來說，如果您為指標缺席條件設定 20 分鐘的重新測試時間範圍，則必須在條件符合前 20 分鐘沒有任何資料。如要提高警告政策的回應速度，請將重新測試時間範圍設為較小的值。如果是指標門檻條件，請將重新測試視窗設為零，確保警告政策能及時發揮作用。只要有一個值對齊，就會符合這些類型的條件。

如果您設定重新測試時間範圍，可能需要縮短對齊時間範圍，因為警告政策有相關限制。

系統會以固定頻率評估警告政策條件。您為對齊週期和重新測試時間範圍所做的選擇，不會決定條件的評估頻率。

具有多項條件的政策

警告政策最多可包含 6 個條件。

如果您使用 Cloud Monitoring API，或警告政策有多項條件，則必須指定開啟快訊的時間。如要設定多個條件的組合方式，請執行下列任一操作：

Google Cloud 控制台

您可以在「多條件觸發」步驟中設定合併器選項。

API

您可以使用 AlertPolicy 結構的 combiner 欄位設定合併器選項。

下表列出 Google Cloud 控制台中的設定、Cloud Monitoring API 中的對等值，以及各項設定的說明：

Google Cloud 控制台 政策觸發條件值	Cloud Monitoring API combiner value	意義
符合任一條件	OR	如果任何資源導致符合任一條件，系統就會開啟快訊。
符合所有條件 ，即使各條件的資源不同 也適用 (預設)	AND	當所有條件都符合時，系統會為每個符合的條件開啟快訊，即使是不同資源導致符合這些條件也一樣。
符合所有條件	AND_WITH_MATCHING_RESOURCE	如果所有條件都符合，且相同資源導致每個條件都符合，系統就會為每個符合的條件開啟警報。這是最嚴格的設定組合。
附註：這項警告政策會使用標籤值，找出導致條件成立的資源。如果警告政策使用這個組合器建立警告或產生通知，則必須符合下列條件： 每個條件都必須監控相同的資源。舉例來說，所有條件的資源類型都會設為 gce_instance。 匯總後可用的受監控資源標籤，必須與所有條件相同。舉例來說，針對 gce_instance 資源，標籤為 project_id、instance_id 和 zone。如果一個條件群組依 zone 分組，則所有條件都必須依 zone 分組。 如需受監控資源及其標籤的清單，請參閱「受監控資源類型」。

在此情況下，「符合」表示條件的設定評估結果為「true」。舉例來說，如果設定為 Any time series is greater than 10 for 5 minutes，則當這項陳述式評估結果為 true 時，即符合條件。

範例

假設有一個 Google Cloud 專案包含兩個 VM 執行個體，分別是 vm1 和 vm2。此外，假設您建立的快訊政策有 2 項條件：

• 名為 CPU usage is too high 的條件會監控執行個體的 CPU 使用率。如果任何執行個體的 CPU 用量超過 100 毫秒/秒達 1 分鐘，即符合這項條件。
• 名為 Excessive utilization 的條件會監控執行個體的 CPU 使用率。如果任何執行個體的 CPU 使用率超過 60% 達 1 分鐘，就會符合這項條件。

一開始，請假設這兩個條件的評估結果都是 false。

接著，假設 vm1 的 CPU 使用率超過 100 毫秒/秒達 1 分鐘。由於 CPU 使用率超過門檻一分鐘，因此符合 CPU usage is too high 條件。如果條件與「符合任一條件」合併，系統就會因為符合條件而建立快訊。如果條件與「符合所有條件」或「即使每個條件適用於不同資源，仍符合所有條件」合併，系統就不會建立快訊。如要使用這些合併條件，必須符合所有條件。

接著，假設 vm1 的 CPU 使用量仍大於 100 毫秒/秒，且 vm2 的 CPU 使用率超過 60% 達 1 分鐘。結果是兩個條件都符合。以下說明條件組合方式不同時，會發生什麼情況：

• 符合任一條件：資源導致符合條件時，系統會建立快訊。在本範例中，vm2 會導致符合 Excessive utilization 條件。

  如果 vm2 導致條件 CPU usage is too high 成立，系統也會建立快訊。由於造成條件 CPU usage is too high 成立的 vm1 和 vm2 是不同的事件，因此系統會建立快訊。

• 即使每個條件的資源不同，所有條件都符合： 由於兩個條件都符合，因此系統會建立快訊。

• 符合所有條件：系統不會建立快訊，因為這個組合器要求所有條件都由同一資源觸發。在本例中，由於 vm1 導致 CPU usage is too high 達到上限，而 vm2 導致 Excessive utilization 達到上限，因此系統不會建立任何警示。

部分指標資料

如果時間序列資料停止傳送或延遲傳送，監控服務會將資料歸類為「遺失」。如果缺少資料，系統就無法關閉快訊。 從第三方雲端服務供應商傳輸資料時，延遲時間最多可能達 30 分鐘，最常見的延遲時間為 5 到 15 分鐘。如果延遲時間過長 (超過重新測試時間範圍)，條件可能會進入「不明」狀態。資料最終抵達時，監控服務可能已遺失部分近期條件記錄。稍後檢查時間序列資料時，可能不會發現這個問題，因為資料抵達後就沒有延遲的證據。

Google Cloud 控制台

您可以設定監控服務在資料停止傳送時，如何評估指標閾值條件。舉例來說，如果警報開啟後，預期測量結果未送達，您希望 Monitoring 讓警報保持開啟，還是立即關閉？同樣地，如果資料停止傳送且沒有開啟任何快訊，您是否希望系統開啟快訊？最後，資料停止傳送後，快訊應保持開啟多久？

有兩個可設定的欄位，用於指定資料停止傳送時，監控服務如何評估指標閾值條件：

• 如要設定 Monitoring 判斷缺少的資料替代值，請使用「條件觸發程序」步驟中設定的「評估缺少的資料」欄位。如果將重新測試時間範圍設為「不重新測試」，這個欄位就會停用。

  重測時間範圍是 Cloud Monitoring API 中稱為「duration」的欄位。

• 如要設定監控服務在資料停止傳送後，等待多久才關閉開啟的快訊，請使用「快訊自動關閉期限」欄位。您可以在「通知」步驟中設定自動關閉時間長度。預設的自動關閉時間為七天。

以下說明缺少資料欄位的不同選項：

Google Cloud 控制台 「評估缺少資料」欄位	摘要	詳細資料
缺少資料空白	未解決的警告仍會保持開啟。 系統不會開啟新的 Google 快訊。	如果條件符合，即使資料停止傳送，條件仍會繼續符合。如果這項條件的快訊處於開啟狀態，快訊就會維持開啟狀態。如果開啟快訊後沒有收到任何資料，系統會在至少延遲 15 分鐘後啟動自動關閉計時器。如果計時器到期，系統就會關閉快訊。 如果條件未達成，當資料停止傳送時，條件仍會處於未達成狀態。
缺少資料點會視為違反政策條件的值	未解決的警告仍會保持開啟。 可以開啟新的 Google 快訊。	如果條件符合，即使資料停止傳送，條件仍會繼續符合。如果這項條件的快訊處於開啟狀態，快訊就會維持開啟狀態。如果開啟的快訊在自動關閉時間加上 24 小時內沒有收到任何資料，系統就會關閉快訊。 如果未符合條件，這項設定會導致指標門檻條件的行為類似於 metric-absence condition。如果資料未在重新測試時間範圍內送達，系統就會評估為符合條件。如果警告政策只有一個條件，只要符合該條件，就會開啟警告。
缺少資料點會視為未違反政策條件的值	未解決的警告已關閉。 系統不會開啟新的 Google 快訊。	如果符合條件，但資料停止傳送，條件就會不再符合。如果這項情況有未解決的警示，系統就會關閉警示。 如果條件未達成，當資料停止傳送時，條件仍會處於未達成狀態。

API

您可以設定監控服務在資料停止傳送時，如何評估指標閾值條件。舉例來說，如果警報開啟後，預期測量結果未送達，您希望 Monitoring 讓警報保持開啟，還是立即關閉？同樣地，如果資料停止傳送且沒有開啟任何快訊，您是否希望系統開啟快訊？最後，資料停止傳送後，快訊應保持開啟多久？

有兩個可設定的欄位，用於指定資料停止傳送時，監控服務如何評估指標閾值條件：

• 如要設定 Monitoring 判斷缺少的資料替代值的方式，請使用 MetricThreshold 結構的 evaluationMissingData 欄位。如果 duration 欄位為零，系統會忽略這個欄位。

• 如要設定監控功能在資料停止傳送後，等待多久才關閉開啟的快訊，請使用 AlertStrategy 結構中的 autoClose 欄位。

以下說明缺少資料欄位的不同選項：

API evaluationMissingData 欄位	摘要	詳細資料
EVALUATION_MISSING_DATA_UNSPECIFIED	未解決的警告仍會保持開啟。 系統不會開啟新的快訊。	如果條件符合，即使資料停止傳送，條件仍會繼續符合。如果這項條件的快訊處於開啟狀態，快訊就會保持開啟狀態。如果開啟快訊後沒有收到任何資料，自動關閉計時器會在延遲至少 15 分鐘後啟動。如果計時器到期，系統就會關閉警報。 如果條件未達成，當資料停止傳送時，條件仍會處於未達成狀態。
EVALUATION_MISSING_DATA_ACTIVE	未解決的警告仍會保持開啟。 開啟新的 Google 快訊。	如果條件符合，即使資料停止傳送，條件仍會繼續符合。如果這項條件的快訊處於開啟狀態，快訊就會保持開啟狀態。如果警報開啟後，在自動關閉時間加上 24 小時內沒有收到任何資料，系統就會關閉警報。 如果未符合條件，這項設定會導致指標門檻條件的行為類似於 metric-absence condition。如果資料未在 `duration` 欄位指定的時間內送達，系統就會評估為符合條件。如果警告政策只有一個條件，只要符合該條件，就會開啟警告。
EVALUATION_MISSING_DATA_INACTIVE	未解決的警告已關閉。 系統不會開啟新的快訊。	如果符合條件，但資料停止傳送，條件就會不再符合。如果這項條件的警報處於開啟狀態，系統就會關閉警報。 如果條件未達成，當資料停止傳送時，條件仍會處於未達成狀態。

您可以採取下列任一做法，盡量減少資料遺失造成的問題：

• 請與第三方雲端服務供應商聯絡，瞭解如何縮短指標收集延遲時間。
• 在條件中設定較長重新測試時間範圍。使用較長重新測試時間範圍的缺點是，這會導致警告政策的反應較慢。

• 選擇收集延遲時間較短的指標：

  • 監控代理程式指標，特別是代理程式在第三方雲端服務的 VM 執行個體中執行時。
  • 自訂指標，直接將資料寫入監控服務。
  • 記錄指標 (如果記錄項目的收集作業未延遲)。

詳情請參閱「Ops Agent 總覽」、「使用者定義的指標總覽」和「記錄指標」。

Monitoring 傳送通知和建立快訊的時機

當時間序列符合條件時，Cloud Monitoring 會傳送通知。通知會傳送至所有通知管道。你無法將通知限制在特定管道，或政策管道的子集。

如果設定重複通知，系統會將相同的通知重新傳送至警告政策的特定通知管道。

如果符合下列任一情況，您可能會收到多則與單一警告政策相關的通知：

• 條件正在監控多個時間序列。

• 政策包含多項條件。在這種情況下，您收到的通知取決於警告政策多重條件觸發的價值：

  • 符合所有條件：符合所有條件時，警告政策會針對每個符合條件的時間序列傳送通知並建立快訊。

    如果警告政策包含多項條件，您無法設定 Cloud Monitoring 只建立一項警告，且只傳送一則通知。

  • 符合任何條件：當時間序列符合條件時，警告政策會傳送通知。

  詳情請參閱「具有多項條件的政策」。

使用 Cloud Monitoring API 建立的警告政策，也會在符合條件和不再符合條件時通知您。如果您是透過 Google Cloud 控制台建立警告政策，系統只會在事件產生時傳送通知。如要讓系統在條件不再符合時傳送通知，請啟用這項功能。

Monitoring 未傳送通知或建立快訊

在下列情況下，當符合警告政策的條件時，Monitoring 不會建立警告或傳送通知：

• 警告政策已停用。
• 警告政策已延後。
• 監控功能已達未解決快訊數量上限。

已停用的警告政策

如果警告政策已停用，監控服務就不會建立警告或傳送通知。不過，即使停用警告政策，監控功能仍會繼續評估政策條件。

啟用已停用的政策後，監控功能會評估最近一次重新測試時間範圍內所有條件的值。最近一次的重新測試期間可能包含啟用政策前、啟用期間和啟用後的資料。即使重新測試的間隔時間很長，停用政策的條件也可能在政策恢復後立即符合。

舉例來說，假設您有監控特定程序的警告政策，並停用這項政策。下週，該程序會停止運作，但由於警告政策已停用，您不會收到通知。如果您重新啟動程序並立即啟用警告政策，Monitoring 會發現程序在過去五分鐘內未啟動，並開啟警告。

停用警告政策後，相關警告仍會保持開啟狀態，直到政策的自動關閉時間到期為止。

已延後的警告政策

如果警告政策暫緩，Monitoring 就不會傳送通知或建立警告。如果只想在短時間內避免警告政策傳送通知，建議暫緩警告政策。舉例來說，您可以在對虛擬機器 (VM) 執行維護作業前建立暫緩通知，並將監控執行個體的警告政策新增至暫緩通知條件。

延後警告政策時，Monitoring 會關閉與該政策相關的所有未解決警告。監控服務可能會在暫緩期限過後開啟新快訊。詳情請參閱「暫緩接收通知和快訊」。

通知和未解決警示的限制

警告政策可套用至多項資源，如果問題影響所有資源，警告政策就會為每項資源開啟警告。系統會為每個符合條件的時間序列開啟快訊。

為避免系統負載過重，單一政策可同時開啟的快訊數量上限為 1,000 則。

舉例來說，假設某項政策適用於 2000 個 Compute Engine 執行個體，且每個執行個體都符合警告觸發條件。監控功能最多只能顯示 1,000 個未解決的警告。在該政策的未解決警告關閉前，系統會忽略任何符合條件的剩餘條件。

因此，單一通知管道一次最多只能接收 1,000 則通知。如果警報政策有多個通知管道，則這項限制會分別套用至每個通知管道。

注意： 如果警告政策有未解決的警告，且觸發警告的時間序列再次超過條件門檻，系統不會開啟其他警告。Cloud Monitoring 只會為警告政策中的每個時間序列保留一則未解決的警告。

延遲時間

延遲是指「監控」取樣指標的時間，與指標資料點顯示為時間序列資料的時間之間的時間差。延遲會影響通知的傳送時間。舉例來說，如果受監控指標的延遲時間最長為 180 秒，則在警告政策條件評估結果為 true 後，監控功能最多會延遲 180 秒才建立警告。詳情請參閱「指標資料的延遲時間」。

下列事件和設定會導致延遲：

• 指標收集延遲：監控服務收集指標值所需的時間。就 Google Cloud 值而言，大多數指標在收集後 60 秒內不會顯示；不過，延遲時間取決於指標。警告政策的計算作業最多會延遲 5 分 30 秒。如果是 AWS CloudWatch 指標，顯示延遲時間可能長達數分鐘。如果是正常運作時間檢查，這可能是兩分鐘的平均值 (從重新測試時間範圍結束時算起)。

• 重新測試週期：為條件設定的週期。 只有在重新測試期間條件皆為 true 時，條件才會成立。舉例來說，如果將重新測試時間間隔設為五分鐘，系統會在事件首次發生後至少五分鐘，才會傳送通知。

• 通知送達時間：電子郵件和簡訊等通知管道可能會發生網路或其他延遲 (與傳送內容無關)，有時甚至會延遲數分鐘。在某些管道 (例如簡訊和 Slack)，我們無法保證訊息一定會送達。

後續步驟

• 如要瞭解如何建立警告政策，請參閱下列文件：

  • 建立指標門檻警告政策
  • 建立指標缺席警告政策
  • 建立預測指標值警告政策
  • 使用 Monitoring API 建立警告政策

• 如需各種快訊政策，請參閱「範例政策」。