Comparisons

10x vs Splunk Ingest Actions, vs Splunk Federated Search for S3, vs Splunk Edge Processor, and a supported-version matrix plus integration order.

10x vs Splunk Ingest Actions

Complementary, not competitive. Ingest Actions run on Heavy Forwarders/Indexers (within Splunk's license boundary). 10x optimizes before data reaches any Splunk component.

Key differences:

  • Processing location: Ingest Actions on Heavy Forwarder; 10x pre-Splunk at log source
  • License impact: Ingest Actions data already counted toward license; 10x Engine reduces data before it counts
  • Deduplication: Ingest Actions not supported; 10x Engine yes (template-based)
  • Destination reach: Ingest Actions are Splunk-only; the 10x Engine forwards to Splunk, Datadog, Elastic, or your own S3. Lossless compact applies on Splunk, self-hosted Elasticsearch or OpenSearch, and ClickHouse; on other destinations the cost levers are tier_down, offload, and sample or drop.

Use together: Ingest Actions for Splunk-specific parsing/routing after ingestion. 10x Engine for cost optimization before ingestion.

Note: Splunk Ingest Actions requires Enterprise 9.0+ and Heavy Forwarders. 10x Engine works with Splunk Cloud and Enterprise.

Federated Search for S3 and Retriever

Not a replacement for Federated Search, the piece that makes aggressive offload safe. Once the 10x Engine offloads low-value patterns to your own S3 to cut the Splunk bill, Retriever reaches that data on demand, a Bloom-scoped fetch over the offloaded slice, and ships matching events back to Splunk or hands them off for analysis. The offloaded data stays reachable, so you can drop more without losing access.

Key points:

  • Offload-and-fetch, not brute-force scan: Retriever indexes at upload and fetches only the patterns you ask for, scoped by Bloom filter, instead of scanning raw S3 end to end.
  • Your S3, your data: Offloaded logs live in your own bucket at $0.023/GB stored, not behind per-scan DSU pricing.
  • Reachable anywhere: Splunk Cloud + Enterprise, AWS + Azure, on-prem + air-gapped.

Use together: Federated Search for ad-hoc queries across Splunk-managed data; Retriever to reach the slice the Engine offloaded to cut cost, and pull it back when you need it.

10x vs Splunk Edge Processor

Edge Processor needs hand-written SPL2 rules and ships kept events at full size. 10x regulates automatically by cost and severity per event type, enforces per-app K8s budgets, and on Splunk compacts what ships by a modeled 50%+ losslessly.

Edge Processor 10x
Filtering Hand-written SPL2 rules per pattern Automatic cost-aware sampling per event type, severity-aware (ERRORs kept, DEBUG throttled first)
Budget control None Per-app K8s budgets, scaling pods doesn't bypass limits
Compact mode None, kept events ship at full size Lossless, modeled 50%+ reduction on Splunk, self-hosted Elasticsearch or OpenSearch, and ClickHouse; a no-op on Datadog and managed Elasticsearch, where tier_down, offload, and sample or drop are the cost levers
Sources Splunk forwarders only Any forwarder (UF, Fluent Bit, OTel, Vector, Logstash)
Destinations Splunk and S3 Splunk, Datadog, Elastic, S3
Fleet config Per-forwarder SPL2 pipelines Environment-wide GitOps driven by cost metrics
Splunk version compatibility & integration order

Version compatibility:

Component Minimum Tested Supported
Splunk Cloud 9.0 9.0, 9.1 9.0+
Splunk Enterprise 8.2 8.2, 9.0, 9.1 8.2+
Universal Forwarder 8.0 8.1, 9.0, 9.1 8.0+
Fluentd (if used) 1.14 1.14, 1.16 1.14+
Fluent Bit (if used) 2.0 2.0, 2.1 2.0+
Helm (K8s deployment) 3.0 3.0, 3.12 3.0+
Kubernetes 1.20 1.24, 1.27 1.20+

Integration order (safe sequence):

  1. Verify prerequisites - [ ] Admin access to Splunk instance - [ ] HEC token configured (or ability to create one) - [ ] K8s cluster with 4GB+ available memory (DaemonSet test)

  2. Deploy Receiver - [ ] Deploy via Helm with --dry-run first to verify manifests - [ ] Apply Helm chart alongside forwarder (sidecar) - [ ] Verify pods are running: kubectl get pods -l app=log10x-receiver - [ ] Check logs for startup errors: kubectl logs -l app=log10x-receiver

  3. Install Splunk App - [ ] Download 10x for Splunk from GitHub - [ ] Install via Splunk UI: Apps → Install app from file - [ ] Verify installation: Settings → Installed apps (should show "10x for Splunk")

  4. Configure KV Store - [ ] Create KV Store collection tenx_dml with required schema - [ ] Verify collection: Settings → Advanced Search → Collections - [ ] Test: Run a simple search to populate collection

  5. Validate end-to-end - [ ] Query compact events in Splunk - [ ] Verify events expand automatically at search time - [ ] Check that dashboards display expanded events correctly - [ ] Confirm reduction ratio in logs

Rollback procedure (if needed): - Remove Receiver: helm uninstall log10x-receiver (logs resume at full volume) - Remove app: Splunk UI → Apps → Uninstall 10x for Splunk - Both actions are safe: No configuration changes needed, no data loss

Compatibility checklist before full deployment: - [ ] Test on non-production environment first - [ ] Verify with actual log volume from your apps - [ ] Confirm reduction ratio meets expectations (typically 50-80%) - [ ] Run for 24+ hours in shadow mode to detect issues - [ ] Validate alerting rules still work - [ ] Test saved search performance (should be similar)