This is a DataNode health test that checks for whether the DataNode has too many blocks. Having too many blocks on a DataNode may affect the DataNode's performance. A DataNode with a large number of blocks will require a larger java heap and may experience longer garbage collection pauses. Additionally, a large number of blocks may be an indicator of the presence of many small files. HDFS is not optimized for dealing with many small files, and processing times may suffer when operating across many small files. If only some DataNodes have a high number of blocks, running the HDFS Rebalance command may address this issue by moving data between DataNodes. If the HDFS Rebalance command reports the cluster as balanced without fixing the block imbalance then the problem is related to the presence of many small files. Consult the HDFS documentation for best-practices on addressing this issue. If many small files is not a concern for your use case, consider disabling this health test. If all DataNodes have a high number of blocks and the issue is not related to small files, additional DataNodes should be added. This test can be configured using the DataNode Block Count Thresholds DataNode monitoring setting.

Short Name: Block Count

This is a DataNode health test that checks for whether the DataNode has reported any failed volumes. A failure of this health test indicates that there is a problem with one or more volumes on the DataNode. See the DataNode system for more information. This test can be configured using the DataNode Volume Failures Thresholds DataNode monitoring setting.

Short Name: Data Directory Status

This DataNode health test checks that the number of file descriptors used does not rise above some percentage of the DataNode file descriptor limit. A failure of this health test may indicate a bug in either Hadoop or Cloudera Manager. Contact Cloudera support. This test can be configured using the File Descriptor Monitoring Thresholds DataNode monitoring setting.

Short Name: File Descriptors

This is a DataNode health test that checks that the amount of free space available for HDFS block data on the DataNode does not fall below some percentage of total configured capacity of the DataNode. A failure of this health test may indicate a capacity planning problem. Try adding more disk capacity and additional data directories to the DataNode, or add additional DataNodes and take steps to rebalance your HDFS cluster. This test can be configured using the DataNode Free Space Monitoring Thresholds DataNode monitoring setting.

Short Name: Free Space

This DataNode health test checks that the DataNode is not spending too much time performing Java garbage collection. It checks that no more than some percentage of recent time is spent performing Java garbage collection. A failure of this health test may indicate a capacity planning problem or misconfiguration of the DataNode. This test can be configured using the Garbage Collection Duration Thresholds and Garbage Collection Duration Monitoring Period DataNode monitoring settings.

Short Name: GC Duration

This DataNode health test factors in the health of the host upon which the DataNode is running. A failure of this test means that the host running the DataNode is experiencing some problem. See that host's status page for more details.This test can be enabled or disabled using the DataNode Host Health Test DataNode monitoring setting.

Short Name: Host Health

This DataNode health test checks that the filesystem containing the log directory of this DataNode has sufficient free space. This test can be configured using the Log Directory Free Space Monitoring Absolute Thresholds and Log Directory Free Space Monitoring Percentage Thresholds DataNode monitoring settings.

Short Name: Log Directory Free Space

This is a DataNode health test that checks that all the running NameNodes in the HDFS service consider the DataNode alive. A failure of this health test may indicate that the DataNode is having trouble communicating with some or all NameNodes in the service. Look in the DataNode logs for more details. This test can be enabled or disabled using the DataNode Connectivity Health Test DataNode monitoring setting. The DataNode Connectivity Tolerance at Startup DataNode monitoring setting and the Health Check Startup Tolerance NameNode monitoring setting can be used to control the test's tolerance windows around DataNode and NameNode restarts respectively.

Short Name: NameNode Connectivity

This DataNode health test checks that the Cloudera Manager Agent on the DataNode host is heart beating correctly and that the process associated with the DataNode role is in the state expected by Cloudera Manager. A failure of this health test may indicate a problem with the DataNode process, a lack of connectivity to the Cloudera Manager Agent on the DataNode host, or a problem with the Cloudera Manager Agent. This test can fail either because the DataNode has crashed or because the DataNode will not start or stop in a timely fashion. Check the DataNode logs for more details. If the test fails because of problems communicating with the Cloudera Manager Agent on the DataNode host, check the status of the Cloudera Manager Agent by running /etc/init.d/cloudera-scm-agent status on the DataNode host, or look in the Cloudera Manager Agent logs on the DataNode host for more details. This test can be enabled or disabled using the DataNode Process Health Test DataNode monitoring setting.

Short Name: Process Status

This is a DataNode health test that checks for whether the DataNode transceivers usage is nearing the configured transceivers limit. A transceiver is a thread used to transfer data into or out of the DataNode. If a DataNode hits its transceivers limit, HDFS reads and writes will begin to fail. This test can be configured using the DataNode Transceivers Usage Thresholds DataNode monitoring setting. The Maximum Number of Transfer Threads DataNode setting controls the DataNode transceivers limit.

Short Name: Transceiver Usage

This DataNode health test checks that the DataNode has not recently exited unexpectedly. The test returns "Bad" health if the number of unexpected exits goes above a critical threshold. For example, if this test is configured with a critical threshold of 1, this test would return "Good" health if there have been no unexpected exits recently. If there has been 1 or more unexpected exits recently, this test would return "Bad" health. This test can be configured using the Unexpected Exits Thresholds and Unexpected Exits Monitoring Period DataNode monitoring settings.

Short Name: Unexpected Exits

This health test checks that the role's web server is responding quickly to requests by the Cloudera Manager Agent, and that the Cloudera Manager Agent can collect metrics from the web server. A failure of this health test may indicate a problem with the web server of the DataNode, a misconfiguration of the DataNode or a problem with the Cloudera Manager Agent. Consult the Cloudera Manager Agent logs and the logs of the DataNode for more detail. If the test's failure message indicates a communication problem, this means that the Cloudera Manager Agent's HTTP requests to the DataNode's web server are failing or timing out. If the test's failure message indicates an unexpected response, then the DataNode's web server responded to the Cloudera Manager Agent's request, but the response could not interpreted for some reason. This test can be configured using the Web Metric Collection DataNode monitoring setting.

Short Name: Web Server Status