Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Introduction
Currently, when there is an OR operator between fields concerned by regexes, the backend is returning an exception saying that Oring regexes are not supported.
Issue description
Until now, this has been an issue on the splunk backend given the fact that, in splunk, regexes need to be handled with an operator preceded by a pipe, like
| regex fieldX=value
. These pipes are making an implicit AND on the whole preceding query and are "ending the query", to continue it, we would need to add a| search
which cannot be combined with parenthesis crossing/englobing pipes. So when regexes have only AND operators in their parents, this is not an issue and they can be appended at the end of the query with their implicit AND. But when they are concerned by an OR operator, as they are applying this implicit AND on the whole preceding query and "ending" it, there is no way to handle it with this method. So, something like(fieldX=test OR (index=* | regex fieldY=test)
is returning an error (parenthesis englobing a pipe), as something like this :index=* | regex fieldX=test OR fieldY=test
(query following the| regex
).Solution presentation
This PR offers to fix this limitation by computing all regexes at the begining, and then appending the query to handle value comparison conditions instead of regex condtions.
So for this PR offers to handle a rule like this :
with the following query :
Implementation
Implementation is passing through an new deferred class
SplunkDeferredORRegularExpression
, and the redefinition offinalize_query
which is just checking if there is an ORing regex case, and if so, is calling thesuper().finalize_query
with the query preceded by the whole train of| rex ...|eval ...
.Cases of multiple regexes on the same field
When multiple regexes are on the same field, with an OR operator between them, i implemented the ability to add a number at the end of
fieldXMatch
andfieldXCondition
to differentiate between them.is handled with :
Notes on performance
This implementation offers to handle the rules using regexes with OR operators, but has a major drawback on the performance side : each regex will be processed on all logs before applying the query logic, this can take some time.