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

本文件說明對齊期間和重測時間間隔如何判斷何時符合條件、警示政策如何結合多個條件，以及警示政策如何取代缺少的資料點。這份報告也會說明政策的未解決事件上限數量、每個事件的通知數量，以及導致通知延遲的原因。

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

對齊期間和重測時間範圍

在判斷是否已符合快訊政策條件時，Cloud Monitoring 會評估對齊期間和重測時間。

校正週期

在快訊政策監控時序資料之前，必須先將資料規則化，讓快訊政策有規則性的資料可供評估。正規化程序稱為「校驗」。

對齊作業包含兩個步驟：

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

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

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

舉例來說，如果對齊期間為五分鐘，下午 1 點時，對齊期間會包含下午 12 點 55 分至下午 1 點之間收到的樣本。下午 1 點 1 分鐘時，對齊期間會往後滑一分鐘，並包含下午 12 點 56 分至下午 1 點 1 分之間收到的樣本。

監控會將對齊期間設定為以下方式：

為了說明對齊期間對警示政策中條件產生的影響，請考慮使用指標門檻條件，監控以一分鐘為取樣週期的指標。假設對齊時間已設為五分鐘，且對齊器設為 sum。此外，假設時間序列的對應值至少連續三分鐘大於兩個，且每分鐘評估一次條件，系統就會判定條件已滿足。在本例中，重測時間 (詳見下一節) 為三分鐘。下圖說明條件的幾個連續評估：

圖中的每一列都代表對條件的單一評估。系統會顯示時間序列資料。對齊期間的點會以藍點顯示；較舊的點則為黑色。每個資料列都會顯示對齊的值，以及這個值是否大於兩個的閾值。對於標示為 start 的資料列，對齊的值會計算為 1，小於閾值。在下次評估時，對齊期間的樣本總數為兩個。在第三次評估時，總和為三，由於這個值大於閾值，因此會啟動重測視窗的計時器。

重新測試週期

快訊政策的條件設有重測期間，可避免因單一測量或預測而符合條件。舉例來說，假設條件的重測時間範圍設為 15 分鐘。以下根據條件類型說明條件的行為：

• 若單一時間序列中，15 分鐘間隔內的每個對齊測量值都違反門檻，就會符合指標門檻條件。
• 如果在 15 分鐘的間隔內，時間序列沒有收到任何資料，就會滿足指標不存在條件。
• 在 15 分鐘的時間區間內，如果每個產生的預測都預測時間序列會在預測時間區間內違反閾值，就會符合預測條件。

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

上圖顯示三項指標門檻條件的評估結果。在 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 控制台中的設定、Cloud Monitoring API 中的等值值，以及每項設定的說明：

Google Cloud console 政策觸發條件值	Cloud Monitoring API 組合器值	意義
符合任一條件	OR	如果任何資源導致任何條件成立，系統就會開啟事件。
所有條件都符合 ，即使每個條件有不同的 資源 (預設)	AND	當所有條件都符合時，系統會為符合每個條件開啟事件，即使不同資源導致這些條件符合也是如此。
符合所有條件	AND_WITH_MATCHING_RESOURCE	只有在所有條件都符合時，系統才會針對每個符合的條件開啟事件，前提是相同資源會導致每個條件都符合。這是最嚴格的組合選項。

在這個情況下，「符合」一詞的意思是條件的設定會評估為「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 用量超過 100ms/s 達 1 分鐘時，就會符合此條件。
• 名為 Excessive utilization 的條件會監控執行個體的 CPU 使用率。當任何執行個體的 CPU 使用率超過 60% 達 1 分鐘時，就會符合此條件。

一開始，假設兩個條件都評估為 false。

接著，假設 vm1 的 CPU 使用率在 1 分鐘內超過 100ms/s。由於 CPU 使用率超過一分鐘的門檻，因此符合 CPU usage is too high 條件。如果條件與「任何條件皆符合」結合，系統會在符合條件時建立事件。如果條件與「所有條件都符合」或「即使每個條件都有不同的資源，所有條件都符合」結合使用，系統就不會建立事件。這些組合選項都必須同時符合兩個條件。

接著，假設 vm1 的 CPU 使用率仍大於 100ms/s，且 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 相符，因此不會建立事件。

部分指標資料

當時序資料停止傳送或資料延遲時，監控會將資料歸類為「缺少」。缺少資料可能會導致事件無法關閉。第三方雲端服務供應商傳送的資料延遲時間可能長達 30 分鐘，最常見的延遲時間為 5 到 15 分鐘。長時間延遲 (超過重測期間) 可能會導致條件進入「不明」狀態。資料最終到達時，監控可能會遺失部分條件近期的記錄。後續檢查時序資料時，可能不會發現這個問題，因為資料傳送後並沒有延遲的證據。

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

• 請與第三方雲端服務供應商聯絡，瞭解如何縮短指標收集延遲時間。
• 在條件中使用較長的重新測試時間範圍。使用較長的重新測試回溯期窗口，缺點是會使快訊政策的回應速度較為緩慢。

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

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

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

監控功能傳送通知及建立事件

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

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

在下列情況下，您可能會收到多則與單一快訊政策相關的通知：

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

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

  • 符合所有條件：當所有條件都符合時，系統會針對每個導致條件符合的時間序列，傳送快訊並建立事件。

    當快訊政策包含多個條件時，您無法設定 Cloud Monitoring 只建立一個事件並傳送一則通知。

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

  詳情請參閱「含有多個條件的政策」。

使用 Cloud Monitoring API 建立的快訊政策也會在符合條件和不再符合條件時通知您。除非您已啟用這項行為，否則使用 Google Cloud 控制台建立的警告政策不會在條件不再符合時傳送通知。

Monitoring 未傳送通知或建立事件時

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

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

停用快訊政策

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

啟用已停用的政策時，監控功能會評估最近重測範圍內所有條件的值。最近的重新測試期間可能包含啟用政策之前、期間和之後擷取的資料。即使持續時間範圍較大，政策也可在繼續之後立即觸發。

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

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

延後的快訊政策

對於延後的警告政策，Monitoring 不會傳送通知或建立事件。如要避免快訊政策在短時間內多次傳送通知，建議您暫停快訊政策。舉例來說，在對虛擬機器 (VM) 執行維護作業前，您可以建立延遲條件，並在延遲條件中加入監控執行個體的快訊政策。

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

通知和未解決事件的限制

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

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

舉例來說，假設有個政策套用至 2000 個 Compute Engine 執行個體，而每個執行個體都會觸發快訊條件。監控功能會將未解決事件數量限制在 1,000 個。直到該政策的部分未解決事件關閉為止，系統會忽略符合的所有其他條件。

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

延遲時間

延遲是指從 Monitoring 取樣指標到指標資料點顯示為時間序列資料的時間差。延遲時間會影響通知傳送時間。舉例來說，如果監控指標的延遲時間最多為 180 秒，那麼在警示政策條件判斷為 True 後，監控服務最多會在 180 秒後才建立事件。詳情請參閱「指標資料的延遲時間」。

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

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

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

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

後續步驟

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

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

• 如要瞭解各種快訊政策，請參閱範例政策。