Splunk Dev

Why is my custom streaming search-command executed on the search head?

sh4kesbeer
Explorer

I am trying to implement a custom streaming search-command right now. I would like to use the SCP v2 protocol with the splunklibs python interface. The command itself is running fine but the "remoteSearch" field and the overall performance indicates that it is not distributed to the indexer-cluster but rather executed on the searchhead.
I tried different options for the Configuration Decorator (e.g. distributed=true) but it did not have any effect.
I am inheriting from StreamingCommand and so I am not able to mutate the "type" field in the configuration. The type is said to be "streaming" in the documentation but it turns out to be "stateful" when read out from "self.configuration" (from inside the commands class)
To me this seems to be the cause for my command not being "distributable streaming" but rather "stateful streaming". How can I tackle this to be able to distribute my command to the indexer-cluster for optimal performance?

hardikJsheth
Motivator

There is parameter called "local = true" in commands.conf file which can be used for determining where to execute the queries with search command.

0 Karma

sh4kesbeer
Explorer

This parameter is not available when using the SCP v2 the spec states:

If true, the only other commands.conf attributes supported are is_risky, maxwait, maxchunksize, filename, and command.arg..

for the "chunked" option which decides on the protocol version

0 Karma
Get Updates on the Splunk Community!

Shape the Future of Splunk: Join the Product Research Lab!

Join the Splunk Product Research Lab and connect with us in the Slack channel #product-research-lab to get ...

Auto-Injector for Everything Else: Making OpenTelemetry Truly Universal

You might have seen Splunk’s recent announcement about donating the OpenTelemetry Injector to the ...

[Puzzles] Solve, Learn, Repeat: Character substitutions with Regular Expressions

This challenge was first posted on Slack #puzzles channelFor BORE at .conf23, we had a puzzle question which ...