Internal Splunk logs aren't sent to 'Main'. they're sent to '_internal' and aren't applied to your license. If you have data going into Main, it's because of inputs you may have set up. Recommend looking at the data in your main index and making determinations from there. ... View more

I think the {3} only applies to the previous token, so you'd have to group before using it for it to apply to the whole pattern. ^(?:[^\|]+\|){3} ... View more

You may have to get more explicit and use regex to parse out the fields then. I would try to make regex extractions that only match one of the two formats. That way when both are applied, there's no way the fields can be swapped around like that. ... View more

Try just this in your props.conf settings: REPORT_name_log = old_log,new_log ... View more

Just to clarify what you're asking for: You want a count of all hits to 'Destination' and a count of all hits to 'Destination' that came from 'Source'. Is that right? ... View more

Do the existing transforms still function on the new format of data, just with incorrect fields? Or does it not apply at all? If it doesn't apply at all, then you can simply add another transforms.conf stanza for the new format, and have the props.conf stanza use both. Splunk will try both and apply whichever works. However, if your extraction still technically works, just is incorrect because the data changed, that complicates things. Can you provide sample data and your existing configuration? ... View more

I'm checking the XML reference, and I'm not seeing any built-in 'Button' modules. I believe the button module is a part of the Sideview Utils package. Do you have that installed as well? If not, that's likely your problem. Another route you could take that doesn't require reliance on Sideview, is to use a StaticContentSample module and then render your button using traditional html/css/js/whatever. ... View more

I would recommend tackling this using searchPostProcess. Essentially, you have a search that acts as a background search to get your initial data set. Then for each of your dashboard panels, you can use searchPostProcess to append search terms to that master search. This way you can drive multiple visualizations from a single search. An example which does what you want is here: http://pastebin.com/KfdJjBmS And this is what it looks like: Keep in mind, that this may not be the fastest dashboard if your dataset is large. ... View more

Unfortunately, you can't do concatentated fields in search-time extractions. I would recommend doing something like: [disk_space] REGEX = DiskSpace\=([^%]+)\%\s+(/[^,]*)\, FORMAT = diskSpace::$1 filesystem::$2 (I modified the regex to include the leading / in the filesystem, that way you don't get null values for diskSpace) This will give you events with the following: diskSpace=17.58 filesystem="/" diskSpace=11.25 filesystem="/storedconfig" diskSpace=7.11 filesystem="/tmp" etc ... View more

I think the only issue is your TIME_PREFIX. The regex you have only matches a single non-pipe character between each pipe. For what you have, you want: TIME_PREFIX = ^[^\|]+\|[^\|]+\|[^\|]+\| Then the rest should work as intended. (Replace + with * if any of the preceeding fields might be empty. |||20131013|...) EDIT: Also need to escape the pipes, as sowings mentioned. ... View more

Right, I'm aware of that. It's just something that's not intuitive to people when they first encounter it. I'm wondering if streamstats is using the same 'newest to oldest' logic. Also, the suggestion is something I've already tried, and it still behaves as seen above. If you include current, it gives you the current value of the event. If you don't include current, you get the value for the next event. ... View more

| reverse | does work! Although seems like the command is working differently than described. (It could be similar to the stats functions like first() last() which also operate counterintuitively) ... View more

this is working fine for me on Splunk 6 in Chrome (29.0.1547.76) on OSX (10.8.5) ... View more

Ahh, totally get that. Glad I could help and good luck! ... View more

So the trick is to extract the number as a field first. You can do this inline, but eventually you'll want to set up a field extraction for it. To do the inline version, you'll want to rex out the field, like so: sourcetype=mylogs | rex "\d+:\d+:\d+\s(?<fileCount>\d+)$" | where fileCount>=25 Now, if you take that same regex and use it to make a field extraction, then your search would simply be: sourcetype=mylogs fileCount>=25 ... View more

I would recommend one index per customer. You can use sourcetypes to differentiate the datafeeds. ... View more

Thanks for the clarification! I thought everything in props essentially ran concurrently. That being the case, this should work in props.conf (either the source:: stanza name or below depening on your incomind data) [HAProxy] MAX_TIMESTAMP_LOOKAHEAD=40 NO_BINARY_CHECK=1 SHOULD_LINEMERGE=false TZ = US/Mountain TRANSFORMS-syslogstripper = haproxy_syslog_stripper REPORT-haproxyfieldextract = haproxyfields, clientinfofields, backendfields, requestinfo, connectioninfo, queueinfo, uriinfo If this doesn't work, can you provide example logs? ... View more

There are a couple of things going on in this setup: First, we need to clarify what is happening at index time, and what is happening at search time. It's also important to note that you really can't have extractions dependent on other extractions, as they don't execute in sequence. Now, first thing I notice is you have index-time transforms being applied to the source stanza, and then timestamp, linemerge, and TZ fields being applied by sourcetype. While they should get mashed together correctly, I'd highly recommend getting them in the stanza if possible. [source::/var/log/*haproxy.log] MAX_TIMESTAMP_LOOKAHEAD=40 NO_BINARY_CHECK=1 SHOULD_LINEMERGE=false TZ=US/Mountain SOURCETPYE=HAProxy (unless this is explicitly set by the forwarder, in which case it's unnecessary, and you can make this entire stanza [HAProxy]) TRANSFORMS-syslogstripper = haproxy_syslog_stripper EXTRACT-haproxy_fields = haproxy_fields And then in transforms.conf you'll have the following: [haproxy_syslog_stripper] REGEX = ^[A-Z][a-z]+\s+\d+\s\d+:\d+:\d+\s[^\s]*\s(.*)$ FORMAT = $1 DEST_KEY = _raw [haproxy_fields] REGEX = SEE BELOW Now, because you can't have extractions dependent on extractions (the field has to exist at search time, and if it's another search-time extraction, it doesn't) you're going to need a BIG regex to extract all of the fields. Assuming your HAProxy logs follow the this format after your syslog headers are removed... [06/Feb/2009:12:14:14.655] http-in static/srv1 10/0/30/69/109 200 2750 - - ---- 1/1/1/1/0 0/0 {1wt.eu} {} "GET /index.html HTTP/1.1" Then you could use something like this: regexr link because formatting gets borked inline It's really long and not exactly easy to read, but it does pull out all of the fields you're looking for. End result is the haproxy_syslog_stripper is an index-time extraction that overwrites _raw with it's results. Then haproxy_fields is a search-time extraction based on the updated _raw. One happens when the data is indexed, and the other happens when the data is searched. So in that case they can rely on each other. Bonus gained is that you shouldn't need to use the | extract command to get the fields to appear. They should simply be available when you're searching this sourcetype. ... View more