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

本文說明對齊週期和重新測試時間範圍如何決定條件是否符合，以及快訊政策如何合併多個條件，並取代缺少的資料點。本文也說明瞭政策的未解決快訊數量上限、每個快訊的通知數量，以及造成通知延遲的原因。

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

校正週期和重新測試時間

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

校正週期

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

對齊作業包含兩個步驟：

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

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

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

舉例來說，如果對齊週期為五分鐘，則在下午 1:00，對齊週期會包含下午 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 合併值	意義
符合任一條件	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 用量在 1 分鐘內超過 100 毫秒/秒，即符合這項條件。
• 名為 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 成立，系統也會建立快訊。由於 vm1 和 vm2 導致條件 CPU usage is too high 成立，因此系統會建立快訊，這兩個事件是不同的。

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

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

部分指標資料

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

Google Cloud 控制台

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

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

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

  在 Cloud Monitoring API 中，重新測試時間範圍的欄位稱為「duration」。

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

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

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

API

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

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

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

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

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

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

如要盡量減少資料遺失造成的問題，請採取下列任一做法：

• 請與第三方雲端服務供應商聯絡，找出減少指標收集延遲時間的方法。
• 在條件中使用較長的重新測試時間範圍。使用較長的重新測試時間範圍，缺點是會使快訊政策的回應速度較為緩慢。

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

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

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

監控服務傳送通知和建立快訊的時機

當時間序列符合條件時，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 秒內建立警告。詳情請參閱「指標資料的延遲時間」。

下列事件與設定導致了延遲：

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

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

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

後續步驟

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

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

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