-
Notifications
You must be signed in to change notification settings - Fork 11.7k
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
Loki: Added query editor and builder support for new Logfmt features #74619
Conversation
Opening for review. Take it for a spin and let me know how it feels. I will be submitting the query builder changes in another PR. |
@@ -451,7 +507,10 @@ function resolveDurations(node: SyntaxNode, text: string, pos: number): Situatio | |||
} | |||
|
|||
function resolveLogRange(node: SyntaxNode, text: string, pos: number): Situation | null { | |||
return resolveLogOrLogRange(node, text, pos, false); |
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.
After pipe used to be hardcoded, now se use the current query to decide. This prevents duplicated pipes in metric queries.
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! Left couple of comments and questions bellow. 🙂
...lugins/datasource/loki/components/monaco-query-field/monaco-completion-provider/situation.ts
Outdated
Show resolved
Hide resolved
}; | ||
|
||
expect(await getCompletions(situation, completionProvider)).toMatchInlineSnapshot(` | ||
[ |
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.
Here it seems like we are mixing mock completion (with mock docs) and real completion (with real docs). Why is that?
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.
Also these snapshot tests are quite long (100s of lines of code). What if we just checked that it has correct labels
, rather than checking everything, as that's what we care about.
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.
Here it seems like we are mixing mock completion (with mock docs) and real completion (with real docs). Why is that?
Because the mocks come from:
jest.mock('../../../querybuilder/operations', () => ({
explainOperator: () => 'Operator docs',
}));
The reason is so tests doesn't break because we change the documentation. The usual "tests should be resilient to change".
Also these snapshot tests are quite long (100s of lines of code). What if we just checked that it has correct labels, rather than checking everything, as that's what we care about.
The whole way we test the completion output here is very cumbersome, to say the least. After having worked multiple times on this, I'm now more inclined to use inline snapshots, as they give you a readable output of the completion in a "similar" way of using the editor and seeing what it offers. I find that with snapshots it's easier to see that the output is good, unlike
Lines 361 to 362 in e16617d
const expected = buildAfterSelectorCompletions('logfmt', 'json', afterPipe, true); | |
expect(completions).toEqual(expected); |
We were also doing "snapshots" in the form of hardcoded json objects in places like this:
Lines 231 to 255 in e16617d
test('Returns completion options when the situation is IN_GROUPING', async () => { | |
const situation: Situation = { type: 'IN_GROUPING', logQuery: '' }; | |
const completions = await getCompletions(situation, completionProvider); | |
expect(completions).toEqual([ | |
{ | |
insertText: 'extracted', | |
label: 'extracted', | |
triggerOnInsert: false, | |
type: 'LABEL_NAME', | |
}, | |
{ | |
insertText: 'place', | |
label: 'place', | |
triggerOnInsert: false, | |
type: 'LABEL_NAME', | |
}, | |
{ | |
insertText: 'source', | |
label: 'source', | |
triggerOnInsert: false, | |
type: 'LABEL_NAME', | |
}, | |
]); | |
}); |
If I were to test this again, at the moment I would change everything to snapshots or json objects, but I'm 100% open to suggestions. Right now I can't see a way of testing completions without having to use very large strings or objects.
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 would think here to check only important things. For example documentation is not that important, but label
and type
.
@@ -136,7 +146,7 @@ export type Situation = | |||
}; | |||
|
|||
type Resolver = { | |||
path: NodeType[]; | |||
paths: NodeType[][]; |
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.
👍
...lugins/datasource/loki/components/monaco-query-field/monaco-completion-provider/situation.ts
Show resolved
Hide resolved
const LOGFMT_ARGUMENT_COMPLETIONS: Completion[] = [ | ||
{ | ||
type: 'FUNCTION', | ||
label: 'strict', |
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.
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.
Interesting. I would expect the autocomplete to pick up -
, but it's probably generating another new path for logfmt. I'll iterate a bit on this 👍
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.
* Query builder: add params to logfmt definition * Logfmt operation: add default params * Query builder: update deprecated JsonExpression * Operation utils: update logfmt renderer * Query builder: parse LogfmtParser * Query builder: parse LogfmtExpressionParser * Remove console log * Remove unused variable * Remove extra character from render * Update unit tests * Fix unit tests * Operations: remove restParams from logfmt booleans * Parsing: group cases * Formatting * Formatting * Update modifyQuery * LogContextProvider: update with parser changes * LogContextProvider: remove unnecessary type castings It takes more energy to write `as unknow as LokiQuery` than to write a refId. * Formatting
@@ -225,8 +230,9 @@ describe('LogContextProvider', () => { | |||
10, | |||
LogRowContextQueryDirection.Backward, | |||
{ | |||
expr: '{bar="baz"} | logfmt | line_format = "foo"', |
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.
Realized this was incorrect in most line format expressions, so I fixed it.
Also removed some type castings that were not really necessary. FYI @svennergr
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, good 👀 !
Backend code coverage report for PR #74619 |
Frontend code coverage report for PR #74619
|
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 job! Left some comments, but LGTM.
}; | ||
|
||
expect(await getCompletions(situation, completionProvider)).toMatchInlineSnapshot(` | ||
[ |
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 would think here to check only important things. For example documentation is not that important, but label
and type
.
* Loki autocomplete: add IN_LOGFMT situation for log queries * Loki autocomplete: add IN_LOGFMT situation for metric queries * Loki autocomplete: improve handling of trailing pipes and spaces * Loki autocomplete: add logfmt arguments completion * Loki autocomplete: add flags support to IN_LOGFMT * Loki autocomplete: extend IN_LOGFMT situation with labels and flag * Loki autocomplete: return logQuery in IN_LOGFMT situation * Loki autocomplete: offer label completions when IN_LOGFMT * Query utils: update parser detection method * Validation: update test * Loki autocomplete: improve IN_LOGFMT detection when in metric query * Loki autocomplete: improve logfmt suggestions * Loki autocomplete: improve logfmt suggestions in different scenarios * Loki autocomplete situation: refactor resolvers to support multiple paths * Situation: add test case * Loki autocomplete: allow user to use 2 flags * Situation: change flag to flags * Remove console log * Validation: import test parser * Completions: better handling of trailing comma scenario * Upgrade lezer-logql * Revert temporary imports * Loki Query Builder: Add support for new logfmt features (#74858) * Query builder: add params to logfmt definition * Logfmt operation: add default params * Query builder: update deprecated JsonExpression * Operation utils: update logfmt renderer * Query builder: parse LogfmtParser * Query builder: parse LogfmtExpressionParser * Remove console log * Remove unused variable * Remove extra character from render * Update unit tests * Fix unit tests * Operations: remove restParams from logfmt booleans * Parsing: group cases * Formatting * Formatting * Update modifyQuery * LogContextProvider: update with parser changes * LogContextProvider: remove unnecessary type castings It takes more energy to write `as unknow as LokiQuery` than to write a refId. * Formatting * Situation: use charAt instead of substring with endsWith * Situation: explain logfmt suggestions * Logfmt: improve flag suggestions * Remove console log * Completions: update test
This PR adds support for new Loki LogQL features:
Additional changes:
path
has been renamed topaths
to allow better grouping of multiple paths that produce the same situation.Which issue(s) does this PR fix?:
Fixes #71121
Special notes for your reviewer:
No special steps to follow. Just install the updated dependencies, write LogQL queries, and expect to be helped by the autocomplete suggestions.
Some examples:
Exception:
In this case we cannot offer labels because the extracted log query has errors:
{place="luna"} | logfmt --keep-empty float, [$__auto]
. We could attempt to improve this in a follow up PR by using error nodes to clean up the query.