4 ms·
How the hell do regexes like these find their way into production …
by scrollaway 6y ago
How the hell do regexes like these find their way into production …
- mannykannot 6y agoThere's an example of the sort of chronic (pun intended) patch-driven-development, YAGNI(Y) thinking that leads to this sort of thing, in the last paragraph: "For instances that can't/won't get updated in time, this Splunk app can be deployed as a workaround. The app executes bash/Powershell at Splunk startup to check for the above regex and add a '6' if needed. It may not be the best fix, but it does kick-the-can on the problem for another 3 years, at least until epoch time reaches 1.7e10." Someone, somewhere is saying "but it passed all the unit tests..."
- a1369209993 6y ago> at least until epoch time reaches 1.7e10. And to add insult to injury: that should actually be 1.7e9; 1.7e10 would be 17000M epoch seconds, not 1700M.
- jcims 6y agoSpunk also has field extractors where they automatically generate regexes from sample data that look a little bit like this.
- peterwwillis 6y agoKnowing Splunk, I'm surprised it was a regex and not a bunch of strchr()s
- foota 6y agoAm I the only one that thinks this isn't completely unreasonable? Is it a hack? Definitely, but I don't see a much better way without more context of determining whether some number is likely to be a timestamp. Should it base it on a range of numbers determined at startup? Probably, but it's not fundamentally much different.
- crehn 6y agoA much saner heuristic could use a reasonable range (for some value of reasonable) around the current timestamp to check whether it's also one. The assumption being that logs will be streamed, hence any timestamp will likely refer to something that happened in the recent past.