Thanks for the quick response. And thanks again for supporting Splunk (and Splunkers) with your TA. It's greatly appreciated. G. ... View more

Hi, You should just be able to do a positive lookahead and an empty capture group. So: [ofx] SHOULD_LINEMERGE = False LINE_BREAKER = (?m)(?=^Event logged at {[\d;]+})() I did a quick test and it looked fairly successful: Hopefully this gets you closer to what you're looking for. ... View more

Hi, Absolutely. You simply need to specifiy the earliest_time and latest_time as their epoch values. So for your example, you could do something like this in your times.conf : [my_custom_time] label = January 1st 2017 earliest_time = 1483228800 latest_time = 1483315199 If you want to work out epoch times, there are many online tools which you could use. Or, Splunk can always help you. Here's an example search, which you could change as required: | makeresults | fields - _time | eval t1="01/01/2017:00:00:00", t2="01/01/2017:23:59:59" | eval t1_epoch=strptime(t1,"%d/%m/%Y:%H:%M:%S"), t2_epoch=strptime(t2,"%d/%m/%Y:%H:%M:%S") I hope this helps. ... View more

Hi, Sorry for the delayed reply. If you've got it working for 1 IP, then that's a great start. My guess it that you may need to amend your search slightly with regards to where you are using the token. Assuming you select a single IP in your dropdown (for example 1.1.1.1), your eval becomes: | eval TrueClientIP=1.1.1.1 But if you have an 'All' label, with the value '*', then this mean your eval becomes: | eval TrueClientIP=* Since '*' is not an IP address, it's not going to work with the iplocation command. Perhaps you could use the token in the initial search string. So something like: sourcetype=iis_dominos_online_adv CookieData="\"UNKNOWN\"" RedirectTo="\"UNKNOWN\"" TrueClientIP=$PublicIP_tkn$ This would then return the single result (assuming the IP from your dropdown is unique), or return multiple results if you select 'All/*'. See if that gets you a bit closer to what you're looking for. ... View more

Hi, I'm pleased to hear that you've got a workaround. But you should still be able to get the EXTRACTs working; there's nothing wrong with your approach. As such, it might be worth raising a Support Case with Splunk to try and get to the bottom of what's going on. Just incase there is a bug, or something else is happening within your setup. You don't want to come across it down the line! ... View more

Hi, Looks like the logging format for these events is a bit of a pain! I'm not 100% sure your: (?<_KEY_1>\w+)(:\s)(?<_VAL_1>[a-zA-Z0-9\\]+)(U|E) Is going to work for you? What if one of the values you're trying to capture (like a Username), ends in a U or and E? I also noticed that the Keys in the 'Event Data' are different in the two event samples. You're also going to want to cater for this and the associated spaces. The default Splunk Key/Value extractor is only going to get you: Profile=iOS Whereas you probably want: Profile=iOS Visual Privacy Webclip Ultimately you may just need to keep refining your regex(s) until you cater for 100% of your data. I get that this is pretty dull... And whilst I'd always go with the 'keep it simple' wherever possible, you may end up with something slightly more complex. For example, I don't like it, but this below works for both of your sample data events: | makeresults | eval _raw="Mar 9 13:52:33 10.0.2.24 March 09 19:52:33 AirWatch AirWatch Syslog Details are as follows Event Type: ConsoleEvent: DeviceDataModfiedUser: domain\JoeUserEvent Source: ServerEvent Module: DashboardEvent Category: DeviceEvent Data: Device=User iPhone iOS 10.2.1 X0XX;DeviceData=OwnerGroup;LoginSessionID=xx1xxx0xxxxx" | append [| makeresults | eval _raw="Mar 9 13:52:32 10.0.2.24 March 09 19:52:32 AirWatch AirWatch Syslog Details are as follows Event Type: DeviceEvent: RemoveProfileRequestedUser: sysadminEvent Source: ServerEvent Module: DashboardEvent Category: CommandEvent Data: Profile=iOS Visual Privacy Webcli"] | fields - _time | rex "Event\sType:\s(?<EventType>[^\s]+)Event:\s(?<Event>[^\s]+)User:\s(?<User>[^\s]+)Event\sSource:\s(?<EventSource>[^\s]+)Event\sModule:\s(?<EventModule>[^\s]+)Event\sCategory:\s(?<EventCategory>[^\s]+)Event\sData:\s(?<EventData>(?:(?:Device=(?<Device>[^;\r\n]+);?)|(?:DeviceData=(?<DeviceData>[^;\r\n]+);?)|(?:LoginSessionID=(?<LoginSessionID>[^;\r\n]+);?)|(?:Profile=(?<Profile>[^;\r\n]+);?))*)" | table EventType Event User EventSource EventModule EventCategory EventData Device DeviceData LoginSessionID Profile You can play and test with it here: https://regex101.com/r/GEpAOP/1/ I.e. You may need to expand the (?<EventData>) grouping to cater for different Keys in that section. Good luck - I hope you find a much simpler way! ... View more

Great to hear that you got it working! If you're happy that the question is resolved, just accept this as the answer, then it gets marked a 'done' when others are looking. Happy Splunking! ... View more

Hi, One approach you could try is to rule out the 'unknown' characters problem by trying your extractions as rex commands first. I tried this with: | makeresults | fields - _time | eval _raw="Mar 9 13:52:33 10.0.2.24 March 09 19:52:33 AirWatch AirWatch Syslog Details are as follows Event Type: ConsoleEvent: DeviceDataModfiedUser: domain\JoeUser Source: ServerEvent Module: DashboardEvent Category: DeviceEvent Data: Device=User iPhone iOS 10.2.1 X0XX;DeviceData=OwnerGroup;LoginSessionID=xx1xxx0xxxxx" | rex "Device=(?P<Device>[^;]+);" | rex "DeviceData=(?P<DeviceData>[^;]+);" | rex "Event:\s+(?P<Event>\w+)User" | rex "Category:\s+(?P<EventCategory>\w+)Event" | rex "Module:\s+(?P<EventModule>\w+)Event" | rex "Event\sType:\s+(?P<EventType>\w+)Event" | rex "User:\s+(?P<User>[^\s]+)" | rex "Source:\s+(?P<EventSource>\w+)Event" A number of your regex statements were slightly off, so I've modified them. This now returns: I'm not 100% sure it would be the cause, but I'd avoid using the 'space' character in the regex, especially when you put them in props.conf I always go with the \s just to be explicit. For example. I've avoid this: EXTRACT-EventType = Event Type:\s+(?P<EventType>\S+)Event And go instead with: EXTRACT-EventType = Event\sType:\s+(?P<EventType>\w+)Event It should be fine, it's more just force of habit for me. If the rex command work but then don't when you move them over to the props.conf file, you can check the config for that sourcetype with btool . For example, if the sourcetype for your data was 'extract-test' you could run the command: ./splunk btool props list extract-test --debug This will give you all of the props config for that sourcetype and which file the config is coming from. It would look a bit like this: /Splunk/etc/system/local/props.conf [extract-test] /Splunk/etc/system/default/props.conf ANNOTATE_PUNCT = True /Splunk/etc/system/default/props.conf AUTO_KV_JSON = true /Splunk/etc/system/default/props.conf BREAK_ONLY_BEFORE = /Splunk/etc/system/default/props.conf BREAK_ONLY_BEFORE_DATE = True /Splunk/etc/system/default/props.conf CHARSET = UTF-8 /Splunk/etc/system/default/props.conf DATETIME_CONFIG = /etc/datetime.xml /Splunk/etc/system/local/props.conf EXTRACT-Device = Device=(?P<Device>[^;]+); /Splunk/etc/system/local/props.conf EXTRACT-DeviceData = DeviceData=(?P<DeviceData>[^;]+); /Splunk/etc/system/local/props.conf EXTRACT-Event = Event:\s+(?P<Event>\w+)User /Splunk/etc/system/local/props.conf EXTRACT-EventCategory = Category:\s+(?P<EventCategory>\w+)Event /Splunk/etc/system/local/props.conf EXTRACT-EventModule = Module:\s+(?P<EventModule>\w+)Event /Splunk/etc/system/local/props.conf EXTRACT-EventSource = Source:\s+(?P<EventSource>\w+)Event /Splunk/etc/system/local/props.conf EXTRACT-EventType = Event\sType:\s+(?P<EventType>\w+)Event /Splunk/etc/system/local/props.conf EXTRACT-User = User:\s+(?P<User>[^\s]+) /Splunk/etc/system/default/props.conf HEADER_MODE = /Splunk/etc/system/default/props.conf LEARN_MODEL = true /Splunk/etc/system/default/props.conf LEARN_SOURCETYPE = true /Splunk/etc/system/default/props.conf LINE_BREAKER_LOOKBEHIND = 100 /Splunk/etc/system/default/props.conf MATCH_LIMIT = 100000 /Splunk/etc/system/default/props.conf MAX_DAYS_AGO = 2000 /Splunk/etc/system/default/props.conf MAX_DAYS_HENCE = 2 /Splunk/etc/system/default/props.conf MAX_DIFF_SECS_AGO = 3600 /Splunk/etc/system/default/props.conf MAX_DIFF_SECS_HENCE = 604800 /Splunk/etc/system/default/props.conf MAX_EVENTS = 256 /Splunk/etc/system/default/props.conf MAX_TIMESTAMP_LOOKAHEAD = 128 /Splunk/etc/system/default/props.conf MUST_BREAK_AFTER = /Splunk/etc/system/default/props.conf MUST_NOT_BREAK_AFTER = /Splunk/etc/system/default/props.conf MUST_NOT_BREAK_BEFORE = /Splunk/etc/system/default/props.conf SEGMENTATION = indexing /Splunk/etc/system/default/props.conf SEGMENTATION-all = full /Splunk/etc/system/default/props.conf SEGMENTATION-inner = inner /Splunk/etc/system/default/props.conf SEGMENTATION-outer = outer /Splunk/etc/system/default/props.conf SEGMENTATION-raw = none /Splunk/etc/system/default/props.conf SEGMENTATION-standard = standard /Splunk/etc/system/default/props.conf SHOULD_LINEMERGE = True /Splunk/etc/system/default/props.conf TRANSFORMS = /Splunk/etc/system/default/props.conf TRUNCATE = 10000 /Splunk/etc/system/default/props.conf detect_trailing_nulls = false /Splunk/etc/system/default/props.conf maxDist = 100 /Splunk/etc/system/default/props.conf priority = /Splunk/etc/system/default/props.conf sourcetype = Have a go with some of the tweaked regular expressions via rex first, then move them into props.conf , restart then check with btool and see where you're at. Your approach is fine and should work, there's just going to be a small niggle tripping you up somewhere! With the regex and props.conf above, I think I get the result you're looking for in my test: ... View more