本文說明可降低快訊費用的策略。如要瞭解定價模式，請參閱「Google Cloud Observability 定價」一文。
合併快訊政策，以便對更多資源執行作業
警告功能會依條件收費。因此，請盡可能使用一項快訊政策監控多項資源，而非為每項資源建立一項快訊政策。
舉例來說，假設您有 100 個 VM。每個 VM 都會為指標類型 my_metric 產生時間序列。以下提供兩種監控時間序列的方式：
您建立一項快訊政策，其中包含一個條件。這項條件會監控
my_metric及匯總 VM 層級的資料。匯總後，每個 VM 都會有一個時間序列。因此，這項條件會監控 100 個時間序列。您建立了 100 項快訊政策，每項政策都包含 1 個條件。每個條件都會監控其中一個 VM 的
my_metric時間序列，並將資料匯總至 VM 層級。因此，每個條件都會監控一個時間序列。
第二個選項會建立 100 個條件，因此費用會比只建立 1 個條件的第一個選項高。這兩個選項都會監控 100 個時間序列。
匯總至您需要發出快訊的層級
快訊政策監控的每個時間序列都會產生費用。 與匯總至較低精細程度相比，匯總至較高精細程度的成本較高。舉例來說，匯總至 Google Cloud 專案層級的費用，會比匯總至叢集層級的費用低；匯總至叢集層級的費用，則會比匯總至叢集和命名空間層級的費用低。
舉例來說，假設您有 100 個 VM。每個 VM 都會為指標類型 my_metric 產生時間序列。每個 VM 都屬於五項服務之一。您決定建立一項快訊政策，其中包含一項監控 my_metric 的條件。以下提供兩種不同的匯總選項：
將資料匯總至服務。匯總後，每項服務都會有一個時間序列。因此，這項條件會監控 5 個時間序列。
您會將資料匯總至 VM 層級。匯總後，每個 VM 都會有一個時間序列。因此，這項條件會監控 100 個時間序列。
第二個選項監控 100 個時間序列，因此比第一個選項 (只監控五個時間序列) 貴。
設定快訊政策時，請選擇最適合用途的匯總層級。舉例來說，如果您想針對 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 秒查詢的一半。