Every Way to Get Data Into Splunk in 2026: Field Guide

How to read this map

Every ingestion path walks the same route, and it helps to picture it as five stops. Data is born at a source: a log file on a host, a Windows API, a network device, a Kubernetes pod, a cloud platform, a SaaS API, a database, a message queue. Usually a collector picks it up: an agent on the host, a container sitting near the source, or a managed cloud service. Some sources skip this stop and push directly.

However it travels, the bytes enter Splunk through one of three doors: HTTP Event Collector (HEC), an HTTPS endpoint you POST events to; Splunk-to-Splunk forwarding (S2S), the binary protocol Splunk's own agents speak; or a native input listening on Splunk itself. Along the way it can optionally pass through a processing tier (Ingest Actions, Edge Processor, or Ingest Processor) to be filtered, masked, or routed in flight. Collectors like SC4S or the OTel Collector can do some of this shaping themselves; the processing tier is the dedicated layer for it. And it finally lands at a destination: an index, S3-compatible storage, or metrics in Splunk Observability Cloud (Splunk's separate metrics-and-traces product).

The Splunk Validated Architectures (SVAs) are Splunk's official reference architectures and the authority on how the layers combine.

1
Sourceswhere data is born
- Host files
- Windows APIs
- Network devices
- Kubernetes
- Cloud platforms
- SaaS APIs
- Databases
- Queues
2
Collectorswhat picks it up
3
Doorshow bytes enter Splunk
4
Processingoptional: shape in flight
5
Destinationswhere it lands
- Indexes
- S3-compatible storage
- Observability metrics

Colored chips jump to the matching section below.

On-host agents: the forwarders

Forwarders are Splunk's data-shipping agents. They usually tail logs on the machine they're installed on, sometimes pull from remote APIs or databases, and ship everything to Splunk over S2S.

Universal Forwarder (UF): the lightweight agent for Linux and Windows. No UI, minimal footprint, explicitly designed for fleets of thousands. It tails logs and ships them over S2S, usually to port 9997.
Heavy Forwarder (HF): a full Splunk install used as a shipper. Unlike the UF, it parses data before forwarding, so you reach for it when events must be transformed or routed by content mid-flight. It's also where most add-on inputs (see Splunkbase below) run in practice.
Deployment Server: Splunk's built-in config manager for the forwarder fleet: it pushes apps and settings to groups of forwarders, with a forwarder-management UI on top.

Network doors: HEC, S2S, and raw TCP/UDP

Whatever collects your data upstream, it enters Splunk through one of these three doors, and their quirks come up again and again in the rest of this article.

HTTP Event Collector (HEC): an HTTPS endpoint on port 8088: put a token in the header, POST your events as JSON, done. No agent required. Enabled by default on Splunk Cloud, disabled by default on Enterprise. Nearly every modern connector below terminates here.
S2S receiving: the forwarders' binary protocol, conventionally port 9997 ([splunktcp://9997]). This is what UF and HF speak natively.
Raw TCP/UDP inputs: open a port on Splunk, receive whatever arrives. The docs themselves warn against pointing devices straight at Splunk: "For Syslog, the best practice is to use a syslog server, such as syslog-ng or Splunk Connect for Syslog." That's SC4S, below; the syslog deep dive explains why in failure-mode detail.

Built-in inputs: files, scripts, and Windows

A plain Splunk instance (or any forwarder) already knows how to collect quite a lot by itself.

File & directory monitoring: tails files and whole directory trees, wildcards included.
Scripted inputs: run a script on an interval, index whatever it prints to stdout.
Modular inputs: the plugin framework behind almost every pull-style add-on. Compared to a bare script you get a config page in Splunk's UI, input validation, and checkpointing (remembering where you left off).
Windows Event Log, performance monitoring, and WMI: Windows event logs are binary, so Splunk reads them through Windows APIs rather than tailing files. WMI still works for remote collection, but the docs recommend a local UF instead. The Splunk Add-on for Windows adds the sourcetypes (format labels that control parsing) and standard field mappings; XmlWinEventLog is the modern default.
Splunk DB Connect: SQL databases over JDBC: pull query results in as events, push events out, or use tables as lookups (MSSQL, Oracle, PostgreSQL, MySQL, Redshift, and more). Actively maintained: v4.2 landed in February 2026.
Splunk Stream: network traffic itself: packet capture, protocol metadata, NetFlow. Quietly alive and well: v8.1.6 shipped March 2026 with support through Splunk 10.5.

Technology Add-ons: the long tail on Splunkbase

For almost any commercial product that emits logs, someone (often Splunk itself) has already built the integration. These live on Splunkbase, Splunk's app store.

The pattern: a Technology Add-on (TA) packages an input plus the sourcetypes and field mappings to Splunk's Common Information Model (CIM), a standard naming scheme that lets prebuilt dashboards and security content work across vendors. The "Splunk Supported" badge tells you who answers the support ticket.
Splunk Add-on for AWS: the workhorse. The SQS-based S3 input is the recommended way to pull CloudTrail, VPC Flow Logs, ELB access logs, and friends. The SVA guidance on AWS data draws a clean line: pull is usually more cost-effective under ~1 TB/day per node; above that, push via Firehose (below). The AWS deep dive walks through the add-on's inputs, their published throughput numbers, and what the pull path actually costs once you count the forwarder fleet.
Splunk Add-on for Microsoft Cloud Services: the Azure counterpart; its Event Hub input subscribes over AMQP, running on a heavy forwarder.
Splunk Add-on for Microsoft Office 365: pulls the Management Activity API, Service Communications API, and Graph message traces; it replaced the O365 input that used to live in the MSCS add-on.
Splunk Add-on for Google Cloud Platform: near-real-time pull from Cloud Pub/Sub subscriptions.
UCC framework: for when no TA exists: ucc-gen generates the add-on scaffolding (configuration UI, REST handlers, modular inputs) from a single config file, and it's what Splunk builds its own supported add-ons with. Run AppInspect, Splunk's app-validation checks, before you publish.

Connectors: syslog, SNMP, Kubernetes, Kafka

Containerized collectors that sit near the source and deliver over HEC. This is where Splunk's own tooling has been heading for years.

Splunk Connect for Syslog (SC4S): a hardened syslog server (syslog-ng) in a container. Network devices send it syslog; SC4S recognizes the vendor, applies the right sourcetype, and delivers to HEC. The recommended answer to syslog at scale; the syslog deep dive covers the five popular methods and what can go wrong with each.
Splunk Connect for SNMP (SC4SNMP): SNMP polling and trap reception, deployed on Kubernetes or Docker Compose, with a MIB server included (MIBs are the schema files SNMP data needs). It's Splunk-supported on Splunkbase.
Splunk OpenTelemetry Collector for Kubernetes: a Helm chart that runs the Splunk OTel Collector as a DaemonSet; Splunk's recommended path for Kubernetes logs and metrics into the platform, delivered over HEC. One caveat from its own README: chart releases don't follow SemVer, so read the notes before upgrading.
Kafka, two ways: Splunk Connect for Kafka is a Kafka Connect sink that writes to HEC; still documented and supported. Its announced successor, the Splunk OpenTelemetry Collector for Kafka (SOC4Kafka), runs standalone on the OTel Collector instead. Worth knowing before you invest: SOC4Kafka doesn't support HEC acknowledgments yet, so it can't confirm delivery.

OpenTelemetry: where it stands with the platform

OpenTelemetry (OTel) is the open, vendor-neutral standard for collecting logs, metrics, and traces. It comes up in every architecture conversation, and the honest answer today has three parts.

Splunk Distribution of the OpenTelemetry Collector: Splunk's supported build of the OTel Collector, designed first for Splunk Observability Cloud. For logs into the Splunk platform, its docs are blunt: "For Linux and Windows environments (physical hosts and virtual machines), use the Universal Forwarder to send logs to the Splunk platform."
Kubernetes is the exception: the Helm chart above is fully supported for platform logs over HEC.
What's coming: in April 2026 Splunk announced native OTLP log ingestion for the platform (OTLP is OTel's wire protocol). Too early to re-platform around it, but it's clear where Splunk is headed.
Splunk Add-on for OpenTelemetry Collector: the pragmatic bridge: the OTel Collector packaged as an add-on, so you can roll it out to an existing UF fleet with the Deployment Server you already run instead of standing up a second agent-management stack.

Data Inputs: managed onboarding for Splunk Cloud

The fastest path for supported cloud sources is to let Splunk build the pipeline for you.

Data Inputs: Splunk Cloud's guided onboarding service: pick a source, and it generates the source-side setup (templates, permissions) and delivers over HEC. Formerly called Data Manager ("Data Manager became Data Inputs," as the docs put it).
Coverage: AWS, Microsoft Azure, Google Cloud, and CrowdStrike sources.
Boundaries: Splunk Cloud only; Office 365 stays with its add-on; and Azure inputs still want the MSCS add-on installed for field parsing.

Agentless cloud push: Firehose, Functions, Dataflow

When you'd rather run as little as possible yourself, each cloud has a documented push path into HEC.

Amazon Data Firehose → Splunk: Splunk is a first-class Firehose destination: fully managed delivery with HEC acknowledgments, automatic retry, and backup of failed events to S3. Splunk's recommended AWS path at high volume; the AWS deep dive compares it against every other push and pull method on cost, latency, and delivery guarantees.
AWS Lambda blueprints: Splunk-published functions for CloudWatch Logs and Kinesis streams. Reference code you deploy and operate yourself, not a supported product.
Azure Functions for Splunk: Event Hub–triggered functions that forward to HEC, with a deploy-to-Azure template. Same caveat: provided as-is.
Google Cloud Pub/Sub to Splunk Dataflow template: a Google-provided streaming job from Pub/Sub to HEC, with optional JavaScript transforms, batching, and a dead-letter topic for failures; Google also publishes a full reference architecture around it.

And it's not just the big three clouds. Because HEC is plain HTTPS, many other providers ship a Splunk destination right in their log-export settings: Cloudflare Logpush, GitHub enterprise audit-log streaming, and Fastly real-time log streaming all push straight to HEC. Before standing up any collector, check whether your vendor already has one of these.

The processing tier: shape data before it lands

Splunk pricing is typically volume-based: what you don't index, you don't pay for. Between collection and the index sits an optional layer that filters noise, masks secrets, and routes streams. Three tools, three operating models.

Ingest Actions: built into Splunk Enterprise and Cloud: rulesets that filter, mask, and route on indexers or heavy forwarders, including routing to S3-compatible storage. Data you filter or route away doesn't count against your ingest license.
Edge Processor: pipelines written in SPL2 (Splunk's newer pipeline language) running on Linux nodes you manage near your sources, controlled from a cloud control plane. Sends to Splunk over S2S or HEC, to Amazon S3, or to Azure storage. GA since March 2023, and since the Splunk Enterprise 10 cycle there's an on-prem variant for Enterprise, so this is no longer a Cloud-only story.
Ingest Processor: the same SPL2 pipeline idea as a Splunk-hosted service inside Splunk Cloud (GA July 2024): nothing to install, autoscaling, and destinations that include Cloud indexes and Amazon S3. Uniquely in this trio, it also does logs-to-metrics conversion into Splunk Observability Cloud.
SPL2 pipeline templates: prebuilt, editable pipelines for common sources on both processors, so you rarely start from a blank editor.

Ingest Actions

Runs: On indexers & heavy forwarders (built in)
Operated by: You (no extra infrastructure)
Pipelines: Rulesets in Splunk Web
Destinations: Indexes · S3-compatible storage
Available on: Splunk Enterprise & Splunk Cloud

Filtered or routed-away data doesn’t count against your ingest license.

Edge Processor

Runs: Customer-managed Linux nodes near your sources
Operated by: You (nodes) + cloud or on-prem control plane
Pipelines: SPL2
Destinations: Splunk via S2S/HEC · Amazon S3 · Azure storage
Available on: Splunk Cloud · Enterprise 10 (on-prem variant)

Pick it when data must be shaped before it leaves your network.

Ingest Processor

Runs: Splunk-hosted service inside Splunk Cloud
Operated by: Splunk (autoscaling, nothing to install)
Pipelines: SPL2
Destinations: Splunk Cloud indexes · S3 · Observability metrics
Available on: Splunk Cloud only

The only one of the three that converts logs to metrics.

Deprecated and renamed: don't build on these

Half the confusion in Splunk ingestion is vocabulary drift, so here's the decoder ring.

You'll hear	Status	Build on instead
Data Stream Processor (DSP)	Reached end of life 28 Feb 2025	Ingest Actions, Edge/Ingest Processor
Splunk Connect for Kubernetes (SCK)	End of support 1 Jan 2024, repo archived	OTel Collector for Kubernetes
SignalFx Smart Agent	End of support 30 Jun 2023	Splunk Distribution of OTel Collector
Light Forwarder	Deprecated	Universal Forwarder
Splunk Connect for Kafka	Supported, but successor announced	Evaluate SOC4Kafka for new builds
"Data Manager"	Renamed	Data Inputs (same product)
"Kinesis Data Firehose"	Renamed by AWS	Amazon Data Firehose

How to choose: three questions that settle most cases

Most onboarding decisions collapse quickly once you ask three questions in order.

Can the source push?

If yes: Take the managed push path: Firehose, Functions, or Dataflow straight to HEC, or Data Inputs on Splunk Cloud. It beats running your own collectors, and on AWS push is the documented default above ~1 TB/day.

No push path? Next question

Do you control the host?

If yes: Universal Forwarder, or the OTel add-on if you’re consolidating agents.
If it speaks syslog or SNMP: SC4S or SC4SNMP in a container near the source.
If it’s Kubernetes: The OTel Collector Helm chart.

None of the above? Last question

Is there an API?

If an add-on exists: Use it. Check Splunkbase before writing anything.
If nothing fits: Write your own with ucc-gen, not a bare scripted input.

Then decide separately whether a processing tier belongs in the path: noise reduction, PII masking, and routing are cheaper to add on day one than to retrofit.

One caveat before you commit: there is rarely a single good answer in data onboarding. The paths above (and the helper below) point at the documented defaults, but for most sources several of the tools in this guide will do the job well. If your team already runs a heavy forwarder fleet, pulling cloud logs through an add-on can beat standing up a push pipeline you've never operated. Treat these as recommendations, not verdicts.

Prefer the full table? Every path at a glance

Source	If you can host collectors	If you want it managed
Linux/Windows hosts	Universal Forwarder (+ Windows TA / OTel TA)	Universal Forwarder; an agent is the point
Syslog devices	SC4S on a container host near the devices	SC4S; syslog always needs a receiver nearby
SNMP devices	SC4SNMP on K8s or Docker Compose	SC4SNMP; same story as syslog
Kubernetes	Splunk OTel Collector Helm chart	Splunk OTel Collector Helm chart
AWS	Splunk Add-on for AWS on a heavy forwarder (pull, < ~1 TB/day)	Data Inputs (Cloud) or Amazon Data Firehose → HEC
Azure	Microsoft Cloud Services add-on on a heavy forwarder	Data Inputs (Cloud) or Azure Function → HEC
Google Cloud	Splunk Add-on for GCP (Pub/Sub pull)	Data Inputs (Cloud) or Pub/Sub → Dataflow → HEC
SaaS APIs	The product’s TA from Splunkbase; ucc-gen if none	Check Data Inputs sources; else the TA
Databases	Splunk DB Connect	Splunk DB Connect; it needs a Splunk instance to run on
Kafka	Splunk Connect for Kafka; evaluate SOC4Kafka for new builds	Same; both run near your Kafka cluster

All product names, statuses, and links above come from official documentation and were verified on 27 July 2026. If you spot drift (docs move fast), tell me and I'll fix it.