Hi Vijaya,   Under-replicated blocks are the blocks which does not meet the target replication factor. HDFS has self healing mechanism wherein it will create  new replicas of under-replicated blocks until they meet the target replication.  if multi node cluster then you can verify if any datanodes are down  Or if it is one node cluster then please ensure replication factor is set to 1.    Thanks. ... View more

-> I dont think there's a way as of now to check the overall capacity of kudu. However, You can check the individual kudu tserver size on disk by using the linux command on the host "du -sh" /<kudu-path>/   Further you can check the individual table size on disk by using CM charts.   How much space a Kudu table is using on disk: 1. Go to the Kudu service and navigate to the Charts Library tab. 2. On the left-hand side menu, click Tables to display the list of tables currently stored in Kudu. 3. Click on a table name to view the default dashboard for that table. The Total Tablet Size On Disk Across Kudu Replicas chart displays the total size of the table on disk using a time-series chart. Hovering with your mouse over the line on the chart opens a small pop-up window that displays information about that data point. Click the data stream within the chart to display a larger pop-up window that includes additional information for the table at the point in time where the mouse was clicked.   Link- https://www.cloudera.com/documentation/enterprise/latest/topics/cm_mc_kudu_service.html#charts_library Hope this helps. ... View more

Hi,   When the NameNode flushes the edits to Journal Nodes it maintains the quorum of 20 seconds. The reason you are seeing this Error message is because it took >20 sec for NN to send the edits. This could be because of various reasons i.e NN GC or JVM pause, whether JN is sharing the disks with other roles, network communication issues , slow group lookups  etc.    Checking the NameNode logs just before the FATAL message would be a good starting point. Check for Warning messages just before the FATAL error message on NameNode logs. ... View more

Addition to what Ben has said, You may want to check if the Journal Node is sharing the disk with any other roles.  Journal Node shouldnt be sharing its disk with any other roles (not even at OS level roles) As this will effect the JN response time under high load and cause slow sync problem.  ... View more

It seems like the DataNode webserver is not responding to CM agent. This could be because of various reasons, from my experience i would suggest you to check for "JVM" Pauses or " Slow BlockReceiver" in the DataNode logs as those are primarliy the reason for slow response from the DN to CM agent.  Datanode logs which you have provided  give some  hint about the slow block receiver but just to be sure check again filter the above mentioned keywords in datanode logs.    Whats the frequency of this alert on CM? is it just a one time alert or persistent ?   You can check your Datanode heap utilization by using the chart. Here's how you can do it CM-> chart builder-> select jvm_max_memory_mb, jvm_heap_used_mb where entityName="<DN-instance"       ... View more

Hi Arun, This error is very generic timeout error. It would be better if you could share the exact problem and share thread dumps. This timeout error is very common and you will be getting it when you are not able to communicate to a service. ... View more