Github shows this fix for distributed flag not working properly: https://github.com/splunk/splunk-sdk-python/pull/182/files The fix seems to be in the current splunklib.   Still not sure how to properly use the distributed flag since I cannot set type=streaming to force splunklib to respect distributed=true/false ... View more

When I remove the partial=true flush I no longer need the smartstreaming command to process records. All records sent by splunk are available to the custom command and returned to splunk for the next spl. When you have a moment could you try this approach and see if I am missing something? Smartstreaming only worked if the spl pipeline feeding it included no other SCPv2 custom commands ... View more

Please see: https://answers.splunk.com/answers/785161/chunkedtrue-smartstreamingcommand-to-support-large.html?minQuestionBodyLength=80 I had to remove the partial flush when hitting maxresultrows to consistently use smartstreamingcommand ... View more

Please see my post below. SmartStreamingCommand appears to never receive 40-50% of the records in some situations. Other times it runs fine. "When using smartstreamingcommand from the package in your updated answer we avoid the error at the subsearch limit but with a new problem:" ... View more

When using smartstreamingcommand from the package in your updated answer we avoid the error at the subsearch limit but with a new problem: Sometimes 50% (about) of records are processed UPDATE: appears to be always with v2 generating command addinfo seems to record the number of records we get out is this a lead? At other times all records are process - UPDATE: appears to be with v1 generating command Have you seen something like this? |mongoreadbeta testdata |table * |echo |table * Can easily process 2 million records however sometimes we see: It appears to always break on the 100K boundary. Ex: 1 1100000 records - chunked generating command Duration (seconds) Component Invocations Input count Output count 0.00 command.addinfo 13 600,000 600,000 47.69 command.echo 13 1,100,000 600,000 Ex: 2 1,041,865 records after search filter Duration (seconds) Component Invocations Input count Output count 0.00 command.addinfo 12 641,865 641,865 56.21 command.echo 12 1,041,865 641,865 7.62 command.mongoreadbeta 12 - 1,100,000 0.28 command.search 12 1,100,000 1,041,865 When i run it with a non-chunked generating command it works: Ex3 1100000 rows - v1 generating command |mongoread testdata |echo |table * Duration (seconds) Component Invocations Input count Output count 114.51 command.echo 23 1,100,000 1,100,000 26.14 command.mongoread 1 - 1,100,000 0.91 command.table 1 1,100,000 2,200,000 Version: 7.2.7 Build: f817a93effc2 Using new echo custom command implemented in this change... https://github.com/TiVo/splunk-sdk-python/commit/5188f7d709cadd80e786692b371a64c4ae0991d2 ... View more

We had a similar and ended up separating the combined accelerated_fields into two separate entries. Our researched showed that these fields has a few multi-valued entries which we believe mongo saves as arrays thus causing the issue,Check if either of the fields in the KV are multi-valued. We believe that a MV field cannot be part of a multi-part accelerated field (mongo index) ... View more

You can put a monitor on the lookup file generated by crontab and then a scheduled search can "build" the new lookup by referencing the data collected by the monitor. The other advantage of this is you can ensure all entries remain in the file in the event that your crontab fails for some reason. (by using a range greater than an hour and dedup) Even better you could monitor a change file every hour and then build the lookup (or kvstore) based on the old lookup plus the changes: |inputlookup lookup.csv |append [ search "find the new data collected by change file" ]|sort - _time |dedup key_to_file | outputlookup lookup.csv ... View more

I would recommend a more structured approach: 1) Move complete search apps to your SHC 2) Disable the scheduled searches on the standalone search hed. Details: Instead of trying to move individual searches moving by app is easier to control. - The splunk cmd btool (from dwaddle) gives you a nice list of all apps that have scheduled searches. - Go through each one and if you want that app's searches running on the SHC copy it to shcluster/apps on the SHC deployer. - Once all apps have been copied do a cluster deploy - Then go back to your standalone search head (or appropriate deployment server) and disable those searches so that they are no longer scheduled on the standalone server. This will be easier to maintain and control. If you continue to create apps on your standalone search head or you already have those same apps on the SHC you will need to merge the app files. I recommend winmerge for this 🙂 Cheers ... View more

What is the reasoning behind why this resolves the issue? What has changed with the auto setting in 6.5? ... View more

We often get a similar issue when apps are invisible; replacing app name with search as above allows the search to run. Can you run a regular search in the app context? ... View more