Just extract the appropriate fields from the URI and split the parameters into a multivalued field. | makeresults | eval _raw="msg: abc.asia - [2021-08-23T00:27:08.152+0000] \"GET /facts?factType=COMMERCIAL&sourceSystem=ADMIN&sourceOwner=ABC&filters=%257B%2522stringMatchFilters%2522:%255B%257B%2522key%2522:%2522BFEESCE((json_data-%253E%253E'isNotSearchable')::boolean,%2520false)%2522,%2522value%2522:%2522false%2522,%2522operator%2522:%2522EQ%2522%257D%255D,%2522multiStringMatchFilters%2522:%255B%257B%2522key%2522:%2522json_data-%253E%253E'id'%2522,%2522values%2522:%255B%25224970111%2522%255D%257D%255D,%2522containmentFilters%2522:%255B%255D,%2522nestedMultiStringMatchFilter%2522:%255B%255D,%2522nestedStringMatchFilters%2522:%255B%255D%257D&sorts=%257B%2522sortOrders%2522:%255B%257B%2522key%2522:%2522id%2522,%2522order%2522:%2522DESC%2522%257D%255D%257D&pagination=null\"" | rex "\"(?<req>\S+)\s(?<uri>\S+)\"" | eval uri=urldecode(uri) | rex field=uri "(?<reqpath>.*)\?(?<query>.*)" | makemv delim="&" query | search query="factType=COMMERCIAL"  Then you can extract the "filters=something" value from the query field and process it apropriately (probably passing it through another urldecode()). ... View more

Well, yes, and no 🙂 I'd advise against formating time to text whenever possible. If possible - keep the time as unix timestamp, only format it on output with | fieldformat. That way any time manipulation is much easier (you just add/substract appropriate number of seconds) without the need of recalculating the date to/from the string representation. ... View more

If you do at - let's say - 10:35:15 a |timechart with span=1m over last 5 minutes, you'll get data from 10:30:15 to 10:35:15 split into a minute-long buckets, aligned at full minutes. So you'll get 6 buckets - one containing events from 10:30:15 to :10:31:00, another one from 10:31:00 to 10:32:00 and so on up to 10:35:00-10:35:15. Obviously, the first and last buckets will be smaller than the rest of them. That's the default behaviour of the |timechart You can however use partial=f option for |timechart wich will omit the not-full first and last buckets from the result. In our example case you'd get only four buckets - 10:31-10:32, 10:32-10:33, 10:33-10:34 and 10:34-10:35. ... View more

Ahhh... I thought you wanted to have a value from last minute compared to an average of previous values. But you simply want a moving average over a sliding window. Just use the timechart (as I wrote before - it's a dedicated command for analysing time series so there's no need to fiddle manually with buckets) and do a streamstats. <<your_search>> | timechart count span=1m | streamstats window=10 avg(count) Alternatively you can use |trendline <<your_search>> | timechart count span=1m |  trendline sma10(count) Remember than with time aligned to full minutes you might want to set your search time range to full minutes otherwise you'll get "not-full" values at the ends of the range since they correspond to only fractions of a minute. ... View more

Well, you can have an action "send email" in alert definition but the email settings for your Splunk Enterprise instance must be specified by the admin. If your Splunk instance was not configured for sending email, it's either an ommision by the admin or a deliberate choice not to use this functionality. Either way - you should consult your Splunk admin about this. And it's overally a good idea - a normal user shouldn't be able to (ab)use email sending functionality by trying to send emails via random servers. ... View more

I don't understand 🙂 I thought you wanted a value of count of events from the last minute and the average per-minute value from some previous minutes. That's what this does. Firstly it calculates per-minute statistics with |timechart. Then it adds a field containing a timestamp of the latest minute (so we can differentiate between the latest minute and the previous ones). Then it rewrites the timestamp for the remainding minutes so they can be aggregated with stats. And finally | stats avg(count) gives you two values - one is an "average" value from a single value from last minute and the other is an average calculated from previous minutes. Is that not what you wanted?   ... View more

"Prettier" solution probably could be made using a lookul translating from one set of codes into another set of categories. But even with a simple eval, instead of a multi-or-ed conditon I'd rather use a case statement - that's a bit more flexible and easy to maintain IMHO. ... View more

As a one-off search, you can just use | rex to extract the data from the event but in general it'd be better to write a proper parsing rules for this sourcetype so you have the data extracted automatically into the fields. ... View more

What do you mean "don't use an index"? You can quite easily find searches which don't have said index literarily entered as a part of the search but what if the searches reference that index in another way? A macro, for example. Or a subsearch? BTW, just because a search doesn't use a "index=something" condition, doesn't mean that it's "bad". You might - for example have searches populating lookups by performing ldapsearch. Or you might use a search to check a dynamicaly created lookup for its validity of some kind. Or any other legit reason not to have an index explicitly included i  the search. ... View more

How do you decide what constitutes a non-working dashboard? One thing is that a query populating widgets might be syntacticaly wrong or might be referencing a non-existing object. Maybe with some deal of painful work you could (semi)automaticaly detect such ones. But what about the ones that simply return wrong values? How would you be able to decide which values make sense and which don't without understanding what they represent? ... View more

To define roles (add capabilities to a role) you have to be an admin. ... View more

Judging from your search, these are not empty rows. You group by accountNumber and targetAccountNumber so even if you could have empty fields to split results by, you definitely cannot have two different "empty", "empty" results. So your results probably (even though you pasted them destroying the formatting a bit) contain just three rows. The fields eventType and eventTime have multivalue contents. For example, for a row with an accountNumber 123456 and targetAccountNumber 789123 you have a _single_ result with multivalue entry at eventType containing entries "apple" and "banana" and two different entries as multivalue entry at eventTime. What's important - since you used values() on both those fields - there is no relation between those values that you can devise from them. In particular, "apple" "banana" and both timestamps could come from four different events. You could do mvexpand but the results can make not much sense so I'd urge you to reconsider your initial search. Again - if you have search results like that: 212121                         999999                              Texas                   09/04/2020 :18:00                                                                                                                        09/04/2020:19:00                                                                                                                       09/04/2020:20:00                                                                                                                       09/04/2020:21:00 It doesn't mean that there is "no eventType" for the 19:00, 20:00 and 21:00 timestamp. The search that you provided should return different combinations of accountNumber and targetAccountNumber field values but for each of those combinations it only lists possible values for the two remaining fields regardless of whether they appear in the events with any connection to one another. In other words - if you have table in form of: A,B 1,2 3,4 5,6 1,7 3,6, 1,4 and you do | stats values(A) values(B) you'll get just a single row of results with two fields - one will be a multivalued field of 1,3 and 5, and the other one will be another multivalued field with 2,4,6 and 7. ... View more

What do you mean by "is being"? Because a question for a simple field=value search seems a bit lazy 😉 ... View more

Well, the regex is indeed a faulty one. Let's analyze (?: - non-capturing group : - a literal colon ) - end of a group So (?::) should match a literal colon withou creating a named or counted capture group. And now is where the "magic" happens: {0} - zero (sic!) repetitions of previous group. Which means that the regex matches any empty string (or rather any "space" between characters). Oh, and at the end you have a lone asterisk which should follow some token but doesn't so it's definitely some mistake in regex definition. ... View more

It won't work with glob patterns. It can't. Remember - as I wrote before - if you have your events as an output of the search (and want to do some further analysis like | stat) splunk doesn't know anymore what were the criteria you were searching by. So my walkaround was not letting you match filenames from "the input". It was just predicting the output. You probably could do some magic to match with glob patterns or any other kind of match but that would involve either some kind of more complicated lookup matching or using some fancy evals. ... View more

Well, that's understandable firstly you select events using a set of constraints (in this case, possible index names), then you do a statistical operation on this set of events. Splunk in the | stats step doesn't know the original conditions. It only knows the events that have been supplied from the search. If the filenames are known beforehand, you might prepare a static table using a lookup or an inline search with count=0 and then sum your results with those prepared earlier. something like: index=magic source IN ("D:\\show\\magic.log", "D:\\show\\magic_new.log", "D:\\show\\magic_old.log") | stats count by source | append [ | makeresults | eval _raw="D:\\show\\magic.log D:\\show\\magic_new.log D:\\show\\magic_old.log" | multikv noheader=t | rename Column_1 as source | table source | eval count=0 ] | stats sum(count) by source Ugly as hell but should do. If you have the filenames in a lookup you could just use inputlookup instead of all this consturction within [] (and use the lookup to generate constraints for the search as well- that way you have your search consistent. ... View more

You can use a transform to rewrite the index metadata field of an event. https://docs.splunk.com/Documentation/Splunk/latest/admin/transformsconf#KEYS: So in a props.conf you do [mysourcetype] TRANSFORMS-redirect=redirect_to_index2 And in transforms.conf (assuming you want to redirect json events: [redirect_to_index2] REGEX = {.*} FORMAT = index2 DEST_KEY = _MetaData:Index   EDIT: I'm not sure if {} don't need to be escaped in regex. ... View more

I don't know why you assume that there needs to be a transaction. And you keep misunderstanding the question. There are no separate types of events to detect. As I wrote earlier, let's assume you have a sequence of login events: Day ,User 1,user1 2,user1 13,user2 14,user3 27,user1 40,user1 51,user2 54,user3 72,user2 82,user3 101,user2 110,user3 140,user1 The original poster's question was how to detect events like user1's login at day 140 (since previous login was over 90 ays earlier). Your transaction-based solution won't do: | makeresults | eval _raw="Day,User 1,user1 2,user1 13,user2 14,user3 27,user1 40,user1 51,user2 54,user3 72,user2 82,user3 101,user2 110,user3 140,user1" | multikv noheader=f | fields Day User | transaction User maxevents=2 | table Day User It results with: Day,User "1 2",user1 "13 51",user2 "14 54",user3 "27 40",user1 140,user1 "110 82",user3 "101 72",user2 As you can see, we miss the user1's login at day 140 completely. Transaction won't do because it just measures separate non-overlapping periods whereas we need a sliding window. ... View more

It's not clear how you're receiving the logs and what's your configuration. Unless you're actively filtering the event categories the data should land somewhere if it is within the same syslog stream as the events you can see. Did you confirm (tcpdump? some debug on your syslog layer if you use some intermediate solution) that the events are really getting sent? ... View more

I thought about this one for a while and the elegant solution eluded me (I had some horrible ideas with table/transpose and the running foreach... yuck). But then I had an epiphany 🤣 I was focusing too much on events in their natural order whereas the key to do it properly is sorting. Firstly, you do | sort user + _time So you have batches of events concerning the same user sorted by time. Now we need to find a way to get the time of the previous login. Luckily, Splunk has a nice feature called autoregress which copies a value of a field from previous event(s). So we copy the previous login time (and user to filter out moments in which we switch from one user to another). | autoregress _time as oldtime p=1 | autoregress user as olduser Now we have all the data needed to find our culprits | where user=olduser AND _time-oldtime>90*86400 And voila, you have your logins after long period of inactivity. As a bonus you also have the time of previous login (although it could use some formating 😉 ... View more

Port number has nothing to do with Wireshark showing TLS negotiation or not (at least in the typical configuration unless you did something bad to it 😉). Even if it wasn't decoding the TLS setup itself you should at least be able to spot some of the certificate data (like DN or CA name) within the packets being exchanged. If you don't it's probable that no TLS negotiation is taking place. ... View more

Correct me if I'm wrong but this way you'll miss sequences of events like this: - login at day 2 (transaction starts here) - login at day 14 (transaction ends here) - login at day 123 (new transaction ends here) ... ... View more