HDDS-13128. Expose per DN space utilisation as JMX metrics

[anuragp010]

What changes were proposed in this pull request?

Currently there are no node-level aggregated DN JMX metrics available to track the space utilised on a Datanode across all its volumes. Having JMX metrics to track the space utilisation per Datanode, allows monitoring and enables the user to take action when the space utilized on a DN is high, by adding nodes or running the Container Balancer.
A new class DatanodeStorageMetrics is added to expose 3 metrics related to space utilisation: Capacity, Used and UsedPercentage.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-13128

How was this patch tested?

1. Resulting JMX Metrics:

{
    "name" : "Hadoop:service=HddsDatanode,name=DatanodeStorageMetrics",
    "modelerType" : "DatanodeStorageMetrics",
    "tag.Context" : "ozone",
    "tag.Hostname" : "7d739934c5d0",
    "OzoneCapacity" : 105076655700,
    "OzoneUsed" : 4382720,
    "OzoneUsedPercentage" : 0.004170974010167322
}

2. Newly added Unit Tests.

[chihsuan]

Thanks for adding the metrics! @anuragp010

I left a few comments, mainly about metric naming and lifecycle. The remaining suggestions are minor.

[yandrey321]

I'd add integration test that checks the metrics in mini ozone cluster, including non 0 used space after creating some files on the cluster.

[jojochuang]

Thanks for the PR. On the "do we already have DN space utilization?" question: the underlying data yes, this JMX shape no.

• Per-volume on the DN: VolumeInfoMetrics-<path> already exposes OzoneCapacity / OzoneUsed per HDDS data volume.
• Per-DN at cluster scope: SCM and Recon already aggregate the same heartbeat storage reports (SCMNodeStat, Recon NodeEndpoint).

What's new here is a single node-level JMX endpoint on the datanode so operators can scrape one bean instead of summing all volume MBeans or going through SCM/Recon. Reusing volumeSet.getStorageReport() is the right source — same numbers we already send upstream.

Two small additions beyond the existing review threads:

1. PR description: "no metrics available" is a bit strong — per-volume DN JMX and SCM/Recon per-DN stats already exist. Worth reframing as "no node-level aggregated DN JMX metric."

2. Scope: please call out in the class javadoc that this totals data volumes only (same scope as OzoneContainer.getNodeReport() storage reports), not meta/DB volumes. That'll avoid surprises for multi-volume DN setups.

Conceptually this looks fine to me — a small monitoring convenience, not new storage accounting.

[anuragp010]

Thanks for the review @chihsuan , @sravani-revuri , @yandrey321 and @jojochuang . I have updated the PR accounting for all the review comments .

[sarvekshayr]

LGTM.

[aryangupta1998]

Thanks for the patch @anuragp010, overall LGTM, with some minor comments inline!

[sarvekshayr]

Please update the metric names in the PR description -

{
    "name" : "Hadoop:service=HddsDatanode,name=DatanodeStorageMetrics",
    "modelerType" : "DatanodeStorageMetrics",
    "tag.Context" : "ozone",
    "tag.Hostname" : "4afdd5f0dd94",
    "OzoneCapacity" : 126482287595,
    "OzoneUsed" : 0,
    "OzoneUsedPercentage" : 0.0
  }

[chihsuan]

Left one small nit. LGTM +1 👍

[chihsuan]

nit: I think this can be removed. This key expects a SpaceUsageCheckFactory, so HddsVolumeFactory falls back to the default anyway.

[anuragp010]

Thanks for pointing this out @chihsuan . Yes, the key expects a SpaceUsageCheckFactory hence it falls back to DUFactory. But we do have to set the config explicitly as the integration-test module's ozone-site-.xml sets hdds.datanode.du.factory.classname=MockSpaceUsageCheckFactory$None which results in the test failing with a NullPointerException. I have updated this line accordingly.

[aryangupta1998]

Thanks for addressing the comments, LGTM!

[sarvekshayr]

Thanks @anuragp010 for the patch, @chihsuan, @yandrey321, @jojochuang, @aryangupta1998 and @sravani-revuri for the review.