OK. Let me start from dissecting your search so far and pointing out a few things. index=windowsevents EventCode=33205 SourceName=MSSQLSERVER
(database_name=prod_prosjekt) (action_id="UP")
(session_server_principal_name!=prod_prosjekt AND session_server_principal_name!="sa") This part is generally OK since you already have several conditions narrowing your search pretty well but remember that exclusion on its own is not a very good way to search. So if you just had the session_server_principal_name on its own, it would be very ineffective. (You can check how many rows are scanned vs. how many results are returned in your job details). | table _time, object_name, action_id, server_principal_name, statement OK. Here's my first objection. The table command in general should not be used early in the search. It moves the processing from the indexers to the search heads. So you no longer benefit from distributed searching. It also gathers all results Splunk has so far so you're not processing data in a streaming fashion. If you want to limit the set of fields processed further (due to memory constraints you might want to remove _raw sometimes for example), use the "fields" command. | eval attrs="extract commaseparated list of the attributes" I suppose this is a placeholder for opration(s) which would result in the "attrs" field being filled with names of several fields extracted from the event, right? | append [ search index=windowsevents EventCode=33205 SourceName=MSSQLSERVER database_name=prod_prosjekt action_id=UP (server_principal_name!=prod_prosjekt AND server_principal_name!="sa") | eval E=_time-3, L=_time+5, tabell="cdc.dbo_"+object_name+"_CT" | map search="search index=esak-audit tablename=$tabell$ earliest=$E$ latest=$L$ | fields _time, tablename, operasjon, client, <here I want to be able use attrs> | fields - _raw | eval result_type='audit_logs' " ] OK. This one has more issues than just map. First and foremost - unless you have a very well-defined case when the appended search is sure to be run quickly and return a small set of result, don't use it. Sometimes append can be optimized out internally to multisearch but it works only for specific searches and you can't count on it always. In this case your appended subsearch does not qualify for changing it to a multisearch. So splunk will try to run the appended subsearch and might hit its limits (60 seconds runtime by default and 10k results returned). Since the appended search contains map, it will be "heavy" - for each row of the "base subsearch" Splunk will try to spawn a whole search - create it, parse, spawn a search job to indexers, fetch results, aggregate them... it's a lot of work. This is definitely _not_ the kind of search you'd want to have as an appended search. Another thing which you overlooked is the scope. You're not only trying to dynamically list fields, you're trying to pass them over _from another search_ - look at it, you're generating the "attrs" field in the "first" search and want to use it in the appended search which - for Splunk - is a completely separate search and Splunk only aggregates results from those searches. Other than that those searches do not share any common "knowledge". This is definitely _not_ how you should approach this. Especially since you're doing two separate "runs" over the same result set (the part search index=windowsevents EventCode=33205 SourceName=MSSQLSERVER database_name=prod_prosjekt action_id=UP (server_principal_name!=prod_prosjekt AND server_principal_name!="sa") is common to the initial search and the appended search. So the issue here is that you're thinking about the problem as a programming problem - about things to _do_ whereas with Splunk you have to think about data manipulation. Think about it in terms of two data sets and combining them. Please post at short snippet of those events: index=windowsevents EventCode=33205 SourceName=MSSQLSERVER (database_name=prod_prosjekt) (action_id="UP") (session_server_principal_name!=prod_prosjekt AND session_server_principal_name!="sa") and those events: search index=esak-audit Anonymize them of course if they contain sensitive information. It's about the structure and correlation, not about the data as such.
... View more