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 です。Collectord は Kubernetes、OpenShift、Docker 向けのコンテナネイティブな商用ログ・メトリクス収集エージェントで、完全な Splunk アプリ (50以上の事前構築済みダッシュボードと39以上の事前構築済みアラート) が付属します。SCK と同じデータフローのまま、本番運用レベルの可視性を取り戻すための作業を大幅に減らせます。

機能比較

トレーシングも必要ですか？ Collectord はログ、メトリクス、イベント、そして Splunk アプリによる可視化に特化しており、分散トレースは収集しません。これは問題になりません。OpenTelemetry Collector を Collectord と並行して実行し、トレースを Splunk Observability Cloud (または任意の OTLP バックエンド) に送信してください。2つのスタックは問題なく共存でき、トレーシングを重視するチームの多くがすでにこの構成を採用しています。

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) の2種類です。他の選択肢の状況は次のとおりです。SCK には FIPS イメージが存在せず、アップストリームの OpenTelemetry Collector には FIPS 検証済みビルドがありません (アップストリームの FIPS 監査 は未解決のままです)。Splunk Distribution of OpenTelemetry Collector は FIPS 準拠のコレクターイメージを提供しています。Collectord の FIPS ビルドは製品そのものであり、Splunk アプリを支えるパイプラインと同一です。シェルもパッケージマネージャーも含まない scratch ベースのイメージとしてパッケージ化され、OpenShift 向けに Red Hat の認定を受けています。

→ Kubernetes 向け FIPS · OpenShift 向け FIPS

マルチテナント対応

多数のチームが利用する共有クラスターを運用していますか？各チームは ConfigMap を編集することなく、SplunkOutput CRD で自チームの Splunk 送信先を宣言できます。トークンは Kubernetes Secret に保存できます。Pod 単位のファンアウトにより、1行のログを SIEM 用インデックスとアプリケーション用インデックスの両方に同時に送信できます。

Splunk Connect for Kubernetes からの移行

移行手順はシンプルで、一度にすべてを切り替える必要はありません。切り替え期間中は Collectord を SCK と並行して実行できます。

1. テスト用のネームスペースを1つ決めて Collectord をインストールします。 インストールは5分で完了し、動作するパイプラインがすぐに手に入ります。初期段階で Collectord が転送する Pod は、ネームスペースのアノテーションで絞り込みます。
2. ソースタイプとインデックスのルーティングを再現します。 SCK のインデックスルーティングは Helm の values で定義されていましたが、Collectord ではアノテーションまたは Configuration CRD で定義します。ほとんどのクラスターでは1時間以内に再現できます。
3. ダッシュボードを確認します。 Monitoring Kubernetes アプリは数分で Splunk にインストールできます。SCK のソースタイプ向けに構築した既存のダッシュボードは、多くの場合ソースタイプ名を変更するだけで流用できます。
4. ネームスペース単位で移行します。 ネームスペースにアノテーションを追加し、データが流れることを確認してから、そのネームスペースを SCK の収集対象から外します。
5. SCK を撤去します。 すべてのネームスペースが Collectord に移行したら、SCK の Helm リリースを削除します。

移行のサポートが必要な場合は、デモを依頼してください。お客様のクラスターで移行手順をライブでご案内します。

チームが乗り換える理由

よく伺う理由は次のとおりです。

• サポート終了で決断を迫られた：OTel を選ぶとダッシュボードを一から作り直すことになる
• 事前構築済みダッシュボード：数か月分のダッシュボード開発が不要になる
• アノテーションによるセルフサービス：プラットフォームチームがルーティング変更のボトルネックにならずに済む
• FIPS：連邦政府や金融のお客様には必須の要件
• OpenShift 対応：プロジェクト、DeploymentConfig、BuildConfig とビルド、ClusterResourceQuota のダッシュボード、および Red Hat 認定イメージ
• 運用のシンプルさ：バイナリ1つ、マニフェスト1つ (Helm チャート も利用可能)。200個もの値を持つパイプライン設定を保守する必要がない

価格とトライアル

Collectord は商用ソフトウェアで、30日間の無料トライアルを提供しています。クレジットカードは不要です。

• 30日間トライアル：全機能、全製品、インストール数の制限なし
• クラスター単位の年間ライセンス：予測しやすくシンプル
• エアギャップ環境向けライセンス：FIPS 環境や機密環境向けに、ご要望に応じて提供

→ トライアルを開始 · 価格 · 営業担当に問い合わせる

よくある質問

Collectord は SCK のフォークですか？ いいえ。Collectord は Outcold Solutions が独自に開発したもので、2017年から本番環境で利用されており、SCK の非推奨化より何年も前から存在しています。

移行中に Collectord を SCK と並行して実行できますか？ はい。両者は独立したエージェントであり、ネームスペースのアノテーションを使ってネームスペースを1つずつ移行できます。

Collectord は OpenSearch / Elasticsearch / syslog に転送できますか？ はい。他の出力先にも対応しています。Elasticsearch への転送 と syslog 経由の転送 をご覧ください。

Splunk アプリは無料ですか？ アプリは SplunkBase で公開されており、無料でダウンロードできます。ただし、このアプリは Collectord が転送するデータの上に載る UI レイヤーです。Collectord のライセンスがなければ、ダッシュボードに表示するデータがありません。30日間の無料トライアルはスタック全体を対象としており、その後も使い続けるには Collectord の有償ライセンスが必要です。

OpenTelemetry のトレースには対応していますか？ 現時点では対応していません。トレーシングが不可欠な場合は、OpenTelemetry Collector と Splunk Observability Cloud の組み合わせが適切な構成です。

ログも OpenTelemetry Collector に任せればよいのではないですか？ 動作はしますし、同じデータを複数のバックエンドに転送するなら、それが正解になることもあります。インデックスとソースタイプのルーティングは、OpenTelemetry Collector でもアノテーションベースです。トレードオフはコンテンツレベルの制御にあります。フィルタリング、マスキング、サンプリングはプラットフォームチームが管理するコレクターのパイプライン設定として Helm の values に置かれ、コンテナ単位のスループット上限はなく、そのデータ向けのダッシュボードは Splunk から提供されません。タスクごとの比較記事を用意しています。Collectord と OpenTelemetry Collector の比較 をご覧ください。