Splunk Connect for Kubernetes 的替代方案 - Collectord
Splunk Connect for Kubernetes 已終止支援
Splunk 於 2023 年宣布 Splunk Connect for Kubernetes（SCK）自 2024 年 1 月 1 日 起終止支援；其 GitHub 儲存庫也已於 2026 年 6 月封存。Splunk 建議的替代方案是 Splunk Distribution of OpenTelemetry Collector。目前仍有數千個叢集在執行 SCK，多數團隊都面臨同一個問題：遷移到 OTel，還是另尋出路？ 想逐項了解這兩條路在日常維運上的差異，請參閱 Collectord 與 OpenTelemetry Collector 的比較。
Collectord 就是那條「出路」。它是一款商用的容器原生日誌與指標代理程式，適用於 Kubernetes、OpenShift 與 Docker，並內含完整的 Splunk 應用程式（50 多個預建儀表板與 118 個警示範本）。資料流程與您使用 SCK 時相同，但要重新取得可用於正式環境的可視性，所需的工作量大幅減少。
並列比較
| 功能 | Splunk Connect for K8s | OpenTelemetry Collector | Collectord |
|---|---|---|---|
| 狀態 | 2024-01-01 終止支援 | 持續維護 | 持續維護，提供商用支援 |
| 預建 Splunk 儀表板 | 不支援 | Splunk 未為 Splunk Enterprise 或 Cloud 提供（Splunk Observability Cloud 中有 Kubernetes 導覽器）；Splunkbase 上有社群應用程式 | 內含 50 多個 |
| 預建 Splunk 警示 | 不支援 | Splunk Enterprise 或 Cloud 未提供；Splunk Observability Cloud 中有 AutoDetect 偵測器 | Alert Catalog 中 118 個範本，其中 10 個針對 etcd |
| 容器日誌轉送至 Splunk | 支援 | 支援 | 支援 |
| 從掛載磁碟區收集應用程式日誌（無需 sidecar） | 有限 | 僅限靜態節點路徑，無 Pod 中繼資料 | 一個 Pod 註解指定磁碟區；完整 Pod 中繼資料 |
| 容器、主機與程序指標 | 部分支援 | 支援（需設定） | 支援，預設啟用 |
| Kubernetes 事件 | 支援 | 支援（預設啟用） | 支援，附專屬儀表板 |
| Kubernetes 稽核日誌 | 支援 | 支援（需設定） | 支援，附專屬應用程式 |
| 透過註解自動探索 Prometheus | 不支援 | 可設定 | 支援，依 Pod 註解 |
| 抓取 Prometheus 端點至 Splunk 指標索引 | 不支援 | 支援 | 支援 |
| 透過 K8s 註解的自助式路由 | 部分支援 | index、sourcetype、exclude（Splunk 發行版） | 完整支援：index、source、type、output、遮罩、取樣、節流 |
| 各容器的吞吐量上限 | 不支援 | 不支援（上游有未處理的功能請求） | 支援，依容器註解設定 |
| 透過 CRD 的叢集層級原則 | 不支援 | 不支援 | Configuration CRD，force 覆寫 |
| 各命名空間的多租戶 SplunkOutput | 不支援 | 不支援 | SplunkOutput CRD，以 Secret 儲存權杖 |
| 同時輸出至多個 Splunk 端點 | 不支援 | 可設定 | 支援，依 Pod 扇出 |
| 轉送前的 PII 遮罩 / 雜湊 | 不支援 | 可設定 | 內建，由註解驅動 |
| 取樣（隨機 + 雜湊式） | 不支援 | 隨機 + 依屬性鍵值（日誌部分為 alpha 版） | 隨機 + 依鍵值 |
| 通過 FIPS 140 驗證的映像檔 | 不支援 | Splunk 發行版：符合 FIPS | amd64 + arm64 |
| Red Hat 認證映像檔 | 不支援 | 不支援 | 支援（OpenShift） |
| OpenShift 專案、DeploymentConfig、BuildConfig 與建置 | 僅日誌 | 僅日誌 | 各有專屬儀表板，另含 ClusterResourceQuota |
| 分散式追蹤 | 不支援 | 支援 | 不支援 |
| 建置可用於正式環境的儀表板所需時間 | 數小時至數天 | 數天至數週（需自建儀表板，或從 Splunkbase 社群應用程式起步） | 約 10 分鐘 |
| 廠商支援 | 僅社群支援 | 社群 + Splunk 付費支援 | Outcold Solutions，自 2017 年起 |
也需要追蹤功能嗎？ Collectord 專注於日誌、指標、事件與 Splunk 應用程式的涵蓋範圍，不收集分散式追蹤資料。這不成問題：讓 OpenTelemetry Collector 與 Collectord 並行執行，將追蹤資料送往 Splunk Observability Cloud（或任何 OTLP 後端）即可。兩套堆疊可以乾淨地共存，多數重視追蹤的團隊早已採用這種做法。
Collectord 實際帶給您的價值
完整的 Splunk 應用程式，而非只是資料管線
這是最關鍵的差異。SCK 把資料送進 Splunk 索引後就結束了；對於 Splunk Enterprise 或 Cloud，OpenTelemetry Collector 至多也只有社群應用程式。建置儀表板、撰寫警示，以及回答「etcd 是否健康？」或「哪個 Pod 正在被 OOM 終止？」這類問題，都得靠您從零開始撰寫 SPL。
Collectord 隨附 Monitoring Kubernetes 與 Monitoring OpenShift 兩款完整的 Splunk 應用程式：
- 工作負載調查：CrashLoopBackOff、OOMKilled、映像檔拉取失敗、探測失敗，皆有預建儀表板與警示範本
- 控制平面：Kubernetes API 伺服器、etcd（10 個警示範本）、kubelet、controller manager、scheduler、CoreDNS
- 容量：可配置資源、Pod/容器/主機/程序排行、命名空間資源用量
- 事件：於 26.04 全面重新設計，包含 Events Timeline、Events Overview、Workload Failures、Scheduling and Node Health、Recurring Problems
- 稽核與安全性：Kubernetes 稽核日誌儀表板、特權容器偵測、網路連線分析
- 儲存：PVC 空間追蹤、掛載統計、磁碟 I/O
- Prometheus：帶入您自己的應用程式指標，使用 Splunk 指標索引
- GPU：適用於 ML 工作負載的 NVIDIA 儀表板
- 警示：Alert Catalog 中的 118 個範本（Monitoring OpenShift 中為 117 個），可限定於叢集與命名空間，並附有建議的嚴重性、抑制與排程設定
透過 Kubernetes 註解的自助式路由
需要把某個命名空間的日誌送到獨立的索引？應用程式團隊想遮罩 PII 卻不想開單？想讓吵鬧的偵錯容器安靜下來？加一個註解就好。平台團隊只需設定 Collectord 一次，其餘一切都是自助式。註解系統具備優先順序模型，並可用 force: true 覆寫，確保合規關鍵規則不被繞過。
通過 FIPS 140 驗證的映像檔
針對聯邦政府、金融、醫療與其他受監管的環境，Collectord 提供 amd64 與 arm64 兩種架構的 FIPS 驗證容器映像檔，並有兩種模式：FIPS 啟用與 FIPS 強制（GODEBUG=fips140=only）。其他方案的現況如下：SCK 從未提供 FIPS 映像檔；上游的 OpenTelemetry Collector 沒有通過 FIPS 驗證的建置（上游 FIPS 稽核 仍未結案）；Splunk Distribution of OpenTelemetry Collector 則提供符合 FIPS 的 collector 映像檔。Collectord 的 FIPS 建置是完整的產品，與驅動 Splunk 應用程式的管線完全相同，以不含 shell 也不含套件管理程式、從零建置（from scratch）的映像檔封裝，並通過 Red Hat 的 OpenShift 認證。
→ Kubernetes 的 FIPS 說明 · OpenShift 的 FIPS 說明
多租戶就緒
為多個團隊執行共用叢集？每個團隊都能透過 SplunkOutput CRD 宣告自己的 Splunk 目的地，無需編輯 ConfigMap。權杖可存放在 Kubernetes Secret 中。依 Pod 扇出讓同一行日誌可以同時進入 SIEM 索引和應用程式索引。
從 Splunk Connect for Kubernetes 遷移
遷移路徑很直接，而且不必一次完成，切換期間 Collectord 可與 SCK 並行執行。
- 先在單一測試命名空間安裝 Collectord。 5 分鐘的安裝就能取得可運作的管線。使用命名空間註解限定 Collectord 一開始要轉送哪些 Pod。
- 重現您的 sourcetype 與索引路由。 SCK 的索引路由以 Helm values 為基礎；Collectord 則以註解或
ConfigurationCRD 為基礎。多數叢集不到一小時就能完成。 - 驗證儀表板。 Monitoring Kubernetes 應用程式數分鐘內即可安裝到 Splunk。您先前針對 SCK sourcetype 建置的儀表板，通常只需重新命名 sourcetype 即可重新對應。
- 逐一遷移命名空間。 加上命名空間註解，確認資料流動後，再將 SCK 從該命名空間移除。
- 拆除 SCK。 當所有命名空間都改用 Collectord 後，即可移除 SCK 的 Helm release。
若您希望有人帶著您走一遍，請申請展示，我們會在您的叢集上即時示範遷移流程。
團隊轉換的原因
我們常聽到的理由：
- 終止支援迫使團隊做出決定：選擇 OTel 就意味著重建儀表板
- 預建儀表板：省下數個月的儀表板工程
- 以註解為基礎的自助服務：平台團隊不想再成為路由設定的瓶頸
- FIPS：聯邦政府/金融客戶少了它就無法上線
- OpenShift 涵蓋範圍：專案、DeploymentConfig、BuildConfig 與建置、ClusterResourceQuota 的儀表板，以及 Red Hat 認證映像檔
- 更簡單的維運：一個二進位檔、一份資訊清單（也提供 Helm chart），不必維護含 200 個值的管線設定
價格與試用
Collectord 是商用軟體，提供 30 天免費試用，無需信用卡。
- 30 天試用：完整功能、所有產品、不限安裝數量
- 依叢集計費的年度授權：可預測、簡單明瞭
- 離線（實體隔離）授權：4,000 vCPU 起的 Business 與 Enterprise 合約提供，離線評估授權可依需求提供
常見問題
Collectord 是 SCK 的分支嗎？ 不是。Collectord 由 Outcold Solutions 獨立開發，自 2017 年起即用於正式環境，比 SCK 淘汰早了好幾年。
遷移期間可以讓 Collectord 與 SCK 並行執行嗎？ 可以。兩者是各自獨立的代理程式，您可以透過命名空間註解，一次遷移一個命名空間。
Collectord 可以轉送到 OpenSearch / Elasticsearch / syslog 嗎？ 可以，支援其他輸出目的地。請參閱轉送至 Elasticsearch與透過 syslog 轉送。
Splunk 應用程式是免費的嗎？ 應用程式發布於 SplunkBase，可免費下載，但它只是 Collectord 所轉送資料之上的 UI 層。沒有 Collectord 授權，儀表板就沒有資料可顯示。30 天免費試用涵蓋完整堆疊；之後若要繼續使用，則需要付費的 Collectord 授權。
你們支援 OpenTelemetry 追蹤嗎？ 目前不支援。若追蹤是必要功能，OpenTelemetry Collector 搭配 Splunk Observability Cloud 才是合適的堆疊。
我是否乾脆也用 OpenTelemetry Collector 收集日誌？ 可行，而且如果您要把同一份資料轉送到多個後端，這可能是正確的選擇。那裡的索引與 sourcetype 路由同樣以註解為基礎。取捨在於內容層級的控制：篩選、遮罩與取樣是以 Helm values 形式存在的 collector 管線設定，由平台團隊掌控；沒有各容器的吞吐量上限；而且 Splunk 未針對 Splunk Enterprise 或 Cloud 中的這些資料提供任何儀表板。我們撰寫了逐項比較：Collectord 與 OpenTelemetry Collector 的比較。
