No, I fear not, it's just another type of lookup, but you still wouldn't be able to make automatic. Well, you could try to insert that information at index time, but then it's fixed, i.e. it's written to the index and can't be changed later on (without running a lookup again to overwrite that value). Where are you getting your data from, what is your data source? Maybe you can preprocess it before indexing to add that information there? ... View more

Okay, your connections time out. In 99% of all cases, this is a firewall related problem, because firewalls tend to silently drop requests that are not allowed, creating timeouts when trying to connect. You should check with your network security people, they're most likely able to help you. ... View more

Okay, then this seems to be a different issue. I was just guessing as I saw a few issues regarding realtime search with 7.1 recently. ... View more

Yeah, my brain is already asleep. Thanks, I updated my answer 🙂 ... View more

Are you, by any chance, running on the free license? There is a known bug with realtime and the free license on 7.1.0. ... View more

You could try it like this: index=whatever your-search-terms | transaction 52634 startswith=eval(isnotnull(cs_uri_query)) endswith=eval(like(cs_method, "POST")) You might need to fine tune the transaction, find more details here: transaction docs ... View more

Good message: It's a known issue, it's been tested, verified and logged into the issue tracker. It's not on purpose or anything, but seems to be a bug that only hits the combination of realtime, 7.1 and free license. Bad message: Seems there is no workaround or fix yet. ... View more

Your search should most likely look like this: index=* sourcetype="*WinEventLog:Security" (4624 OR 4647 OR 4648 OR 551 OR 552 OR 540 OR 528 OR 4768 OR 4769 OR 4770 OR 4771 OR 4768 OR 4774 OR 4776 OR 4778 OR 4779 OR 672 OR 673 OR 674 OR 675 OR 678 OR 680 OR 682 OR 683) (EventCode=4624 OR EventCode=4647 OR EventCode=4648 OR EventCode=551 OR EventCode=552 OR EventCode=540 OR EventCode=528 OR EventCode=4768 OR EventCode=4769 OR EventCode=4770 OR EventCode=4771 OR EventCode=4768 OR EventCode=4774 OR EventCode=4776 OR EventCode=4778 OR EventCode=4779 OR EventCode=672 OR EventCode=673 OR EventCode=674 OR EventCode=675 OR EventCode=678 OR EventCode=680 OR EventCode=682 OR EventCode=683) | lookup windows_event_lookup.csv EventID AS EventCode OUTPUT Event_Desc | table user Event_Desc Putting the search parameters in the first line will make Splunk fetch only those relevant events from the beginning, and also only do the lookup on those events instead of all events. Twice the performance improvement. The thing about EventCode/EventID being twisted has already been said by others. 😉 ... View more

Basically - the initial sourcetype determines the props.conf rules that are being applied to the data at index time. Therefore, you can rewrite the sourcetype at index-time, but Splunk will not use index-time rules for that new sourcetype. It will however use search-time rules for that new sourcetype. Therefore, you either need to get data in with the right sourcetype from the very beginning - best practice is not to let Splunk receive on port 514, but a syslog server like syslog-ng, that writes the data to disk, split by hostname/IP of sender. You can then built proper file monitors for every device and assign them the proper sourcetype. 🙂 ... View more

Yeah, that's right, if it does index-time stuff, that won't happen, because the rules that are applied are only determined once for the very first sourcetype that the data is ingested with. You can rewrite the sourcetype at index-time, but it won't use the new sourcetype's props rules - so yeah, it doesn't fix your problem. In that case, writing that stuff to disk and using proper file monitors seems to be the only way to do it right. ... View more

I don't think that's possible at all. ... View more

@Yorokobi is right - if you add the HFs as search peers on your Monitoring console, the MC will contact them via port 8089 and you can use it's built-in alert to get a notification when one of them goes down. Actually works for all Splunk instances, be they indexers, search heads, HFs... ... View more

I updated my original answer, check out if that helps you 🙂 ... View more

To build a proper regex, you need to describe your data properly, it has to have some reliable characteristics. With your example above, multiple characteristics are possible, but without further example data it's hard to find those similarities. This is an example: ^[^:]+:[^:]+:(?<yourfield>[^:]+:) This one would assume that there is always to parts in that field, seperated by : , and the value you want to extract is between the second and third : . If that's true - here's your regex 😉 ... View more

Basically - all data that comes to a certain UDP/TCP port looks the same to Splunk, so you can only give it a single sourcetype for everything that comes in. Best practice would be to fire up a syslog server (like syslog-ng), and have it write all data to disk, split by hostname/IP. You can then create file monitor inputs for single device, with it's own sourcetype and other settings. There are a few examples for best practices out there, e.g. here. If that's not possible at all, try this: You'll have to seperate it by the only identifier you get - the hostname/IP address of the sender. Set up a props.conf like this: [host::your_hostname_or_IP] TRANSFORMS-rewrite-sourcetype1 = rewrite-sourcetype1 and a transforms.conf like this: [rewrite-sourcetype1] FORMAT = sourcetype::fgt_log DEST_KEY = MetaData:Sourcetype ... View more

Try this: | makeresults | eval host="host3.CA.domain.com" | eval host=if(match(host, "^\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3}$"), host, replace(host, "^([^\.]+)\..*$", "\1")) More explanation here in the docs, explanation of the regex here. ... View more

Did you try setting KV_MODE=JSON in the corresponding sourcetype in props.conf? That should actually extract fields from JSON on it's own. To access certain fields without changing KV_MODE, take a look at | spath here: http://docs.splunk.com/Documentation/Splunk/6.3.3/SearchReference/Spath ... View more

Changing the first table to fields should yield the same results, but be faster (with large lookups). 🙂 ... View more

Can you please add some details to your question? I don't really get what are trying to do, so maybe adding screenshots, example data etc. makes it easier to grasp it. ... View more

Are your numbers in Splunk too high or too low? ... View more