Alternativa a Splunk Connect for Kubernetes - Collectord

Splunk Connect for Kubernetes ha raggiunto la fine del supporto

Nel 2023 Splunk ha annunciato la fine del supporto (End of Support) per Splunk Connect for Kubernetes (SCK) con effetto dal 1° gennaio 2024; il repository GitHub è stato archiviato a giugno 2026. Il sostituto consigliato da Splunk è la Splunk Distribution of OpenTelemetry Collector. Migliaia di cluster eseguono ancora SCK, e la maggior parte dei team si trova ora davanti alla stessa domanda: migrare a OTel o scegliere qualcos’altro? Per un confronto attività per attività di ciò che ciascuna strada comporta nel lavoro quotidiano, si veda Collectord vs OpenTelemetry Collector.

Collectord è quel qualcos’altro: un agente commerciale e container-native per log e metriche su Kubernetes, OpenShift e Docker, con un’app Splunk completa - 50+ dashboard predefinite e 39+ alert predefiniti - inclusa. Lo stesso flusso di dati che si aveva con SCK, con molto meno lavoro per tornare ad avere una visibilità pronta per la produzione.

Confronto punto per punto

Serve anche il tracing? Collectord si concentra su log, metriche, eventi e copertura dell’app Splunk - non raccoglie tracce distribuite. Non è un problema: si esegue l’OpenTelemetry Collector accanto a Collectord e si instradano le tracce verso Splunk Observability Cloud (o qualsiasi backend OTLP). I due stack convivono senza attriti - la maggior parte dei team a cui interessa il tracing fa già così.

Cosa si ottiene davvero con Collectord

Un’app Splunk completa - non una semplice pipeline di dati

È la differenza che conta di più. SCK e OTel consegnano i dati negli indici Splunk e si fermano lì. Costruire le dashboard, scrivere gli alert e rispondere a domande come “etcd è in salute?” o “quale pod va in OOMKilled?” resta a carico del team, che deve scrivere SPL da zero.

Collectord fornisce Monitoring Kubernetes e Monitoring OpenShift come app Splunk complete:

• Analisi dei workload: CrashLoopBackOff, OOMKilled, errori di pull delle immagini, probe fallite - dashboard predefinite e ricerche salvate
• Control plane: API server di Kubernetes, etcd (8 alert dedicati), kubelet, controller manager, scheduler, CoreDNS
• Capacità: risorse allocabili, top pod/container/host/processi, utilizzo delle risorse per namespace
• Eventi: riprogettati nella 26.04 - Events Timeline, Events Overview, Workload Failures, Scheduling and Node Health, Recurring Problems
• Audit e sicurezza: dashboard per i log di audit Kubernetes, rilevamento dei container privilegiati, analisi delle connessioni di rete
• Storage: monitoraggio dello spazio dei PVC, statistiche dei mount, I/O del disco
• Prometheus: le proprie metriche applicative, nell’indice metriche di Splunk
• GPU: dashboard NVIDIA per i workload ML

→ Sfoglia le dashboard

Routing self-service tramite annotazioni Kubernetes

I log di un namespace devono finire in un indice separato? Un team applicativo deve mascherare dati PII senza aprire un ticket? Un container di debug troppo rumoroso va messo a tacere? Basta un’annotazione. Il team di piattaforma configura Collectord una sola volta; tutto il resto è self-service. Il sistema di annotazioni ha un modello di precedenza con override force: true per le regole critiche ai fini della conformità.

→ Come funzionano le annotazioni a livelli

Immagini validate FIPS 140

Per la pubblica amministrazione, il settore finanziario, la sanità e gli altri ambienti regolamentati, Collectord fornisce immagini container validate FIPS sia per amd64 sia per arm64. Due modalità - FIPS-enabled e FIPS-enforced (GODEBUG=fips140=only). A che punto sono le alternative: SCK non ha mai avuto immagini FIPS, l’OpenTelemetry Collector upstream non ha build validate FIPS (l’audit FIPS upstream è ancora aperto) e la Splunk Distribution of OpenTelemetry Collector fornisce immagini del collector conformi FIPS. La build FIPS di Collectord è il prodotto completo - la stessa pipeline che alimenta le app Splunk - confezionata come immagine from-scratch senza shell e senza package manager, e certificata Red Hat per OpenShift.

→ FIPS per Kubernetes · FIPS per OpenShift

Pronto per il multi-tenant

Un cluster condiviso tra molti team? Ogni team può dichiarare la propria destinazione Splunk tramite la CRD SplunkOutput, senza modifiche alla ConfigMap. I token possono risiedere in Secret di Kubernetes. Il fan-out per pod fa arrivare la stessa riga di log in un indice SIEM e in un indice applicativo contemporaneamente.

Migrare da Splunk Connect for Kubernetes

Il percorso di migrazione è lineare e non deve essere completato tutto in una volta - Collectord può funzionare in parallelo a SCK durante il passaggio.

1. Installare Collectord su un singolo namespace di test. Un’installazione di 5 minuti fornisce una pipeline funzionante. Le annotazioni sui namespace delimitano quali pod Collectord inoltra inizialmente.
2. Riprodurre il routing di sourcetype e indici. Il routing degli indici di SCK si basava sui values di Helm; quello di Collectord si basa sulle annotazioni o su una CRD Configuration. Nella maggior parte dei cluster si replica in meno di un’ora.
3. Verificare le dashboard. L’app Monitoring Kubernetes si installa in Splunk in pochi minuti. Le dashboard costruite in precedenza sui sourcetype di SCK si possono in genere riadattare rinominando il sourcetype.
4. Migrare namespace per namespace. Aggiungere l’annotazione al namespace, verificare il flusso dei dati, dismettere SCK per quel namespace.
5. Rimuovere SCK. Quando tutti i namespace sono su Collectord, si disinstalla la release Helm di SCK.

Se desidera un supporto durante il percorso, richieda una demo e faremo insieme una migrazione guidata dal vivo sul Suo cluster.

Perché i team passano a Collectord

Le motivazioni che sentiamo più spesso:

• La deprecazione ha imposto una scelta - e OTel avrebbe significato ricostruire le dashboard
• Dashboard predefinite - mesi di sviluppo di dashboard risparmiati
• Self-service basato sulle annotazioni - i team di piattaforma non vogliono più essere il collo di bottiglia del routing
• FIPS - i clienti della pubblica amministrazione e del settore finanziario non possono andare in produzione senza
• Copertura OpenShift - dashboard per progetti, DeploymentConfigs, BuildConfigs e build, ClusterResourceQuotas e un’immagine certificata Red Hat
• Operatività più semplice - un binario, un manifest (è disponibile anche un Helm chart), nessuna configurazione di pipeline da 200 values da mantenere

Prezzi e prova

Collectord è un software commerciale con una prova gratuita di 30 giorni - senza carta di credito.

• Prova di 30 giorni - tutte le funzionalità, tutti i prodotti, nessun limite di installazioni
• Licenza annuale per cluster - prevedibile e semplice
• Licenza air-gapped - disponibile su richiesta per ambienti FIPS / classificati

→ Inizia la prova · Prezzi · Contatta il team commerciale

Domande frequenti

Collectord è un fork di SCK? No. Collectord è sviluppato in modo indipendente da Outcold Solutions, è in produzione dal 2017 e precede di anni la deprecazione di SCK.

È possibile eseguire Collectord insieme a SCK durante la migrazione? Sì - sono agenti indipendenti, e i namespace si possono spostare uno alla volta con le annotazioni sui namespace.

Collectord inoltra anche a OpenSearch / Elasticsearch / syslog? Sì - sono supportate destinazioni di output alternative. Si vedano inoltro a Elasticsearch e inoltro via syslog.

L’app Splunk è gratuita? L’app è pubblicata su SplunkBase e si scarica gratuitamente - ma è un livello di interfaccia sui dati che Collectord inoltra. Senza una licenza Collectord, le dashboard non hanno nulla da visualizzare. La prova gratuita di 30 giorni copre l’intero stack; per continuare a usarla in seguito è necessaria una licenza Collectord a pagamento.

Le tracce OpenTelemetry sono supportate? Al momento no. Se il tracing è essenziale, OpenTelemetry Collector + Splunk Observability Cloud è lo stack giusto.

Conviene usare l’OpenTelemetry Collector anche per i log? Funziona, e se gli stessi dati vengono inoltrati a più backend può essere la scelta giusta. Anche lì il routing di indici e sourcetype si basa sulle annotazioni. Il compromesso sta nei controlli a livello di contenuto: filtraggio, mascheramento e sampling vivono nei values di Helm come configurazione della pipeline del collector, in carico al team di piattaforma; non esistono limiti di throughput per container e Splunk non fornisce dashboard per quei dati. Abbiamo scritto un confronto attività per attività: Collectord vs OpenTelemetry Collector.