Hi in many cases if you haven't done data onboarding correctly and setting TIME_FORMAT correctly Splunk can decide that 05/03/2024 is actually 3rd of May 2024 not 5th or March 2024. To check this you need to look if those events are in future. That needs that you add correct end data or actually enough long span into future e.g. latest=+10mon in your SPL query. You can also check if there is issues on those date parsing on MC and/or from internal logs. r. Ismo

Hour (7-21,0-9,12-21):  The range 7-21 includes hours from 7 AM to 9 PM. The additional ranges 0-9 and 12-21 ensure that hours from midnight to 9 AM and from noon to 9 PM are also included. Therefore, the cron job runs every minute from 7 AM to 9 PM, excluding 10 PM and 11 PM.

@richgalloway or @General_Talos  How do we need to hide the app that is downloaded from Splunk base to be viewed by other customers through source control like Git? I see a file with default.meta where it says [] owner =admin access =  read : [*], write : [ admin ] export = system   Thanks

Thank you.   index=<value> source=<sourcePath.log> host=<value> | <evalQueryGiven> vs index=<sameValue> source=<splunkForwarderPath.log> host=<sameValue> | <evalQueryGiven>     [SourceLogs vs Summary logs from SplunkForwarder] [Last 15mins] 250K events vs 82K events.  [Time difference]  -0.023 vs -0.77 at lowest  -0.894 vs 1.14 at highest Missing log from source had time definition (example: 06/Mar/2024:10:08:17.894). I couldn't say if this is a queue problem? 

cant post links so just search for freeload101 github for updated code #!/bin/bash ########################## FUNC function UFYUM(){ cd /tmp rpm -Uvh --nodeps `curl -s https://www.splunk.com/en_us/download/universal-forwarder.html\?locale\=en_us | grep -oP '"https:.*(?<=download).*x86_64.rpm"' |sed 's/\"//g' | head -n 1` yum -y install splunkforwarder.x86_64 sleep 5 } function UFDEB(){ cd /tmp wget `curl -s https://www.splunk.com/en_us/download/universal-forwarder.html\?locale\=en_us | grep -oP '"https:.*(?<=download).*amd64.deb"' |sed 's/\"//g' | head -n 1` -O amd64.deb dpkg -i amd64.deb sleep 5 } function UFConf(){ mkdir -p /opt/splunkforwarder/etc/apps/nwl_all_deploymentclient/local/ cd /opt/splunkforwarder/etc/apps/nwl_all_deploymentclient/local/ cat <<EOF> /opt/splunkforwarder/etc/apps/nwl_all_deploymentclient/local/app.conf [install] state = enabled [package] check_for_updates = false [ui] is_visible = false is_manageable = false EOF cat <<EOF> /opt/splunkforwarder/etc/apps/nwl_all_deploymentclient/local/deploymentclient.conf [deployment-client] phoneHomeIntervalInSecs = 60 [target-broker:deploymentServer] targetUri = XXXXXXXXXXXXXXXXXXXXXXX:8089 EOF cat <<EOF> /opt/splunkforwarder/etc/system/local/user-seed.conf [user_info] USERNAME = admin PASSWORD = XXXXXXXXXXXXXXXXXXXXXXXX EOF /opt/splunkforwarder/bin/splunk cmd btool deploymentclient list --debug /opt/splunkforwarder/bin/splunk start --accept-license } ######################################################### MAIN # Check for RPM package managers if command -v yum > /dev/null; then UFYUM UFConf else echo "No YUM package manager found." fi # Check for DEB package managers if command -v dpkg > /dev/null; then UFDEB UFConf else echo "No DEB package manager found." fi

I doubt if Splunk has truly extracted JSON array content.payload{}.  As you observed, Splunk gives you a flattened structure of the array.  As @gcusello said, spath is the right tool.  The syntax is   | spath content.payload{} | mvexpand content.payload{}   Normally, you can then continue to use spath to extract content.payload{} after this.  But your data has another layer of array.  That's not usually a problem.  But then, your developers did you a great injustice by using actual data values (e.g., "GL Import flow processing results") as JSON key.  Not only is this data, but the key name included major SPL breakers.  I haven't found a method to use spath to handle this.  If you have any influence over your developers, insist that they change "GL Import flow processing results" to a value and assign it an appropriate key such as "workflow".  Otherwise, your trouble will be endless. Luckily, Splunk introduced from_json in 9.0.  If you use 9+, you can work around this temporarily before your developers take action.   | spath path=content.payload{} | mvexpand content.payload{} | fromjson content.payload{} | mvexpand "GL Import flow processing results"   You sample data should give you GL Import flow processing results content.payload{} {"concurBatchId":"4","batchId":"6","count":"50","impConReqId":"1","errorMessage":null,"filename":"CONCUR_GL.csv"} { "GL Import flow processing results" : [ { "concurBatchId" : "4", "batchId" : "6", "count" : "50", "impConReqId" : "1", "errorMessage" : null, "filename" : "CONCUR_GL.csv" } ] }   AP Import flow related results : Extract has no AP records to Import into Oracle (Scroll right to see other columns.) This is an emulation for you to play with and compare with real data   | makeresults | eval _raw = "{ \"content\" : { \"jobName\" : \"AP2\", \"region\" : \"NA\", \"payload\" : [ { \"GL Import flow processing results\" : [ { \"concurBatchId\" : \"4\", \"batchId\" : \"6\", \"count\" : \"50\", \"impConReqId\" : \"1\", \"errorMessage\" : null, \"filename\" : \"CONCUR_GL.csv\" } ] }, \"AP Import flow related results : Extract has no AP records to Import into Oracle\" ] } }" ``` data emulation above ```