@gcusello  Hi! Thank you for your advice! (1) It will be kind of difficult to list all 280  indexes. We can probably decrease it to 68 by using something like index=p* I was wondering if there might be another alternative way to do it without listing all the indexes in search of in macro  (2) The rule is actually useful to us, since we had few issues with performance due to users using index=*  , selecting big time period and searching for some "text" through all of our 280+ indexes But just curious on why are you saying it isn't useful? Regards, @mlevsh  ... View more

@richgalloway Thank you for the reply!  Already found that <<ITEM>> token was introduced in first release of v. 9: So the difference in our EVNs versions is indeed the reason for different behavior. https://docs.splunk.com/Documentation/Splunk/9.0.0/SearchReference/Foreach fieldstr <<FIELD>> The whole field name. multifield matchstr <<MATCHSTR>> The part of the field name that matches the wildcard values in the wildcard field. multifield matchseg1 <<MATCHSEG1>> The part of the field name that matches the first wildcard. multifield matchseg2 <<MATCHSEG2>> The part of the field name that matches the second wildcard. multifield matchseg3 <<MATCHSEG3>> The part of the field name that matches the third wildcard. multifield itemstr <<ITEM>> Matches each element in a multivalue field or JSON array. multivalue or json_array <<ITEM>> is not available in last release of version 8 https://docs.splunk.com/Documentation/Splunk/8.2.9/SearchReference/Foreach Token Description <<FIELD>> Each time the subsearch is run, the field value substitutes the whole field name for each field you specify in the <field-list>. <<MATCHSTR>> The part of field name that matches wildcards in the specifier. <<MATCHSEG1>> The part of field name that matches first wildcard. <<MATCHSEG2>> The part of field name that matches second wildcard. <<MATCHSEG3>> The part of field name that matches third wildcard. ... View more

@richgalloway   Thank you for your reply! I will verify if data are going directly to the heavy forwarder or indexers . We have Heavy Forwarder - on - prem , but search head and indexers are on Splunk Cloud.  So we installed  and configured Splunk add-on for MS Cloud Services on our on-prem Heavy Forwarder and assumed that Azure storage blob data are being pulled from our Heavy Forwarder   I also see the following error messages in internal logs: Unable to find segmenter for conf=source::source_storage_blob_name.csv|host::our_heavy_forwarder|mscs:storage:blob:csv|remoteport::17575. Will attempt to use the default configuration ... View more

Hi @richgalloway  Sorry for the delay. Hopefully you will see my reply 1) Where did you put the props.conf file? in app local directory: /opt/splunk/etc/apps/Splunk_TA_microsoft-cloudservices/local 2)  Did you restart Splunk after modifying the file?  Yes, splunk was restarted 3) Does the data come in to the indexers directly or via a heavy forwarder?  Best to my knowledge, they are going to heavy forwarder first. Input is csv file with a lot of columns (from A to BA) , first line is a header. When I onboard with the same props.conf via Data input right on Heavy Forwarder - it extracts fields perfectly.    ... View more

Hi PickleRick, Thank you for suggestion. Unfortunately , it didn't work   ... View more

@isoutamo , thank you. Thought so, but really hoped for a different answer.  ... View more

@bowesmana  Thank you! That worked perfectly!     ... View more

@s2_splunk  Thank you for you suggestions! Majority (99.9%) of logs have header set as a 1st line and this Sourcetype works for other logs. What makes this issue harder to troubleshoot that  the files are deleted after they ingested. We were not successful to catch the actual log file so far.  the team will try HEADER_FIELD_LINE_NUMBER = 0 (which is default anyway) , but they want to troubleshoot without this change first   ... View more