Alternative à Splunk Connect for Kubernetes - Collectord

Splunk Connect for Kubernetes est arrivé en fin de support

En 2023, Splunk a annoncé la fin du support de Splunk Connect for Kubernetes (SCK) au 1er janvier 2024 ; le dépôt GitHub a été archivé en juin 2026. Le remplaçant recommandé par Splunk est la Splunk Distribution of OpenTelemetry Collector. Des milliers de clusters exécutent encore SCK, et la plupart des équipes se posent aujourd’hui la même question : migrer vers OTel, ou choisir autre chose ? Pour un examen tâche par tâche de ce que chaque option implique au quotidien, lisez Collectord vs OpenTelemetry Collector.

Collectord est cet « autre chose ». C’est un agent commercial de collecte de logs et de métriques, natif pour les conteneurs, destiné à Kubernetes, OpenShift et Docker, application Splunk complète incluse - 50+ tableaux de bord et 39+ alertes prêts à l’emploi. Le même flux de données qu’avec SCK, avec nettement moins de travail pour retrouver une visibilité prête pour la production.

Comparaison côte à côte

Besoin de traçage aussi ? Collectord se concentre sur les logs, les métriques, les événements et la couverture de l’application Splunk - il ne collecte pas les traces distribuées. Ce n’est pas un problème : exécutez l’OpenTelemetry Collector à côté de Collectord et routez les traces vers Splunk Observability Cloud (ou tout backend OTLP). Les deux piles coexistent proprement - la plupart des équipes qui tiennent au traçage le font déjà.

Ce que vous obtenez réellement avec Collectord

Une application Splunk complète - pas un simple pipeline de données

C’est la différence qui compte le plus. SCK et OTel livrent des données dans des index Splunk et s’arrêtent là. À vous de construire les tableaux de bord, d’écrire les alertes et de répondre à « etcd est-il en bonne santé ? » ou « quel pod est tué par OOM ? » en écrivant du SPL à partir de zéro.

Collectord livre Monitoring Kubernetes et Monitoring OpenShift sous forme d’applications Splunk complètes :

• Investigation des workloads : CrashLoopBackOff, OOMKilled, échecs de pull d’image, échecs de probes - tableaux de bord et recherches enregistrées prêts à l’emploi
• Plan de contrôle : serveur d’API Kubernetes, etcd (8 alertes dédiées), kubelet, controller manager, scheduler, CoreDNS
• Capacité : ressources allouables, top des pods/conteneurs/hôtes/processus, consommation des ressources par namespace
• Événements : repensés dans la version 26.04 - Events Timeline, Events Overview, Workload Failures, Scheduling and Node Health, Recurring Problems
• Audit et sécurité : tableaux de bord des logs d’audit Kubernetes, détection des conteneurs privilégiés, analyse des connexions réseau
• Stockage : suivi de l’espace des PVC, statistiques des montages, E/S disque
• Prometheus : apportez vos propres métriques applicatives, utilisez l’index de métriques Splunk
• GPU : tableau de bord NVIDIA pour les workloads de ML

→ Parcourir les tableaux de bord

Routage en libre-service via les annotations Kubernetes

Besoin des logs d’un namespace dans un index séparé ? Qu’une équipe applicative masque des PII sans ouvrir de ticket ? De faire taire un conteneur de debug bavard ? Ajoutez une annotation. L’équipe plateforme configure Collectord une fois ; tout le reste est en libre-service. Le système d’annotations repose sur un modèle de priorité avec des surcharges force: true pour les règles critiques en matière de conformité.

→ Comment fonctionnent les annotations en couches

Images validées FIPS 140

Pour le secteur public, la finance, la santé et les autres environnements réglementés, Collectord fournit des images de conteneur validées FIPS pour amd64 et arm64. Deux modes - FIPS activé et FIPS imposé (GODEBUG=fips140=only). Où en sont les alternatives : SCK n’a jamais eu d’images FIPS, l’OpenTelemetry Collector amont n’a pas de builds validés FIPS (l’audit FIPS amont est toujours ouvert), et la Splunk Distribution of OpenTelemetry Collector fournit des images de collector conformes FIPS. Le build FIPS de Collectord est le produit complet - le même pipeline qui alimente les applications Splunk - empaqueté dans une image from-scratch, sans shell ni gestionnaire de paquets, et certifié Red Hat pour OpenShift.

→ FIPS pour Kubernetes · FIPS pour OpenShift

Prêt pour le multi-tenant

Vous exploitez un cluster partagé entre de nombreuses équipes ? Chaque équipe peut déclarer sa propre destination Splunk via la CRD SplunkOutput, sans modifier la ConfigMap. Les jetons peuvent résider dans des Secrets Kubernetes. Le fan-out par pod permet à une même ligne de log d’atterrir simultanément dans un index SIEM et dans un index applicatif.

Migrer depuis Splunk Connect for Kubernetes

La migration est simple, et vous n’avez pas à tout faire d’un coup - Collectord peut tourner à côté de SCK pendant la bascule.

1. Installez Collectord sur un seul namespace de test. Une installation de 5 minutes vous donne un pipeline fonctionnel. Utilisez les annotations de namespace pour délimiter les pods que Collectord transfère dans un premier temps.
2. Reproduisez votre routage de sourcetypes et d’index. Le routage d’index de SCK reposait sur des valeurs Helm ; celui de Collectord repose sur des annotations ou une CRD Configuration. La plupart des clusters peuvent le reproduire en moins d’une heure.
3. Vérifiez les tableaux de bord. L’application Monitoring Kubernetes s’installe dans Splunk en quelques minutes. Les tableaux de bord que vous aviez construits sur les sourcetypes SCK peuvent généralement être reciblés en renommant le sourcetype.
4. Migrez namespace par namespace. Ajoutez l’annotation de namespace, observez le flux de données, retirez SCK de ce namespace.
5. Désinstallez SCK. Une fois chaque namespace passé sur Collectord, la release Helm de SCK peut être supprimée.

Si vous souhaitez être accompagné, demandez une démo et nous ferons une démonstration de migration en direct sur votre cluster.

Pourquoi les équipes changent

Les raisons que nous entendons le plus souvent :

• La dépréciation a forcé une décision - et OTel signifiait reconstruire les tableaux de bord
• Des tableaux de bord prêts à l’emploi - des mois d’ingénierie de tableaux de bord évités
• Le libre-service par annotations - les équipes plateforme ne veulent plus être le goulot d’étranglement du routage
• FIPS - les clients du secteur public et de la finance ne peuvent pas s’en passer
• La couverture OpenShift - tableaux de bord pour les projets, DeploymentConfigs, BuildConfigs et builds, ClusterResourceQuotas, et une image certifiée Red Hat
• Une exploitation plus simple - un binaire, un manifeste (un chart Helm est aussi disponible), pas de configuration de pipeline à 200 valeurs à maintenir

Tarifs et essai

Collectord est un logiciel commercial avec un essai gratuit de 30 jours - sans carte bancaire.

• Essai de 30 jours - toutes les fonctionnalités, tous les produits, sans limite d’installations
• Licence annuelle par cluster - prévisible, simple
• Licence air-gapped - disponible sur demande pour les environnements FIPS / classifiés

→ Démarrer votre essai · Tarifs · Contacter l’équipe commerciale

Questions fréquentes

Collectord est-il un fork de SCK ? Non. Collectord est développé de façon indépendante par Outcold Solutions, est en production depuis 2017 et précède de plusieurs années la dépréciation de SCK.

Puis-je exécuter Collectord à côté de SCK pendant la migration ? Oui - ce sont des agents indépendants, et vous pouvez migrer les namespaces un par un à l’aide des annotations de namespace.

Collectord transfère-t-il vers OpenSearch / Elasticsearch / syslog ? Oui - d’autres destinations de sortie sont prises en charge. Voir transfert vers Elasticsearch et transfert via syslog.

L’application Splunk est-elle gratuite ? L’application est publiée sur SplunkBase et gratuite au téléchargement - mais c’est une couche d’interface au-dessus des données que Collectord transfère. Sans licence Collectord, les tableaux de bord n’ont rien à afficher. L’essai gratuit de 30 jours couvre toute la pile ; une licence Collectord payante est ensuite nécessaire pour continuer à l’utiliser.

Prenez-vous en charge les traces OpenTelemetry ? Pas aujourd’hui. Si le traçage est essentiel, OpenTelemetry Collector + Splunk Observability Cloud est la bonne pile.

Devrais-je simplement utiliser l’OpenTelemetry Collector pour les logs aussi ? Cela fonctionne, et si vous transférez les mêmes données vers plusieurs backends, ce peut être le bon choix. Le routage des index et des sourcetypes y est aussi basé sur des annotations. Le compromis porte sur les contrôles au niveau du contenu : le filtrage, le masquage et l’échantillonnage vivent dans des valeurs Helm, sous forme de configuration du pipeline du collector détenue par l’équipe plateforme, il n’y a pas de plafonds de débit par conteneur, et Splunk ne fournit aucun tableau de bord pour ces données. Nous avons rédigé une comparaison tâche par tâche : Collectord vs OpenTelemetry Collector.