Ok. Again. One search gives you a single number. Another search returns several numbers (depending on how many titles you have in your data). What do you want to substract from what? And again - why extract so many fields when in the end you're just doing stats count?

Ok. So you have some data which might have some format but then again it might not and you want us to find for you something but you don't tell us what it is. How are we supposed to be able to do so if we neither understand the data nor know what you're looking for?

It should be achievable but not with GUI, not with "just CLI". It requires a lot of bending over backwards to find the buckets, copy them over, rename... Especially if the destination cluster is a production environment I wouldn't touch it without testing in a dev environment and a help from a friendly Splunk Consultant (or someone equally knowledgeable). And you can't "copy" just part of the buckets. You'd need to export the raw data and reingest it into the destination cluster.

consider this a one-time thing, based on the requirement we only move the data from one index to another index in another cluster, and we are not going to configure new data forwarding to the new index.

Thank you; and yes, I understand that. It's just that this is my only option "once per event" and I don't know if you have different options on your Splunk instance. If you do, then it's probably that I need to get with the team that administers this and ask them to add the other options. 

Can we use the similar approach for udp events as well ?    I have a udp port monitor configured in inputs of a UF.  And multiple hosts are sending the logs to that port while i want to whitelist only one host and blacklist the rest. 

Is this a one-time thing, or will you have an on-going need to replicate data like this? Are you trying to isolate data for some org to search without being able to see other data?   If it is a one-time thing, can you add an indexer to your existing cluster and get the data replicated/balanced to it.  Then, remove that from the cluster and reconfigure it to be on its own, and make the necessary retention settings for this new environment in your indexes.conf?  You could also remove any data you didn't need. Overall, moving just a single sourcetype from one environment to another when the data has already been at rest means you're probably going to need to do a manual export from Index Cluster A over to Index (cluster) B.  If it's not the only sourcetype in a single index, then that means you're going to have a bunch of interleaved data within your index buckets on the filesystem.  If you have on-going requirements to have data forked like this, then you should look towards using some sort of stream-management product like Splunk Edge or Cribl.

This has finally been addressed in a useable way that seems to not have any downside/impact in 9.1 (search for "Preserve search history across search heads"): https://docs.splunk.com/Documentation/Splunk/9.1.1/ReleaseNotes/MeetSplunk Scarily enough, it appears to be enabled by default.

This has finally been addressed in a useable way that seems to not have any downside/impact in 9.1 (search for "Preserve search history across search heads"): https://docs.splunk.com/Documentation/Splunk/9.1.1/ReleaseNotes/MeetSplunk Scarily enough, it appears to be enabled by default.

That's strange because as far as I remember, the SA_CIM should _not_ have any "Launch app" link associated with it. It should have the "Set up" link which should lead to the setup screens (specifying filters, enabling acceleration and such). But there is nothing "launchable" within the app.