Hi Rich, I installed these settings under system/local on both SH and Indexer and also a single instance. btool checks out fine and I've applied the same transformation on the [scheduler] sourcetype and everything works as expected.  Odd Behavior with the audit.log also the default inputs.conf  /etc/system/default/inputs.conf states the following. [fschange:$SPLUNK_HOME\etc] disabled = false #poll every 10 minutes pollPeriod = 600 #generate audit events into the audit index, instead of fschange events signedaudit=true recurse=true followLinks=false hashMaxSize=-1 fullEvent=false sendEventMaxSize=-1 filesPerDelay = 10 delayInMills = 100 I'm under the impression Splunk's security measures lock the ability of transforming the audit log ... View more

At index time I'm have trying to extract and index the field app from the audittrail  Audit:[timestamp=04-27-2023 16:51:22.073, user=test, action=search, info=completed, search_id='1682628653.251613', has_error_warn=false, fully_completed_search=true, total_run_time=0.61, event_count=9, result_count=0, available_count=9, scan_count=9, drop_count=0, exec_time=1682628653, api_et=1682539200.000000000, api_lt=1682628653.000000000, api_index_et=N/A, api_index_lt=N/A, search_et=1682539200.000000000, search_lt=1682628653.000000000, is_realtime=0, savedsearch_name="", search_startup_time="88", is_prjob=false, is_flex_search=false, rate_limit_retry_enabled=false, acceleration_id="E06599A7-7307-4983-8459-FD948B9F996B_search_argus_test_6d524bc0f6be8430", app="search", provenance="UI:Search", mode="historical", From my tests it' doesn't matter what REGEX I used in the  transforms.conf, there seems to be a behavior where the [audittrail] is read only props.conf   [audittrail] TRANSFORMS-audit_addMetadata = add_app_to_metadata   transforms.conf   [add_app_to_metadata] SOURCE_KEY = _raw REGEX = app=\"([^"]+) FORMAT = mApp::$1 WRITE_META = true   ... View more

The mvzip approach is what I was trying to accomplish, but thank you for your response it's very helpful ... View more

Thank you this was very helpful ... View more

HI Guys, I want to post some of my findings which could cut your dbxquery time in half. Findings: 1. Keep an eye out for the number columns you are returning I tested this against a table with 227 columns returning 5001 rows all 227 rows took 32-34 seconds 1 column took 13- seconds 2. @health.logger attributes slow response times Have a look at def execute_query in dbquery.py. I commented out the attribute #@health.Logger("dbquery:execute_query", health.DB) This took the same query as above down from 13 to 6-8 seconds ... View more

Yes it does help - I just successfully finished testing a panel with your suggestion. Thank you for your help ... View more