使用警告政策監控 SQL 查詢結果

Observability Analytics 中的 SQL 警告政策會定期對記錄資料執行 SQL 查詢，並在結果符合指定條件時傳送通知。舉例來說，您可以設定警告政策，在指定期間內至少有 25% 的記錄項目嚴重程度為 ERROR 時，通知您。

從「Observability Analytics」頁面建立的警告政策會在 BigQuery 引擎上執行，因此查詢的記錄檔檢視表必須有連結的 BigQuery 資料集。這些 SQL 查詢只能查詢記錄檢視，無法查詢分析檢視表。

如需 Observability Analytics 的一般資訊，請參閱「使用 Observability Analytics 查詢及分析記錄」。

警告政策的運作方式

警告政策會說明警告發送時機及通知方式。當記錄資料中出現內容或模式時，您可以透過三種不同方式接收通知：

• 如要掃描個別記錄項目，找出特定詞組，請建立記錄警告政策。如要接收安全性相關事件等通知，請使用這類警告政策。

• 如要監控記錄項目資料中的事件，您可以建立記錄指標，然後建立警告政策來監控指標。如要監控記錄項目資料的長期趨勢，這類警告政策就很實用。不過，如果預期事件數量不多，這類方法的效果就不太好。

• 如要監控記錄項目資料的匯總分析，請將 Observability Analytics 與警告政策搭配使用。在這個情境中，您會升級記錄檔 bucket 以使用 Observability Analytics，並為該記錄檔 bucket 建立連結的 BigQuery 資料集。接著，您會使用支援 SQL 查詢的 Observability Analytics，查詢記錄檔 bucket 的記錄檔檢視表。最後，您會建立警告政策，監控 SQL 查詢結果。這類警告政策稱為「SQL 警告政策」。

SQL 警告政策最適合用於評估多個記錄項目的確切值。如要評估個別記錄項目，請建立記錄警告政策。

本文其餘部分將說明如何使用以 SQL 為基礎的警告政策。

警告政策元件

SQL 警告政策包含條件和排程：

• 「條件」包含「查詢」，也就是查詢資料的 SQL 查詢。條件也會定義查詢結果導致 Monitoring 建立快訊的情況。

• 排程定義警告政策執行查詢的頻率。排程也會定義回溯期的大小，這是一種篩選器，只會選取自上次評估查詢以來收到的資料。舉例來說，如果將排程設為 60 分鐘，系統就會每 60 分鐘執行一次查詢，並使用回溯期選取最近 60 分鐘的資料。

警告政策也包含通知管道清單。當符合警告政策的條件時，Cloud Monitoring 會建立警告，並透過這些管道傳送警告通知。「快訊」是符合條件的資料記錄，以及其他相關資訊。這項資訊有助於排解造成警告的問題。您可以使用 Google Cloud 控制台查看快訊。

SQL 警告政策的評估類型

監控 SQL 查詢結果的條件支援兩種評估類型：

• 列數門檻：查詢結果中的列數大於、等於或小於門檻值時，即符合條件。

  舉例來說，假設您希望在回溯期內，有超過 50 個記錄項目的嚴重性大於 200 時收到通知。您建立查詢，回報嚴重性大於 200 的記錄項目。接著設定條件，選取「Row count threshold」(資料列數量門檻)，並將門檻設為 50。

• 布林值：查詢結果資料表中的特定布林值資料欄，包含任何值為 true 的資料列時，即符合條件。

  舉例來說，假設您希望在回溯期內，有超過 25% 的記錄項目嚴重程度為 ERROR 時收到通知。您建立查詢，計算嚴重性等級為 ERROR 的記錄項目百分比。當百分比超過 25% 時，查詢會將 true 寫入 notify 欄。接著，您建立條件，將類型設為「Boolean」，並設定條件來監控 notify 欄。

監控 SQL 查詢結果的警告政策只能有一個條件。

警告政策和 BigQuery

如要讓警告政策查詢記錄資料，您必須設定連結的 BigQuery 資料集。連結的 BigQuery 資料集可讓 BigQuery 讀取記錄資料，並對 SQL 查詢傳回的資料執行 BigQuery 函式。

警告政策執行 SQL 查詢時，該查詢會在定義警告政策的 Google Cloud 專案中，透過 BigQuery 引擎執行。根據預設，在 BigQuery 引擎上執行的查詢會使用隨選運算單元。隨選運算單元和預留運算單元須依 BigQuery 定價付費。

您也可以選擇為專案設定專屬的 BigQuery 運算單元預留項目：

1. 建立具備專屬運算單元的預留項目，或找出既有的預留項目。
2. 為專案建立預留項目指派作業。

已評估的記錄項目

如要讓警告政策的 SQL 查詢評估記錄項目，必須符合下列兩項條件：

• 記錄項目的接收時間戳記 (記錄 Cloud Logging 收到記錄項目的時間) 必須在警告政策的回溯期內。
• 記錄項目的時間戳記 (記錄產生時間) 必須在回溯期 15 分鐘內。

舉例來說，SQL 警告政策的回溯期為 60 分鐘。Observability Analytics 會在下午 1:30 執行警告政策的 SQL 查詢。記錄項目必須符合下列兩項條件，才會納入查詢：

• 接收時間戳記必須介於下午 12:30 至下午 1:30 之間。
• 時間戳記必須介於下午 12:15 至 1:45 之間。

從 Observability Analytics 介面執行查詢時，系統會根據記錄項目的時間戳記，評估所選日期範圍內的所有記錄項目。

回溯期和警告傳播時間

警告政策排定評估條件時，Observability Analytics 會將 SQL 查詢執行作業延遲五分鐘，讓 Cloud Logging 有時間為回溯期內收到的資料建立索引。舉例來說，如果警告政策使用的回溯期在下午 2:00 結束，Observability Analytics 會等到下午 2:05 才執行 SQL 查詢。

如果查詢執行後符合警告觸發條件，則警告最多可能需要兩分鐘才會在系統中傳播。

查詢失敗

SQL 警告政策發出的查詢可能會因各種原因而失敗，包括：

• Monitoring 服務帳戶已不存在，或不再具備必要權限，無法讀取查詢的記錄資料。

• 查詢執行時間超過五分鐘。

• 發生內部錯誤。

如果查詢失敗，系統會產生記錄項目，其中包含警告政策 ID 和錯誤狀態。您可以使用記錄檔警告政策，在記錄錯誤時建立警告。

事前準備

本節假設您已升級記錄檔 bucket，可使用 Observability Analytics，因此能透過 Observability Analytics 頁面查詢及查看記錄檔資料。此外，我們也假設您已在記錄檔 bucket 建立連結的 BigQuery 資料集。

建立 SQL 警告政策前，請先完成下列步驟：

1. 如要取得查詢記錄檢視表，以及建立和管理 SQL 警告政策所需的權限，請要求管理員授予您下列 IAM 角色：

   • 專案的 Monitoring 編輯者 (roles/monitoring.editor)
   • 專案的 SQL 警告寫入者 (roles/logging.sqlAlertWriter)
   • 專案的記錄檢視器 (roles/logging.viewer)
   • 專案或記錄檢視表的記錄檢視存取者 (roles/logging.viewAccessor)
   • 專案或連結資料集的 BigQuery 資料檢視者 (roles/bigquery.dataViewer)
   • 專案的 BigQuery 工作使用者 (roles/bigquery.jobUser)

2. 確認監控服務帳戶存在，且具備下列角色：

   1. 專案的 Monitoring 服務代理 (roles/monitoring.notificationServiceAgent)。
   2. 連結的 BigQuery 資料集具備 BigQuery 資料檢視者 (roles/bigquery.dataViewer) 角色。

   如果沒有 Monitoring 服務帳戶，請參閱「疑難排解：沒有 Monitoring 服務帳戶」。

3. 設定要用於接收警告通知的通知管道。為提供備援，建議您建立多種通知管道。詳情請參閱「建立及管理通知管道」。

建立 SQL 警告政策

如要建立 SQL 警告政策，請按照下列步驟操作：

控制台

1. 在 Google Cloud 控制台中，前往 「Observability Analytics」(觀測能力分析) 頁面：

   前往「Observability Analytics」(觀測能力分析) 頁面

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「Logging」的結果。

2. 在「Observability Analytics」頁面的查詢編輯器中，輸入 SQL 查詢來查詢記錄資料。

   注意：設定警告政策的查詢時，請勿使用 WHERE 子句，依時間戳記篩選記錄項目。Observability Analytics 評估查詢時，會自動對每個評估的記錄項目套用正確的時間戳記篩選器。

   如要進一步瞭解如何為記錄檢視表編寫 SQL 查詢，請參閱「查詢記錄檢視表」。

3. 在工具列中，點選「在 BigQuery 執行」。

   Observability Analytics 會在 BigQuery 引擎上執行查詢，並在「Results」(結果) 資料表中顯示結果。

   如果未顯示「Run on BigQuery」(在 BigQuery 執行)，請按一下 「Select query engine」(選取查詢引擎)，然後點選「BigQuery」。「Run query」(執行查詢) 按鈕會變更為「Run on BigQuery」(在 BigQuery 執行)。

4. 在「Observability Analytics」頁面的「Results」(結果) 資料表中，點選 「Create alert」(建立快訊)。

   「Observability Analytics」頁面會顯示「Create sql alert policy」(建立 SQL 警告政策) 視窗，其中「SQL query」(SQL 查詢) 專區下方會顯示您的查詢。

5. 在「Alert condition」(警告觸發條件) 專區，設定警告政策的條件和時間表。

6. 設定警告政策的警告詳細資料。

   1. 新增通知管道，並設定通知內容，例如自訂主旨行。

   2. 選用：新增警告政策標籤和說明文件。

   3. 點選「下一步」。

7. 檢查警告政策，然後按一下「儲存」來建立政策。

Terraform

1. 為專案安裝及設定 Terraform。如要設定 App Hub，請選取 App Hub 主專案或管理專案。

2. 在 Cloud Shell 中，前往 Terraform 設定所在的目錄。

3. 在 Terraform 設定中，設定 google_monitoring_alert_policy 資源的執行個體，包括 condition_sql。

4. 在 Cloud Shell 中輸入 terraform apply。

如要修改警告政策，請編輯並重新套用 Terraform 設定。詳情請參閱「使用 Terraform 管理警告政策」。

如需搭配使用 Google Cloud 與 Terraform 的一般資訊，請參閱「搭配使用 Terraform 與 Google Cloud」。

REST

使用 alertPolicies.create 方法，透過程式輔助方式建立警告政策。警告政策的 Condition 類型必須是 conditionSql，這是 SqlCondition 的例項。這類條件可讓您使用 SQL 定義警告政策的條件。

如要定義時間表，請為 minutes、hours 或 days 欄位之一設定 periodicity 值。舉例來說，如要每 12 小時執行一次查詢，請將 hours 欄位的週期設為 12。

如要定義條件，請使用下列欄位：

• boolean_test：設定警告政策，當查詢結果資料表的布林值資料欄中，有資料列包含 true 值時，即符合條件。
• row_count_test：設定警告政策， 當查詢結果資料表中的資料列數量達到特定 門檻時，即符合條件。

如需完整的欄位和定義清單，請參閱 Cloud Monitoring API 說明文件中的 SqlCondition。

如要進一步瞭解警告政策的 Monitoring API，請參閱「透過 API 管理警告政策」。

限制

• 每項 SQL 警告政策只能有一個條件。

• SQL 警告政策無法查詢分析檢視表。

• 如果 SQL 警告政策發出的查詢執行時間超過五分鐘，就會失敗。

• 從排定查詢到建立警告，最多可能會有七分鐘的延遲，再加上查詢執行時間。

如要查看與警告政策相關的完整限制清單，請參閱「Monitoring 限制」。

定價

如要瞭解定價，請參閱下列文件：

• BigQuery 定價
• Google Cloud Observability 定價頁面的 Cloud Logging 和 Cloud Monitoring 部分。

後續步驟

• 如要瞭解如何根據 Observability Analytics 資料建立圖表，請參閱「使用 Observability Analytics 繪製查詢結果圖表」。

• 如要瞭解如何管理這些警告政策的警告，請參閱「SQL 警告政策的警告」。