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

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

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

對齊週期和重測時間範圍

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 就會傳送通知。

請將重新測試時間範圍設得夠長，以盡量減少誤判，但也要夠短，才能確保適時開啟事件。

設定對齊週期和重新測試時間範圍的最佳做法

校正週期會決定校正器合併的樣本數：

• 指標類型的對齊週期最小值，是該指標類型的取樣週期。舉例來說，如果指標類型是每 300 秒取樣一次，則對齊週期應至少為 300 秒。不過，如要合併 5 個樣本，請將對齊週期設為 5 * 300 秒或 1500 秒。

• 對齊週期的最大值為 24 小時，減去指標類型的擷取延遲時間。舉例來說，如果指標的擷取延遲時間為 6 小時，則對齊週期的最大值為 18 小時。

使用重新測試時間範圍指定快訊的反應速度。舉例來說，如果您為指標不存在條件設定 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 用量在 1 分鐘內超過 100 毫秒/秒，即符合這項條件。
• 名為 Excessive utilization 的條件會監控執行個體的 CPU 使用率。如果任何執行個體的 CPU 使用率超過 60% 達 1 分鐘，就會符合這項條件。

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

接著，假設 vm1 的 CPU 使用量在 1 分鐘內超過 100 毫秒/秒。由於 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 讓事件保持開啟狀態，還是立即關閉？同樣地，如果資料停止傳送，且沒有任何未解決的事件，您是否要開啟事件？最後，資料停止傳送後，事件應保持開啟多久？

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

• 如要設定 Monitoring 判斷遺漏資料替代值的方式，請使用「Evaluation of missing data」(評估遺漏資料) 欄位，該欄位是在「Condition trigger」(條件觸發條件) 步驟中設定。如果將「重新測試時間範圍」設為「不重新測試」，系統就會停用這個欄位。

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

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

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

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

API

您可以設定資料停止傳送時，Monitoring 評估指標閾值條件的方式。舉例來說，如果事件開啟後未收到預期測量結果，您希望 Monitoring 讓事件保持開啟狀態，還是立即關閉？同樣地，如果資料停止傳送，且沒有任何未解決的事件，您是否要開啟事件？最後，資料停止傳送後，事件應保持開啟多久？

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

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

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

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

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

您可以執行下列任何作業，將資料遺失造成的問題降到最低：

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

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

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

詳情請參閱「監控代理程式總覽」、「使用者定義指標總覽」和「記錄指標」。

Monitoring 傳送通知和建立事件的時機

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

如果設定重複通知，系統會將同一則通知重新傳送至快訊政策的特定通知管道。

如果發生下列任何情況，您可能會收到與一項快訊政策相關的多個不重複通知：

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

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

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

    如果警告政策包含多個條件，您無法設定 Cloud Monitoring，只在發生事件時建立一個事件，並只傳送一則通知。

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

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

使用 Cloud Monitoring API 建立的快訊政策，也會在符合條件和不再符合條件時通知您。如果您是透過 Google Cloud 控制台建立警告政策，系統不會在條件不再符合時傳送通知，除非您已啟用這項功能。

Monitoring 未傳送通知或建立事件

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

• 快訊政策已停用。
• 快訊政策已延後。
• 監控系統已達開放事件數量上限。

停用快訊政策

如果停用警告政策，監控功能就不會建立事件或傳送通知。不過，Monitoring 仍會繼續評估已停用快訊政策的條件。

啟用已停用的政策時，Monitoring 會評估最近重新測試時間範圍內所有條件的值。最近的重新測試時間範圍可能包含啟用政策之前、期間及之後擷取的資料。即使重新測試時間範圍較大，停用政策的條件也可在政策恢復後立即符合。

舉例來說，假設您有監控特定程序的快訊政策，並停用這項政策。下週，該程序停止運作，但由於快訊政策已停用，您不會收到通知。如果您重新啟動程序並立即啟用快訊政策，則 Monitoring 會識別出過去五分鐘未啟動程序，並且會開啟事件。

停用快訊政策後，相關事件會保持未解決狀態，直到政策的自動關閉時間到期為止。

已延後的快訊政策

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

暫緩快訊政策時，Monitoring 會關閉與該政策相關的所有未解決事件。延後時間到期後，監控系統可能會開啟新的事件。詳情請參閱「暫緩顯示通知和事件」。

通知和未解決事件的相關限制

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

為防止系統超載，單一政策可以同時未解決的事件數限制為 1,000 個。

舉例來說，假設某項政策套用至 2000 個 Compute Engine 執行個體，且每個執行個體都符合快訊觸發條件。監控功能會將未解決的事件數限制為 1,000 個。其餘符合條件的執行個體都會遭到忽略，直到該政策的未解決事件關閉為止。

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

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

延遲時間

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

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

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

• 重新測試週期：針對條件設定的週期。 只有在整個重新測試期間條件都為 true 時，才會符合條件。舉例來說，如果將重新測試時間範圍設為五分鐘，則從事件初次發生開始，通知將延遲至少五分鐘的時間。

• 通知抵達的時間：通知管道 (例如電子郵件與簡訊) 可能存在網路或其他延遲 (與傳送內容無關)，有時可能是接近幾分鐘的時間。在某些管道 (例如簡訊與 Slack) 中，無法保證傳送訊息。

後續步驟

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

  • 建立指標閾值快訊政策
  • 建立指標缺席快訊政策
  • 建立預測指標值快訊政策
  • 使用 Monitoring API 建立快訊政策

• 如要瞭解快訊政策的分類，請參閱範例政策。