-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Support negative numbers in LogQL #13091
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We could add some more logql syntax example, specially the one about the structure of the tree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cyriltovena I've rethought my approach and moved the changes to the Parser and out of the Lexer. I've added comments on the relevant pieces, and added tests to clarify & valid the expected behaviour.
| IDENTIFIER NEQ NUMBER { $$ = log.NewNumericLabelFilter(log.LabelFilterNotEqual, $1, mustNewFloat($3))} | ||
| IDENTIFIER EQ NUMBER { $$ = log.NewNumericLabelFilter(log.LabelFilterEqual, $1, mustNewFloat($3))} | ||
| IDENTIFIER CMP_EQ NUMBER { $$ = log.NewNumericLabelFilter(log.LabelFilterEqual, $1, mustNewFloat($3))} | ||
IDENTIFIER GT literalExpr { $$ = log.NewNumericLabelFilter(log.LabelFilterGreaterThan, $1, $3.Val)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the crux of new approach: numberFilters now accept literal expressions instead of the NUMBER token. This means the filter can include +1
, 1
or -1
as equally valid. They get parsed as a float as other literals do, the value is then extracted via Val.
@@ -95,6 +95,19 @@ func TestLex(t *testing.T) { | |||
{`{foo="bar"} | logfmt --strict code"`, []int{OPEN_BRACE, IDENTIFIER, EQ, STRING, CLOSE_BRACE, PIPE, LOGFMT, PARSER_FLAG, IDENTIFIER}}, | |||
{`{foo="bar"} | logfmt --keep-empty --strict code="response.code", IPAddress="host"`, []int{OPEN_BRACE, IDENTIFIER, EQ, STRING, CLOSE_BRACE, PIPE, LOGFMT, PARSER_FLAG, PARSER_FLAG, IDENTIFIER, EQ, STRING, COMMA, IDENTIFIER, EQ, STRING}}, | |||
{`decolorize`, []int{DECOLORIZE}}, | |||
{`123`, []int{NUMBER}}, | |||
{`-123`, []int{SUB, NUMBER}}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reverted the changes in the lexer so all negative numbers now evaluate as SUB, NUMBER. The AST does the work now.
@@ -499,19 +499,19 @@ var ParseTestCases = []struct { | |||
// label filter for ip-matcher | |||
{ | |||
in: `{ foo = "bar" }|logfmt|addr>=ip("1.2.3.4")`, | |||
err: logqlmodel.NewParseError("syntax error: unexpected ip, expecting BYTES or NUMBER or DURATION", 1, 30), | |||
err: logqlmodel.NewParseError("syntax error: unexpected ip", 1, 30), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the biggest caveat with this change: The error messages presented to users are less clear. Presumably because numberFilter is now an expression, so there is no specific TOKEN to look for next.
There is no change to the syntax, just in the error message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
What this PR does / why we need it:
Adds negative number support to the LogQL
lexerparser.