HDDS-15147. Improve Recon Datanode Insight export: filename, size unit

[navinko]

What changes were proposed in this pull request?

• Updated Server side Datanode insight, export filename generation with clusterId appended with timestamp.
  Fomat used: Datanode_Insights_ClusterId_timestamp
  Example: Datanode_Insights_CID-ec3d0c23-7863-4f94-9e48-78134b891a62_20260502_1115.csv
• Unit of header kept as Byte
• Fixed PMD failures

What is the link to the Apache JIRA

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

How was this patch tested?

Verified with updated unit test class and dev tool downloaded filename.

Datanode_Insights_CID-6ece86f7-d869-411e-832c-1dad626c0991_20260505_1314.csv

Successful CI : https://github.com/navinko/ozone/actions/runs/25384413555

[sreejasahithi]

Thanks @navinko , left few minor comments

[sreejasahithi]

nit : better to name is as ClusterID

[navinko]

Done , used clusterID instead of ClusterID bcz checkstyle validations warns for non camel case.

"Name 'ClusterID' must match pattern '^[a-z][a-zA-Z0-9]*$'.""

[sreejasahithi]

This can be made to a private static final field in the class

[navinko]

done

[sreejasahithi]

Here for getting PendingBlockSize it would be better if add a guard for v.getMetric() != null since we are reading the value form the metric.

[navinko]

done , good catch ..It was missed across prev reviews as well.

[navinko]

Thanks @sreejasahithi for reviewing .

[priyeshkaratha]

@arunsarin85 @navinko
I’d prefer to keep the exported sheet values in bytes only. The primary purpose of this CSV report is to enable accurate comparisons and validate calculations, so exact byte-level values are more useful. If users want to view the data in GB, they can apply their own column conversions as needed. So it’s better not to convert the values to GB in the report. Renaming the columns would be fine.
cc : @ChenSammi @devmadhuu what is your thought on this?

[navinko]

Thanks @priyeshkaratha i do agree with you.
Converting to GB will make loss of precision for smaller bytes .
In this PR have used , Byte to GB conversion upto 2 decimal places and in exported sheet it will be 0.00 as used space for 4.2 MB on UI , unless we accept that it will lead to confusions and better to go with byte approach on csv.

[arunsarin85]

bytes only.

@arunsarin85 @navinko I’d prefer to keep the exported sheet values in bytes only. The primary purpose of this CSV report is to enable accurate comparisons and validate calculations, so exact byte-level values are more useful. If users want to view the data in GB, they can apply their own column conversions as needed. So it’s better not to convert the values to GB in the report. Renaming the columns would be fine. cc : @ChenSammi @devmadhuu what is your thought on this?

@priyeshkaratha Agreed ! Keeping it in bytes makes more sense.

[navinko]

Thanks @priyeshkaratha for review. Addressed review comments .