擷取指標總覽

Google SecOps 提供詳細的擷取指標，讓您掌握安全資料管道的健康狀態、資料量和處理狀態。監控這些指標，對於確保資料正確流動、找出潛在問題，以及最佳化 Google SecOps 部署作業至關重要。

擷取指標的重要性

• 健康監控：追蹤資料動態饋給和收集代理程式的狀態。
• 疑難排解：快速診斷資料遺失、剖析錯誤或連線問題等。
• 追蹤資料量：瞭解從各種來源擷取的資料量，有助於規劃容量及管理成本。
• 正規化深入分析：監控記錄剖析為統合式資料模型 (UDM) 的成功率。
• 警告：設定資料流程異常、錯誤或資料量變更的通知。

如何查看擷取指標

• Google Cloud Monitoring：

  • 將 Google SecOps 指標整合至 Cloud Monitoring，讓您根據擷取的記錄數量、大小和正規化事件等指標門檻，建立資訊主頁及設定警告政策。
  • 指標位於 Chronicle Collector 和 Chronicle Log Type 等前置字元下方。
  • 參考資料：使用 Cloud Monitoring 取得擷取洞察資料

• Google SecOps Health Hub：

  • Health Hub 是 Google SecOps 平台中的集中檢視畫面，可監控資料來源狀態、擷取量和剖析健康狀態。這項工具會醒目顯示錯誤，並提供連結，方便您深入瞭解。
  • 參考資料：使用健康中心

• BigQuery Export：

  • Google SecOps 可將詳細的ingestion_metrics 資料表匯出至 BigQuery 資料集。這可讓您進行深入的 SQL 分析、自訂報表，以及與其他資料彙整。
  • 參考資料：BigQuery 中的 Google SecOps 資料
  • 參考資料：Looker 和 BigQuery 的擷取指標參考資料

主要指標類別和欄位

擷取指標會依擷取管道的不同元件細分 (例如轉寄站、Ingestion API、正規化工具、動態饋給)。以下是您會遇到的一些重要欄位：

• 數量指標：

  • log_count：收到的原始記錄項目數量，或處理的原始記錄項目數量。
  • log_volume：接收或處理的記錄總大小 (以位元組為單位)。
  • event_count：剖析後產生的 UDM 事件數。

• 正規化指標：

  • state：記錄檔正規化程序的結果 (例如 parsed、failed_parsing、failed_validation)。
  • total_events：成功驗證的 UDM 事件數量。
  • total_error_events：剖析或驗證失敗的事件數量。
  • drop_reason_code：記錄或事件遭到捨棄的原因。

• 健康與效能：

  • last_heartbeat_time：指出收集器或動態饋給上次處於啟用狀態的時間。
  • drop_count：元件捨棄的記錄數量。
  • cpu_used、memory_used、disk_used：適用於 Bindplane 代理程式或舊版轉送器等內部部署元件的資源用量。
  • latency_count：與擷取和正規化之間所花時間相關的指標。

• 配額指標 (Ingestion API)：

  • quota_rejected_long_term_log_volume：因超出配額限制而遭拒的記錄量。

瞭解維度

指標通常會依維度細分，方便您篩選及分組資料：

• component：指標參照的擷取管道部分 (例如 Forwarder、Ingestion API、Normalizer、Out-of-Band Processor)。
• log_type：記錄來源類型 (例如 WINDOWS_DNS、CS_EDR)。
• collector_id / feed_id：特定收集器執行個體或資料動態饋給的專屬 ID。
• namespace：用於整理記錄，通常用於 API 擷取。

注意：如擷取指標結構定義所述，匯總擷取指標應視為約略數量的指標，而非任何指定日期範圍內的確切計數。

原始記錄量與資訊主頁記錄量不一致

Google SecOps 資訊主頁 (例如查詢 ingestion.component = "Ingestion API" 時) 顯示的總計 ingestion.log_volume，可能與您執行個體中儲存的原始記錄總量有顯著差異。Google SecOps 介面不會顯示自執行個體佈建以來，歷來累積的擷取計數器。由於每項報表工具都會強制執行回溯期上限，因此當執行個體超過工具的保留期限時，就無法計算歷來累計總數。

造成這些差異的原因如下：

• 不同的日期範圍和回溯限制：

  • 原始記錄儲存空間：根據設定的執行個體保留政策保留資料。執行個體自佈建以來，可能已擷取多年來的記錄。
  • Google SecOps 資訊主頁：僅計算所選日期範圍內的 ingestion.log_volume，回溯上限為 365 天 (在 Cloud Monitoring 中，自備專案 (BYOP) 執行個體的回溯上限為 24 個月)。如果執行個體擷取資料的時間超過 365 天，資訊主頁查詢回報的總計量會低於累積的歷來擷取量。

• 不同的資料來源和收集管道：

  • 原始記錄儲存空間：記錄儲存在 Google SecOps 的原始記錄批次直接位元組大小。
  • Google SecOps 資訊主頁：從 ingestion_metrics 資料表查詢 ingestion.log_volume，該資料表會以非同步方式收集遙測資料，間隔約 5 分鐘。由於這個遙測管道可能會發生收集延遲、取樣或暫時性指標下降的情況，因此資訊主頁查詢會提供大概的資料量，而非確切的位元組數。

計算擷取量的位置和值有何不同

Google SecOps 介面不會顯示從執行個體開始時間開始的累計擷取量計數器，因此請根據所需日期範圍，使用下列位置計算擷取量：

• Google SecOps 資訊主頁 (最多 365 天)：

  • 計算位置：依序開啟「資訊主頁和報表」>「資訊主頁」，然後在「主要」或「資料擷取和健康狀態」資訊主頁上查看「輸送量」小工具 (包括「擷取 - 輸送量 (歷來)」圖表)。您也可以執行自訂資訊主頁查詢，依「$event.ingestion.component = "Ingestion API"」篩選「sum($event.ingestion.log_volume)」。
  • 日期範圍上限：查詢日期範圍上限為 365 天，即使在精選的「Ingestion - Throughput (All-Time)」圖表上也是如此。
  • 值差異：資訊主頁會查詢非同步 ingestion_metrics 資料表，該資料表會以約 5 分鐘的間隔收集遙測資料，且可能會發生收集延遲或暫時性指標下降。這些值為約略值，僅反映在所選日期範圍內透過 Ingestion API 擷取的記錄，而非歷來原始記錄位元組或最終計費量。

• Cloud Monitoring Metrics Explorer (BYOP 執行個體最多 24 個月)：

  • 計算位置：在 Google Cloud 控制台中，依序開啟「Monitoring」>「Metrics Explorer」，然後執行 chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"} 查詢 (如需逐步操作說明，請參閱「查看計費擷取量」)。
  • 日期範圍上限：根據 Cloud Monitoring 指標保留期限，查詢日期範圍最多為 24 個月。
  • 值有何不同：Cloud Monitoring 查詢收集器層級的擷取位元組計數，時間範圍為您選取的時間視窗。這些值涵蓋的回溯期比 Google SecOps 資訊主頁長 (最多 24 個月，而非 365 天)，但如果執行個體超過 24 個月，則不會反映歷來總計。

• BigQuery Export (超過 365 天，視資料集保留期限而定)：

  • 計算位置：匯出 ingestion_metrics 資料表後，開啟 BigQuery 專案，然後執行查詢，找出以 component = "Ingestion API" 篩選的 SUM(log_volume) (或 Looker 和 BigQuery 中的 total_size_bytes)。
  • 日期範圍上限：查詢範圍受限於 BigQuery 資料表設定的保留期限 (從啟用匯出功能起算)，而非資訊主頁的 365 天限制。
  • 值有何差異：BigQuery 查詢的非同步 ingestion_metrics 資料表與 Google SecOps 資訊主頁相同。這些值與相同日期範圍的資訊主頁查詢相符，但仍為近似的遙測指標，而非所有時間的原始記錄位元組或最終計費量。

使用擷取指標

• 疑難排解：依 log_type 和 state (例如 failed_parsing) 篩選 Normalizer 指標，找出剖析問題。檢查 drop_count 和 drop_reason_code 是否有資料遺失。

• 快訊：在 Cloud Monitoring 設定快訊，監控重要記錄來源的 log_count 是否突然下降，或 total_error_events 是否偏高。如要監控每日擷取量是否超出合約限制，請使用「擷取的記錄檔總大小」(chronicle.googleapis.com/ingestion/log/bytes_count) 指標。請勿使用 chronicle.googleapis.com/ingestion/quota_limit 指標設定每日數量快訊，原因如下：

  • quota_limit 指標會測量與動態後端限制的接近程度，而非實際擷取的資料量。
  • 如果使用 quota_limit 接收每日數量快訊，後端門檻調整時可能會誤報。

  如要瞭解如何設定每日資料量警告政策，請參閱「設定範例政策，監控每日擷取量」。

• 容量規劃：在 BigQuery 中分析 log_volume 趨勢，預測未來需求。

• 驗證設定：設定新的資料來源後，請檢查指標，確認資料是否正常傳輸及剖析。

定期監控並瞭解這些擷取指標，可確保 Google SecOps 執行個體的資料管道可靠且有效率。

還有其他問題嗎？向社群成員和 Google SecOps 專家尋求解答。