feat: add or operator for metric expression

[groobyming]

MetricQL is an enhanced extension of PromQL, And is backward-compatible with PromQL.

Currently, MetricQL already supports using the "or" operator to connect label filters as follows:
For example, the following query selects time series with {job="app1",env="prod"} or {job="app2",env="dev"} labels:

{job="app1",env="prod" or job="app2",env="dev"}

A more detailed description of this feature can be found here MetricsQL filtering-by-multiple-or-filters

This PR is to support filtering by multiple “or” filters

[groobyming]

@yuanbohan hi，yuanbohan.if you have time, please help to review it

[yuanbohan]

May I ask a question:

Is this PR the beginning of total implementation of MetricsQL, or only to support OR in label matcher?

[groobyming]

May I ask a question:

Is this PR the beginning of total implementation of MetricsQL, or only to support OR in label matcher?

@yuanbohan just only to support OR in label matcher

[yuanbohan]

BTW, this PR is to support MetricsQL filtering-by-multiple-or-filters

[evenyag]

@groobyming Could you please update the PR description to summarize what the PR does? There is an example: #76

[groobyming]

@groobyming Could you please update the PR description to summarize what the PR does? There is an example: #76

OK

[groobyming]

@yuanbohan @evenyag I extended the Matchers structure to support "or filters", if you have time, please help review new commit😀

[groobyming]

@yuanbohan @evenyag
I found that when processing ordinary mather and or_matcher, it is necessary to record whether the last processed matcher or or_matcher was, otherwise there is no way to decide the next action. Refer to the following example:
a{label1="1", label2="2" or label3="3" or label4="4"}
a{label1="1" or label2="2", label3="3" or label4="4"}

When processing the label4="4" node, if there is no previous processing status, how do you know whether to append to the original {label2="2" or label3="3"}, or to create a new or_matcher and add label1=" 1" and label4="4"?

[groobyming]

@yuanbohan @evenyag I found that when processing ordinary mather and or_matcher, it is necessary to record whether the last processed matcher or or_matcher was, otherwise there is no way to decide the next action. Refer to the following example: a{label1="1", label2="2" or label3="3" or label4="4"} a{label1="1" or label2="2", label3="3" or label4="4"}

When processing the label4="4" node, if there is no previous processing status, how do you know whether to append to the original {label2="2" or label3="3"}, or to create a new or_matcher and add label1=" 1" and label4="4"?

In general, there is still a lot of content and state to maintain when adding changes to the matchers structure.

like this

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct Matchers {
    pub matchers: Vec<Matcher>,
    pub or_matchers: Vec<Vec<Matcher>>,
    pub last_filter_action: ActionType
}

#[derive(Eq, PartialEq)]
pub enum ActionType {
    AND,
    OR,
}

[groobyming]

@yuanbohan @evenyag Add last_filter_action to mark the last append type, if you have time, please help review new commit😀

[evenyag]

@yuanbohan @evenyag I found that when processing ordinary mather and or_matcher, it is necessary to record whether the last processed matcher or or_matcher was, otherwise there is no way to decide the next action. Refer to the following example: a{label1="1", label2="2" or label3="3" or label4="4"} a{label1="1" or label2="2", label3="3" or label4="4"}

When processing the label4="4" node, if there is no previous processing status, how do you know whether to append to the original {label2="2" or label3="3"}, or to create a new or_matcher and add label1=" 1" and label4="4"?

I guess that we have inconsistent understandings of the "or filter" in MetricsQL.

According to the document

MetricsQL supports selecting time series, which match at least one of multiple “or” filters. Such filters must be delimited by or inside curly braces.
For example, the following query selects time series with {job="app1",env="prod"} or {job="app2",env="dev"} labels:

{job="app1",env="prod" or job="app2",env="dev"}

The number of or groups can be arbitrary. The number of ,-delimited label filters per each or group can be arbitrary. Per-group filters are applied with and operation, e.g. they select series simultaneously matching all the filters in the group.

I think or is the delimiter for filter groups.

a{label1="1", label2="2" or label3="3" or label4="4"} contains three groups:

{label1="1", label2="2"}
or
{label3="3"}
or
{label4="4"}

a{label1="1" or label2="2", label3="3" or label4="4"} indicates the following groups:

{label1="1"}
or
{label2="2", label3="3"}
or
{label4="4"}

The previous matchers group always ends with or. It should be clear and we don't need to maintain the process status.

[groobyming]

@yuanbohan @evenyag I found that when processing ordinary mather and or_matcher, it is necessary to record whether the last processed matcher or or_matcher was, otherwise there is no way to decide the next action. Refer to the following example: a{label1="1", label2="2" or label3="3" or label4="4"} a{label1="1" or label2="2", label3="3" or label4="4"}
When processing the label4="4" node, if there is no previous processing status, how do you know whether to append to the original {label2="2" or label3="3"}, or to create a new or_matcher and add label1=" 1" and label4="4"?

I guess that we have inconsistent understandings of the "or filter" in MetricsQL.

According to the document

MetricsQL supports selecting time series, which match at least one of multiple “or” filters. Such filters must be delimited by or inside curly braces.
For example, the following query selects time series with {job="app1",env="prod"} or {job="app2",env="dev"} labels:

{job="app1",env="prod" or job="app2",env="dev"}

The number of or groups can be arbitrary. The number of ,-delimited label filters per each or group can be arbitrary. Per-group filters are applied with and operation, e.g. they select series simultaneously matching all the filters in the group.

I think or is the delimiter for filter groups.

a{label1="1", label2="2" or label3="3" or label4="4"} contains three groups:

{label1="1", label2="2"}
or
{label3="3"}
or
{label4="4"}

a{label1="1" or label2="2", label3="3" or label4="4"} indicates the following groups:

{label1="1"}
or
{label2="2", label3="3"}
or
{label4="4"}

The previous matchers group always ends with or. It should be clear and we don't need to maintain the process status.

@evenyag Indeed, I misunderstood the usage of OR. I will try to fix this problem later, Thanks 👍

[groobyming]

@yuanbohan @evenyag Make some changes to fix the problem according to the suggestion 😀

[evenyag]

LGTM

[yuanbohan]

rebase the main branch to fix the codecov failure please

[groobyming]

rebase the main branch to fix the codecov failure please

Done

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.99%. Comparing base (5bc0088) to head (d76bbaa).

Changes have been made to critical files, which contain lines commonly executed in production. Learn more

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #84      +/-   ##
==========================================
+ Coverage   98.96%   98.99%   +0.02%     
==========================================
  Files          14       14              
  Lines        6098     6272     +174     
==========================================
+ Hits         6035     6209     +174     
  Misses         63       63              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[evenyag]

Please fix the clippy warning

[yuanbohan]

Please fix the clippy warning

@groobyming

[groobyming]

Please fix the clippy warning

@evenyag Hi, evenyag. What version of rustc are we using, my local version is "rustc 1.80.0-nightly" and when running the "cargo Clippy" command no warnings appear.

[yuanbohan]

Please fix the clippy warning

@evenyag Hi, evenyag. What version of rustc are we using, my local version is "rustc 1.80.0-nightly" and when running the "cargo Clippy" command no warnings appear.

You can find the failure detail from the action: https://github.com/GreptimeTeam/promql-parser/actions/runs/9152892165/job/25161349969 , and the command is cargo clippy --all-targets -- -D warnings

[groobyming]

Please fix the clippy warning

@evenyag Hi, evenyag. What version of rustc are we using, my local version is "rustc 1.80.0-nightly" and when running the "cargo Clippy" command no warnings appear.

You can find the failure detail from the action: https://github.com/GreptimeTeam/promql-parser/actions/runs/9152892165/job/25161349969 , and the command is cargo clippy --all-targets -- -D warnings

Ok

[groobyming]

Please fix the clippy warning

@groobyming

Please fix the clippy warning

@groobyming

Please fix the clippy warning

@evenyag Hi, evenyag. What version of rustc are we using, my local version is "rustc 1.80.0-nightly" and when running the "cargo Clippy" command no warnings appear.

You can find the failure detail from the action: https://github.com/GreptimeTeam/promql-parser/actions/runs/9152892165/job/25161349969 , and the command is cargo clippy --all-targets -- -D warnings

Ok

fixed