Looks like the only thing you are missing is something to get rid of the day of the week from the beginning, and use the proper syntax for rex. Oh, one other thing. You can make splunk's job easier if you do not use [ ]* for the spaces between numbers. Explanation after the code.
| rex field=_raw "^\w+\s+(?P<DP_Date_Time>\w+\s+\d+\s+\d+\s+\d+:\d+:\d+)\s+(?P<DP_Error_Code>[[^ ]\w+])\[\w+]\[\w+]\s(?P<DP_Service_Name>\w+\(\w+\)):\s+\w+\((?P<DP_Transaction_ID>\d+)\)\[(?P<DP_TID>\d+.\d+.\d+.\d+)\]\s+\w+\((?P<DP_GTID>\d+)\):\s+Latency:\s+(?P<DP_LATENCY_TIME_REQ_HDR_READ>\d+)\s+(?P<DP_LATENCY_TIME_REQ_HDR_SENT>\d+)\s+(?P<DP_LATENCY_TIME_FSTB>\d+)\s+(?P<DP_LATENCY_TIME_FSTC>\d+)\s+(?P<DP_LATENCY_TIME_ENTIRE_REQ_TRS>\d+)\s+(?P<DP_LATENCY_TIME_FS_SYTLE_READY>\d+)\s+(?P<DP_LATENCY_TIME_FS_PARSING_COM>\d+)\s+(?P<DP_LATENCY_TIME_RES_HDR_RECVD>\d+)\s+(?P<DP_LATENCY_TIME_RES_HDR_SENT>\d+)\s+(?P<DP_LATENCY_TIME_BSTB>\d+)\s+(?P<DP_LATENCY_TIME_BSTC>\d+)\s+(?P<DP_LATENCY_TIME_RES_TRS>\d+)\s+(?P<DP_LATENCY_TIME_BS_STYLE_READ>\d+)\s+(?P<DP_LATENCY_TIME_BSPC>\d+)\s+(?P<DP_LATENCY_TIME_BSCA>\d+)\s+(?P<DP_LATENCY_TIME_BSCC>\d+) \[(?P<DP_Backside_URL>.*)\]"
Remember that * matches ZERO of something. With the spaces after numbers, that means that [0-9]*[ ]*[0-9]* matches a zero-length string, as well as an uncountable number of substrings of any succession of digits and spaces.
With this tiny piece of string...
243 254
the regex (?[0-9])(?[ ])(?[0-9]*) will match roughly 4*3^3 different ways, including...
1) the zero-length string before the first character where item1, space2 and item3 are all empty
2) the 1-length string "2" that has item1 and space2 empty and item3 as "2".
3) the 1-length string "2" that has item1 as "2" and space2 and item2 empty.
4) the 2-length string "24" that has item1 and space2 empty and item3 as "24".
5) the 2-length string "24" that has item1 as "2" and space2 and item3 as "4".
6) the 2-length string "24" that has item1 as "24" and space2 and item3 empty .
Since you were using the greedy * , those alternatives will not get tested until after the version where item1 gets "243" and item3 gets "254", so you will be okay as long as the overall pattern matches. However, the minute that your overall pattern somehow fails, your search is going bye-bye with way too many potential backtracks to ever come back from.
This is easily solved, because In each of these cases, you want one or more digits, and one or more spaces, so you can use + instead, so there are zero potential backtracks.
To see this in action, take your original rex string, go over to regex101, and plop it in the tester. Copy your sample into the test string box and see the match was found in 144 steps or so.
Now add some bad data late in the event - for example change one of the 36 to 36U. Up above to the right, after a short while, you will see the words "catastrophic backtracking". Now copy our version of the rex up there, and the message will instead be that it failed with no match after perhaps 136 steps.
... View more