@dicksola Hello, You can combine both the queries and create one single dashboard. Use lookup and map to add your CSV dataset to Splunk fields. You may view the fields and values of your dataset in Splunk after uploading the CSV file. You can now write your query 2 using the |inputlookup or |lookup commands. Subsearch or the append command can then be used to combine your query 2 with your query 1 (index=test* "users").   https://docs.splunk.com/Documentation/Splunk/9.2.0/SearchReference/Append  https://docs.splunk.com/Documentation/Splunk/9.2.0/SearchReference/Lookup  https://docs.splunk.com/Documentation/Splunk/9.2.0/Knowledge/Aboutlookupsandfieldactions   

@RyanPrice The stanza which you've added monitors the log files under ///var/www/.../storage/logs/laravel*.log . If these logs are large or frequently updated, it could contribute to increased memory usage.  verify if you have disabled THP. refer the splunk doc on it https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes/SplunkandTHP  please check the limits.conf https://docs.splunk.com/Documentation/Splunk/latest/Admin/Limitsconf  [thruput] maxKBps = [thruput] maxKBps = <integer> * The maximum speed, in kilobytes per second, that incoming data is processed through the thruput processor in the ingestion pipeline. * To control the CPU load while indexing, use this setting to throttle the number of events this indexer processes to the rate (in kilobytes per second) that you specify. * NOTE: * There is no guarantee that the thruput processor will always process less than the number of kilobytes per second that you specify with this setting. The status of earlier processing queues in the pipeline can cause temporary bursts of network activity that exceed what is configured in the setting. * The setting does not limit the amount of data that is written to the network from the tcpoutput processor, such as what happens when a universal forwarder sends data to an indexer. * The thruput processor applies the 'maxKBps' setting for each ingestion pipeline. If you configure multiple ingestion pipelines, the processor multiplies the 'maxKBps' value by the number of ingestion pipelines that you have configured. * For more information about multiple ingestion pipelines, see the 'parallelIngestionPipelines' setting in the server.conf.spec file. * Default (Splunk Enterprise): 0 (unlimited) * Default (Splunk Universal Forwarder): 256 the default value here is 256, you might consider increasing it if this is the actual reason for the data getting piled up, you can st the integer value to "0" which means unlimited.   Universal or Heavy, that is the question? | Splunk  Splunk Universal Forwarder | Splunk  

I just tested this and it works perfectly.   I tweaked a few names and combined the file contents from @kiran_panchavat with the regex from @PickleRick and I'm good to go.  Thanks guys! props.conf [source::auditd] TRANSFORMS-set=setnull transforms.conf [setnull] REGEX = acct=appuser.*exe=/usr/(sbin/crond|bin/crontab) DEST_KEY = queue FORMAT = nullQueue

Your expression is matching on at least 1 word character or non-word character i.e. almost anything, it then reduces back to the fewest characters match this, i.e. 1 character, so each instance of x is now a single character. This is why you are blowing the max_match limit. Try either including a trailing anchor pattern (and removing the ?), or improving the matching pattern.

1) The limits.conf file is configured by your administrator: https://docs.splunk.com/Documentation/Splunk/9.2.0/admin/limitsconf#.5Brex.5D 2) When I search for similar questions to yours. I find some possible answers to your problem: https://community.splunk.com/t5/Splunk-Search/Rex-has-exceeded-configured-match-limit/m-p/391837 https://community.splunk.com/t5/Splunk-Search/Regex-error-exceeded-configured-match-limit/m-p/469890 https://community.splunk.com/t5/Splunk-Search/Error-has-exceeded-configured-match-limit/m-p/539725 3) You'll notice in these other answers, that the questions supply a log sample and their query to show what the rex is working against. Only do this if the event information is not sensitive. But without that information, it'll be difficult for the community to help you. That's why I'm supplying you with some other information too.

Hello @bowesmana  Q: Are you collecting a _raw field or are you collecting fields without _raw? >> I am not sure what you meant, my  understanding _raw is the one that got pushed to index=summary Q: Are you specifying an index to collect to?   What's your collect command? I figured out why collect command didn't push the data. I put the wrong index name.  I stroke the incorrect name below | collect   index= summary     summary_test_1    testmode=false    file=summary_test_1.stash_new   name=summary_test_1"   marker="report=\"summary_test_1\"" Q:Are you running this as an ad-hoc search or as a scheduled saved search? I ran this as an ad-hoc search as a proof of concept using the past time Once it's working I will use a scheduled saved search for future time I added your suggestion to my search below and it worked, although I don't completely understand how.   Note that addtime=true/false didn't make any difference I appreciate your help.  Thank you.   If you have an easier way, please suggest     index=original_index ``` Query ``` | addinfo | eval _raw=printf("_time=%d", info_max_time) | foreach "*" [| eval _raw=_raw.case(isnull('<<FIELD>>'),"", mvcount('<<FIELD>>')>1,", <<FIELD>>=\"".mvjoin('<<FIELD>>',"###")."\"", true(), ", <<FIELD>>=\"".'<<FIELD>>'."\"") | fields - "<<FIELD>>" ] table ID, name, address | collect index= summary testmode=false addtime=true file=summary_test_1.stash_new name=summary_test_1" marker="report=\"summary_test_1\""