最快自 2026 年 5 月 1 日起，Cloud Monitoring 將開始收取快訊政策的使用費用。如要瞭解定價模式，請參閱 Google Cloud Observability 定價。
本文說明可降低快訊費用的策略。
合併快訊政策，以便對更多資源執行作業
由於每個條件的費用為 $0.10 美元，因此使用一項快訊政策監控多項資源，比使用一項快訊政策監控一項資源更具成本效益。請見以下範例：
範例 1
資料
- 100 個 VM
- 每個 VM 會發出一個指標，即
metric_name metric_name有一個標籤，其中有 10 個值
- 一個警告觸發條件
- 將條件匯總至 VM 層級
- 30 秒執行期
- 條件費用： 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
- 時間序列費用： 每個週期傳回 100 個時間序列 * 每月 86,400 個週期 = 每月傳回 860 萬個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $3.02 美元
- 總費用：每月$3.12 美元
示例 2
資料
- 100 個 VM
- 每個 VM 會發出一個指標，即
metric_name metric_name有一個標籤，其中有 10 個值
- 100 個條件
- 每項條件都會經過篩選並彙整至一個 VM
- 30 秒執行期
- 條件費用：100 個條件 * 每月 $0.10 美元 = 每月 $10 美元
- 時間序列費用： 100 個條件 * 每個週期每個條件傳回 1 個時間序列 * 每月 86,400 個週期 = 每月傳回 860 萬個時間序列 * 每 100 萬個時間序列 $0.35 美元 = 每月 $3.02 美元
- 總費用：每月$13.02 美元
在這兩個範例中，您監控的資源數量相同。不過，範例 2 使用 100 項快訊政策，範例 1 則只使用一項快訊政策。因此，範例 1 每月可省下近 $10 美元。
匯總至您需要發出快訊的層級即可
與匯總至較低精細程度相比，匯總至較高精細程度的成本較高。舉例來說，匯總至 Google Cloud 專案層級的費用，會比匯總至叢集層級的費用低；匯總至叢集層級的費用，則會比匯總至叢集和命名空間層級的費用低。
請見以下範例：
範例 1
資料
- 100 個 VM
- 每個 VM 會發出一個指標，即
metric_name metric_name有一個標籤，其中有 10 個值
- 一個警告觸發條件
- 將條件匯總至 VM 層級
- 30 秒執行期
- 條件費用： 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
- 時間序列費用： 每個週期傳回 100 個時間序列 * 每月 86,400 個週期 = 每月傳回 860 萬個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $3.02 美元
- 總費用：每月$3.12 美元
示例 4
資料
- 100 個 VM，每個 VM 屬於一項服務
- 最多五項服務
- 每個 VM 會發出一個指標，即
metric_name metric_name有一個標籤，其中有 10 個值
- 一個條件
- 將條件匯總至服務層級
- 30 秒執行期
- 條件費用： 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
- 時間序列費用： 每個週期傳回 5 個時間序列 * 每月 86,400 個週期 = 每月傳回 432,000 個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $0.14 美元
- 總費用：每月$0.24 美元
範例 5
資料
- 100 個 VM
- 每個 VM 會發出一個指標，即
metric_name metric_name有 100 個標籤，每個標籤有 1,000 個值
- 一個條件
- 將條件匯總至 VM 層級
- 30 秒執行期
- 條件費用： 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
- 時間序列費用： 每個週期傳回 100 個時間序列 * 每月 86,400 個週期 = 每月傳回 850 萬個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $3.02 美元
- 總費用：每月$3.12 美元
比較範例 1 和範例 4： 這兩個範例都使用相同的基礎資料，且只有一項快訊政策。不過，由於範例 4 中的快訊政策會匯總至服務，因此比範例 1 中的快訊政策便宜，後者會以更精細的方式匯總至 VM。
此外，請比較範例 1 和範例 5： 在本例中，範例 5 的指標基數比範例 1 的指標基數高出 10,000 倍。不過，由於範例 1 和範例 5 中的警報政策都會匯總至 VM，且兩個範例中的 VM 數量相同，因此價格相同。
設定快訊政策時，請選擇最適合您用途的匯總層級。舉例來說，如果您想針對 CPU 使用率發出快訊，可以匯總至 VM 和 CPU 層級。如果您想根據端點延遲時間發出快訊，則可能需要匯總至端點層級。
不要根據未經匯總的原始資料發送快訊
監控系統採用多維度指標系統，任何指標的基數總數，都等於受監控資源數量乘以該指標的標籤組合數量。舉例來說，如果您有 100 個 VM 發出指標，而該指標有 10 個標籤，每個標籤有 10 個值，則總基數為 100 * 10 * 10 = 10,000。
由於基數的規模，對原始資料發出快訊的成本可能非常高。在上一個範例中，每個執行期間會傳回 10,000 個時間序列。不過，如果匯總至 VM，則無論基礎資料的標籤基數為何，每個執行期間只會傳回 100 個時間序列。
如果對原始資料設定快訊，當指標收到新標籤時，時間序列可能會增加，進而提高費用。在先前的範例中，如果使用者為指標新增標籤，總基數就會增加至 100 * 11 * 10 = 11,000 個時間序列。在這種情況下，即使警報政策沒有變更，每個執行週期傳回的時間序列數量仍會增加 1,000 個。如果改為匯總至 VM，即使基礎基數增加，系統仍只會傳回 100 個時間序列。
篩除不必要的回應
設定條件，只評估警報需求所需的資料。如果不想採取行動修正問題，請將該項目從警告政策中排除。舉例來說，您可能不需要針對實習生的開發 VM 發出快訊。
如要減少不必要的事件和費用，可以篩除不重要的時間序列。您可以使用 Google Cloud 中繼資料標籤為資產加上類別標記，然後篩除不需要的中繼資料類別。
使用頂端串流運算子減少傳回的時間序列數量
如果條件使用 PromQL 查詢，則可使用 top-streams 運算子選取傳回最高值的時間序列數量：
- PromQL：
topk
舉例來說，PromQL 查詢中的 topk(metric, 5) 子句會將每個執行期間傳回的時間序列數量限制為五個。
如果將時間序列數量限制在一定範圍內，可能會導致資料遺失和事件錯誤，例如：
- 如果超過 N 個時間序列違反門檻，您就會錯過前 N 個時間序列以外的資料。
- 如果違規時間序列發生在排名前 N 的時間序列之外，即使排除的時間序列仍違反門檻，事件也可能會自動關閉。
- 條件查詢可能不會顯示重要背景資訊，例如運作正常的基準時間序列。
為降低這類風險，請為 N 選擇較大的值，並僅在評估多個時間序列的警報政策中使用 top-streams 運算子，例如個別 Kubernetes 容器的事件。
延長執行時間長度 (僅限 PromQL)
如果條件使用 PromQL 查詢，您可以透過在條件中設定 evaluationInterval 欄位，修改執行期間的長度。
評估間隔越長，每月傳回的時間序列就越少；舉例來說，間隔 15 秒的條件查詢執行頻率是間隔 30 秒查詢的兩倍，間隔 1 分鐘的查詢執行頻率則是間隔 30 秒查詢的一半。