feat(prometheus-client): add metric label about root on using PrometheusClientLayer

[flaneur2020]

Which issue does this PR close?

Closes #4909.

Rationale for this change

I did not found the bucket value in the accessor, but i found a parameter called root might be helpful on this case. To make this PR work as expected, I need to make sure that the bucket should be the prefix of the root parameter.

What changes are included in this PR?

• refactor: seperate registering metrics and helpers to update metrics with the common labels
• feat: add root label to all the labels

Are there any user-facing changes?

this PR adds a new label on the prometheus metrics, if you had an existed dashboard, this change may make additional data lines on your chart. however it would not change your chart if you use sum(xx) by (op) or other metric aggregation operations.

to make this change possible, we had to make the type of labels from (&'static str, &'static str) to (&'static str, String), this may degrade a bit performance.

[flaneur2020]

a question I need to confirm about this PR: does this root parameter contain the bucket in it?

[Xuanwo]

does this root parameter contain the bucket in it?

No. root is the base path for all opendal operations. You might want to include name in the metrics.

[flaneur2020]

does this root parameter contain the bucket in it?

No. root is the base path for all opendal operations. You might want to include name in the metrics.

thank you for the suggestion, i've added a namespace label (i feel afraid that name might has some risks conflicting with some built-in prometheus labels) in the appended commit. the root label might still be useful for some other cases, i did not remove it after namespace added.

[Xuanwo]

Others LGTM, thanks!

[Xuanwo]

I'm thinking of implementing EncodeLabelSet directly for our lables to avoid to_string() here.

ref: https://docs.rs/prometheus-client/latest/prometheus_client/metrics/family/struct.Family.html#family-with-custom-type-for-performance-andor-type-safety

Would you like to start a new PR for this or just in this PR?

[flaneur2020]

let me have a try in this pr

[flaneur2020]

i switched to a Cow<'static, str> in daab9db which helps reduces copy but can not reduce all the copies.

it turns out that we can not simply add lifetime annotations (for the labels like root and namespace which stored in a singleton struct) in the labels type within promtheus-client, because each metric (with labels together) will be registered into a global registry, which requires the metrics to be 'static.

(imho it would be better to allow us make the label set as a trait object in a metric type, which help us decoupling the lifetime and metrics registration, however it's not allowed in prometheus-client yet)

[Xuanwo]

Hi, I'm thinking about making OperationLabels a seperate struct and implement EncodeLabelSet for it. For example:

struct OperationLabels {
  scheme: Scheme,
  op: &'static str,
  namespace: Arc<String>,
  root: Arc<String>,
}

impl EncodeLabelSet for OperationLabels { .. }

In this way, we can constrct OperationLabels and use:

family.get_or_create(&OperationLabels { ... }).inc();

This design will also avoid unexpected breaking changes like field doesn't match.

[flaneur2020]

makes sense, i've changed them to structs, PTAL

[Xuanwo]

Thanks a lot!