You need to tell stats to carry those other fields along, and at the same time how you want to carry them along. stats count by user will only give two fields back, count and user. The most usual path would be with values(foo) as foo , which says "take all the values of foo you see for that user along the way and roll them up into a multivalue field called foo". Even if there is often or always only one value in the results, I recommend values() to catch unexpectedness when there are two or more there. If you fall into the habit of using first() or last() always, you can miss crucial logic in edge cases. So with values(foo) as foo , it would look like: index=windows "fail" | stats count values(host) as host values(message) as message values(field1) as field1 values(field2) as field2 by user | where count >4 To save some characters, I prefer to restrict the fields down with the fields command, then do values(*) as *, like so index=windows "fail" | fields host message field1 field2 user | stats count values(*) as * | where count>4 but be very careful with using "*" in stats. Without something like this fields command to narrow down the incoming fields it can blow up on you and slow your search to a crawl. There's a good blog post giving an overview of stats. http://blogs.splunk.com/2014/04/01/search-command-stats-eventstats-and-streamstats-2/ and of course the official reference page for the stats command is very important. http://docs.splunk.com/Documentation/Splunk/6.2.2/SearchReference/Stats ... View more

index=fw_log src_ip=1.2.3.4 dst_ip=5.6.7.8 | stats sum(bytes) AS "Total Bytes" by src_ip dst_ip That will give you the one row. You don't want to use eventstats here, but rather its bigger brother stats. Stats with a "by foo" or "by foo bar", will output one row for every unique combination of the "by" fields. Eventstats however, will output pretty much exactly the same rows that it received from the prior command, except that it will have tacked on a couple extra fields that it computed in various ways. If you want to see all pairs of src_ip and dst_ip, that would be index=fw_log | stats sum(bytes) AS "Total Bytes" by src_ip dst_ip ... View more

Assuming the host value is just present in the "host" field, you can then use the metadata command, which allows this nice and quick search as a solution. SourceName="EBS Check" | eval hasEBSCheck=1 | append [| metadata type="hosts" | eval hasEBSCheck=0] | stats max(hasEBSCheck) as hasEBSCheck by host | search hasEBSCheck=0 We basically get the EBS Check events, paint a little field on them hasEBSCheck=1, then we glue onto the set some more rows that come from | metadata type="hosts" , onto which rows we have painted hasEBSCheck="0", then stats command does the work of figuring which hosts have the event and which don't. Note: if your events are in some other index, you'll have to put the right index=foo expression into the metadata command as well as the initial search. Another Note: append is commonly overused. Usually you can do things like this by pouring all the relevant events in with a simple disjunction and grouping with stats. Here though it's far more efficient to just pull the list of all hosts with the metadata command and thus we need append. ... View more

index=abc feels like a simple query, but it's actually quite an expensive search for Splunk to run. It's definitely not a good candidate if you're looking for a "speed of light" test. A good speed of light test would be this index=abc | stats count . Paradoxically the added search syntax often allows splunk to do less work. In index=abc | stats count , splunk notes that you don't actually need any fields extracted, thus no lookups run, no raw event text, or anything. It can really pare this search down to a bare minimum and do the work on the indexer. In index=abc , you're telling Splunk you want to actually see the raw events, so it will run all possible field extractions, calculate the timeline, the summaries of all the fields and their top values, and the search head will have to pull all the raw event text and fields from the indexer to assemble the results locally. ... View more

Assuming that you have fields named Status and State, <search terms> | fillnull State value="no state" | stats count by Status State | eventstats sum(count) as StatusCount by Status | eventstats sum(count) as TotalCount | search Status="Status1" | eval percent=100*StatusCount/TotalCount | sort - count This search first uses fillnull to fill in a "no state" value for the State field if it's missing. We don't care about events that don't have any Status value, but presumably we don't want to exclude the events that have a Status value but no State value. Then stats gets the unique combinations of Status and State. Then it gets interesting. Eventstats is a lot like stats, except that it leaves the rows untransformed. Instead it paints its output field values onto the same rows. Anyway, eventstats makes a pass through the data, and on each row it will add a field statusCount, that is the number of events in the entire set that have the status value of that row. Then eventstats makes a second pass through, writing on each row a TotalCount field that is, you guessed it, the total count of all events. Now a search clause narrows us down to only the rows where Status="Status1", an eval calculates our ratio for us, and we sort so that the most common State values will be at the top. If you want the search to return zero results if the radio is less than 5%, that's pretty easy. Also if you want to present the three top States differently. ... View more

Splunk's stores an event's time as an epochtime value, ie as the number of seconds since 1/1/1970, and no timezone information is stored with it at all. Before that, as the event is indexed, when a string formatted time is encountered in the raw data, Splunk of course relies on it's configuration to tell what timezone it should interpret this string as, before it converts it to an epochtime value. Then much later when the event is displayed in the Splunk UI, splunk will at that moment convert the _time value from epochtime (big number of seconds), to a string formatted time. Here of course it needs to pick a timezone again and what it picks is the timezone of the Search Head. I think it's worth noting that UTC can sometimes be misinterpreted as a synonym for "epochtime", which it is not. UTC is a timezone, basically GMT with no daylight saving time ever. Sometimes you'll also come across the idea that "epochtime is in UTC" which is nonsensical cause an epochtime is just a number of seconds. Anyway, it's not uncommon for a whole splunk deployment to have everything including search heads, living in the UTC timezone. In my experience this is extremely confusing for many of the users, but it does work as advertised; all displayed times would be in the UTC (ie GMT) timezone. And if you just want it to work on this search, knowing the above, you can see now that the space of hacks you've already discovered are pretty much what you need to do. To do it automatically for that one search, as well as reliably throughout the year incorporating the changing DST offset is a challenge. What you could do, at least for timezones west of GMT to the date line, is use search language like this, possibly hiding it in a macro called like "utc_timezone_hack" <your search > | eval hourAndMinuteOffset=split(strftime(_time, "%k:%M"),":") | eval hourOffset=mvindex(hourAndMinuteOffset,0) | eval minuteOffset=mvindex(hourAndMinuteOffset,1) | eval hourOffset=24-hourOffset | eval offsetSeconds=hourOffset*60 + minuteOffset | eval _time=_time-offsetSeconds What that search language does, is a bit of a hack, but it will get the number of seconds by which your timezone differs from UTC, and manually subtract those from your events _time values. For others reading this whose locations are east of GMT to the date line, I think you'd want to remove that "eval hourOffset=24-hourOffset" line. ... View more

In the form elements at the top of the page, one of them is labeled "include". If you click that one, you can include a couple optional datasources in the overall query. One of these is "call quality". It's telling you that you have to open that include pulldown and add the "call quality" data. ... View more

I think what you need, is to use eventstats to get the total bytes, before transaction gets involved. Your second search index="ihs_test"| transaction clientip | stats sum(bytes) as total_pageuse by uri_path. may not be doing what you think it's doing. That search will make rows that are transactions by clientip, on which uripath and bytes are both multivalue fields. But there's no association any longer as to which uripath value has which bytes value, they're just big piles of multivalue values. Therefore when the sum(bytes) by uri_path comes along, that is going to try and untangle all the mashed-together uripath values and even if it does find something reasonable to do with them, I don't think it's going to be what you need coming out. Anyway, I think this will be more reasonable. index="ihs_test" | eventstats sum(bytes) as total_bytes | transaction clientip | stats sum(bytes) as total_pageuse first(total_bytes) as total_bytes by uri_path | eval CompliancePct=round(total_pageuse/total_bytes,2) eventstats makes it's own pass, creating a new field called total_bytes that just is the sum of all bytes across all events. We have to make sure to pass it along in our stats clause, but then we can have at the end to do your percent calculation, etc. ... View more