Hi @Nawab, no it isn't possible: in Splunk data are replicated between all the indexers (based on Replication Factor and Search Factor) and all the Indexers partecipate to searches. You can choose the number of copies of replicated raw data (Replication Factor) that use around 15% or the original data and the number of copies of idxs (Replication Factor) that use around 35% or the original data. For more infos see at https://docs.splunk.com/Documentation/Splunk/9.1.2/Indexer/Aboutclusters. Ciao. Giuseppe

Hi @Real_captain , sorry, if you want to exclude results from search 2 you have to use the NOT operator: `eoc_stp_events_indexes` host=p* OR host=azure_srt_prd_0001 NOT [ search (index=events_prod_srt_shareholders_esa OR index=eoc_srt) seev.047 Name="Created Disclosure Response Status Advice Accepted" | fields messageBusinessIdentifier ] | table timestampOfReception, messageOriginIdentifier, messageType, status, messageBusinessIdentifier, originPlatform, direction, sourcePlatform, currentPlatform, targetPlatform, senderIdentifier, receiverIdentifier, currentPlatform Ciao. Giuseppe  

Ok, in reality this logid is not a numeric field, it's a string, but some unknown reason splunk convert it to number. Maybe this is bug and you should create a support case. What happen if you try this index=<myindex> logid="0000000013" AND logid!="13" | stats count If this didn't help, I don't know how to tell in search to splunk that this field should keep as string instead of convert it to numeric.

| eval merged=API."|".host."|".method | chart count over merged by StatusCode | addtotals | eval API=mvindex(split(merged,"|"),0) | eval host=mvindex(split(merged,"|"),1) | eval method=mvindex(split(merged,"|"),2) | fields - merged

Hi  Can we use below to fetch only those events which are extracted by Search1 and not extracted by Search2 based on the field messageBusinessIdentifier.   `eoc_stp_events_indexes` host=p* OR host=azure_srt_prd_0001   NOT [ search (index=events_prod_srt_shareholders_esa OR index=eoc_srt) seev.047 Name="Created Disclosure Response Status Advice Accepted" | fields messageBusinessIdentifier ] | fillnull timestampOfReception , messageOriginIdentifier, messageBusinessIdentifier, direction, messageType, currentPlatform, sAAUserReference value="-" | sort timestampOfReception | table timestampOfReception, messageOriginIdentifier, messageType, status, messageBusinessIdentifier, originPlatform, direction, sourcePlatform, currentPlatform, targetPlatform, senderIdentifier, receiverIdentifier, currentPlatform, | rename timestampOfReception AS "Timestamp of reception", originPlatform AS "Origin platform", sourcePlatform AS "Source platform", targetPlatform AS "Target platform", senderIdentifier AS "Sender identifier", receiverIdentifier AS "Receiver identifier", messageOriginIdentifier AS "Origin identifier", messageBusinessIdentifier AS "Business identifier", direction AS Direction, currentPlatform AS "Current platform", sAAUserReference AS "SAA user reference", messageType AS "Message type"

In a search for logid=13, I looked up the source of the returned events and they do have the logid information. Here is an extract: eventtime=1701795599940432762 tz="+0100" logid="0000000013" type="traffic" subtype="forward" level="notice"

@PickleRick I have to admit that I do not fully understand your explanation. Note that I get more results with a search for 0000000013 than just 13. @isoutamo Here are outputs of other queries, still for the very same time intervals: index=<myindex> logid=13 | stats count 822,434 index=<myindex> logid="13" | stats count 0 index=<myindex> logid=0000000013 | stats count 3,183,571 index=<myindex> logid="0000000013" | stats count 8,183,571 index=<myindex> logid=013 | stats count 0 index=<myindex> | stats count by logid 0000000011 8,000 0000000013 3,183,571 0000000023 127,753 0419016384 5,154 I wanted to see which records match 13 and not 0000000013 with the following request index=<myindex> logid=0000000013 AND logid!=13 | stats count but results is 0...

Actually, storage is usually not that much of a problem (although it does come with some overhead). It's mostly the losing of flexibility typically associated with Splunk that matters - an indexed field is indexed as is on the indexing pipeline and its value cannot be changed afterwards. Also searching indexed fields is different than "normal" Splunk search and can lead to unexpected results, especially if you don't configure your fields properly in fields.conf.

There are several possible approaches to this problem. One is to use a subsearch. https://docs.splunk.com/Documentation/Splunk/9.1.2/SearchTutorial/Useasubsearch Long story short - if you have search1 returning a list of values for field1, you use NOT ([your search | returining| values | table field1]) as part of your main search. This however has its drawbacks - the typical limits of a subsearch - the number of returned results and the execution time limit. That means that your search can be silently finalized without you even realizing that you're getting incomplete/invalid results. Another approach would be to append both of those resultsets adding a field which describes which search they come from and then do stats over the common field and filter out those that do have the identifier. Like <search1> | eval wherefrom=1 | append     [ <search2> | eval wherefrom=2 ] | stats values(*) as * by common_field | where NOT wherefrom=2 Append though is also subject to subsearch limitations  If both your searches are streaming searches, you can use multisearch instead of appending results - multisearch is _not_ subject to subsearch limitations.

Hi @Real_captain , Please try something like this: `eoc_stp_events_indexes` host=p* OR host=azure_srt_prd_0001 [ search (index=events_prod_srt_shareholders_esa OR index=eoc_srt) seev.047 Name="Created Disclosure Response Status Advice Accepted" | fields messageBusinessIdentifier ] | table timestampOfReception, messageOriginIdentifier, messageType, status, messageBusinessIdentifier, originPlatform, direction, sourcePlatform, currentPlatform, targetPlatform, senderIdentifier, receiverIdentifier, currentPlatform in few words: you have to use a subsearch putting attention that the fields at the end of the subsearch are only the ones you want to use as key and that the field names are exactly the same. Ciao. Giuseppe