[Feature] Add new metric type=STANDARD_VALUE

[wu-sheng]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

After we brought MQE into the key query feature and OTEL monitoring integration as an important eco-system, we noticed the labeled value we have is too simple. Currently, it is just one label with its value. You can't do multiple labels in the persistence. In the previous solution, we connect the remained labels as a new label.

Such

In the query stage, although we have MQE system, we still can't merge the metric on-demand to get per instance or per error_code. The hands of system capabilities are tired.

Use case

The typical use cases mentioned in [Bug] Metrics are not aggregated properly as OTEL collector targeting per node. To support that, we were trying to use the existing labeled valued, but it is not powerful enough.

The new proposal is adding a new metric type, type=STANDARD_VALUE. The data is assembled like a MQEValues, which includes entity, labels and value.

https://github.com/apache/skywalking-query-protocol/blob/f0bdba688afecff2167d018ecdaf509d2c8598f7/metrics-v3.graphqls#L70-L78

---

This data should be hosted through a new implementation of StorageDataComplexObject, but not DataTable. Because of this, this metric can't be queried out by v1 and v2 query APIs. Users have to use MQE system and syntax.

Note, as this is a new metric type, the MQE implementation on the alerting side should be supported too. LabeledValueHolder is not enough, we need a new StandardValueHolder.

About the UI side, the current UI is easily using metric.labels[0].value to show the only label. In the use case, the logic should be, that if the label key is _ and there is only one key, the logic keeps the same, otherwise, if there are multiple key-value pairs in the MQE return, it should combine them to visualize like key1=value key2=value2...

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[pg-yang]

I think it's related to #11982 (comment).
If we support multiple labels, aggregate_labels should support aggregation based on specified labels, we can aggregate results through specified labels to get accurate service level metrics

[wu-sheng]

I think it's related to #11982 (comment). If we support multiple labels, aggregate_labels should support aggregation based on specified labels, we can aggregate results through specified labels and preserve other labels at the same time to get accurate service level metrics

Yes, that could be a use case. FYI @wankai123

[wu-sheng]

About adding a new type=STANDARD_VALUE, another option is, we re-implemented the labeled value metric. Only treat today LABELED_VALUE and DataTable as special cases of the multiple labels feature.
Let's see whether this is possible in codes.