Hey there, I have a _raw where I am extracting a timestamp. But this is in a bad format. So I wanted to have a "calculated field" (via the splunk interface option, not in the conf to which I dont have access). But while other calculated fields seem to work. basically I have a field called "exTimeString". I want to create a calculated field exTimeStamp What I put into the eval field is: strptime(exTimeString,"%Y-%m-%dT%H:%M:%S") Unfortunately it doesn't work. Is it because of the strptime? Ormaybe the % characters cause issues here? ... View more

Hey there! I have logs from two different sources in one search. One source provides a time range, while the other provides a time stamp. I am wondering how these could best be matched (with a minimum of processing power). So one source leads to: startTime| endTime | userId| task 12:00 | 12:47| 34 | Processing 12:10 | 13:11| 22 | Initiating 12:50 | 12:55| 34 | Cleaning 13:12 | 13:22| 22 | Processing The other leads to timestamp | userId | actionStatus 12:05 | 34 | Error 12:20 | 22 | Finished 12:45 | 22 | Error 13:00 | 22 | Error Both are searched together (the unused fields of the different index are accordingly empty). So the full table is: |table startTime, endTime, userId, task, timestamp, userId,actionStatus Each line of the second batch (with the actionStatus) needs the additional info regarding the task which took place on that userId and at that timeframe. So the final result should be: timestamp | userID | actionStatus | task 12:05 | 34 | Error | Processing 12:20 | 22 | Finished | Initiating 12:45 | 22 | Error | Initiating 13:00 | 22 | Error | Initiating Is there any good way to enrich the data like this? The major complication is that the userId and timestamp need to be compared with the userId and timeframe of another batch. The only rather bad way which comes to mind is breaking up the time spans and timestamps into hourly or minutely brackets and then group by them, but that seems to be quite messy. ... View more

Hey there! I am currently having some trouble in converting a flattened multivalue field back into a real multivalue field. I know that there are easy ways with multi value field commands. However I need to do this via regex in this specific case. So the _raw is looking like this 06/23/2019 11:59:32 +0000, lotsofrandomstuff="lotsofrandomstuff",interestingIds="1234 2345 56784", lotsofotherrandomstuff="lotsofotherrandomstuff" However I just cannot get it to work. If I just take the field interestingIds and extract it from there its fairly easy and working: | rex field=_raw max_match=100 "(?<Ids>\d*)\s?" But as soon as I set the beginning (interestingIds=”) and the end (“), I only ever get one value, either the first or the last. Or of course all in the same format as before, but not as multivalue. Get the same field: | rex field=_raw "interestingIds=\"(?<Ids>((\d)|(\s))*)\".*" Other stuff I tried: This only takes the first value | rex field=_raw max_match=100 "interestingIds=((\"|\s)(?\d+)(\"|\s))*.*" This one only takes the last value (which kind of means that the value is overwritten each time I guess) | rex field=_raw max_match=100 " interestingIds=\"((?<Ids>\d+)\s?)*\".*" This one only gives the very last digit: | rex field=_raw max_match=100 " interestingIds=\"(\d+\s?)*(?<Ids>\d+)(\s?\d+)*\".*" You can replace the first * with a ? to get the second segment or a {2} to get the third segment, but it’s only one segment then. So maybe you have an idea on how to make it work. Update: So my next idea was to not focus on the stuff I want to take away, but to filter out everything else, hoping that the Front and Rear Anchor would work: | rex field=_raw max_match=0 "^(.*interestingIds=)(\"|(.*\s))(?<Ids>\d+)(\"|(\s.*))(, lotsofotherrandomstuff=.*)$" | rex field=_raw max_match=0 "^(.*interestingIds=\")(?<Ids>\d+)(\", lotsofotherrandomstuff=.*)$" Unfortunately both options do not work. It seems like as soon as you specify any kind of position, it fails. ... View more

Heyho! I am currently working on putting together a summary index and would like to do it via an alert. The basics are all clear on how to set an alert, scheduling, writing into the index and so on. However I haven’t been able to find any best practice info here and info on how splunk behaves on delayed alerts (not delayed indexing). So the Alert I am setting up (and this is already working in a csv) is doing a search for 6h which is at least full 24h ago, and it snaps to the last completed 6h batch of the previous day ( 0,6,12,18). So if you run a search on the 26. of May at 6:01 or at 11:55 it will automatically search for the timeframe of 25. May at 0:00 to 6:00. And that’s all fine in itself, no assistance needed. What I do not know though is how splunk alerts usually behave. When I schedule a search in Splunk to run at 0:00 and let’s say select the timeframe in the alert of -6h to now. What happens if due to technical issues the search is delayed and runs at 6 AM? Will it now search from 0:00 to 6:00 instead? When a search is delayed, will the now() command in the search refer back to the “old” scheduled date or will it accordingly use the date of runtime? What happens if you schedule a hourly search but due to technical issues no search can run in a 90m time window. Will the delayed search run together with the next search or will it be skipped? With using these 6h intervals I mentioned before in my plans, do you think that all issues are minimized as far as it gets or do you have any other recommendations? ... View more

I encountered a very weird behaviour. This has now also been reported as bug. Update: I did manage to create some fake data now and further isolated the issue. I cannot attach the files nor links. So you'd need to create them on your own. So first run this to create some fake logs: | makeresults | eval id=1 | eval number= 816341959 | append [|makeresults | eval id=1 | eval number=816295885] | fields - _time | outputlookup testlog.csv And now run this to create a lookup: | makeresults | eval color="Purple" | eval number=816295885 | fields - _time | outputlookup testlookup.csv Now that we got the files, run this: |inputlookup testlog.csv | eval number=mvindex(number,0,0) | lookup testlookup.csv number output color as color1 | eval mydump=number | eval mydump2=color | eventstats dc(test.id) as ids by number | lookup testlookup.csv number output color as color2 | search number=816295885 Result: color1 is null color2 is "Purple" as it should be Things you can play around with: - Remove the mvindex -> it will populate color1 correctly - Remove the eventstats -> it will populate color1 correctly (even though there is nothing which affects this field at that point) - in the testlog.csv switch around the two values -> it will populate color1 correctly - switch the value which is NOT looked up (816341959) to 100 -> it will populate color1 correctly (from 816295885) - now switch the value which is NOT looked up to 916341959 -> it will populate color1 correctly (from 816295885) This basically means that with numbers in this range of ~816295885 splunk becomes unreliable, if it is at a location of a similar lookup, which is extremely bad. You can even do this: | makeresults | eval number= 816295885 | append [ makeresults | eval number=816341959] | table number | lookup testlookup.csv number output color Even though only 816295885 is in the lookup, the color will also be found for 816341959, which is even more extremely bad I guess. Splunk Version 7.2 was used in this case. Don't know if this is version specific. ... View more