@Jay Kumar SenSharma We have added "export ZEPPELIN_JAVA_OPTS='-Dspark.yarn.queue=zeppelin'" to the zeppelin configs in Ambari as we have done in the past with 2.6.2.2. We have since upgraded to 2.7.3 and this does not seem to be working in 2.7.3. New zeppelin users are using the "default" queue. I would like to know if that has changed in the new version and what can we do to fix it? @scharan Zeppelin by default uses spark's queue but when running, zeppelin uses up all available resources for the container it's in. We need to set a different queue for zeppelin so we can run it while still having available resources for separate spark queries. ... View more

@Rene Vargas As mentioned earlier that in case of auro-recovery. Ambari Server detects the "desired State" and current state of the host components and if they do not match then it sends a "Recobery" instruction to the agents. At this point you should see exact time when ambari server sent the "Recovery" command to the agent on the problematic host inside the "ambari-server.log" Then you can check the "/var/log/ambari-agent.log" to know when it actually received the recovery command and action performed on it. . Using above way we can findout how much time the communication between agent and server took to initiate the actual start of the component. Then from that time in the agent log we can get and then check how much time individual components took to restart Like NameNode might have taken longer time ... or DataNode ..etc. . If the host is slow then by looking at the individual component startup time we can get some idea like who is taking more time .... ... View more