Study guide
12.3 Deploying a Remote Monitor Input, Network Shares & Archives
Splunk Enterprise Certified Admin SPLK-1003
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the Splunk Enterprise Certified Admin Exam
2 Chapter 1: Splunk Admin Basics
1.1 Splunk Enterprise Architecture & Core Components
3 Chapter 2: License Management
2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting
4 Chapter 3: Splunk Configuration Files
3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations
5 Chapter 4: Splunk Indexes
4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy
6 Chapter 5: Splunk User Management
5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits
7 Chapter 6: Splunk Authentication Management
6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication
8 Chapter 7: Getting Data In
7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder
9 Chapter 8: Distributed Search
8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)
10 Chapter 9: Getting Data In – Staging
9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options
11 Chapter 10: Configuring Forwarders
10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing
12 Chapter 11: Forwarder Management
11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting
13 Chapter 12: Monitor Inputs
12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives
14 Chapter 13: Network and Scripted Inputs
13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection
15 Chapter 14: Agentless Inputs
14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration
16 Chapter 15: Fine Tuning Inputs
15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data
17 Chapter 16: Parsing Phase and Data
16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview
18 Chapter 17: Manipulating Raw Data
17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue
12.3 Deploying a Remote Monitor Input, Network Shares & Archives
Key Takeaways Explain This Topic AI
A remote monitor input is created centrally and delivered to forwarders by the deployment server, either through Settings > Add Data > Forward or through a deployment app mapped to a server class.
Add Data > Forward needs at least one deployment client; a server class chosen there must contain hosts of a single platform.
Splunk supports monitoring mounted or shared directories, including network file systems, if the forwarder can read them, but a local forwarder on the source host is usually the better design.
Forwarders decompress TAR, GZ, BZ2, TGZ, TBZ/TBZ2, ZIP, and Z archives before processing, and adding data to an existing archive causes the whole archive to be processed again.
[batch://<path>] with the required move_policy = sinkhole reads files once and deletes them; the default spool directory $SPLUNK_HOME/var/spool/splunk works the same way.
Last updated: September 2026
Deploying a Remote Monitor Input
Blueprint objective 12.3 is "Deploy a remote monitor input" . In a distributed deployment you rarely add a monitor input on the machine where you are logged in. Instead you create the input centrally and let the deployment server deliver it to the forwarders that sit next to the data.
Method 1: Splunk Web "Add Data > Forward"
When a Splunk Enterprise instance is also a deployment server with connected deployment clients, Settings > Add Data > Forward walks you through a remote input:
Prerequisite: at least one forwarder must be configured as a deployment client of this instance, for example with splunk set deploy-poll <ds>:8089 and a restart. Otherwise the page reports that no deployment clients were found.
Select Forwarders: choose New or Existing server class, move hosts from Available host(s) to Selected host(s) , and name the server class. A server class must contain hosts of a single platform ; you cannot mix Windows and *nix hosts.
Select Source: choose the data source for the forwarders, for example Files & Directories with the path to monitor.
Input Settings: set the source type, app context, host, and destination index .
Review and Submit. Splunk stores the input in a deployment app mapped to the server class, and the forwarders download it the next time they phone home.
Splunk documents this page for a single Splunk Enterprise instance that acts as both the indexer and the deployment server. With several indexers, the page isn't useful, and you build the deployment app yourself (Method 2).
- Method 2: A Deployment App Built by Hand $SPLUNK_HOME/etc/deployment-apps/org_linux_web_inputs/
- └── local/
- └── inputs.conf # inputs.conf inside the deployment app
- [monitor:///var/log/nginx/access.log]
- index = web
- sourcetype = nginx:access
- disabled = false # serverclass.conf on the deployment server
- [serverClass:linux_web]
- whitelist.0 = web-*
- machineTypesFilter = linux-x86_64
- [serverClass:linux_web:app:org_linux_web_inputs]
- restartSplunkd = true
- stateOnClient = enabled
Then run splunk reload deploy-server , or save the same mapping in forwarder management. Each matching forwarder downloads org_linux_web_inputs into $SPLUNK_HOME/etc/apps/ , restarts, and starts monitoring the file. Data flows to the indexers through the forwarder's existing outputs.conf , which is often delivered by a separate outputs app.
Verifying the Remote Input
Forwarder management shows that the clients downloaded the app.
On a forwarder, splunk list monitor shows the monitored files, and splunk btool inputs list --debug shows the stanza came from the deployment app.
On the search head, run index=web sourcetype=nginx:access host=web-* to confirm events arrive. If they do not, check the forwarder's _internal logs for the tailing processor and its output connections.
Monitoring Remote File Systems (NFS, SMB/CIFS)
Splunk's documentation allows a monitor input on a mounted or shared directory, including network file systems, as long as the forwarder can read it . It is supported, but it has trade-offs:
The monitoring host has to open, read, and re-check files across the network, which adds latency and load on the file server.
Network interruptions and file-system client caching can make files appear to change size or content unexpectedly, which can cause gaps or duplicate reads.
On Windows, use UNC paths or local drives the service account can reach, and run the forwarder as a user that has access to the share.
Where you can, install a universal forwarder on the machine that writes the logs and monitor the files locally. That is simpler, avoids network file-system behavior, and lets the forwarder use indexer acknowledgment on its outbound connection.
Compressed Archive Processing Mechanics
Log archiving pipelines often package older log segments into compressed archives. Splunk's forwarders decompress archive files before processing them , and they process archives single-threaded.
- Supported Archive Formats
- TAR , TAR.GZ / TGZ , TBZ / TBZ2
- GZ , BZ2
- ZIP
- Z
- How Archives Are Processed
The monitor input recognizes the archive type, and the archive processor decompresses it before the contents enter the parsing pipeline.
props.conf can customize this with unarchive_cmd (in [source::...] stanzas) and unarchive_sourcetype .
Archive processing is single-threaded, so very large archives take time.
The Immutability Requirement for Archives
A critical operational distinction between plain text logs and compressed archives is that Splunk cannot tail an active or appending compressed archive .
Plain text files can be tailed because new bytes are appended after data already read, and the seek address stays valid.
A compressed archive has to be decompressed as a whole, so there is no "new data after the seek address" to read.
Splunk's documentation is explicit: if you add new data to an existing archive file, the forwarder reprocesses the entire file rather than just the new data , which can duplicate events.
Practical rule: Build and compress archives outside the monitored directory, then move each finished archive in. Never append to an archive that Splunk has already read.
Batch Inputs & The Sinkhole Policy
While [monitor://...] keeps watching files as they grow, the batch input ( [batch://<path>] ) loads files once and destructively . For a single static file you can also use the CLI commands splunk add oneshot or splunk spool .
The Batch Ingestion Architecture
A batch input is defined in inputs.conf using the [batch://<path>] stanza: [batch:///var/spool/splunk_drop/*.csv]
- disabled = false
- index = historical_data
- sourcetype = csv:billing
- move_policy = sinkhole
Unlike monitor inputs, which keep tracking files, a batch input is a one-time, destructive loader. Splunk also has a built-in spool directory, $SPLUNK_HOME/var/spool/splunk , where any file you drop in is processed and deleted.
The Mandatory move_policy = sinkhole
The defining characteristic of a batch input is the move_policy setting. The spec marks it as required : you must include move_policy = sinkhole in every batch stanza: move_policy = sinkhole
What the Sinkhole Policy Does
When move_policy = sinkhole is configured:
Splunk discovers the file in the designated batch directory.
Splunk reads the whole file and sends its events through the pipeline like any other input.
After reading the file, Splunk deletes it. That is what "sinkhole" means, and inputs.conf.spec requires move_policy = sinkhole for batch inputs.
Why It Matters
Batch inputs are meant for files that should disappear once loaded. Because the policy is destructive, point them only at a dedicated drop directory, and make sure the Splunk service account can delete files there.
Caution
Filesystem Permissions and Staging Hazards:
Delete Permissions: The operating system user running splunkd (e.g., splunk ) must possess both read AND write/delete permissions on the target directory and files. If Splunk cannot delete a file, the file stays in the drop directory, and the input cannot work as intended.
Never Point Batch at Master Copies: Because sinkhole permanently destroys the source file upon ingestion, never point a [batch://...] input at a directory containing original, master, or live log files . Batch inputs must only monitor dedicated drop folders (such as /var/spool/splunk_drop/ ) where automated ETL workflows deposit disposable copies of historical archives.