最佳化及監控 Google Cloud Observability 費用

本頁面說明如何最佳化及監控 Google Cloud Observability 費用。如要瞭解定價資訊,請參閱「Google Cloud Observability 定價」。

您可能也會對下列文件感興趣:

最佳化

本節提供相關指引,說明如何減少或調整與 Cloud Logging、Cloud Trace 和 Google Cloud Managed Service for Prometheus 相關的費用。

降低 Cloud Logging 費用

如要降低 Cloud Logging 的儲存費用,請在記錄接收器上設定「排除」篩選器,防止低價值記錄項目串流至記錄桶。您可以設定記錄檔接收器,排除所有符合排除篩選器的記錄項目,或只排除某個百分比的相符記錄項目。已排除的記錄項目不會串流至記錄儲存空間,也不會計入儲存空間配額。詳情請參閱「記錄檔接收器篩選器」。

Cloud Logging 儲存費用僅適用於儲存在記錄檔值區中的記錄檔資料。您可以設定記錄檔接收器,讓記錄檔資料不會儲存在記錄檔 bucket 中,而是轉送至下列其中一個目的地:

將記錄項目轉送至所列目的地時,Cloud Logging 不會收費。 不過,當目的地收到記錄項目時,系統可能會向您收費。

如要瞭解如何轉送記錄檔資料,請參閱「轉送記錄檔至支援的目的地」。

最佳化 Managed Service for Prometheus 的成本

Managed Service for Prometheus 的計價方式可控管費用。由於系統會根據樣本數計費,因此您可以透過下列方式控管費用:

  • 取樣期間:將指標抓取期間從 15 秒變更為 60 秒,即可省下 75% 的成本,而不會犧牲基數。您可以根據每個工作、每個目標或全域來設定取樣期間。

  • 篩選:您可以使用篩選器來減少傳送至服務全域資料儲存空間的樣本數量;詳情請參閱篩選匯出的指標。 在 Prometheus 抓取設定中,使用指標重新標籤設定,依據標籤比對器在擷取時捨棄指標。

  • 將高基數和低價值資料存放在本機。您可以使用相同的抓取設定執行標準 Prometheus 和代管服務,並將不須傳送到服務全域資料儲存空間的資料保留在本機。

Managed Service for Prometheus 的價格是可預測的。

  • 您無須為資料稀疏的直方圖支付費用。只有第一個非零值,以及值區n值大於值區n-1值時,系統才會計算樣本。舉例來說,有 10 10 13 14 14 14 這個值的直方圖在第 1、3 和 4 個值區計為 3 個樣本。

    視您使用的直方圖數量和用途而定,與直方圖值區指示的絕對值相比,如果計費時排除不變值區,通常會導致用於計費的樣本減少 20% 至 40%。

  • 如果以每個樣本來計費,系統不會針對快速調度和未調度、先占或臨時容器 (例如 HPA 或 GKE Autopilot 建立的容器) 向您收費。

    如果 Managed Service for Prometheus 是按指標計費,則您每次啟動新容器時,都必須一次支付整月的基數費用。如為按取樣計費,您只須在容器執行期間付費。

查詢,包括快訊查詢

使用者發出的所有查詢 (包括執行 Prometheus 記錄規則時發出的查詢),都會透過 Cloud Monitoring API 呼叫計費。

減少追蹤記錄用量

如要控管 Trace 時距的擷取數量,您可以透過管理追蹤記錄取樣率的方式,在效能分析所需的追蹤記錄量與支出的費用之間取得平衡。

針對流量偏高的系統,大部分的客戶僅須採用每 1,000 筆交易取 1 的取樣率 (甚至是每 10,000 筆交易取 1),就能取得足夠的資訊來進行效能分析。

您可以使用 Cloud Trace 用戶端程式庫來設定取樣率。

減少快訊費用

本節說明可降低快訊費用的策略。如要瞭解定價模式,請參閱「Google Cloud Observability 定價」和「快訊定價範例」。

使用 UI 內建的 Pricing Calculator 查看預估帳單

建立或編輯警告政策時,Cloud Alerting 會顯示政策的預估費用。您可以透過這項計算機,瞭解變更警告政策參數後,預估費用會如何變化。

使用 Metrics Explorer 驗證傳回的點數

警告政策查詢傳回的點數主要取決於警告政策查詢輸出內容的基數。如要查看警告政策的預估基數,請按照下列步驟操作:

  • 如果是指標閾值快訊條件,請使用 Metrics Explorer 建構相同的查詢。新增「計算時間序列」的次要轉換,並選取「無」
  • 如果是 PromQL 警報條件,請將查詢複製到 Metrics Explorer,然後執行下列操作:
    • 將查詢分割成多個子句,方法是依據每個 ><>=<===!=ANDORUNLESS 運算子進行分割。
    • 刪除不含指標的任何子句,例如數值門檻值。
    • 將每個子句包裝在 count() 函式中。
    • 加總結果。
  • 如果是 MQL 快訊觸發條件,請將查詢複製到 Metrics Explorer。移除 | condition 行。在結尾處新增 | group_by [], .count 行。

    MQL 已淘汰,Cloud Customer Care 可能會拒絕處理要求協助偵錯帳單問題的案件。

合併快訊政策,以便對更多資源執行作業

快訊會收取每項指標參照的費用,且每項指標門檻政策的每個條件都有一項指標參照。因此,請盡可能使用一項警告政策監控多項資源,而不是為每項資源建立一項警告政策。

舉例來說,假設您有 100 個 VM。每分鐘,每個 VM 會為 my_metric 指標類型產生一個點。以下提供兩種不同的方式,供您監控退回的點數:

  • 您建立的警告政策只有一個條件,因此只有一個指標參照。這項條件會監控 my_metric,並將資料匯總至 VM 層級。匯總後,每個 VM 都會傳回一個點。 因此,條件會為每次評估作業回傳 100 分。

  • 您建立了 100 項快訊政策,每項政策都包含一個條件,因此各有一項指標參照。每個條件都會監控其中一個 VM 的 my_metric 時間序列,並將資料匯總至 VM 層級。因此,每個條件在每次評估時都會傳回一個點。

第二個選項會建立 100 個條件 (100 個指標參照),因此比第一個選項 (只建立 1 個條件,即 1 個指標參照) 更昂貴。這兩種選項每次評估都會回饋 100 點。

匯總至您需要發出快訊的層級

系統會為警報政策監控的每個時間序列傳回一個點。與匯總至較低精細程度相比,匯總至較高精細程度的成本較高。舉例來說,匯總至Google Cloud 專案層級的費用,會比匯總至叢集層級的費用低;匯總至叢集層級的費用,則會比匯總至叢集和命名空間層級的費用低。

舉例來說,假設您有 100 個 VM。每個 VM 都會為指標類型 my_metric 產生一個點。每個 VM 都屬於五項服務之一。您決定建立一項警告政策,其中包含一項監控 my_metric 的條件。以下提供兩種不同的匯總選項:

  • 您將資料匯總至服務。彙整後,每個警告政策執行作業都會針對每項服務傳回一個點。因此,條件每次執行都會傳回 5 分。

  • 您會將資料匯總至 VM 層級。匯總後,每項警告政策執行作業都會為每個 VM 傳回一個點。因此,條件每次執行都會傳回 100 點。

第二個選項每次執行會傳回 100 點,比第一個選項 (每次執行只會傳回 5 點) 貴。

設定快訊政策時,請選擇最適合用途的匯總層級。舉例來說,如果您想針對 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(metric, 5) 子句會將每個執行週期傳回的點數限制為五個。

如果將點數限制為上限,可能會導致資料遺失和事件錯誤,例如:

  • 如果超過 N 個點違反門檻,您就會遺失前 N 個點以外的資料。
  • 如果違規點出現在前 N 個點以外,即使排除的點仍違反門檻,事件也可能會自動結案。
  • 條件查詢可能不會顯示重要背景資訊,例如可正常運作的基準點。

為降低這類風險,請為 N 選擇較大的值,並僅在評估多個時間序列的警報政策中使用 top-streams 運算子,例如個別 Kubernetes 容器的事件。

延長執行時間 (僅限 PromQL)

如果條件使用 PromQL 查詢,您可以透過在條件中設定 evaluationInterval 欄位,修改執行期間的長度。

評估間隔越長,每月傳回的點就越少;舉例來說,間隔 15 秒的條件查詢執行頻率是間隔 30 秒查詢的兩倍,間隔 1 分鐘的查詢執行頻率則是間隔 30 秒查詢的一半。

請勿使用「未指定的資源」(僅限記錄指標)

使用記錄指標的快訊條件可讓您將「未指定資源」設為受監控的資源類型。這麼做時,系統會針對 Cloud Monitoring 中的每個受監控資源類型,分別啟動查詢。由於每項查詢至少會傳回一個點,因此如果未指定資源類型,就會產生高額的點數費用。

如要降低帳單費用,請選擇特定資源類型,而非使用「未指定資源」。這是因為大多數以記錄為準的指標只會出現在一種資源類型中。如果記錄檔指標顯示多種資源類型,您可以建立多個警告政策,或在單一警告政策中使用多個條件。

監控

本節說明如何建立快訊政策,監控費用。警告政策可以監控指標資料,並在資料超過門檻時通知您。

監控每月擷取的記錄檔位元組數

如要建立警告政策,以便在寫入記錄檔 bucket 的記錄檔位元組數超過使用者定義的 Cloud Logging 限制時接收通知,請使用下列設定。

新條件
欄位

資源和指標 在「資源」選單中,選取「全域」
在「指標類別」選單中,選取「記錄指標」
在「指標」選單中,選取「每月擷取的記錄位元組數」
篩選器
跨時間序列
時間序列匯總
sum
滾動視窗 60 m
滾動視窗函式 max
設定快訊觸發條件
欄位

條件類型 Threshold
快訊觸發條件 Any time series violates
門檻位置 Above threshold
門檻值 由您定義可接受的值。
重新測試週期 可接受的最低值為 30 分鐘。

監控擷取的指標總數

您無法依據每個月擷取的指標量建立快訊,但可以建立 Cloud Monitoring 費用快訊。詳情請參閱「設定帳單快訊」。

監控每月擷取的追蹤記錄時距數量

如要建立警告政策,以便在每月擷取的 Cloud Trace 時距超過使用者定義的限制時接收通知,請使用下列設定。

新條件
欄位

資源和指標 在「資源」選單中,選取「全域」
在「指標類別」選單中,選取「帳單」
在「指標」選單中,選取「每月擷取的追蹤記錄範圍」
篩選器
跨時間序列
時間序列匯總
sum
滾動視窗 60 m
滾動視窗函式 max
設定快訊觸發條件
欄位

條件類型 Threshold
快訊觸發條件 Any time series violates
門檻位置 Above threshold
Threshold value 由您定義可接受的值。
重新測試週期 可接受的最低值為 30 分鐘。

設定帳單快訊

您可以在 Google Cloud 控制台的「預算與快訊」頁面建立快訊,設定何時 (例如當計費或預估費用超出預算時) 要收到通知:

  1. 前往 Google Cloud 控制台的「Billing」(帳單) 頁面:

    前往「帳單」

    您也可以透過搜尋列找到這個頁面。

    如果您有多個 Cloud Billing 帳戶,請依照下列其中一種方式來設定:

    • 如要管理目前專案的 Cloud Billing,請選取 [前往連結的帳單帳戶]
    • 如要查看其他 Cloud Billing 帳戶,請選取 [管理帳單帳戶],然後選擇您想設定預算的帳戶。
  2. 在「帳單」導覽選單中,選取 [預算與快訊]
  3. 按一下 [設定預算]
  4. 完整填寫預算對話方塊。從這個對話方塊中選取 Google Cloud 專案和產品,然後為您的組合設定預算。根據預設,當帳單達到預算的 50%、90% 和 100% 時,您都會收到通知。如需完整的說明文件,請參閱設定預算和預算快訊