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 K8s | OpenTelemetry Collector | Collectord |
|---|---|---|---|
| 状态 | 已于 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 并行运行。
- 先在一个测试命名空间安装 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 天试用:全部功能、全部产品、不限安装数量
- 按集群的年度许可:可预测、简单
- 物理隔离环境许可:可按需为 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 的对比。