Fix for segment/count Metric Not Emitting with Statsd-emitter

[YongGang]

Description

This pull request resolves a bug where the segment/count metric was not being emitted as expected when using the Statsd-emitter. The issue was traced to a discrepancy in the serviceName used within the metric name. While the Statsd-emitter was correctly appending the serviceName to the metric name, the configured metric name within the Statsd-emitter did not include the correct serviceName. This mismatch led to a failure during the metric name comparison check, resulting in the segment/count metric not being reported. The configuration has been corrected to include the appropriate serviceName, ensuring that the segment/count metric is now emitted correctly for each service.

Release note

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[TSFenwick]

Lgtm

[suneet-s]

Good find!

Can you update the docs for statsd and prometheus as well to indicate the correct service name.

Also, it looks like some service names are configurable - like the coordinator, overlord and broker, but historicals, peons, middle managers are hardcoded. Can the docs make reference to these configurations so that users know how to decide what service name to use.

[YongGang]

Good find!

Can you update the docs for statsd and prometheus as well to indicate the correct service name.

Also, it looks like some service names are configurable - like the coordinator, overlord and broker, but historicals, peons, middle managers are hardcoded. Can the docs make reference to these configurations so that users know how to decide what service name to use.

Doc Updated

[suneet-s]

I think I mis spoke earlier. It looks like the service name for the coordinator is hard coded in CliCoordinator. Thanks for the fix!

binder.bindConstant()
                  .annotatedWith(Names.named("serviceName"))
                  .to(TieredBrokerConfig.DEFAULT_COORDINATOR_SERVICE_NAME);