Splunk Connect for Kubernetes 的替代方案 - Collectord

Splunk Connect for Kubernetes 已停止支持

2023 年,Splunk 宣布停止对 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 个以上的预构建仪表板和 39 个以上的预构建告警。数据流与您在 SCK 上的完全相同,而恢复生产级可见性所需的工作量却大幅减少。

功能对比

功能对比:Splunk Connect for Kubernetes(已弃用)、OpenTelemetry Collector 与 Collectord,涵盖状态、仪表板、告警、日志/指标收集、安全和支持。
功能Splunk Connect for K8sOpenTelemetry CollectorCollectord
状态已于 2024-01-01 停止支持活跃维护中活跃维护中,提供商业支持
预构建 Splunk 仪表板不支持Splunk 未提供内置 50 个以上
预构建 Splunk 告警不支持Splunk 未提供内置 39 个以上
容器日志转发到 Splunk支持支持支持
从挂载卷收集应用程序日志(无需边车)有限支持仅静态节点路径,无 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
分布式追踪不支持支持不支持
达到生产级仪表板所需的部署时间数小时至数天数天至数周(需自行构建仪表板)约 10 分钟
厂商支持仅社区社区 + Splunk 付费支持Outcold Solutions,自 2017 年起

也需要追踪功能? Collectord 专注于日志、指标、事件以及 Splunk 应用的覆盖,不收集分布式追踪数据。这并不是问题:将 OpenTelemetry Collector 与 Collectord 并行运行,把追踪数据路由到 Splunk Observability Cloud(或任何 OTLP 后端)即可。两套技术栈可以互不干扰地共存,大多数重视追踪的团队已经在这样做。

Collectord 实际为您带来什么

完整的 Splunk 应用,而不只是数据管道

这是最重要的区别。SCK 和 OTel 把数据送入 Splunk 索引就止步了。构建仪表板、编写告警,以及回答“etcd 是否健康?”或“哪个 Pod 正在被 OOM 终止?”这类问题,都得靠您从零开始编写 SPL。

Collectord 将 Monitoring Kubernetes 和 Monitoring OpenShift 作为完整的 Splunk 应用一并提供:

  • 工作负载排查:CrashLoopBackOff、OOMKilled、镜像拉取失败、探针失败,均有预构建的仪表板和已保存搜索
  • 控制平面:Kubernetes API 服务器、etcd(8 个专用告警)、kubelet、控制器管理器、调度器、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 仪表板

→ 浏览仪表板

通过 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 标准的收集器镜像。Collectord 的 FIPS 构建就是完整的产品本身,与驱动 Splunk 应用的是同一条管道,打包为不含 shell 和包管理器的 from-scratch 镜像,并通过了面向 OpenShift 的 Red Hat 认证。

→ Kubernetes 的 FIPS · OpenShift 的 FIPS

多租户就绪

您运行的是供多个团队共用的集群?每个团队都可以通过 SplunkOutput CRD 声明自己的 Splunk 目标,无需编辑 ConfigMap。令牌可以存放在 Kubernetes Secret 中。按 Pod 扇出可以让同一行日志同时进入 SIEM 索引和应用索引。

从 Splunk Connect for Kubernetes 迁移

迁移路径很直接,而且不必一次完成:切换期间 Collectord 可以与 SCK 并行运行。

  1. 先在一个测试命名空间安装 Collectord。 5 分钟的安装就能得到一条可用的管道。使用命名空间注解限定 Collectord 最初转发哪些 Pod。
  2. 重现您的 sourcetype 和索引路由。 SCK 的索引路由基于 Helm values,Collectord 的则基于注解或 Configuration CRD。大多数集群不到一小时就能完成重现。
  3. 验证仪表板。 Monitoring Kubernetes 应用几分钟内即可安装到 Splunk 中。您之前针对 SCK sourcetype 构建的仪表板,通常只需重命名 sourcetype 即可重新指向新数据。
  4. 逐个命名空间迁移。 添加命名空间注解,观察数据流入,然后在该命名空间中停用 SCK。
  5. 拆除 SCK。 当每个命名空间都已切换到 Collectord,就可以卸载 SCK 的 Helm release。

如果您希望有人协助您完成整个过程,请申请演示,我们会在您的集群上进行一次实时迁移演示。

团队为何选择切换

我们常听到的原因:

  • 弃用迫使团队做出决定:选择 OTel 就意味着重建仪表板
  • 预构建仪表板:省去数月的仪表板开发工作
  • 基于注解的自助服务:平台团队不想再成为路由变更的瓶颈
  • FIPS:联邦政府 / 金融客户没有它就无法上线
  • OpenShift 覆盖:为项目、DeploymentConfig、BuildConfig 和构建、ClusterResourceQuota 提供仪表板,并有 Red Hat 认证镜像
  • 更简单的运维:一个二进制文件、一个清单(也提供 Helm chart),无需维护 200 个值的管道配置

价格与试用

Collectord 是商业软件,提供 30 天免费试用,无需信用卡。

  • 30 天试用:全部功能、全部产品、不限安装数量
  • 按集群的年度许可:可预测、简单
  • 物理隔离环境许可:可按需为 FIPS / 涉密环境提供

→ 开始试用 · 价格 · 联系销售

常见问题

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 中,由平台团队掌管;没有按容器的吞吐量上限;Splunk 也不为这些数据提供仪表板。我们逐项写了一篇对比:Collectord 与 OpenTelemetry Collector 的对比。

告别自建。专注运维。

30 天免费试用。无需信用卡。不限安装数量。`kubectl apply` 之后十分钟内即可看到可用的仪表板。

关于 Outcold Solutions

Outcold Solutions 为 Splunk Enterprise 和 Splunk Cloud 开发应用程序。我们经过认证的监控解决方案以 Collectord 为核心,将 Kubernetes、OpenShift 和 Docker 集群、Linux 主机以及 Windows 容器的日志、指标和事件送入 Splunk,并提供相应的仪表板和告警,帮助开发人员关注应用程序的运行状况,帮助运维人员保持集群健康。我们的搜索应用无需摄取任何数据,即可在搜索栏中实时查询 Kubernetes 和 AWS;OS AI Agent 则让您选择的模型在 Splunk 中工作,并使用每位用户自己的权限。自 2017 年以来,我们一直帮助企业将解答基础设施复杂问题所需的一切集中在一处。

Red Hat
Splunk
AWS