Unfortunately not. Adding inputs requires the "edit_monitor" capability, which is independent of role-restricted indexes. ... View more

You have a couple choices here: Use ... | mvexpand username to break each event into a distinct event per username, duplicating the message, followed by the dedup to find the most recent per username. Use ... | stats count by username | fields username to just aggregate the list of username values. The first is better if you want to see the original messages, but is less efficient than the second, which is better for just finding the user list. ... View more

Nick's search is certainly on the right path, but it doesn't split by version. Let's take it further to get percentages, assuming we're starting with just basic counts like: sourcetype=access_combined | timechart count by version sourcetype=some_crash_log | timechart count by version Then we'll use the same technique of taking the OR of the two sourcetypes, but this time liberally use "eval" in timechart, both to calculate the number of events per sourcetype and the ratio of the two sourcetypes: sourcetype=access_combined OR sourcetype=some_crash_log | timechart eval(count(eval(sourcetype=="some_crash_log"))/count(eval(sourcetype=="access_combined"))) Now, we could have broken this down for clarity, like: sourcetype=access_combined OR sourcetype=some_crash_log | eval is_crash = if(sourcetype=="some_crash_log",1,0) | eval is_access = if(sourcetype=="access_combined",1,0) | timechart eval(sum(is_crash)/sum(is_access)) by v ... View more

In 4.0 and 4.1, the best way to classify a field, like clientip is through eventtypes. For example, in splunk's own app to monitor the splunk.com website we use eventtypes like: [clientip-internal] search = clientip=64.127.105.32/27 [clientip-nonroutable] search = clientip=10.0.0.0/8 OR clientip=172.16.0.0/12 OR clientip=192.168.0.0/16 [clientip-public] search = eventtype!=clientip-internal eventtype!=clientip-nonroutable With these, you can construct a field like clientip_class through the search fragment: ... | eval clientip_class = mvfilter(clientip LIKE "clientip-%") | ... Now, another alternative is to use scripted lookups, since native lookup tables don't support CIDR netblocks or wildcards in 4.0 and 4.1. In 4.2, the best practice is to use lookup tables. For example, in transforms.conf add: [ipdomain] filename = clientipclass.csv match_type = CIDR(clientip) And in clientipclass.csv have: clientip,class 10.0.0.0/8,internal 172.16.0.0/12,internal 192.168.0.0/16,internal 64.127.105.32/27,corporate Of course, in this case you'll have to set min_matches and default_value in transforms.conf to fill in the default of external. ... View more

If you are using 4.1 or newer, you can have multiple stanzas in inputs.conf where the whitelist is implied by the stanza name. for example: [monitor:///var/log/app/\w+.log*] sourcetype = log4j index = main [monitor:///var/log/app/\w+-(web|req).log*] sourcetype = access_common index = main [monitor:///var/log/app/\w+-billing.log*] sourcetype = custom_billing index = billing Note that the trailing * is needed to convince us to treat the pattern as a regex. However, your props/transforms approach will work fine without any performance degradation. ... View more

The obvious search is something like: eventtype=Request | timechart count by SourceIP limit=10 The problem with this is that it shows the top 10 globally, not the top 10 per day. The problem with "per-day" is that every day could have 10 completely different top SourceIPs and thus for a month, you may need 300 series. If you really want to calculate per day, it's something more like: eventtype=Request | bin span=1d _time | stats count by _time SourceIP | sort - _time count | dedup 10 _time So this will give you, per-day, the top 10 SourceIP,count pairs (using count). To make this into a chart, you could add: | timechart span=1d sum(count) by SourceIP limit=1000 . ... View more

I'd recommend using OR to combine the searches: source=netstat OR sourcetype=threats | eval RX = if(source="netstat", RX, null()) | eval is_threats = if(sourcetype="threats",1,0) | stats sum(RX) as RX sum(is_threats) as count by splunk_server | eval ratio = RX/count ... View more

Unfortunately we don't ship our "DateTimeTest" utility that allows easy testing of strptime/strftime functionality, please file an ER for that to be included from the CLI/UI. Here's my findings (first note that you have $H rather than %H): [ssorkin@MrT current]$ src/util/tests/DateTimeTest '%d/%b/%Y:%H:%M:%S.%3N+%z' '01/Mar/2011:17:25:49.666+0000' 01/Mar/2011:09:25:49.666+-0800 [ssorkin@MrT current]$ src/util/tests/DateTimeTest '%d/%b/%Y:%H:%M:%S.%3N%z' '01/Mar/2011:17:25:49.666+0000' 01/Mar/2011:09:25:49.666-0800 So basically, %z does essentially the right thing, but the + is unnecessary and actually causes wrong results. As a clarification, the : in %z says how to split the time zone offset. One : looks like -08:00 for PST, two : looks like -08:00:00 . ... View more

Adding more summary indexes will not affect license usage. No summary indexed data will count against the license. ... View more

The stanza above should be in transforms.conf, since it defines the lookup table. To make it apply for a given sourcetype, you should add to props.conf: [<sourcetype>] LOOKUP-env = mylookup host OUTPUT env Editing to include new findings: I can't reproduce the problem using time_format and rendered time, provided I change it to 2011, not 2010 (I haven't tried with 2010). It works if I use UTC epoch time, like 1298942760,host1,dev and take out the time_format attribute in transforms.conf. Are you sure that you're looking at data from 2010 and not 2011? ... View more

No, the specific conditions that head will preemptively stop search aren't enumerated. In general it will halt search when the results remain correct if search is preempted. This means that any search that is fully distributable or that can incrementally process events once sorted by time will preempt with head . If any search command before head requires seeing every event to emit a final result, say a transforming command like stats or a command like sort, the search cannot be preempted for correctness. ... View more

No, that is not possible. ... View more

It must be placed on the server that's parsing the data. If it's a heavyweight forwarder, it goes on the forwarder. If it's a light forwarder, it goes on the indexer. ... View more

You can tell eval that the string is a field name rather than a string literal by wrapping the string with '$'. For example: | stats count as 123 | eval abc = $123$ ... View more

The preferred approach for "classifying" events is to use either lookup tables or eventtypes. Lookup tables work best when there is a mapping (not necessarily one-to-one) between source and destination field values. Eventtypes allow mapping between arbitrary search statements (e.g., booleans, negations, disjunctions on keywords and fields) and categories. Field extractions aren't ideal for this since, for efficiency, they make the assumption that the field value itself can be found in the source data. You can configure this assumption away in fields.conf, at a performance penalty. ... View more