Getting Data In

Can move_policy actually move things?

renems
Communicator

Hi all,

I'd like to move a batch input after reading. Except not to /dev/null.
The manual is pretty clear:

move_policy = sinkhole
* IMPORTANT: This setting is required. You *must* include
  "move_policy = sinkhole" when you define batch inputs.
* This setting causes the input to load the file destructively.
* Do not use the 'batch' input type for files you do not want to delete after
  indexing.
* The "move_policy" setting exists for historical reasons, but remains as an
  explicit double check.  As an administrator you must very explicitly declare
  that you want the data in the monitored directory (and its sub-directories) to
  be deleted after being read and indexed.

However, instead of removing, it would be so nice to move it to another location. Anyone knows if this is possible?

0 Karma
1 Solution

skoelpin
SplunkTrust
SplunkTrust

I believe sinkhole is the only supported property of move_policy so in my opinion, no this is not possible. You could always script it by setting a daily cron schedule

View solution in original post

skoelpin
SplunkTrust
SplunkTrust

I believe sinkhole is the only supported property of move_policy so in my opinion, no this is not possible. You could always script it by setting a daily cron schedule

TStrauch
Communicator

Correct. Splunk has no mechanism to move files around in the filesystem.

Get Updates on the Splunk Community!

Automatic Discovery Part 1: What is Automatic Discovery in Splunk Observability Cloud ...

If you’ve ever deployed a new database cluster, spun up a caching layer, or added a load balancer, you know it ...

Real-Time Fraud Detection: How Splunk Dashboards Protect Financial Institutions

Financial fraud isn't slowing down. If anything, it's getting more sophisticated. Account takeovers, credit ...

Splunk + ThousandEyes: Correlate frontend, app, and network data to troubleshoot ...

 Are you tired of troubleshooting delays caused by siloed frontend, application, and network data? We've got a ...