將記錄檔從 Google Cloud 串流至 Splunk

Last reviewed 2024-10-24 UTC

本文將說明參考架構，協助您建立可正式發布的可擴充、容錯的日誌匯出機制，以便將資源中的日誌和事件串流傳送至 Splunk。 Google Cloud Splunk 是一款熱門的數據分析工具，提供整合的安全性和可觀察性平台。事實上，您可以選擇將記錄資料匯出至 Splunk Enterprise 或 Splunk Cloud Platform。如果您是管理員，也可以將這個架構用於 IT 作業或安全性用途。

這個參考架構假設資源階層類似下圖所示。機構、資料夾和專案層級的所有 Google Cloud 資源記錄都會匯入匯總接收來源。匯總接收器會將這些記錄傳送至記錄匯出管道，該管道會處理記錄並匯出至 Splunk。

匯出至 Splunk 的機構層級匯總記錄檔接收器。

架構

下圖顯示部署此解決方案時使用的參考架構。這張圖表說明記錄資料如何從Google Cloud 流向 Splunk。

從 Google Cloud 傳送至 Splunk 的記錄檔流程。

這個架構包含下列元件：

  • Cloud Logging：為了啟動這個程序，Cloud Logging 會將記錄收集到機構層級的匯總記錄檔接收器，並將記錄傳送至 Pub/Sub。
  • Pub/Sub：Pub/Sub 服務會為記錄檔建立單一主題和訂閱項目，並將記錄檔轉送至主要 Dataflow 管道。
  • Dataflow：這個參考架構中有兩個 Dataflow 管道：
    • 主要 Dataflow 管道：在程序的中心，主要 Dataflow 管道是 Pub/Sub 到 Splunk 的串流管道，可從 Pub/Sub 訂閱中提取記錄，並將記錄傳送至 Splunk。
    • 輔助 Dataflow 管道：與主要 Dataflow 管道並行，輔助 Dataflow 管道是 Pub/Sub 到 Pub/Sub 串流管道，可在傳送失敗時重播訊息。
  • Splunk：在程序結束時，Splunk Enterprise 或 Splunk Cloud Platform 會充當 HTTP 事件收集器 (HEC)，並接收記錄檔以便進一步分析。您可以將 Splunk 部署在地端、Google Cloud 以 SaaS 形式部署，或透過混合式方法部署。

用途

這個參考架構採用雲端的推播方式。在這種以推送為基礎的方法中，您會使用 Pub/Sub 到 Splunk Dataflow 範本，將記錄串流傳送至 Splunk HTTP Event Collector (HEC)。參考架構也說明瞭資料流程容量規劃，以及如何在發生暫時性伺服器或網路問題時，處理可能發生的提交失敗情形。

雖然這個參考架構著重於 Google Cloud 記錄，但同樣的架構也可用於匯出其他 Google Cloud 資料，例如即時資產變更和安全性發現。只要整合 Cloud Logging 的記錄，您就能繼續使用 Splunk 等現有的合作夥伴服務，做為統一記錄分析解決方案。

以推送為基礎的方法可將 Google Cloud 資料串流至 Splunk，具有以下優點：

  • 代管服務。作為代管服務，Dataflow 會維護資料處理作業 (例如記錄檔匯出作業) 所需的資源。 Google Cloud
  • 分散式工作負載。這個方法可讓您將工作負載分散至多個工作站，以便並行處理，因此不會發生單一故障點。
  • 安全性。由於 Google Cloud 會將資料推送至 Splunk HEC，因此您不必擔心建立及管理服務帳戶金鑰的維護和安全問題。
  • 自動調度資源。Dataflow 服務會根據傳入記錄的數量和待處理工作量變化，自動調整工作站數量。
  • 容錯功能：如果發生暫時性伺服器或網路問題，以推送為主的做法會自動嘗試將資料重新傳送至 Splunk HEC。它也支援未處理的主題 (又稱為無效信件主題)，可用於處理任何無法傳送的記錄訊息，避免資料遺失。
  • 簡單易用：您不必在 Splunk 中管理一或多個重型轉發器，也不必為此付費。

這個參考架構適用於許多產業別的企業，包括製藥和金融服務等受監管的產業。選擇將 Google Cloud 資料匯出至 Splunk 時，您可能會考量以下原因：

  • 業務數據分析
  • IT 維運
  • 應用程式效能監控
  • 資安營運
  • 法規遵循

設計替代方案

將記錄匯出至 Splunk 的另一種方法，是從Google Cloud擷取記錄。在這種以拉取為基礎的方法中，您可以使用 Google Cloud API 透過 Splunk Google Cloud外掛程式擷取資料。您可能會在下列情況下選擇使用以拉取為基礎的方法：

  • 您的 Splunk 部署沒有提供 Splunk HEC 端點。
  • 記錄資料量偏低。
  • 您想匯出及分析 Cloud Monitoring 指標、Cloud Storage 物件、Cloud Resource Manager API 中繼資料、Cloud Billing 資料或記錄檔。
  • 您已在 Splunk 中管理一或多個重型轉送器。
  • 您使用代管的 Splunk Cloud 專用輸入資料管理工具。

此外，請注意使用這項以拉取為基礎的方法時，可能會產生的其他考量：

  • 單一 worker 會處理資料攝入工作負載，但不提供自動調整資源配置功能。
  • 在 Splunk 中，使用重型轉送器來擷取資料可能會導致單一故障點。
  • 使用以提取為基礎的方法時，您必須建立及管理服務帳戶金鑰，以便用於設定 Google Cloud的 Splunk 外掛程式。

使用 Splunk 外掛程式前，必須先使用記錄接收器將記錄項目路由至 Pub/Sub。如要建立以 Pub/Sub 主題做為目的地的記錄檔接收器，請參閱「建立接收器」。請務必將 Pub/Sub 發布者角色 (roles/pubsub.publisher) 授予接收器的寫入者身分，以便在該 Pub/Sub 主題目的地使用。如要進一步瞭解如何設定接收器目的地權限，請參閱「設定目的地權限」。

如要啟用 Splunk 外掛程式，請執行下列步驟：

  1. 在 Splunk 中，按照 Splunk 操作說明安裝 Splunk 外掛程式 Google Cloud。
  2. 如果尚未建立，請針對記錄會傳送至的 Pub/Sub 主題建立 Pub/Sub 拉取訂閱項目。
  3. 建立服務帳戶。
  4. 為剛建立的服務帳戶建立服務帳戶金鑰。
  5. 將 Pub/Sub 檢視者 (roles/pubsub.viewer) 和 Pub/Sub 訂閱者 (roles/pubsub.subscriber) 角色授予服務帳戶，讓帳戶接收 Pub/Sub 訂閱項目中的訊息。

  6. 在 Splunk 中，按照 Splunk 操作說明在 Google Cloud的 Splunk 外掛程式中設定新的 Pub/Sub 輸入來源。

    記錄匯出作業產生的 Pub/Sub 訊息會顯示在 Splunk 中。

如要確認外掛程式是否正常運作，請執行下列步驟：

  1. 在 Cloud Monitoring 中開啟 Metrics Explorer。
  2. 在「Resources」選單中，選取 pubsub_subscription。
  3. 在「指標」類別中，選取 pubsub/subscription/pull_message_operation_count。
  4. 監控訊息拉取作業的數量，持續一到兩分鐘。

設計須知

您可以參考下列指南，開發符合貴機構安全性、隱私權、法規遵循、營運效率、可靠性、容錯性、效能和成本最佳化等需求的架構。

安全性、隱私權和法規遵循

以下各節將說明此參考架構的安全性考量：

使用私人 IP 位址保護支援 Dataflow 管道的 VM

您應限制對 Dataflow 管道中所用工作站 VM 的存取權。如要限制存取權，請使用私人 IP 位址部署這些 VM。不過，這些 VM 也必須能夠使用 HTTPS，將匯出的記錄串流至 Splunk 並存取網際網路。如要提供這項 HTTPS 存取權，您需要使用 Cloud NAT 閘道，讓系統自動將 Cloud NAT IP 位址分配給需要的 VM。請務必將包含 VM 的子網路對應至 Cloud NAT 閘道。

啟用 Private Google Access

建立 Cloud NAT 閘道時，系統會自動啟用私人 Google 存取權。不過，如果您想讓具有私人 IP 位址的 Dataflow 工作者存取 Google Cloud API 和服務使用的外部 IP 位址，則必須手動為子網路啟用私人 Google 存取權。

將 Splunk HEC 入站流量限制在 Cloud NAT 使用的已知 IP 位址

如果您想將 Splunk HEC 的流量限制在已知 IP 位址的子集內，可以保留靜態 IP 位址，並手動將這些位址指派給 Cloud NAT 閘道。接著，視 Splunk 部署作業而定，您可以使用這些靜態 IP 位址設定 Splunk HEC 入站防火牆規則。如要進一步瞭解 Cloud NAT，請參閱「使用 Cloud NAT 設定及管理網路位址轉譯」。

將 Splunk HEC 權杖儲存在 Secret Manager 中

部署 Dataflow 管道時，您可以透過下列任一方式傳遞符記值：

  • 純文字
  • 使用 Cloud Key Management Service 金鑰加密的密文
  • 由 Secret Manager 加密及管理的密鑰版本

在這個參考架構中，您會使用 Secret Manager 選項，因為這個選項提供最簡單且最有效率的方式，保護 Splunk HEC 權杖。這個選項也會防止 Splunk HEC 權杖從 Dataflow 主控台或工作詳細資料中外洩。

Secret Manager 中的密鑰包含一系列密鑰版本。每個密鑰版本都會儲存實際的密鑰資料，例如 Splunk HEC 權杖。如果您日後選擇輪替 Splunk HEC 權杖，做為額外的安全措施，您可以將新權杖新增為此密鑰的新密鑰版本。如需密鑰輪替的一般資訊，請參閱「關於輪替時間表」。

建立自訂 Dataflow 工作站服務帳戶，遵循最低權限最佳做法

Dataflow 管道中的 worker 會使用 Dataflow worker 服務帳戶存取資源及執行作業。根據預設，工作站會將專案的 Compute Engine 預設服務帳戶做為 worker 服務帳戶使用，為 worker 授予專案中所有資源的廣泛權限。不過，如要在實際工作環境中執行 Dataflow 工作，建議您建立自訂服務帳戶，並授予最低必要的角色和權限。接著，您可以將這個自訂服務帳戶指派給 Dataflow 管道工作站。

下圖列出您必須指派給服務帳戶的必要角色，才能讓 Dataflow 工作站成功執行 Dataflow 工作。

指派給 Dataflow 工作者服務帳戶的必要角色。

如圖所示，您必須將下列角色指派給 Dataflow 工作站的服務帳戶：

  • Dataflow 管理員
  • Dataflow 工作者
  • Storage 物件管理員
  • Pub/Sub 訂閱者
  • Pub/Sub 檢視者
  • Pub/Sub 發布者
  • 密鑰存取器

如果您使用私人 CA，請使用內部根 CA 憑證設定 SSL 驗證

根據預設，Dataflow 管道會使用 Dataflow 工作站的預設信任存放區，驗證 Splunk HEC 端點的 SSL 憑證。如果您使用私人憑證授權單位 (CA) 簽署 Splunk HEC 端點使用的 SSL 憑證，可以將內部根 CA 憑證匯入信任儲存庫。資料流程 worker 就能使用匯入的憑證進行 SSL 憑證驗證。

您可以使用及匯入自己的內部根 CA 憑證，為使用自行簽署或私人簽署憑證的 Splunk 部署作業提供憑證。您也可以只為內部開發和測試用途，完全停用 SSL 驗證。這種內部根 CA 方法最適合用於非網際網路環境的內部 Splunk 部署作業。

詳情請參閱 Pub/Sub 到 Splunk Dataflow 範本參數 rootCaCertificatePath 和 disableCertificateValidation。

提升作業效率

以下各節說明這個參考架構的作業效率考量：

使用 UDF 在執行期間轉換記錄或事件

Pub/Sub 到 Splunk Dataflow 範本支援使用者定義函式 (UDF)，可用於自訂事件轉換。用途範例包括使用額外欄位強化記錄、遮蓋部分敏感欄位，或篩除不必要的記錄。使用 UDF 可讓您變更 Dataflow 管道的輸出格式，而無須重新編譯或維護範本程式碼本身。這個參考架構會使用 UDF 處理管道無法傳送至 Splunk 的訊息。

重播未處理的訊息

有時管道會收到傳送錯誤，並不會再嘗試傳送訊息。在這種情況下，Dataflow 會將這些未處理的訊息傳送至未處理的主題，如下圖所示。解決傳送失敗的根本原因後，您就可以重播未處理的訊息。

將記錄檔匯出至 Splunk 時的錯誤處理。

以下步驟概述上圖所示的程序：

  1. 從 Pub/Sub 到 Splunk 的主要傳送管道會自動將無法傳送的訊息轉送至未處理的主題，供使用者調查。

  2. 作業人員或網站可靠性工程師 (SRE) 會調查未處理的訂閱項目中失敗的訊息。作業員會排解並修正提交失敗的根本原因。舉例來說，修正 HEC 權杖設定錯誤可能會讓訊息順利傳送。

  3. 運算子會觸發重播失敗訊息管道。這個 Pub/Sub 到 Pub/Sub 管道 (在前述圖表的虛線部分中加粗標示) 是臨時管道，可將未處理訂閱項目中的失敗訊息移回原始記錄接收器主題。

  4. 主要傳送管道會重新處理先前失敗的郵件。這個步驟要求管道使用 UDF，以便正確偵測及解碼失敗的訊息酬載。以下程式碼是實作此條件解碼邏輯的範例函式，其中包含用於追蹤的提交嘗試次數計數：

    // If the message has already been converted to a Splunk HEC object
// with a stringified obj.event JSON payload, then it's a replay of
// a previously failed delivery.
// Unnest and parse the obj.event. Drop the previously injected
// obj.attributes such as errorMessage and timestamp
if (obj.event) {
 try {
   event = JSON.parse(obj.event);
   redelivery = true;
 } catch(e) {
   event = obj;
 }
} else {
 event = obj;
}

// Keep a tally of delivery attempts
event.delivery_attempt = event.delivery_attempt || 1;
if (redelivery) {
 event.delivery_attempt += 1;
}

可靠性和容錯能力

就可靠性和容錯性而言，下表 (表 1) 列出一些可能的 Splunk 提交錯誤。這份表格也會列出管道在將這些訊息轉送至未處理的主題之前，針對每則訊息記錄的對應 errorMessage 屬性。

表 1：Splunk 提交錯誤類型

提交錯誤類型 管道是否會自動重試？ errorMessage 屬性範例

暫時性網路錯誤

是

Read timed out

或

Connection reset

Splunk 伺服器 5xx 錯誤

是

Splunk write status code: 503

Splunk 伺服器 4xx 錯誤

否

Splunk write status code: 403

Splunk 伺服器發生問題

否

The target server failed to respond

Splunk SSL 憑證無效

否

Host name X does not match the certificate

使用者定義函式 (UDF) 中的 JavaScript 語法錯誤

否

ReferenceError: X is not defined

在某些情況下，管道會套用指數輪詢，並自動嘗試再次傳送訊息。舉例來說，當 Splunk 伺服器產生 5xx 錯誤代碼時，管道就需要重新傳送訊息。當 Splunk HEC 端點超載時，就會發生這些錯誤代碼。

或者，可能有持續性問題，導致訊息無法提交至 HEC 端點。針對這類持續性問題，管道不會再嘗試傳送訊息。以下是持續性問題的範例：

  • UDF 函式中的語法錯誤。
  • 無效的 HEC 權杖，導致 Splunk 伺服器產生 4xx「Forbidden」伺服器回應。

效能和成本最佳化

如要將效能和成本最佳化，您必須決定 Dataflow 管道的最大大小和總處理量。您必須計算正確的大小和吞吐量值，讓管道能夠處理來自上游 Pub/Sub 訂閱的每日記錄峰值 (GB/天) 和記錄訊息速率 (每秒事件數，或 EPS)。

您必須選取大小和傳輸量值，以免系統發生下列任一問題：

  • 因訊息積壓或訊息節流而造成的延遲。
  • 管道超額配置產生的額外費用。

完成大小和吞吐量計算後，您可以使用結果設定最佳管道，以平衡效能和成本。如要設定管道容量，請使用下列設定：

以下各節將說明這些設定。在適用情況下，這些部分也會提供使用各公式的公式和計算範例。這些計算範例和產生的值假設組織具有下列特徵：

  • 每天產生 1 TB 的記錄檔。
  • 平均郵件大小為 1 KB。
  • 持續性的峰值郵件比率是平均比率的兩倍。

由於您的 Dataflow 環境是獨一無二的，因此在完成各個步驟時，請將範例值替換為您機構的值。

機型

最佳做法：將 --worker-machine-type 標記設為 n2-standard-4，即可選取提供最佳效能/成本比的機器大小。

由於 n2-standard-4 機器類型可處理 12k EPS，建議您將此機器類型做為所有 Dataflow 工作站的基準。

針對這個參考架構，請將 --worker-machine-type 標記設為 n2-standard-4 值。

機器數量

最佳做法：設定 --max-workers 標記，以便控制處理預期最高 EPS 所需的工作站數量上限。

在資源使用量和負載發生變化時，Dataflow 自動調度資源功能可讓服務根據情況調整用來執行串流管道的工作站數量。為避免在自動調度資源時過度配置，建議您一律定義用於做為 Dataflow 工作站的虛擬機器數量上限。部署 Dataflow 管道時，您會使用 --max-workers 標記定義虛擬機器數量上限。

Dataflow 會以靜態方式佈建儲存體元件，如下所示：

  • 自動調整資源的管道會為每個可能的串流工作站部署一個資料永久磁碟。預設的永久磁碟大小為 400 GB，您可以使用 --max-workers 標記設定工作站數量上限。磁碟會在任何時間點掛載至執行中的 worker，包括啟動時。

  • 由於每個 worker 例項最多只能使用 15 個永久磁碟，因此啟動的工作站數量下限為 ⌈--max-workers/15⌉。因此，如果預設值為 --max-workers=20，管道用量 (和成本) 如下：

    • 儲存空間：靜態，含 20 個永久磁碟。
    • 運算：動態，至少有 2 個 worker 執行個體 (⌈20/15⌉ = 2)，最多 20 個。

    這個值等同於 8 TB 的永久磁碟。如果磁碟未完全使用，這個永久磁碟的大小可能會產生不必要的費用，尤其是當大部分時間只有一或兩個 worker 在執行時。

如要判斷管道所需的工作站數量上限，請依序使用下列公式：

  1. 使用下列公式，判斷每秒平均事件數 (EPS)：

    \( {AverageEventsPerSecond}\simeq\frac{TotalDailyLogsInTB}{AverageMessageSizeInKB}\times\frac{10^9}{24\times3600} \)

    計算示例：假設每天記錄 1 TB 的記錄，且平均訊息大小為 1 KB，這個公式會產生平均 EPS 值 11.5k EPS。

  2. 請使用下列公式判斷持續的峰值 EPS，其中調節係數 N 代表記錄的突發性質：

    \( {PeakEventsPerSecond = N \times\ AverageEventsPerSecond} \)

    計算示例：假設 N=2 的值為示例值，且您在前一個步驟中計算出的平均 EPS 值為 11.5k，此公式會產生 23k EPS 的持續高峰 EPS 值。

  3. 請使用下列公式，判斷所需的 vCPU 數量上限：

    \( {maxCPUs = ⌈PeakEventsPerSecond / 3k ⌉} \)

    計算示例：使用您在前一個步驟計算的持續峰值 EPS 為 23k，這個公式會產生 ⌈23 / 3⌉ = 8 個 vCPU 核心。

  4. 使用下列公式，判斷 Dataflow 工作站的數量上限：

    \( maxNumWorkers = ⌈maxCPUs / 4 ⌉ \)

    計算示例：以上一個步驟計算出的 vCPU 上限值為 8，因此這個公式 [8/4] 會為 n2-standard-4 機器類型產生 2 個上限值。

在本範例中，您會根據先前的計算範例，將 --max-workers 旗標設為 2 值。不過，請務必在環境中部署此參考架構時，使用您自己的不重複值和計算。

平行處理任務數量

最佳做法：將 Pub/Sub 到 Splunk Dataflow 範本中的 parallelism 參數設為 Dataflow 工作站的最大數量所需 vCPU 數量的兩倍。

parallelism 參數可協助您盡量增加並行 Splunk HEC 連線的數量，進而提高管道的 EPS 率。

1 的預設 parallelism 值會停用並限制輸出率。您必須覆寫這個預設設定，以便針對每個 vCPU 的 2 到 4 個並行連線，部署工作站的數量上限。一般來說，您可以將 Dataflow 工作站的最大數量乘以每個工作站的 vCPU 數量，然後再乘以 2，即可計算此設定的覆寫值。

如要判斷所有 Dataflow 工作站與 Splunk HEC 的並行連線總數，請使用下列公式：

\( {parallelism = maxCPUs * 2} \)

計算範例：以先前計算的機器數量為例，上限 vCPU 數量為 8，因此這個公式會產生 8 x 2 = 16 個並行連線。

在本範例中，您可以根據先前範例的計算結果，將 parallelism 參數設為 16 的值。不過，請務必在環境中部署此參考架構時，使用您自己的專屬值和計算方式。

批次計數

最佳做法：如要讓 Splunk HEC 以批次處理事件，而不是逐一處理，請將 batchCount 參數設為 10 到 50 個事件/記錄要求的值。

設定批次計數有助於提高 EPS，並減少 Splunk HEC 端點的負載。這項設定會將多個事件合併為單一批次，以便更有效率地處理。建議您將 batchCount 參數設為 10 到 50 個事件/記錄要求的值，前提是您可以接受兩秒的最大緩衝延遲時間。

\( {batchCount >= 10} \)

由於本例中的平均記錄訊息大小為 1 KB，建議您每個要求至少批次處理 10 個事件。在本例中，您會將 batchCount 參數設為 10 值。不過，請務必在環境中部署此參考架構時，使用您自己的專屬值和計算方式。

如要進一步瞭解這些效能和成本最佳化建議，請參閱「規劃 Dataflow 管道」。

後續步驟