Fix prometheus metric format (#2825)

[ZhengweiZhu]

To meet specification of prometheus metric, there should be only one TYPE field for the same metric name.

We have meet this problem when implementing prometheus exporter for our own product, and this patch is applied with this problem fixed. The code is simple and efficient.

BTW, there are some other issue regarding to prometheus output format, which I will create issues and push PR. Thanks

What problem does this PR solve?

Issue Number:
#2825

Problem Summary:

What is changed and the side effects?

Changed:

Side effects:

• Performance effects(性能影响): NO

• Breaking backward compatibility(向后兼容性):

---

Check List:

• Please make sure your changes are compilable(请确保你的更改可以通过编译).
• When providing us with a new feature, it is best to add related tests(如果你向我们增加一个新的功能, 请添加相关测试).
• Please follow Contributor Covenant Code of Conduct.(请遵循贡献者准则).

[wasphin]

Simply ignoring metrics that are duplicates of the previous ones does not completely solve the problem. If the metrics themselves are repetitive, perhaps we should try to identify and address the root cause; if it's just a matter of duplicate names, consider fixing the metrics name.

[ZhengweiZhu]

Let me add some background knowledge. The metrics are stored in butil::FlatMap and the uniqueness of metric name is guaranteed. The problem arises from the introduction of mvar, where one metric name will correspond to multiple metric with different labels. My patch just handles this problem

[wwbmmm]

This PR is similar to #2870, which one is better?

[ZhengweiZhu]

This PR is similar to #2870, which one is better?

The #2870 introduced a std::set container to remove duplicates, which is unnecessary and impacts performance. As the metrics are stored in butil::FlatMap and the uniqueness of metric name is guaranteed.

When we just expose bvar, the current upstream code is fine. The problem arises from the introduction of mvar, where one metric name will correspond to multiple metric with different labels. My patch handles this problem and follow the specifition of Prometheus metric.

[wwbmmm]

LGTM

[wasphin]

There's a new dump_comment API when introducing mvar by @serverglen, is this the case to set some HELP/TYPE for it? dump_comment is only used by mvar.

$ git grep dump_comment

src/bvar/multi_dimension_inl.h:242:    if (label_names.empty() || !dumper->dump_comment(name(), METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:279:        if (!dumper->dump_comment(name() + "_latency", METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:312:        if (!dumper->dump_comment(name() + "_max_latency", METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:323:        if (!dumper->dump_comment(name() + "_qps", METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:334:        if (!dumper->dump_comment(name() + "_count", METRIC_TYPE_COUNTER)) {
src/bvar/variable.h:56:    virtual bool dump_comment(const std::string&, const std::string& /*type*/) {

[ZhengweiZhu]

There's a new dump_comment API when introducing mvar by @serverglen, is this the case to set some HELP/TYPE for it? dump_comment is only used by mvar.

$ git grep dump_comment

src/bvar/multi_dimension_inl.h:242:    if (label_names.empty() || !dumper->dump_comment(name(), METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:279:        if (!dumper->dump_comment(name() + "_latency", METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:312:        if (!dumper->dump_comment(name() + "_max_latency", METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:323:        if (!dumper->dump_comment(name() + "_qps", METRIC_TYPE_GAUGE)) {
src/bvar/multi_dimension_inl.h:334:        if (!dumper->dump_comment(name() + "_count", METRIC_TYPE_COUNTER)) {
src/bvar/variable.h:56:    virtual bool dump_comment(const std::string&, const std::string& /*type*/) {

Reasonable. By overriding dump_comment method of PrometheusMetricsDumper to output HELP/TYPE for a metric, then the dump method should be changed to only output name and value (not including HELP/TYPE). I will try it this way.