[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

[RockteMQ-AI]

⚠️ Merge conflict detected

This PR has conflicts with the base branch and cannot be merged. Please rebase or merge the base branch into your branch and resolve the conflicts:

git fetch origin
git checkout feature-code-review
git rebase origin/main
# resolve conflicts, then:
git push --force-with-lease

This is a one-time reminder. Feel free to @mention me for a re-review after conflicts are resolved.

---

Automated notification by github-manager-bot

[RockteMQ-AI]

Summary

This PR modifies 10 file(s) with 670 lines of diff. No test changes detected — consider adding test coverage.

---

Automated review by github-manager-bot

Additional notes (not anchored to a changed line)

• [INFO] README.md:1 — Large diff (670 lines). Consider breaking into smaller, focused PRs for easier review. (line outside diff)

[RockteMQ-AI]

No test changes detected alongside source modifications. Consider adding tests to cover the changes.