[question] Whether the logics about metrics in cri dir needs to revise?

[fengzixu]

Question

When I read codes about metrics of gRPC in the pouch, I found that there are some not standard approaches in using the object called Registerer in Prometheus.

Actually, in https://github.com/alibaba/pouch/blob/master/cri/metrics/metrics.go#L78, the method called MustRegister registers metrics into the register variant in Prometheus. But, that is a default and global register. We can see this behaviour in https://github.com/prometheus/client_golang/blob/0a8115f42e037a6e327f9a269a26ff6603fb8472/prometheus/registry.go#L51 .

According to those comments about DefaultRegisterer, we can know that there is a big risk about using global variant in our code especially in the dependent package. If someone modifies this variant accidentally through some methods written in prometheus. That is a disaster. That is a reason, we should avoid using global variants as much as possible.

I contributed some examples to go-grpc-prometheus. In that PR, the member of Prometheus give me some advice about using register:

1. Using NewRegistry method to create a register variant which owned by yourself.
2. Registering all metrics which you cared for, including some default metrics or custom metrics.

Ref: grpc-ecosystem/go-grpc-prometheus#35 (comment)

So, if someone thinks that we should optimize the logics about using prometheus. I'm very glad to handle it. I have some experiences in there.

[fengzixu]

We should supply a standard pattern of using Prometheus in pouch.

[allencloud]

cc @starnop @CodeJuan

[starnop]

@fengzixu Thank you very much for your advice. In fact, so do that with the apis/metrics .
We are very glad that if you are willing to help with this. ^_^

[fengzixu]

Sure. I'm very glad to handle it.