-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Add LogQL AST walker #3991
Add LogQL AST walker #3991
Conversation
return e.matchers | ||
} | ||
|
||
func (e *matchersExpr) Shardable() bool { return true } | ||
func (e *MatchersExpr) AppendMatchers(m []*labels.Matcher) { | ||
e.matchers = append(e.matchers, m...) |
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'm wondering if we should get the matchers just public. WDYT ?
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.
Yeah I like this suggestion more as well.
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.
AFAICS, none of the expression structs exposes any of their field public, e.g. some interesting field would be LiteralExpr.value
, *AggrevationExpr.params
, OffsetExpr.offset
. IMHO ASTs are very sensitive to public scoping of internals. ASTs are often subject of optimizations and thus keeping fields private is a good choice to save your options for later. WDYT?
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.
Both sound fine to me 👍
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 think ultimately we'll make those public if we move to another package.
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.
Let's move them to public when we and if we publish this to another package.
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.
Nice change, LGTM.
The follow-up for grafana#3991, it makes using LogQL syntax outside possible, it also makes LogRange implements Expr interface.
What this PR does / why we need it:
The following change set provides a simple extension that enables walking the LoqQL AST for parsed and valid LogQL expressions. This helps to build third-party tooling that can inspect and manipulate LogQL queries before hitting the target Loki query-frontend/querier (e.g. prom-label-proxy).
Furthermore this PR changes:
MatcherExpr
struct includes a simpleAppendMatchers
method to append new label matchers when executing the walking function.walkSampleExpr
is replaced byexpr.Walk
Which issue(s) this PR fixes:
Special notes for your reviewer:
Checklist
cc @cyriltovena @owen-d