[ISSUE #50] Feature add rocketmq exporter to nameserver

[linjiemiao]

No description provided.

[liuruiyiyang]

Thanks for your contribution~
There are several questions:

1. Design. Since the exporter is an independent service, would it be better to deploy in an independent pod and be optional?
2. Docker image. The image used by rocketmq-operator is better also open-sourced. So the dockerfile and other image related code should be added to our image package(dir) in general (or at least add some docs about how to build it). In that way we can build it, test it and push it to our official repository apacherocketmq.
3. Documentation. It is better to add some documents/related links about how to use it in full functioning. In fact there are dependencies like Prometheus and Grafana.

[linjiemiao]

Thanks for your contribution~
There are several questions:

1. Design. Since the exporter is an independent service, would it be better to deploy in an independent pod and be optional?
2. Docker image. The image used by rocketmq-operator is better also open-sourced. So the dockerfile and other image related code should be added to our image package(dir) in general (or at least add some docs about how to build it). In that way we can build it, test it and push it to our official repository apacherocketmq.
3. Documentation. It is better to add some documents/related links about how to use it in full functioning. In fact there are dependencies like Prometheus and Grafana.

Design：

If the exporter is used as an independent pod, when I have multiple nameservers, my exporter does not know which nameserver to connect, so I use exporter as an option of nameserver, deploy it as a sidecar to nameserver。Can you give me some design advice?

[liuruiyiyang]

Thanks for your contribution~
There are several questions:

1. Design. Since the exporter is an independent service, would it be better to deploy in an independent pod and be optional?
2. Docker image. The image used by rocketmq-operator is better also open-sourced. So the dockerfile and other image related code should be added to our image package(dir) in general (or at least add some docs about how to build it). In that way we can build it, test it and push it to our official repository apacherocketmq.
3. Documentation. It is better to add some documents/related links about how to use it in full functioning. In fact there are dependencies like Prometheus and Grafana.

Design：

If the exporter is used as an independent pod, when I have multiple nameservers, my exporter does not know which nameserver to connect, so I use exporter as an option of nameserver, deploy it as a sidecar to nameserver。Can you give me some design advice?

In fact operator maintains a variable in the shared package named NameServersStr which is the NAMESRV_ADDR like: 192.168.1.1:9876;192.168.1.2:9876. You can check the code and use that.

[linjiemiao]

Thanks for your contribution~
There are several questions:

1. Design. Since the exporter is an independent service, would it be better to deploy in an independent pod and be optional?
2. Docker image. The image used by rocketmq-operator is better also open-sourced. So the dockerfile and other image related code should be added to our image package(dir) in general (or at least add some docs about how to build it). In that way we can build it, test it and push it to our official repository apacherocketmq.
3. Documentation. It is better to add some documents/related links about how to use it in full functioning. In fact there are dependencies like Prometheus and Grafana.

Design：
If the exporter is used as an independent pod, when I have multiple nameservers, my exporter does not know which nameserver to connect, so I use exporter as an option of nameserver, deploy it as a sidecar to nameserver。Can you give me some design advice?

In fact operator maintains a variable in the shared package named NameServersStr which is the NAMESRV_ADDR like: 192.168.1.1:9876;192.168.1.2:9876. You can check the code and use that.

ADD exporter image and document.

Please check it. I tend to use the exporter as the sidecar of the nameserver. Please check the exporter's dockerfile.

Because I tend to adjust the fields in the share package to private, so that multiple clusters can be deployed using one operator.

If you still want to deploy the exporter separately, I will do as you say.

thanks

[anguoming]

I think it better to init the NAMESRV_ADDR env in nameservice_controller.go