1. You're using a very old Splunk version judging by the screenshot. 2. Your initial search is very, very ineffective (Splunk cannot use its index of terms, it has to look through every single event to find your sought for ones) 3. What do you mean by "filter duplicate URL"? You're counting by a triplet - url, status and lob, whatever that is. So you'll get a separate result for each combination of those three values. If you don't want to break it down by status, don't include that field in the BY clause. ... View more

Mind you this RFC is informational and only aims to document common practices. It's by no means to be a standard. ... View more

You're supposed to check the log for this search, not the general logs ingested into _internal. Log for a particular search is - as far as I remember - a part of the artifacts package from the search and gets removed after the search outlives its retention. So search.log is the thing that you get to by clocking at Job -> Inspect Job and there you have the link to see the search.log And in your case it's probably an issue with permissions (you haven't exported the script itself properly from the app - I struggled with it for a long time myself; you can't do it via GUI, exporting lookup definition is not sufficient, you must export the script and allow reading) ... 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

OK. Please describe your ingestion process. Where do the events come from? How are they received/pulled? On which component? Where does the event stream go to from there? What components are involved and in what order? Where are you putting your settings? ... View more

There are generally two methods - either add metadata during ingestion or dynamically clasify the sources during searching. The latter approach is usually easiest done with a lookup as @PaulPanther wrote. This way you don't have to touch your sources at all, you just have to keep the lookup contents up to date. The downside is that... you have to keep the lookup contents up to date and have it's desirable that you have a 1-1 mapping between an existing field (like host) and the information you're looking up. Otherwise you need to do some calculated fields evaluated conditionally... and it's getting messy and hard to maintain. Another approach is to add an indexed field directly at the source or at an intermediate forwarder. The IF approach of course requires you to have that intermediate HF to add a field with a different value for each group. (you can also do it directly at the receiving indexers but then you'd have a hard time differentiating between source - ingest-time lookup? Ugh). You might as well add the _meta setting to a particular input on the source forwarder. For example _meta = source_env::my_lab This will give each event ingested via input with this setting an additional indexed field called source_env with a value of "my_lab". It's convenient and it's very useful if you want to do some summaries with tstats but it also has downsides - you need to define it separately at each source (or at least in the [default] stanza for input as well as at [wineventlog] general stanza - default settings are not inherited to wineventlog!). And it must have a static value(s) defined. There is no way to define this setting dynamically like "source_hostname::$hostname" or something like that - you must define it explicitly. Another thing is that you can only have one _meta entry. Since there are no multiple _meta-something settings, multiple _meta definitions will overwrite each other according to normal precedence rules. So while you can define multiple indexed fields with _meta = app_name::testapp1 env::test_env But you can't define _meta = app_name::testapp1 in one config file and _meta = env::test_env in another. Only one of those fields would be defined (depending on the files precedence). ... View more

Yes. Web interface is the only "standard" (not including any unpredictable things done by add-on developers) component which behaves differently. While all other "areas of activity" (inputs, outputs, inter-splunkd connections) require certs in a single-file form (from the top - subject cert, private key, certificate chain), web interface requires two separate files - one with the private key and another with the chained subject certificate. And TLS-protecting your web interface while desired as a general rule has nothing to do with inputs and outputs. ... View more

This shouldn't be the case. With such a simple pattern there is not much backtracking. It would be important if there were wildcards, alternatives and such. With a pretty straightforward match it's not it. ... View more

It depends on what information you have ingested into your Splunk environment. Splunk is "just" a data processing tool. You have to feed it with data. If you have your AD logs in Splunk, you can search them but while there might be some people around here who have more experience with MS systems, it's generally more of a AD-related question how to find that info than it is a Splunk Question. You must know what to look for. If your data is properly onboarded and CIM-compliant, you can look through Change datamodel (if I remember the syntax correctly) | datamodel Change Account_Management.Locked_Accounts | search user="whatever"  I'm not sure though if it will only find the lockout event as such or will it contain the reason as well. ... View more

Ahh... ok. If it is suppossed to mean all results for the max value of field1, it's also a relatively easy to use sort and streamstats. Your typical | sort - field1 will give you your data sorted in descending order. That means that you have your max values first. This in turn means that you don't have to eventstats over whole resukt set. Just use streamstats to copy over the first value which must be the maximum value. | streamstats current=t first(field1) as field1max Now all that's left is to filter | where field1=field1max Since we're operating on our initial result we've retained all original fields. Of course for for additional performance boost you can remove unnecessary fields prior to sorting so you don't needlessly drag them around just to get rid of them immediately after if you have a big data set to sort.(Same goes for limiting your processed data volume in with eventstats-based solution) ... View more

Yes, those volumes of data seem off. While in csv case you could argue that it's a gzipped file size (but it still looks a bit low - with typical gzip compression you expect around 1:10 ratio) the KV size is way too small. ... View more

I'm not aware of any built-in mechanism that allows you to do so. Maybe some external EDR solution captures that but I can't advise any. ... View more

I think I've read about similar problems back then but I don't recall details, sadly. ... View more

Ok. Honestly, I'm a bit confused. I don't understand what you mean by "where value is max". As I understand it if you have title1 title4 1 3 2 5 3 7 1 2 2 3 3 5 1 1 You want title1 title4 1 3 2 5 3 7 as a result because for each value of title1 you want the max value of title4, no? Maybe we just misunderstand each other... ... View more

What exactly are you trying to achieve and how are you doing that? What you've shown is an event from Windows Security eventlog which is apparently an audit entry informing you that a process has been spawned on a machine. As far as I remember it doesn't capture command's output. ... View more

You might double-check that but if I remember correctly csv lookups do linear search through contents so in a pessimistic case you'll be doing a million comparisons per each input row only to return a negative match. It has nothing to do with fuzziness. ... View more

Yup. +1 on eventstats. Stats will aggregate all data leaving you with just max value. Appendpipe will append stats at the end but you'll still have them as a separate entity. You could use subsearch but it would be ugly and ineffective (you'd have to run the main search twice effectively). Eventstats it is. But since eventstats has limitations, you can cheat a little. | sort - title1 title4 | dedup title1 It doesn't replace eventstats in a general case but for max or min value it might be a bit quicker than eventstats and will almost surely have lower memory footprint. ... View more

"Best practice" depends heavily on use case. There are some general best practices but they might not be suited well to a particular situation at hand. That's why I suggest involving a skilled professional who will review your detailed requirements and suggest appropriate solution. ... View more

Please stop UP-ing the thread. You haven't found a similar issue in old threads, noone seems to be able to help you here right now. It's time to engage support. Posting "UP" once a week only clutters the forum. Thanks for understanding. ... View more

OK. You can't "forward" already existing data. You need to search the indexes, create a "dump" of the results and push them to the other solution. For the continuously incoming data you can either use syslog output on your indexers or a s2s output to an external component (either a HF or a third-party solution which can talk s2s). The caveat here is that it introduces additional complexity and possible points of failure on your indexers. If your architecture had a separate HF layer before indexers through which all input streams went you could do that on that HF layer instead of indexers. General forwarding to an external system solution is tricky to do well. You might want to engage PS or your local Splunk Partner. ... View more

Nope. That was the issue that I had. If yours is caused  by something else - you might need to raise a support ticket. ... View more

Yes. I'm just pointing it out because it's a common use case - to find something that is (not) followed by another something and it's a bit unintuitive that Splunk by default returns results in reverse chronological order. So you sometimes need to either manipulate the order of results so that "previous" in terms of carrying over values further down the stream means the desired way. Or you have to remember that you're returning the end of some interesting period, not its beginning. As I said - depending on the use case it can be sometimes confusing and it's worth remembering to always double check your results order when you're doing similar things. ... View more

If you mean Splunk Enterprise trial, you can configure TLS on any component. If you mean Splunk Cloud trial - no. The inputs are not encrypted and the webui uses self-signed certs as far as I remember. ... View more

The overall idea is ok but if you want to check if something happens _after_ an interesting event you must reverse the original data stream because you cannot streamstats backwards. But the example data was in chronological order while the defaul result sorting is opposite. So it's all a bit confusing. ... View more

Yes. The naming is a bit confusing here... ... View more