virajjasani commented on pull request #4107:
URL: https://github.com/apache/hadoop/pull/4107#issuecomment-1079369473


   @ayushtkn While I agree that JMX metric for slownode is already available, 
not every downstreamer might have access to it directly, for instance in K8S 
managed clusters, unless port forward is enabled (not so common case in prod), 
HDFS downstreamer would not be able to access JMX metrics. We have similar case 
with `DFS.getDataNodeStats()` API, it provides live/decomm/dead node info, 
however such node info is already used by JMX metrics, but when it's about 
downstream or deployment management application trying to use such info, DFS 
APIs are preferred and not JMX metrics due to similar concerns mentioned above.
   
   Moreover, it's not only about downstreamer using the API, we should also 
provide `dfsadmin -report` option to report slownode info for operators, 
something that only an API can offer.
   We only expose slowNode and reportingNodes info for each unique slow peer 
detection, we do not expose other imp data e.g. how many blocks are currently 
available, what is the DFS usage etc with the same JMX metric, and we don't 
even need to. However, providing as much concrete info related to each slow 
node would be API's responsibility.
   With API, we also don't need to keep tuning 
`dfs.datanode.max.nodes.to.report` to adjust how many top N slow nodes we want 
to get exposed (which is a nice limitation for JMX metrics for sure).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

Reply via email to