fix(metrics): use raw metrics vec in connection metrics

[wenym1]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

#13981

Previously we use LabelGuardedXxx metrics vec to report connection metrics. We use the label guarded one to prevent label leak. However, the lifetime of the label guarded metrics is within the lifetime of each connection, and for some short connection such as connection with s3, it is used for short time, and is dropped soon, which will cause the label to be dropped and later reset and the metrics will become inaccurate.

However, the label of connection metrics is [connection_type, endpoint]. The set of connection_type is bounded, and endpoint is actually ip, and the set of endpoint is bounded. So for connection metrics, we don't need to use the label guarded metrics. So in this PR, we change to use the raw metrics vec back for connection metrics.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (d1128cb) 68.09% compared to head (79f1348) 68.08%.
Report is 3 commits behind head on main.

Files	Patch %	Lines
src/common/src/monitor/connection.rs	94.73%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #14017      +/-   ##
==========================================
- Coverage   68.09%   68.08%   -0.02%     
==========================================
  Files        1543     1543              
  Lines      267096   267096              
==========================================
- Hits       181890   181852      -38     
- Misses      85206    85244      +38     

Flag	Coverage Δ
rust	68.08% <94.73%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[fuyufjh]

Wonder if my understanding is correct... Either of the following should be good, right?

1. Dimension [connection_type, endpoint] + raw metrics, which means the metrics measures traffic between nodes, so it has unlimited lifetime
2. Dimension [connection_type, endpoint, port]+ LabelGuarded metrics, which means the metrics measures traffic of each connection, so it should have lifetime of the connection

And this PR chose 1. Is this correct?

[wenym1]

Wonder if my understanding is correct... Either of the following should be good, right?

Dimension [connection_type, endpoint] + raw metrics, which means the metrics measures traffic between nodes, so it has unlimited lifetime
Dimension [connection_type, endpoint, port]+ LabelGuarded metrics, which means the metrics measures traffic of each connection, so it should have lifetime of the connection
And this PR chose 1. Is this correct?

Yes, we chose 1, and before this PR, we already use the dimension [connection_type, ip].

The drawback of 2 is because of the drawback of the current label guarded metrics. For example, when we measure the connection to S3, which has a fixed endpoint, if we use the label guarded metrics, after a query has finished, the connection is dropped, and metrics of the labels will be dropped and reset and may cause the same incorrect metric as #13948, though we will report metrics of the same label very soon when we make the next S3 query.