I maintain an app with a data input wizard, under the hood of which is a custom controller that can list and create normal "monitor" data inputs very reliably. I now need to expand this to listing and creating "batch" data inputs aka "sinkhole" inputs, and from what I'm seeing maybe this isn't even possible.
The REST API Path for normal monitor inputs is /data/inputs/monitor
and in inputs.conf these look like:
[monitor://D:\some\path\*]
index = foo
sourcetype = bar
I now need to be able to also list and create "batch" data inputs. In inputs.conf these end up in the form:
[batch://D:\some\path\*]
move_policy = sinkhole
index = foo
sourcetype = bar
I cannot use a oneshot input. In this particular use case, files are ftp'ed to the given directory every minute or so in real time and I want to delete them as they are indexed. Hence batch is perfect.
1) Listing batch inputs:
There seems to be no separate endpoint for these, but they do get listed (oddly) in the output results for /data/inputs/monitor.
So, the only way I've found to list them, is to request /data/inputs/monitor and then look for the "move_policy" key being set to sinkhole.
Q1: Is there a better way?
2) Creating batch inputs:
I have not found any way to do this. There is no /data/inputs/batch or /data/inputs/sinkhole endpoint and thus no /data/inputs/batch/_new to POST to.
Following the weirdness of #1 above, if I use the entity code to create a "_new" monitor input, and I sneak in a "move_policy" key set to "sinkhole", that doesn't work either - it just complains
Argument "move_policy" is not supported by this handler.
Q2: Am I missing something? Is there a way to actually do what I need?
Eager for any help or any advice. If I have to conclude that such a simple data input administration task is impossible, I'll be sad and I'll have to just resort to doing filesystem operations to write the conf files directly through popen, and then prompt the user to restart the server afterwards.
... View more