Thanks @P_vandereerden and it worked as the way I wanted. ... 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

Had I not chosen the solution already I would have given it to you for a more comprehensive answer 🙂 ... 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

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

Hi gcusello, Thanks for your response and suggestions. 1- As yuanliu  said, please see samples in text format (using the Insert/Edit Code Sample button). 2- I put all the search terms in the main search like you said as below:   index=nprod_database sourcetype=tigergraph:app:auditlog:8542 host=VCAUSC11EUAT* clientHost failedAttempts userAgent userName authType message timestamp actionName status "actionName":"login" "message":"Authentication failed" "status":"FAILURE" "timestamp":"2025-01-08T*"   Sample results:   {"endpoint":"/requesttoken","clientHost":"localhost:36976","userAgent":"Apache-HttpClient/5.2.3 (Java/17.0.13)","userName":"TEST6","authType":"LDAP","message":"Generate new token successfully.\nWarning: TEST6 Support cannot restore access to secrets/tokens for security reasons. Please save your secret/token and keep it safe and accessible.","timestamp":"2024-12-30T11:27:02.881-06:00","actionName":"requestToken","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"localhost:53964","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"login succeed","timestamp":"2024-12-30T15:47:15.496-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"localhost:54556","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2024-12-30T15:47:33.226-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/authtoken","clientHost":"localhost:54552","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"Generate new token successfully.\nWarning: TEST6 Support cannot restore access to secrets/tokens for security reasons. Please save your secret/token and keep it safe and accessible.","timestamp":"2024-12-30T15:47:35.36-06:00","actionName":"requestToken","status":"SUCCESS"}, {"endpoint":"/gsql/userdefinedtokenfunctions","clientHost":"localhost:54556","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"getUDFs succeeded","timestamp":"2024-12-30T15:47:38.872-06:00","actionName":"getUDFs","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"100.71.65.228","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2024-12-30T15:47:39.214-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/file","clientHost":"100.71.65.229","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"exportJob succeeded","timestamp":"2024-12-30T15:47:39.292-06:00","actionName":"exportJob","status":"SUCCESS"}, {"endpoint":"/gsql/authtoken","clientHost":"localhost:54552","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"Generate new token successfully.\nWarning: TEST6 Support cannot restore access to secrets/tokens for security reasons. Please save your secret/token and keep it safe and accessible.","timestamp":"2024-12-30T15:47:40.63-06:00","actionName":"requestToken","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"localhost:54556","userAgent":"GraphStudio","userName":"TEST1","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2024-12-30T15:47:41.877-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.229","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST2","authType":"LDAP","message":"login succeed","timestamp":"2024-12-31T10:00:19.455-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.229","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST2","authType":"LDAP","message":"login succeed","timestamp":"2024-12-31T10:03:22.203-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"localhost:47404","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST3","authType":"LDAP","message":"login succeed","timestamp":"2024-12-31T10:18:22.9-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.229","failedAttempts":0,"userAgent":"GrpahStudio","userName":"TEST3","authType":"LDAP","message":"Authentication failed!","timestamp":"2024-12-31T10:25:32.26-06:00","actionName":"login","status":"FAILURE"}, {"endpoint":"/requesttoken","clientHost":"localhost:35260","userAgent":"Apache-HttpClient/5.2.3 (Java/17.0.13)","userName":"TEST6","authType":"LDAP","message":"Generate new token successfully.\nWarning: TEST6 Support cannot restore access to secrets/tokens for security reasons. Please save your secret/token and keep it safe and accessible.","timestamp":"2024-12-31T11:00:05.35-06:00","actionName":"requestToken","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.229","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST3","authType":"LDAP","message":"login succeed","timestamp":"2024-12-31T11:24:31.435-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"localhost:47318","userAgent":"Apache-HttpClient/5.2.3 (Java/17.0.13)","userName":"c089265","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2024-12-31T21:15:55.995-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"localhost:38336","userAgent":"Apache-HttpClient/5.2.3 (Java/17.0.13)","userName":"c089265","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2025-01-02T11:36:45.844-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"100.82.128.85","userAgent":"Apache-HttpClient/5.2.3 (Java/17.0.13)","userName":"c089265","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2025-01-03T03:59:10.235-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"localhost:38012","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"login succeed","timestamp":"2025-01-06T13:47:43.429-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.229","failedAttempts":0,"userAgent":"GrpahStudio","userName":"TEST4","authType":"LDAP","message":"Authentication failed!","timestamp":"2025-01-06T13:48:27.717-06:00","actionName":"login","status":"FAILURE"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.228","failedAttempts":0,"userAgent":"GrpahStudio","userName":"TEST4","authType":"LDAP","message":"Authentication failed!","timestamp":"2025-01-06T13:48:32.587-06:00","actionName":"login","status":"FAILURE"}, {"endpoint":"/gsql/simpleauth","clientHost":"/127.0.0.1:43520","failedAttempts":0,"userAgent":"GrpahStudio","userName":"TEST4","authType":"LDAP","message":"Authentication failed!","timestamp":"2025-01-06T13:48:36.03-06:00","actionName":"login","status":"FAILURE"}, {"endpoint":"/gsql/simpleauth","clientHost":"localhost:60404","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST5","authType":"LDAP","message":"login succeed","timestamp":"2025-01-06T19:59:28.295-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.229","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST5","authType":"LDAP","message":"login succeed","timestamp":"2025-01-06T19:59:40.885-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/login","clientHost":"localhost:53886","clientOSUsername":"TEST4","failedAttempts":0,"userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"login succeeded","timestamp":"2025-01-06T20:45:36.492-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/file","clientHost":"10.138.170.165","clientOSUsername":"TEST4","userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"showCatalog succeeded","timestamp":"2025-01-06T20:45:37.241-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/login","clientHost":"localhost:39154","clientOSUsername":"TEST4","failedAttempts":0,"userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"login succeeded","timestamp":"2025-01-06T20:46:48.666-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/file","clientHost":"10.138.170.165","clientOSUsername":"TEST4","userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"showCatalog succeeded","timestamp":"2025-01-06T20:46:49.376-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/login","clientHost":"10.138.170.165","clientOSUsername":"TEST4","failedAttempts":0,"userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"login succeeded","timestamp":"2025-01-06T20:47:14.033-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/file","clientHost":"localhost:39154","clientOSUsername":"TEST4","userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"Successfully used graph 'aml_risk_graph'.","timestamp":"2025-01-06T20:47:14.863-06:00","actionName":"useGraph","status":"SUCCESS"}, {"endpoint":"/gsql/file","clientHost":"localhost:39154","clientOSUsername":"TEST4","userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"Successfully created query 'Del_orphan_edges_for_previous_primary'.","timestamp":"2025-01-06T20:47:17.079-06:00","actionName":"createQuery","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.228","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"login succeed","timestamp":"2025-01-06T20:55:21.895-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"localhost:43048","userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2025-01-06T20:56:34.057-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/queries","clientHost":"localhost:43048","userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"showQuery succeeded","timestamp":"2025-01-06T20:56:34.781-06:00","actionName":"showQuery","status":"SUCCESS"}, {"endpoint":"/gsql/file","clientHost":"localhost:39154","clientOSUsername":"TEST4","userAgent":"GSQL Shell","userName":"TEST4","authType":"LDAP","message":"Successfully installed query [Del_orphan_edges_for_previous_primary].","timestamp":"2025-01-06T20:57:36.229-06:00","actionName":"installQuery","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"100.71.65.229","userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2025-01-06T20:57:46.93-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/queries","clientHost":"localhost:60138","userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"showQuery succeeded","timestamp":"2025-01-06T20:57:47.563-06:00","actionName":"showQuery","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"localhost:48050","failedAttempts":0,"userAgent":"GraphStudio","userName":"sxvedag","authType":"LDAP","message":"login succeed","timestamp":"2025-01-07T08:56:29.476-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/gsql/schema","clientHost":"localhost:48036","userAgent":"GraphStudio","userName":"sxvedag","authType":"LDAP","message":"Successfully got schema for graph aml_risk_graph.","timestamp":"2025-01-07T08:56:38.165-06:00","actionName":"showCatalog","status":"SUCCESS"}, {"endpoint":"/gsql/queries","clientHost":"100.71.65.229","userAgent":"GraphStudio","userName":"sxvedag","authType":"LDAP","message":"showQuery succeeded","timestamp":"2025-01-07T08:56:38.823-06:00","actionName":"showQuery","status":"SUCCESS"}, {"endpoint":"/gsql/simpleauth","clientHost":"100.71.65.228","failedAttempts":0,"userAgent":"GraphStudio","userName":"TEST4","authType":"LDAP","message":"login succeed","timestamp":"2025-01-07T10:16:11.689-06:00","actionName":"login","status":"SUCCESS"}, {"endpoint":"/requesttoken","clientHost":"localhost:45058","userAgent":"Apache-HttpClient/5.2.3 (Java/17.0.13)","userName":"TEST6","authType":"LDAP","message":"Generate new token successfully.\nWarning: TEST6 Support cannot restore access to secrets/tokens for security reasons. Please save your secret/token and keep it safe and accessible.","timestamp":"2025-01-08T09:20:02.381-06:00","actionName":"requestToken","status":"SUCCESS"} ]   But here I don’t know why the filter is giving me information about "status":"SUCCESS" and "message":"login succeed" even my login failed condition is "message":"Authentication failed!" Maybe my condition in the search query is wrong. Also I was trying to get the results for the timestamp but it is showing all for other timestamp. 3- I suppose also  to check the condition for each host in our  infrastructure and each account by using my search below:   index=nprod_database sourcetype=tigergraph:app:auditlog:8542 host=VCAUSC11EUAT* clientHost failedAttempts userAgent userName authType message timestamp actionName status "actionName":"login" "message":"Authentication failed" "status":"FAILURE" "timestamp":"2025-01-08T*"   4- I tried  to use the stats command to aggregate results and the where command to filter them, something like this:   index=nprod_database sourcetype=tigergraph:app:auditlog:8542 host=VCAUSC11EUAT* clientHost failedAttempts userAgent userName authType message timestamp actionName status "actionName":"login" "message":"Authentication failed" "status":"FAILURE" "timestamp":"2025-01-08T*" | stats count BY actionName host | where count>3   Results: No results found. Thank you for your help. ... View more

As I said above, there is a steep learning curve with SPL's JSON flattening schema.  But it is learnable, and the syntax is reasonably logical. (Logical, not intuitive or self-explanatory.) First, the easiest way to to examine each individual array element is by mvexpand.  Like | spath path=json.msg | spath input=json.msg path=query{} | mvexpand query{} | rename query{} as query_single Here, xxx{} is  SPL's explicity denotation of an array that is flattened from a structure; array is most commonly known in SPL as multivalued.  You will see a lot of this word in documentation. Second, if you only want the first element, simply take the first element using mvindex. | spath path=json.msg | spath input=json.msg path=query{} | eval first_query = mvindex('query{}', 0) Test these over any of the emulations @ITWhisperer and I supplied above, and compare with your real data. ... View more

Thanks for your support and help. I worked more with my search, and I found a way to craft the search with some additional limiting material to extract what I want. The next step that was to join the material with the results from this subsearch, and even that was successful, so right now it looks like I have been able to solve the problems I had. In any case, the core of my original problem was related to using localize and map in a saved search, and that has now been resolved. In addition I managed to improve my search, so I think we can both be happy about it. ... View more

The problem arises at least in part from missing header in event data.  If the illustrated raw event is a complete event in _raw, this is what you can do to add that header.  No need for rex.   index=test_event source=/applications/hs_cert/cert/log/cert_monitor.log | head 1 | eval _raw = "Severity,Hostname,CertIssuer,FilePath,Status,ExpiryDate " . replace(_raw, "\|", ",") | multikv forceheader=1 | table Severity Hostname CertIssuer FilePath Status ExpiryDate   Here is a complete emulation:     | makeresults | eval _raw="ALERT|appu2.de.com|rootca12|/applications/hs_cert/cert/live/h_hcm.jks|Expired|2020-10-18 WARNING|appu2.de.com|key|/applications/hs_cert/cert/live/h_hcm.jks|Expiring Soon|2025-06-14 INFO|appu2.de.com|rootca13|/applications/hs_cert/cert/live/h_core.jks|Valid|2026-10-18 ALERT|appu2.de.com|rootca12|/applications/hs_cert/cert/live/h_core.jks|Expired|2020-10-18 WARNING|appu2.de.com|key|/applications/hs_cert/cert/live/h_core.jks|Expiring Soon|2025-03-22 ALERT|appu2.de.com|key|/applications/hs_cert/cert/live/h_mq.p12|Expired|2025-01-03" ``` the above emulates index=test_event source=/applications/hs_cert/cert/log/cert_monitor.log ``` | head 1 | rex field=_raw "(?<Severity>[^\|]+)\|(?<Hostname>[^\|]+)\|(?<CertIssuer>[^\|]+)\|(?<FilePath>[^\|]+)\|(?<Status>[^\|]+)\|(?<ExpiryDate>[^\|\s]+)" | multikv forceheader=1 | table Severity Hostname CertIssuer FilePath Status ExpiryDate   Output is Severity Hostname CertIssuer FilePath Status ExpiryDate ALERT appu2.de.com rootca12 /applications/hs_cert/cert/live/h_hcm.jks Expired 2020-10-18 WARNING appu2.de.com key /applications/hs_cert/cert/live/h_hcm.jks Expiring Soon 2025-06-14 INFO appu2.de.com rootca13 /applications/hs_cert/cert/live/h_core.jks Valid 2026-10-18 ALERT appu2.de.com rootca12 /applications/hs_cert/cert/live/h_core.jks Expired 2020-10-18 WARNING appu2.de.com key /applications/hs_cert/cert/live/h_core.jks Expiring Soon 2025-03-22 ALERT appu2.de.com key /applications/hs_cert/cert/live/h_mq.p12 Expired 2025-01-03   ... View more

It is best not to use rex to extract information from structured data.  As @ITWhisperer says, the OP should post complete sample logs instead of a fragment of JSON.  If the raw event is itself compliant JSON, there should be no need to extract using search commands because Splunk automatically does this at search time. ... View more

You would get better help if you follow these golden rules that I call the four commandments: 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

@sarathi125 FYI: Although you have a solution, using join is not a Splunk way of doing things, joining data sets should really be done using stats, it's faster, more efficient and does not have the limitations of join, which will silently discard results if the join subsearch exceeds 50,000 results - this may not be an issue in your case, but it's good practice to get your head around using stats to achieve joins. I also recommend you sort out the automatic field extraction so that you don't have to manually extract jobId - which then means you can use the fields in subsearches and only then have to make a single search.     ... View more

I would use list() instead of values() to prevent removal of duplicates and wrap the product in exact() to prevent rounding errors: | makeresults format=csv data="value_a 0.44 0.25 0.67 0.44" | stats list(value_a) as value_a | eval "product(value_a)"=1 | foreach value_a mode=multivalue [ eval "product(value_a)"=exact('product(value_a)' * <<ITEM>>) ] | table "product(value_a)"  => product(value_a) 0.032428 ... View more

Thank you! Works well. I'm struggling to get the last date value to calculate the percentage deviation. Could you please help ... View more

Several pointers about asking questions: When sharing structured data, please click "Raw text" before copying from event window.  Splunk's formatted display creates hurdle for volunteers to reverse. If you expect people to help read some SPL code you illustrate, your illustrated data should include relevant details used in your code.  For example, your illustration does not give indication of message.ssoType, message.incomingRequest.partner, etc. (In the following, I will assume that they are flat paths that require no special treatment.) The key to solving your problem is to note that JSON node message.backendCalls is an array.  In SPL, the flattened JSON array is denoted with a pair of curly brackets, i.e., message.backendCalls{}.  In addition, IF the raw events has a structure similar to your illustration, message.incomingRequest.partner, message.backendCalls{}.*, etc., should have already been extracted by Splunk at search time.  There is no need for spath.  Further more, placing filters in index search is more efficient than putting them downstream.  Combining these pointers, you should consider   index="uhcportals-prod-logs" sourcetype=kubernetes container_name="myuhc-sso" logger="com.uhg.myuhc.log.SplunkLog" message.ssoType="Outbound" message.incomingRequest.partner = * | rename message.incomingRequest.partner as "SSO_Partner" | stats distinct_count("UUID") as Count by SSO_Partner, Membership_LOB, message.backendCalls{}.responseCode   Your sample data would result in SSO_Partner Membership_LOB message.backendCalls{}.responseCode Count FBI CIA 200 1 Here is a reverse engineered emulation for you to play with and compare with real data   | makeresults | eval _raw = "{ \"@timestamp\": \"2024-12-25T08:10:57.764Z\", \"Membership_Category\": \"*******\", \"Membership_LOB\": \"CIA\", \"UUID\": \"********\", \"adminId\":\"*************\", \"adminLevel\": \"*************\", \"correlation-id\": \"*************\", \"dd.env\":\"*************\", \"dd.service\":\"*************\", \"dd.span_id\":\"*************\", \"dd.trace_id\":\"*************\", \"dd.version\":\"*************\", \"logger\":\"*************\", \"message\": { \"incomingRequest\": { \"partner\": \"FBI\" }, \"ssoType\": \"Outbound\", \"backendCalls\": [ { \"elapsedTime\": \"****\", \"endPoint\":\"*************\", \"requestObject\": { }, \"responseCode\": 200, \"responseObject\": { } } ] } }" | spath ``` the above emulates index="uhcportals-prod-logs" sourcetype=kubernetes container_name="myuhc-sso" logger="com.uhg.myuhc.log.SplunkLog" message.ssoType="Outbound" message.incomingRequest.partner = * ```       ... View more

Gentlemen you're right Search code:   | where my_time>=relative_time(now(),"-1d@d") AND _time<=relative_time(now(),"@d")   updated to    | where my_time &gt;=relative_time(now(),"-1d@d") AND _time &lt;=relative_time(now(),"@d")   will work in a dashboard. I started from scratch with all my trials and were not able to reproduce my issues with the html tags.  This must be a classic PIBCAK (Problem Is Between Chair and Keyboard) ... View more

Something like this: | makeresults | eval host="sender" | eval raw = mvappend("2024-12-18 17:02:50 , file_name=XYZ.csv, file copy success", "2024-12-18 17:02:58, file_name=ABC.zip, file copy success", "2024-12-18 17:03:38, file_name=123.docx, file copy success", "2024-12-18 18:06:19, file_name=143.docx, file copy success") | append [ | makeresults | eval host="receiver" | eval raw = "2024-12-18 17:30:10 <FileTransfer status=success> <FileName>XYZ.csv</FileName> <FileName>ABC.zip</FileName> <FileName>123.docx</FileName> </FileTransfer>" ] | mvexpand raw | rename raw AS _raw | rex "^(?<_time>\S+\s+\S+)" | eval _time = strptime(_time, "%Y-%m-%d %H:%M:%S") | rex max_match=0 "(?ms)(\<FileName\>|file_name=)(?<FileName>.*?)(\<|,)" | rex "(<FileTransfer status=\"?|file copy )(?<status>[^\"\>]+)" | stats list(status) AS status_list list(host) AS host_list dc(host) AS hosts values(status) AS status BY FileName | where hosts==1 OR status="fail*" ... View more

Have you look this answer https://community.splunk.com/t5/Alerting/Throttle-alerts-based-on-field-value/m-p/172536 if it fulfills your needs? ... View more

Hi @Sailesh6891 , good for you, see next time! Ciao and happy splunking Giuseppe P.S.: Karma Points are appreciated by all the contributors 😉 ... View more

Ahhhh... You had yet another field _called_ value. I suppose we all missed that and assumed "value" meant the value of one of the title* fields, not a separate field. *facepalm* In this case, you can still avoid using eventstats | sort - alert_level title1 | streamstats current=t dc(alert_level) as selector by title1 | where selector=1 | stats values(title4) as title4s by title1 Don't get me wrong - eventstats is a powerful and useful command but with some bigger datasets you might consider alternatives. ... View more

Hello, Thank you very much for all of the details, that did the trick and I can finally move on to the next task. Thanks again, Tom ... View more

Sure.  startswith and endwith can also be sophisticated.   | rename "Log text" as LogText | transaction maxspan=120s startswith=eval(match(LogText, "\bdisconnected\b")) endswith=eval(match(LogText, "\bconnected\b")) keeporphans=true | where isnull(closed_txn)   Here is an emulation   | makeresults format=csv data="Row, _time, Log text 1, 7:00:00am, text connected\ntext 2, 7:30:50am, text\ndisconnected\n\ntext 3, 7:31:30am, text connected\ntext 4, 8:00:10am, text\ndisconnected\n\ntext 5, 8:10:30am, text\ndisconnected\n\ntext" | eval _time = strptime(_time, "%I:%M:%S%p"), "Log text" = replace('Log text', "\\\n", " ") | sort - _time ``` data emulation above ```   The above search gives LogText Row _raw _time closed_txn duration eventcount field_match_sum linecount text disconnected text 5 1 2024-12-18 08:10:30           text disconnected text 4 1 2024-12-18 08:00:10           ... View more