Conversation
|
Log queries are much more complex than other existing queries in SkyWalking now, such as more data size and need custom Tokenizer in es. We need to be careful with this. |
|
That is another story about the stop word, word analyzer, etc. But none of them relate to the query abstract implementation and protocol. |
|
I'm big +1 to have this functionality, the performance concern will be discussed in specific implementations though. |
|
I'm +1 at first of all. |
@dmsolr Yes, I am thinking about this too. How about we add a response text when the implementation doesn't support that, they could add description for the UI. |
rainbend
left a comment
rainbend
left a comment
There was a problem hiding this comment.
I think this is a very useful functionality.
| } | ||
|
|
||
| extend type Query { | ||
| supportQueryLogsByKeywords: Boolean! |
There was a problem hiding this comment.
@arugal @kezhenxu94 @EvanLjp @dmsolr What about this? And I put keywords as List.
|
Maybe need to be enhanced the feature. We need not only |
| # Fuzzy query conditions for the log content. | ||
| # Use these 2 keyword related condition, when supportQueryLogsByKeywords = TRUE. | ||
| keywordsOfContent: [!String] | ||
| excludingKeywordsOfContent: [!String] |
5 participants
Log content fuzzy query is a risky operation. What do you think about this?