This is a very very old thread. It's highly unlikely that its participants are still on this forum. If you have a similar problem, just post a question with a description of your issue in a new thread, possibly putting a link to this thread for reference.

And how did you come up with the range() stats function? This function is for something completely different - it tells you what's the difference between lowest and highest value in your result set whereas you want to count things. The range() function is completely unsuited for this. You should be doing count by Account_Name. In order to make it over sliding window, you need to use streamstats with a proper time window. <your_initial_search> | streamstats time_window=10m count by Account_Name This will give you counts of logins over 10 minute windows. From this you'll be able to pick the one with the highest count. For example with | sort - count | head  

Hi @rsreese , sorry, I didn't notice the "Dashboard Studio" label! No it works only in Dashboard Classic: I haven't started using Dashboard Studio yet because it still can't do everything I can do with the Classic version. Ciao. Giuseppe

I need drop down default taken as log1,log2,log3 As @dural_yyz hinted at, the actual solution depends very much on how you will use the input token in search.  If you want the comma delimited list as part of IN function, you can just use appendpipe.   | inputlookup mylookup | appendpipe [stats values(log_group) as log_group | eval Name = "Any", log_group = mvjoin(log_group, ",")]   You get Name log_group Name 1 Log1 Name 2 log2 Name 3 log3 Any log1,log2,log3    

Although you can get rex to work to some extent, treating structure data such as JSON as string is not robust.  I always recommend changing to Splunk's tested builtin functions such as spath or fromjson. If your event is JSON, Splunk should have given you the data field unless there's some serious problem with event parsing.  If the string snippet is part of a data field that contains compliant JSON, say data, just do | spath input=data If the snippet is not in a field yet, use rex to extract the entire compliant JSON, then use spath.  You will have much better data to work with.

As @PickleRick said, this is not about parsing but about presentation, and that spath command that we usually use is not handling JSON keys containing dot (.) correctly because in SPL, as well as in many other languages that flatten structured data use dot to represent hierarchy. But keys containing dot are not the only problem that makes @dtburrows3's solution so wonky.  The bigger problem is the data design.  It uses implied semantics about what represents a URL.  Implied semantics in structured data is generally unacceptable. (At higher level, this is abusing key names to represent data.)  If you have any influence with your developers, beg them to change data structure so key and data are completely separate. Thanks to @dtburrows3, I learned that fromjson (introduced in 9.0) is more robust than spath (from 7.0 or earlier), and learned the trick to leverage the evil dot in key name in order to single out actual data in abused structure, namely foreach *.*.  It is less robust but works for the limited dataset.  So, I offer a more semantic, hopefully less wonky solution.   | makeresults | eval _raw="{ \"a.com\": [ { \"yahoo.com\":\"10ms\",\"trans-id\": \"x1\"}, { \"google.com\":\"20ms\",\"trans-id\": \"x2\"} ], \"trans-id\":\"m1\", \"duration\":\"33ms\" }" ``` data emulation above ``` | table _* | fromjson _raw | rename duration as Duration, trans-id as Trans_id | foreach * [eval url = mvappend(url, if("<<FIELD>>" IN ("Duration", "Trans_id"), null, "<<FIELD>>"))] | mvexpand url ``` nothing in this data structure prevents multiple URLs ``` | foreach *.* [mvexpand <<FIELD>> | eval subkey = json_array_to_mv(json_keys('<<FIELD>>')) | eval sub_trans_id = json_extract('<<FIELD>>', "trans-id") | eval subdata = json_object() | eval subdata = mvmap(subkey, if(subkey == "trans-id", null(), json_set(subdata, "sub_url", subkey, "sub_duration", json_extract_exact('<<FIELD>>', subkey))))] | fromjson subdata | table _time Trans_id url Duration sub_duration sub_url sub_trans_id   The output is _time Trans_id url Duration sub_duration sub_url sub_trans_id 2024-01-19 13:01:54 m1 a.com 33ms 10ms yahoo.com x1 2024-01-19 13:01:54 m1 a.com 33ms 20ms google.com x2

Hi @sgabriel1962  As you noticed yourself, you're responding to an old thread regarding a relatively old and unsupported version of Splunk. So even if your problem seems similar, it is quite likely that it's caused by different thing (especially that original one was supposed to be due to a but which should have been patched long ago). Instead of digging up an old thread, it's better to create a new one with a detailed description of your problem (and possibly a link to the old thread as a reference to something you'd found while looking for solutions but what may not be applicable to your situation).

Just search your data over a month period and calculate your statistics. But seriously - we have no way of knowing what data you have in your Splunk environment, what do "TPS" or "route codes" mean in this context and what is it you want to get (especially that you're saying about some TPS parameter which suggests "something per second"; most probably transactions of some kind) but then talk about count - how would you want to "match' those TPS to count of something else? Provide some sample (anonymized if needed) data you have, be more precise about what you want to achieve (possibly including mockup results) and we can try to think about your problem.

But 'assuming local time' is ok if the server is GMT/UTC, right, then the user's timezone should adjust? This exact same sourcetype and configuration works at another installation, so something must be configured differently. Here is the example of it 'working' (attached) where the timestampStr is UTC, but the _time is showing as Central Standard Time, which is my user defined timezone.    

Those CSS examples would work quite well but are they supported in Dashboard Studio or only Classic Dashboards? In Dashboard Studio, it's not clear how you can use a different icons for different values in a single field.

Your timestamp raw feed does not have a time zone indicator.  In that case the indexer will assume local system time zone and apply that in most cases.  If our collection point (UF) is -4 and your indexing point (IDX) is -5 it will assume that the timestamp is also -5. A best practice is to always define your time zone and never allow Splunk to automagically assume based on the datetime.xml auto extractions. https://docs.splunk.com/Documentation/Splunk/9.1.2/Admin/Propsconf#Timestamp_extraction_configuration