Splunk online course

Splunk Data Sources and Inputs

Learn how Splunk collects machine data from files, networks, Windows systems, queues, and APIs, then turns it into searchable events stored in indexes.

Splunk can search, report on, and analyze machine data only after that data reaches Splunk. Machine data is operational information produced by systems, applications, devices, and services. Examples include application logs, operating-system records, network-device messages, Windows security events, and records returned by an API.

A data source is the origin of the machine data. An input is the configured mechanism through which Splunk receives or gathers that data. Choosing the right input is one of the first decisions in data onboarding because it determines how Splunk finds or receives the source records.

How Splunk data becomes searchable

At a high level, Splunk follows this workflow:

1. A system, application, device, or service produces machine data.
2. A configured input collects the data locally or receives it from a remote source.
3. Splunk processes the collected data for indexing, preparing it for storage and search.
4. The data is represented as individual events.
5. Splunk stores the indexed events in a selected index.
6. Users search and analyze those events.

An event is one unit of data represented in Splunk after ingestion. Depending on the source, an event might be a log record, a Windows Event Log entry, a network message, or a record returned by a script. Event data is the basic unit used in Splunk searches, reports, alerts, and other analysis.

An index is both a logical grouping and a data store for indexed events. Assigning data to an appropriate index helps organize access, retention, and searching. For example, an organization might separate security events from application events.

Splunk Enterprise stores indexed data in files organized in directories. This storage model does not require separate database software for the indexed event data. The index provides the logical destination while Splunk manages the underlying files and search structures.

Files and directory inputs

Monitoring one known file

A file monitor watches a specified file for new data. This is useful when an application writes to one known log path, such as a dedicated application log or a particular operating-system log file.

As the file receives new records, the input can collect those records and make them available for indexing. The file path, permissions, rotation behavior, and intended destination index should all be considered when configuring the input.

Monitoring a directory

A directory monitor watches a location for eligible data files. It is appropriate when an application writes several related logs to one directory, or when new log files can appear over time.

For example, an application may create separate files for access, error, and audit activity. Monitoring the directory allows Splunk to discover matching files within that path instead of requiring a separate input for every known file.

Network data inputs

A network input receives event data through a network connection or port. This allows Splunk to collect data from systems that do not store the source data on the Splunk Enterprise host.

Network-delivered data can come from network devices, infrastructure services, applications, or other systems that send event streams to a configured endpoint. The sending device and the Splunk input must agree on the delivery method, network destination, and any required protocol or format.

SNMP event collection

SNMP, or Simple Network Management Protocol, is a network-management protocol used by infrastructure and networked devices. SNMP-related collection can provide event information such as device conditions, status changes, and notifications from routers, switches, servers, or other managed equipment.

SNMP collection is different from monitoring a text file. The source is a remote device, and the input must use an SNMP-compatible collection method or integration that receives the device information.

Windows-specific data sources

Windows systems expose important operational and security information through mechanisms that are not ordinary text log files. Windows inputs allow Splunk to collect these sources directly or through an appropriate remote collection arrangement.

Windows Event Log

Windows Event Log contains records generated by Windows and by applications running on Windows. These records can include operating-system activity, authentication and security events, application errors, and service information.

Windows Registry

The Windows Registry is a Windows configuration database. Monitoring or collecting Registry information can help identify configuration values and changes that would not normally appear in a text log.

WMI

WMI stands for Windows Management Instrumentation. It provides an interface for querying Windows management data. WMI-based inputs can collect system or administrative information exposed through that interface.

Active Directory

Active Directory provides Microsoft directory services. Active Directory-related collection can supply identity and directory data, such as information about users, groups, computers, and related directory objects.

Windows inputs therefore cover operating-system and directory-service data that is not typically gathered by simply monitoring ordinary text files.

Other supported inputs

FIFO queues

A FIFO queue is a first-in, first-out named pipe. One process writes data into the pipe, and another process reads it in the order received. A FIFO input can stream data between a producer process and Splunk without requiring the producer to write a conventional log file first.

Scripted inputs

A scripted input runs a script-based collection method that emits data for Splunk to ingest. Scripts are useful when the source does not have a ready-made file or network input, or when collection requires custom logic.

A script can call an API, which is an application programming interface used to retrieve data from a service or application. The script might authenticate to a remote service, request records, format the returned data, and provide the output to Splunk. The script must be able to reach the remote interface and must emit usable output consistently.

Splunk data source types

Local versus remote data collection

Source location affects the input and collection design. A source can be local to the Splunk Enterprise instance, or it can reside on another machine, network device, or service.

When logs exist on the Splunk Enterprise host, a local file input may be sufficient. When data originates elsewhere, Splunk must receive it over the network, query it remotely, or use a collection component on the source system to deliver it. Forwarders are a common distributed-collection approach; see What Are Forwarders and Monitor Logs Using Forwarders.

From input data to events and indexes

Consider three lines written to an application log. A file input reads the new data, Splunk processes it for indexing, and the records become separate events according to the source's event structure. Those events are then written to the selected index.

2026-08-18 10:00:01 user=alex action=login result=success
2026-08-18 10:01:14 user=lee action=login result=failure
2026-08-18 10:02:03 user=alex action=logout result=success

In this conceptual example, each log record can become an individual event. A search then operates on the events in the destination index rather than directly on the original file or device.

Choosing an input: a practical decision process

1. Identify the source: file, directory, network device, Windows interface, named pipe, or remote service.
2. Identify the source location: local host, remote machine, device, or API endpoint.
3. Choose the input that matches how the source exposes data.
4. Decide whether one known file or a directory of files should be monitored.
5. Choose the destination index for the resulting events.
6. Verify that the input can access the source and that the resulting events appear in the intended index.

For a guided data-onboarding workflow, see Add Data To Splunk. To understand indexes in more detail, read What Is An Index or Create An Index.

Troubleshooting missing data

Expected data does not appear in search

• Confirm that the selected input type matches the source.
• Verify whether the source is local or remote and whether the collection path matches that location.
• Check that the intended destination index is included in the search.
• Confirm that the input has access to the source and is active.

A log file is collected but related files are missing

• Determine whether a single-file monitor was configured when directory monitoring was needed.
• Check the monitored directory path.
• Review which files are eligible for collection and whether newly created or rotated files are included.

Remote device events are absent

• Verify that the device is sending data to the expected network endpoint or SNMP collection mechanism.
• Confirm that network connectivity and the receiving configuration are correct.
• Ensure that the selected input matches the device's event-delivery method.

A scripted integration produces no events

• Confirm that the script can access the target API or remote interface.
• Check authentication, permissions, and connectivity required by the service.
• Verify that the script emits usable output for Splunk ingestion.
• Confirm that the scripted input is associated with the intended index.

Exam-relevant notes

• A data source is the origin of machine data; an input is the mechanism used to collect it.
• File monitoring targets a known file, while directory monitoring targets a location containing eligible files.
• Network inputs receive data from remote systems through network connections or ports.
• SNMP provides event information from networked infrastructure and devices.
• Windows inputs can collect Event Log, Registry, WMI, and Active Directory data that is not normally stored as ordinary text logs.
• Scripted inputs can retrieve data from APIs and other remote interfaces.
• Collected data is processed for indexing, represented as events, and stored in indexes.
• Splunk Enterprise stores indexed data in files organized in directories rather than requiring separate database software for that indexed data.