You must have heard the phrase, time is of essence.  This is especially true in time series such as Splunk.  Could you start from the beginning and describe your use case?  What is the input, what is the expected output, and what is the logic between input and expected output without SPL? ... View more

To receive help in Splunk search, it is best to give more concrete information, even if you use mock names and values. Assuming the two different sources are sourcetype sourceA and sourceB.  The 3 parameters in sourceA are named "ID", "param2", and "param3".  Further assume that sourceB has the same field name "ID" to match that in sourceA, and that "actual name of the object" is in field named "name".  Assuming that all these fields are already extracted. sourcetype IN (sourceA, sourceB) | stats values(name) as name values(param2) as param2 values(param3) as param3 by ID   ... View more

Like @bowesmana says but do you really need the $env$ in the field name? Wouldn't  | stats dc(hostname) by host_environment make more sense in a dashboard?  ... View more

First, when illustrating structured data, please post compliant raw text.  In your case, a compliant JSON should be   { "application": "app1", "feature": "feature1", "timestamp": "01/29/2025 23:02:00 +0000", "users": [ { "userhost": "client1", "username": "user1" }, { "userhost": "client2", "username": "user2" } ] }   The trick here is to reach into the JSON array to perform mvexpand and ignore Splunk's default flattening of array.   | spath path=users{} | mvexpand users{} | spath input=users{}   Your sample data will give application feature timestamp userhost username users{} app1 feature1 01/29/2025 23:02:00 +0000 client1 user1 { "userhost": "client1", "username": "user1" } app1 feature1 01/29/2025 23:02:00 +0000 client2 user2 { "userhost": "client2", "username": "user2" } Here is an emulation for you to play with and compare with real data   | makeresults | eval _raw = "{ \"application\": \"app1\", \"feature\": \"feature1\", \"timestamp\": \"01/29/2025 23:02:00 +0000\", \"users\": [ { \"userhost\": \"client1\", \"username\": \"user1\" }, { \"userhost\": \"client2\", \"username\": \"user2\" } ] }" | spath ``` data emulation above ```     ... View more

Your question seems to be really about extracting user ID.  In other words, given the illustrated data, you want _raw restoftext trx user 10 1/17/2025 15:03:20 account record user100 does not exist account record user100 does not exist 10 user100 12 1/17/2025 15:03:20 login as admin login as admin 12 admin  Is this correct? The above can be achieve by regex.  But you have to enumerate all those login events and write alternative expressions.  For these two,   | rex "^(?<trx>\d+)\s+\S+\s+\S+\s+(?<restoftext>.+)" | rex field=restoftext "(login as|account record) (?<user>\S+)"   Here is an emulation for you to play with and compare with real data   | makeresults format=csv data="_raw 10 1/17/2025 15:03:20 account record user100 does not exist 12 1/17/2025 15:03:20 login as admin, raising privileges" ``` data emulation above ```   Hope this helps. ... View more

Given that a transaction_id would either not exist if a user never calls service 1, or it doesn't matter to your problem, service1_status is superfluous.  Is this correct?  I also do not see service URL as part of required output.  As such, @gcusello's solution can be further simplified.  More than that, I'm not sure if service is an existing field.  On the other hand, the two services are probably logged into different sources or different sourcetypes or both different.  I will assume that service 1 logs into source1 and service 2 logs into source 2.   source IN (source1, source2) | stats dc(source) AS service_count BY transaction_id | eval status1 = "yes", status2=if(service_count > 1,"yes","no") | table transaction_id status1 status2     ... View more

I think I understand the essence of the challenge.  Data analytics solution all depends on data characteristics.  Can you describe data further?  For example, the alternative field names, do they appear in the two different sources?  In other words, is there a relationship like this? index=email source=/var/logs/esa_0.log index=cyber source=/varlogs/fe01.log sender, recipient, subject, ...  suser, duser, msg, ... Such relationship can improve search by not using too many OR, which usually decreases efficiency.  On the other hand, even if such relationships exist, if suser, duser, subject, ... do not always exist in the same event, your search will not satisfy all filters.  As @PickleRick says, in that case you will have to sacrifice efficiency and fetch all events then filter. However, you have already clarified that except attachments,  sender, recipient, subject, etc., always exist, so do suser, duser, msg, and so on.  This means you can take advantage of those always-on fields. Now, to the bottom of the challenge.  Yes, you can do that.  But you need to change token strategy a little.  For this, we will single out the token for attachments from the rest. Just to distinguish this token, I call it attachments_tok, and set up Name-Value pairs (Label-Value in Dashboard Studio parler) like these: Name Value Any * filename1 attachments = filename1 filename2 attachments = filename2 ...   Once attachment_tok is set up, reorganize the search like this:   (index=email source=/var/logs/esa_0.log ($attachments_tok$) sha256=$hash$ sender="$sender$" recipient="$recipient$" subject="$subject$" message-id="$email_id$" from-header="$reply_add$") OR (index=cyber source=/varlogs/fe01.log suser="$sender$" duser="$recipient$" msg="$subject$" id="'<$email_id$>'" ReplyAddress="$reply_add$")    Hope this helps. ... View more

Combining everyone's suggestions, here is a command that is ready to go if that string is all you need: | rex "Setting connector (<myfield>\S+)" How strictly or loosely you want to set anchors and matches heavily depends on actual data and use case.  This is just something to get you started. ... View more

As with any good languages, there are many ways to do this.  A simple and semantically expressive method is to use coalesce. sourcetype IN (tableA, tableB) | eval col2 = coalesce(col2, colA) | stats values(col1) as col1 values(colB) as colB by col2   ... View more

Splunk uses different colors for different numeric fields.  Your stats command results in only one, count.  There are many ways to make a field named Pass and another named Fail.  As your output only contains a 2x2, the easiest is probably just transpose the output. index="sampleindex" source="samplesource" test_name="IR Test" serial_number="TC-7" | stats count by result | transpose header_field=result Additional tips: Do not use screenshot to share text data.  Share raw text. Do not cascade filters that can be performed in initial index search. Format Splunk searches with pipe sign at beginning of line, not end.  You can enable "Search auto-format" in preferences to help you create readable searches. ... View more

It's not really clear how you want your dashboard to behave.  If I have to guess, do you mean to say if a user specifies $file$ value as "thisfile", you want to return Emails with attachment named "thisfile" as well as Emails with no attachment?  If so, you can tell the search command to do so using OR logic. index=email source=/var/email_0.log (attachments=$file$ OR NOT attachments=*) OR sha256=$hash$ ... View more

Thank you @kgorzynski! Updated information provides much needed clarity. ... View more

You haven't answered key questions from me and @bowesmana.  Without SPL, what do you use to count number of sensors per host (if the total number of events is not the answer). Let me repeat the four commandments of asking answerable questions in this forum: Illustrate data input (in raw text, anonymize as needed), whether they are raw events or output from a search (SPL that volunteers here do not have to look at). Illustrate the desired output from illustrated data. Explain the logic between illustrated data and desired output without SPL. If you also illustrate attempted SPL, illustrate actual output and compare with desired output, explain why they look different to you if that is not painfully obvious. ... View more

As @bowesmana exemplifies, putting your complete set of values in a lookup is one way to count "missing" values.  Another way to is to put them in an multivalued field and use this field for counting.  Here is an example   index=idx1 host=host1 OR host=host2 source=*filename*.txt field1!=20250106 (field2="20005") OR (field2="20006") OR (field2="20007") OR (field2="666") | eval field2prime = mvappend("20005", "20006", "20007", "666") | mvexpand field2prime | eval field2match = if(field2 == field2prime, 1, 0) | stats sum(field2match) as count by field2prime | rename field2prime as field2   Here is an emulation you can play with and compare with real data:   | makeresults count=16 | streamstats count as _count | eval field2 = round(_count / 😎 % 3 + 20005 ``` the above emulates index=idx1 host=host1 OR host=host2 source=*filename*.txt field1!=20250106 (field2="20005") OR (field2="20006") OR (field2="20007") OR (field2="666") ```   Mock data looks like this: fiel2 20005 20005 20005 20006 20006 20006 20006 20006 20006 20006 20006 20007 20007 20007 20007 20007 If you count this against field2 directly, you get field2 count 20005 3 20006 8 20007 5 Using the above search, the result is field2 count 20005 3 20006 8 20007 5 666 0 ... View more

I can manually count and see that there are x # of sensors setup per hostname.  You need to show volunteers here HOW do you count number of sensors from logs (without using SPL). Here are four commandments to help you ask answerable questions in this forum: Illustrate data input (in raw text, anonymize as needed), whether they are raw events or output from a search (SPL that volunteers here do not have to look at). Illustrate the desired output from illustrated data. Explain the logic between illustrated data and desired output without SPL. If you also illustrate attempted SPL, illustrate actual output and compare with desired output, explain why they look different to you if that is not painfully obvious. ... View more

Not sure if I fully understand the requirement.  But in general, you can assign a non-null string to those fields.  For example, | eval MX = coalesce(MX, "MX is null") The issue, I suspect, is when you transpose, all those values representing null will collapse and skew format.  Is this the problem?  If so,  you can force these values to be different, e.g., | eval MX = coalesce(MX, "MX is null for " . FQDN) Hope. this helps. ... View more

I see you want to determine full paths of the value input list.  You have a second requirement that the input be a JSON array,  ["Tag3", "Tag4"], and a third that the code needs to run in 8.0, which precludes JSON functions introduced in 8.1.  Note each of the path{} array has multiple values.  Without help of JSON functions, you need to handle that first. The most common way to do this is with mvexpand. (The input array also needs this.) | makeresults | eval _raw = "{ \"Info\": { \"Apps\": { \"ReportingServices\": { \"ReportTags\": [ \"Tag1\" ], \"UserTags\": [ \"Tag2\", \"Tag3\" ] }, \"MessageQueue\": { \"ReportTags\": [ \"Tag1\", \"Tag4\" ], \"UserTags\": [ \"Tag3\", \"Tag4\", \"Tag5\" ] }, \"Frontend\": { \"ClientTags\": [ \"Tag12\", \"Tag47\" ] } } } }" | spath ``` data emulation above ``` | eval Tags = "[\"Tag3\", \"Tag4\"]" | foreach *Tags{} [mvexpand <<FIELD>>] | spath input=Tags | mvexpand {} | foreach *Tags{} [eval tags=mvappend(tags, if(lower('<<FIELD>>') = lower('{}'), "<<FIELD>>", null()))] | dedup tags | stats values(tags) If your dataset is large, mvexpand has some limitations. ... View more

Do you mean this?   | makeresults | eval _raw = "{ \"Info\": { \"Apps\": { \"ReportingServices\": { \"ReportTags\": [ \"Tag1\" ], \"UserTags\": [ \"Tag2\", \"Tag3\" ] }, \"MessageQueue\": { \"ReportTags\": [ \"Tag1\", \"Tag4\" ], \"UserTags\": [ \"Tag3\", \"Tag4\", \"Tag5\" ] }, \"Frontend\": { \"ClientTags\": [ \"Tag12\", \"Tag47\" ] } } } }" | eval Tag = "Tag1" | spath | foreach *ReportTags{} [| eval tags=mvappend(tags, if(lower('<<FIELD>>') = lower(Tag), '<<FIELD>>', null()))] | dedup tags | stats values(tags)   This gives values(tags) Tag1 Tag4 Note when you use double quote on the right-hand side of an eval expression, in quoted entity is used as literal, therefore your original search gives values(tags) Info.Apps.MessageQueue.ReportTags{} Info.Apps.ReportingServices.ReportTags{} ... View more

First, map is usually not the solution to the problem you are trying to solve. Secondly, could you explain the relationship between values "a", "b" and the searches "index=_internal | head 1 | eval val=\"Query for a1\" | table val" and "index=_internal | head 1 | eval val=\"Query for b\" | table val"? Confusingly, everyone of the three searches will result in a predetermined string value of a single field.  Why bother with index=_internal?  If you are just trying to make a point of map, you can compose them with makeresults just as easily. If you really want to use map, study the syntax and examples in map.  The whole idea of map is to NOT use case function.  To produce the result you intended, here is a proper construct:   | makeresults | eval name1 = mvappend("c", "b", "a") | mvexpand name1 | map search="search index=_internal | head 1 | eval val=if(\"$name1$\" IN (\"a\", \"b\"), \"Query for $name1$\", \"Default query\") | table val"   This is the output no matter what data you have in _internal. val Default query Query for b Query for a However, there are often much easier and better ways to do this.  To illustrate, forget val="Query for a".  Let's pick more realistic mock values "info", "warn".  This is a construct using map.   | makeresults | eval searchterm = mvappend("info", "warn", "nosuchterm") | mvexpand searchterm | map search="search index=_internal log_level=\"$searchterm$\" | stats count by log_level | eval val=if(\"$searchterm$\" IN (\"info\", \"warn\"), \"Query for $searchterm$\", \"Default query\")"   If you examine _internal events, you will know that, even though searchterm is given three values, the above should only give two rows, like log_level count val INFO 500931 Query for info WARN 17262 Query for warn However, the syntax of map makes the search much harder to maintain.  Here is an alternative using subsearch. (There are other alternatives based on actual search term and data characteristics.)   index=_internal [makeresults | eval searchterm = mvappend("info", "warn", "nosuchterm") | fields searchterm | rename searchterm as log_level] | stats count by log_level | eval val = if(log_level IN ("INFO", "WARN"), "Query for " . log_level, "Default query")   If you apply this to the exact same time interval, it will give you exactly the same output. Hope this helps. ... View more

I can confirm that this is fixed in 9.4.0   | makeresults format=csv data="field a a:b" | eval field = split(field, ":"), count = mvcount(field), map = mvmap(field, "1")   In 9.4.0, it returns count field map 1 a 1 2 a b 1 1 Before the fix, it would return the following, incorrect first row. count field map 1 a a 2 a b 1 1 ... View more

Two problems with the search. In an evaluation function, deep path payload.status needs to be single quoted (i.e., 'payload.status') to dereference its value.  Otherwise bare word payload.status evaluates to null. If you want to use count(is_ok), you should make the "other" value disappear, i.e., make it be a null, not a "real" value of 0.  If you think 0 is a better representation for "other", use sum as @ITWhisperer suggests. In other words, on mock event sequence _raw payload.status seq {"seq":1,"payload":{"status":"ok"}} ok 1 {"seq":2,"payload":{"status":"degraded"}} degraded 2 {"seq":3,"payload":{"status":"ok"}} ok 3 either   | eval is_ok=if('payload.status'=="ok", 1, null()) | stats count as total, count(is_ok) as ok_count   or   | eval is_ok=if('payload.status'=="ok", 1, 0) | stats count as total, sum(is_ok) as ok_count   or even   | eval is_ok=if('payload.status'=="ok", 1, 0) | stats count as total, count(eval(is_ok = 1)) as ok_count   should give you total ok_count 3 2 This is an emulation you can play with and compare with real data   | makeresults format=json data="[ { \"seq\": 1, \"payload\": { \"status\": \"ok\", } }, { \"seq\": 2, \"payload\": { \"status\": \"degraded\", } }, { \"seq\": 3, \"payload\": { \"status\": \"ok\", } } ]" | fields - payload, seq, _time | spath ``` data emulation above ```     ... View more

Actually, I think transaction should work in this case.  @bowesmana is correct that your command is missing host as parameter.  But more than that, it is also missing option keeporphans.  Also the determinant is not eventcount but closed_txn.   | transaction host maxspan=5m keeporphans=true startswith="%ROUTING-LDP-5-NSR_SYNC_START" endswith="%ROUTING-LDP-5-NBR_CHANGE" | where closed_txn != 1 | stats count by host   Apply the above to this mock dataset: _raw _time host 1 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:02:45 host1 2 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:02:39 host2 3 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:02:33 host3 5 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:02:21 host0 6 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:02:15 host1 7 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:02:09 host2 8 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:02:03 host3 9 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:01:57 host4 10 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:01:51 host0 11 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:01:45 host1 13 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:01:33 host3 14 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:01:27 host4 15 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:01:21 host0 16 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:01:15 host1 17 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:01:09 host2 18 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:01:03 host3 19 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:00:57 host4 20 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:00:51 host0 21 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:00:45 host1 22 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:00:39 host2 23 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:00:33 host3 25 %ROUTING-LDP-5-NBR_CHANGE 2025-01-11 19:00:21 host0 26 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:00:15 host1 27 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:00:09 host2 28 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 19:00:03 host3 29 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 18:59:57 host4 30 %ROUTING-LDP-5-NSR_SYNC_START 2025-01-11 18:59:51 host0 You get host count host2 1 host4 2 Here is an emulation that produces the above mock data   | makeresults count=30 | streamstats count as _count | eval _time = _time - _count * 6 | eval host = "host" . _count % 5 | eval _raw = _count . " " . mvindex(mvappend("%ROUTING-LDP-5-NSR_SYNC_START", "%ROUTING-LDP-5-NBR_CHANGE"), -ceil(_count / 5) %2) | search NOT (_count IN (4, 12, 24) %ROUTING-LDP-5-NBR_CHANGE) ``` the above emulates index = test ("%ROUTING-LDP-5-NSR_SYNC_START" OR "%ROUTING-LDP-5-NBR_CHANGE") ```   Play with it and compare with real data. ... View more

Please share event with raw text, not search app's format. Regardless, you should not need any regex to deal with this data because Splunk already extracted everything.  Secondly, you do not need to consider logs{}.action because your requirement only concerns status "Open" and "Escalated".  What actions have been taken is irrelevant to filter. In other words, given status and id like the following: _time id status 2025-01-10 23:24:57 xxx10 Escalated 2025-01-10 23:17:57 xxx10 Other 2025-01-10 23:10:57 xxx10 Open 2025-01-10 23:03:57 xxx10 Other 2025-01-10 22:56:57 xxx10 Open 2025-01-10 23:30:57 xxx11 Closed 2025-01-10 23:23:57 xxx11 Closed 2025-01-10 23:16:57 xxx11 Open 2025-01-10 23:09:57 xxx11 Escalated 2025-01-10 23:02:57 xxx11 Other 2025-01-10 22:55:57 xxx11 Open 2025-01-10 23:29:57 xxx12 Assigned 2025-01-10 23:22:57 xxx12 Open 2025-01-10 23:15:57 xxx12 Closed 2025-01-10 23:08:57 xxx12 Closed 2025-01-10 23:01:57 xxx12 Open 2025-01-10 22:54:57 xxx12 Escalated 2025-01-10 23:28:57 xxx13 Open 2025-01-10 23:21:57 xxx13 Open 2025-01-10 23:14:57 xxx13 Assigned 2025-01-10 23:07:57 xxx13 Open 2025-01-10 23:00:57 xxx13 Closed 2025-01-10 22:53:57 xxx13 Closed 2025-01-10 23:27:57 xxx14 Assigned 2025-01-10 23:20:57 xxx14 Escalated 2025-01-10 23:13:57 xxx14 Open 2025-01-10 23:06:57 xxx14 Open 2025-01-10 22:59:57 xxx14 Assigned 2025-01-10 22:52:57 xxx14 Open 2025-01-10 23:26:57 xxx15 Open 2025-01-10 23:19:57 xxx15 Open 2025-01-10 23:12:57 xxx15 Assigned 2025-01-10 23:05:57 xxx15 Escalated 2025-01-10 22:58:57 xxx15 Open 2025-01-10 22:51:57 xxx15 Open 2025-01-10 23:25:57 xxx16 Open 2025-01-10 23:18:57 xxx16 Other 2025-01-10 23:11:57 xxx16 Open 2025-01-10 23:04:57 xxx16 Open 2025-01-10 22:57:57 xxx16 Assigned You only want to count events for id's xxx10 (last status Escalated), xxx13 (Open), xxx15 (Open), and xxx16 (Open).  Using eventstats is perhaps the easiest.     | eventstats latest(status) as final_status by id | search final_status IN (Open, Escalated) | stats count by id final_status   Here, final_status is thrown in just to confirm that final_status only contains Open or Escalated.  The above mock data will result in id final_status count xxx10 Escalated 5 xxx13 Open 6 xxx15 Open 6 xxx16 Open 5 Here is the emulation that generates the mock data.  Play with it and compare with real data.   | makeresults count=40 | streamstats count as _count | eval _time = _time - _count * 60 | eval id = "xxx" . (10 + _count % 7) | eval status = mvindex(mvappend("Open", "Assigned", "Other", "Escalated", "Closed"), -(_count * (_count % 3)) % 5) ``` data emulation above ```   Hope this helps. ... View more

Please do not use screenshot to illustrate text data.  Use text table or text box.  But even the two index search screenshots are inconsistent, meaning there is no common dest_ip.  You cannot expect all fields to be populated when there is no matching field value.  This is basic mathematics. Like @bowesmana says, find a small number of events that you know have matching dest_ip in both indices, manually calculate what the output should be, then use the proposed searches on this small dataset. Here is a mock dataset losely based on your screenshots but WITH matching dest_ip src_zone src_ip dest_zone dest_ip transport dest_port app rule action session_end_reason packets_out packets_in src_translated_ip dvc_name index server_name ssl_cipher ssl_version trusted 10.80.110.8 untrusted 152.88.1.76 UDP 53 dns_base whatever1 blocked policy_deny 1 0 whateverNAT don'tmatter *firewall*             152.88.1.76                     *corelight* whatever2 idon'tcare TLSv3 The first row is from index=*firewall*, the second from *corelight*. Because your two searches operators on different indices, @gcusello 's search can also be expressed with append (as opposed to OR) without much penalty.  Like this   index="*firewall*" sourcetype=*traffic* src_ip=10.0.0.0/8 | append [search index=*corelight* sourcetype=*corelight* server_name=*microsoft.com*] | fields src_zone, src_ip, dest_zone, dest_ip, server_name, transport, dest_port, app, rule, action, session_end_reason, packets_out, packets_in, src_translated_ip, dvc_name | stats values(*) AS * BY dest_ip | rename src_zone AS From, src_ip AS Source, dest_zone AS To, dest_ip AS Destination, server_name AS SNI, transport AS Protocol, dest_port AS Port, app AS "Application", rule AS "Rule", action AS "Action", session_end_reason AS "End Reason", packets_out AS "Packets Out", packets_in AS "Packets In", src_translated_ip AS "Egress IP", dvc_name AS "DC"   Using the mock dataset, the output is Destination Action Application DC Egress IP End Reason From Packets In Packets Out Port Protocol Rule SNI Source To 152.88.1.76 blocked dns_base don'tmatter whateverNAT policy_deny trusted 0 1 53 UDP whatever1 whatever2 10.80.110.8 untrusted This is a full emulation for you to play with and compare with real data   | makeresults format=csv data="src_zone, src_ip, dest_zone, dest_ip, transport, dest_port, app, rule, action, session_end_reason, packets_out, packets_in, src_translated_ip, dvc_name trusted, 10.80.110.8, untrusted, 152.88.1.76, UDP, 53, dns_base, whatever1, blocked, policy_deny, 1, 0, whateverNAT, don'tmatter" | table src_zone, src_ip, dest_zone, dest_ip, transport, dest_port, app, rule, action, session_end_reason, packets_out, packets_in, src_translated_ip, dvc_name | eval index="*firewall*" ``` the above emulates index="*firewall*" sourcetype=*traffic* src_ip=10.0.0.0/8 ``` | append [makeresults format=csv data="server_name, dest_ip, ssl_version, ssl_cipher whatever2, 152.88.1.76, TLSv3, idon'tcare" | eval index="*corelight*" ``` the above emulates index=*corelight* sourcetype=*corelight* server_name=*microsoft.com* ```] | fields src_zone, src_ip, dest_zone, dest_ip, server_name, transport, dest_port, app, rule, action, session_end_reason, packets_out, packets_in, src_translated_ip, dvc_name | stats values(*) AS * BY dest_ip | rename src_zone AS From, src_ip AS Source, dest_zone AS To, dest_ip AS Destination, server_name AS SNI, transport AS Protocol, dest_port AS Port, app AS "Application", rule AS "Rule", action AS "Action", session_end_reason AS "End Reason", packets_out AS "Packets Out", packets_in AS "Packets In", src_translated_ip AS "Egress IP", dvc_name AS "DC"     ... View more