快訊政策深入資訊

本頁面提供 Stackdriver Monitoring 快訊政策的詳細概念總覽。瞭解這些內容有助於您有效使用快訊政策。

如要瞭解如何建立及管理快訊政策,請參閱:

政策

快訊政策定義了將服務視為健康狀態不良的條件。符合條件時,政策會觸發並開啟新事件。若已設定,觸發的政策也會傳送通知。

政策屬於個別工作區,且每個工作區都可以包含最多 500 個政策。

條件

決定快訊政策的觸發時機的條件。如要描述條件,可指定:

  • 要測量的指標。
  • 判斷該指標何時達到您要瞭解之狀態的測試。

視您要監控的內容而定,您可以建立參照下列內容的條件:

  • 要監控的資源,例如個別 VM 執行個體或執行個體群組、第三方應用程式、資料庫、負載平衡器、網址端點等。

  • 測量資源效能的預先定義的指標

  • 您自己建立的自訂指標記錄指標

條件的類型

條件是根據指標來建構而且可以監控,例如,監控指標是否達到某一個值,或是開始快速變更等情況。指標與資源相關聯,並且可以測量該資源的一些特性,例如 VM 群組的平均 CPU 使用率。如要進一步瞭解指標,請參閱指標、時間序列和資源一文。

所有條件的關注點都在三件事情上:某一個指標在某一段時間內以某種方式運作。

所有條件都會做為下列兩種一般類型的其中一種來實作:

  • 指標不存在條件:這個條件會觸發特定持續時間區間內沒有資料的指標中的任何時間序列。

    從安裝政策開始,或者在持續時間範圍上限 (24 小時) 內,指標不存在條件需要至少一個成功的測量結果,也就是擷取資料的測量結果。

    例如,假設您將指標不存在政策中的持續時間範圍設定為 30 分鐘。如果寫入指標資料的子系統從未寫入資料點,則無法滿足條件。子系統需要輸出至少一個資料點,然後在 30 分鐘的時間內沒有輸出其他資料點,才可以滿足這個條件。

  • 指標臨界值條件:這個條件會在指標上升或下降到特定持續時間區間值時觸發。

    在指標臨界值條件類別中,有些模式屬於一般子類別:

    • 指標變更頻率 (百分比):如果在持續時間範圍內,指標增加或降低特定百分比或更多,即會觸發。

      在這類條件下,會先將變更百分比計算套用至時間序列,再與臨界值進行比較。

      這個條件會先計算出過去 10 分鐘指標的平均值,然後再將結果與持續時間範圍之前測量的 10 分鐘平均值進行比較。指標變更頻率條件使用的 10 分鐘回溯期是一個固定值;無法變更。但是,您可以在建立條件時指定持續時間範圍。

    • 群組匯總臨界值:跨資源群組測量的指標超過臨界值時觸發。

    • 運作時間檢查健康狀態:如果您建立了運作時間檢查,且資源未成功回應從至少兩個地理位置傳送的要求,就會觸發這個條件。

      運作時間檢查的結果只會顯示在 Stackdriver Monitoring 主控台的運作時間檢查總覽頁面中。您可以針對運作時間檢查建立快訊政策,讓運作時間檢查以間接方式開啟事件,並在檢查失敗時,選擇性地傳送通知。

    • 程序健康狀態:如果 (1) 在 VM 執行個體或執行個體群組中執行且 (2) 符合某一字串的程序數,在持續時間範圍內高於或低於特定數目,就會觸發這個條件。

      這個條件類型需要對受控資源執行 Monitoring 代理程式

為每種類型提供下列範例:

條件類型 JSON 範例
指標門檻 查看
變更頻率 查看
群組匯總 查看
運作時間檢查 查看
程序健康狀態 查看

合併條件

一個政策最多可包含 6 個條件。如果您使用多個條件,可選擇三個選項來指定違反政策的組合:

  • OR:符合任何一個條件。
  • AND:至少一個資源違反每個條件,即使不同資源違反每個條件也是如此。
  • AND_WITH_RESOURCES相同資源違反所有條件 (這個選項僅適用於使用 Monitoring API 建立的條件)。

持續時間範圍

條件包含持續時間範圍,即條件必須評估為 true 才能觸發的時間長度。條件的持續時間範圍可避免傳訊政策反應過度。您可能想要降低誤判率,因為傳送穩定通知串流的快訊政策最終會被忽略。

根據經驗法則,服務的可用性越高,或者未偵測到問題的處罰值越大,您想要指定的持續時間範圍就越短。

由於效能的正常波動,您不會想在一個測量結果符合條件的情況下觸發政策,而是通常想在多個連續測量結果符合條件時,才將應用程式視為健康狀態不良。

每當測量結果不符合條件時,條件都會重設其持續時間範圍。

範例

下列條件指定五分鐘的持續時間範圍:
連續五分鐘內,HTTP 延遲時間超過兩秒鐘。

以下序列說明持續時間範圍如何影響條件的評估:

  1. 連續三分鐘內,HTTP 延遲時間超過兩秒。
  2. 在下次測量時,延遲時間低於兩秒,因此,條件會重設持續時間範圍。
  3. 在下一個連續五分鐘內,HTTP 延遲時間超過兩秒,因此會觸發政策。

持續時間範圍應足夠長,才能降低誤判率,但足夠短的話,可確保適時開啟事件。

政策行為

快訊政策存在於動態且複雜的環境中,因此,若要良好地使用這些政策,需要瞭解可能影響其行為的一些變數。條件監控的指標與資源、條件的持續時間範圍以及通知管道都會產生影響。

本節提供一些額外資訊,可協助您瞭解快訊政策的行為。

停用快訊政策

您可以透過停用及啟用政策,來暫停及重新啟動快訊政策。例如,如果您有一個快訊政策,在程序停止超過 5 分鐘時通知您,則您可以在停止程序以進行升級或其他維護時,停用快訊政策。

停用快訊政策可防止政策觸發 (或解決) 事件,但這不會阻止 Stackdriver 評估政策條件及記錄結果。

假設受監控的程序停止 20 分鐘,以進行維修。如果您重新啟動程序並立即重新啟用快訊政策,系統將會識別出過去 5 分鐘未啟動程序,並且會開啟事件。

重新啟用已停用的政策時,Stackdriver 會檢查最近持續時間範圍內所有的條件值,其中可能包含暫停間隔之前、期間及之後擷取的資料。即使持續時間範圍較大,政策也可在繼續之後立即觸發。

異常事件

快訊政策 (尤其是指標不存在或具有「小於」臨界值條件的政策) 可能會顯示在「Alerting」(快訊) >「Incidents」(事件) 頁面中,進而導致提前或錯誤地觸發。

如果資料存在遺漏情況,就會發生這類情形,但識別這種遺漏情況並不容易。有時這類遺漏情況較為模糊,有時則已經被修正了。

例如,在圖表中,會在資料的遺漏部分插入新內容。可能會遺漏幾分鐘的資料,但圖表會連接遺漏的資料點,以實現視覺連續性。基礎資料中的這種遺漏情形可能足以觸發快訊政策。

在過去長達 10 分鐘的時間內,記錄指標中的資料點可能較晚抵達,並且可進行回填。這樣可以有效修正遺漏情形;當資料最終抵達時,會填入遺漏部分。因此,記錄指標中無法再看見的遺漏可能會觸發快訊政策。

指標不存在與「小於」臨界值條件會即時評估,且查詢延遲較小。條件的狀態可在評估時間與對應事件顯示在 Stackdriver Monitoring 主控台中的時間之間變更。

部分指標資料

如果缺少測量結果 (例如,若幾分鐘內沒有 HTTP 要求),政策會使用最後的記錄值來評估條件。

範例

  1. 條件指定連續五分鐘內,HTTP 延遲時間為兩秒或更多。
  2. 連續三分鐘內,HTTP 延遲時間為三秒。
  3. 連續兩分鐘內,沒有 HTTP 要求。 在這種情況下,條件會在這兩分鐘的時間內進行最後一次測量 (三秒)。
  4. 總計五分鐘後,政策會觸發,即使過去兩分鐘沒有資料也是如此。

遺漏或延遲的指標資料可能會使政策不發出快訊,且事件不會關閉。來自第三方雲端服務供應商的資料延遲時間可能高達 30 分鐘,最常見的延遲時間為 5-15 分鐘。延遲時間較長 (長於持續時間範圍) 可能會使條件進入「未知」狀態。當資料最終抵達時,Stackdriver Monitoring 可能會遺失條件的一些最新歷史記錄。稍後檢查時間序列資料時可能不會顯示這個問題,因為資料抵達之後,延遲的證據就不存在了。

您可以執行下列任何作業,將這些問題降到最低:

  • 聯絡第三方雲端服務供應商,查看是否有縮短指標收集延遲時間的方式。
  • 在條件中使用較長的持續時間範圍。此做法的缺點是會使快訊政策的回應速度較為緩慢。
  • 選擇收集延遲時間較短的指標:

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

詳情請參閱監控代理程式總覽使用自訂指標記錄指標說明文章。

每個政策的事件

快訊政策可能會套用至許多資源,而影響所有資源的問題可能會觸發每個資源的政策與未解決事件。如要防止系統超載,單一政策可以同時未解決的事件數限制為 5000 個。

例如,若將一個政策套用至 2000 (或 20,000) 個 Compute Engine 執行個體,而有某件事導致每一個執行個體都違反快訊觸發條件,那麼將只會有 5000 個事件保持在未解決狀態。其餘違反觸發條件的執行個體都會遭到忽略,直到該政策的未解決事件得到解決為止。

每個事件的通知

每個事件傳送的通知數因政策中的條件而有所不同。

如果政策只包含一個條件,則事件最初開啟時,只會傳送一則通知,即使後續測量繼續符合條件也是如此。

如果政策包含多個條件,可能會根據您設定政策的方式,傳送多個通知:

  • 如果政策僅在符合所有條件時觸發,則只有在事件最初開啟時,政策才會傳送通知。

  • 如果政策在符合任何一個條件時觸發,則每次符合新條件組合時,政策都會傳送通知。例如:

    1. 符合 ConditionA,會開啟事件並傳送通知。
    2. 後續測量同時滿足 ConditionA 與 ConditionB 時,事件仍會開啟。在這種情況下,事件會保持開啟,且會傳送另一則通知。

通知延遲時間

通知延遲時間是從問題初次開始時間到觸發政策時間的延遲。

下列事件與設定導致了整體通知延遲:

  • 指標收集延遲時間:Stackdriver Monitoring 需要用來收集指標值的時間。針對 GCP 值,這通常是可以忽略不計的。針對 AWS CloudWatch 指標,這可以是數分鐘的時間。針對運作時間檢查,這個時間平均為 4 分鐘,最多為 5 分鐘 30 秒 (從持續時間範圍結束算起)。

  • 持續時間範圍:針對條件設定的範圍。請注意,只有在整個持續時間範圍內條件都為 true 時,才會符合條件。例如,如果您指定五分鐘的時間範圍,則從事件初次發生開始,通知將延遲至少五分鐘的時間。

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

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Stackdriver Monitoring
需要協助嗎?請前往我們的支援網頁