Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 11 Jun 2015 22:57:01 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12836641.1433881830000.51155.1434063421104@Atlassian.JIRA>
In-Reply-To: <JIRA.12836641.1433881830000@Atlassian.JIRA>
References: <JIRA.12836641.1433881830000@Atlassian.JIRA>
 <JIRA.12836641.1433881830633@arcas>
Subject: [jira] [Commented] (AMBARI-11821) With HBase master HA Ambari
 sometimes displays incorrect dashboard information
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/AMBARI-11821?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D14=
582653#comment-14582653 ]=20

Hadoop QA commented on AMBARI-11821:
------------------------------------

{color:green}+1 overall{color}.  Here are the results of testing the latest=
 attachment=20
  http://issues.apache.org/jira/secure/attachment/12739120/AMBARI-11821_3.p=
atch
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author=
 tags.

    {color:green}+1 tests included{color}.  The patch appears to include 2 =
new or modified test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the =
total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not incre=
ase the total number of release audit warnings.

    {color:green}+1 core tests{color}.  The patch passed unit tests in amba=
ri-server.

Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/3143//t=
estReport/
Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/3143/=
/console

This message is automatically generated.

> With HBase master HA Ambari sometimes displays incorrect dashboard inform=
ation
> -------------------------------------------------------------------------=
-----
>
>                 Key: AMBARI-11821
>                 URL: https://issues.apache.org/jira/browse/AMBARI-11821
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-web
>    Affects Versions: 2.1.0
>            Reporter: Jaimin D Jetly
>            Assignee: Jaimin D Jetly
>            Priority: Critical
>             Fix For: 2.1.0
>
>         Attachments: AMBARI-11821.patch, AMBARI-11821_2.patch, AMBARI-118=
21_3.patch
>
>
> PROBLEM:  When there is more than one HBase Master certain metrics, in pa=
rticular the "Average Load" on the dashboard, are incorrect.  In the case o=
f "Average Load", the load will read "0".  After checking I noticed that th=
e web UI is hitting the following URL to refresh the metrics:
> {code}
> http://ADDRESS_OF_AMBARI_SERVER:8080/api/v1/clusters/CLUSTER_NAME/compone=
nts/?ServiceComponentInfo/component_name=3DAPP_TIMELINE_SERVER|ServiceCompo=
nentInfo/category=3DMASTER&fields=3DServiceComponentInfo/Version,ServiceCom=
ponentInfo/StartTime,ServiceComponentInfo/HeapMemoryUsed,ServiceComponentIn=
fo/HeapMemoryMax,ServiceComponentInfo/service_name,host_components/HostRole=
s/host_name,host_components/HostRoles/state,host_components/HostRoles/maint=
enance_state,host_components/HostRoles/stale_configs,host_components/HostRo=
les/ha_state,host_components/HostRoles/desired_admin_state,host_components/=
metrics/jvm/memHeapUsedM,host_components/metrics/jvm/HeapMemoryMax,host_com=
ponents/metrics/jvm/HeapMemoryUsed,host_components/metrics/jvm/memHeapCommi=
ttedM,host_components/metrics/mapred/jobtracker/trackers_decommissioned,hos=
t_components/metrics/cpu/cpu_wio,host_components/metrics/rpc/RpcQueueTime_a=
vg_time,host_components/metrics/dfs/FSNamesystem/*,host_components/metrics/=
dfs/namenode/Version,host_components/metrics/dfs/namenode/LiveNodes,host_co=
mponents/metrics/dfs/namenode/DeadNodes,host_components/metrics/dfs/namenod=
e/DecomNodes,host_components/metrics/dfs/namenode/TotalFiles,host_component=
s/metrics/dfs/namenode/UpgradeFinalized,host_components/metrics/dfs/namenod=
e/Safemode,host_components/metrics/runtime/StartTime,host_components/metric=
s/hbase/master/IsActiveMaster,ServiceComponentInfo/MasterStartTime,ServiceC=
omponentInfo/MasterActiveTime,ServiceComponentInfo/AverageLoad,ServiceCompo=
nentInfo/Revision,ServiceComponentInfo/RegionsInTransition,metrics/api/v1/c=
luster/summary,metrics/api/v1/topology/summary,host_components/metrics/yarn=
/Queue,ServiceComponentInfo/rm_metrics/cluster/activeNMcount,ServiceCompone=
ntInfo/rm_metrics/cluster/lostNMcount,ServiceComponentInfo/rm_metrics/clust=
er/unhealthyNMcount,ServiceComponentInfo/rm_metrics/cluster/rebootedNMcount=
,ServiceComponentInfo/rm_metrics/cluster/decommissionedNMcount&minimal_resp=
onse=3Dtrue
> {code}
> The results that come back seem to sometimes be for the wrong server.  Sp=
ecifically this stuff:
> {code}
>       "ServiceComponentInfo" : {
>         "AverageLoad" : 0.0,
>         "HeapMemoryMax" : 2075918336,
>         "HeapMemoryUsed" : 541616216,
>         "MasterActiveTime" : 0,
>         "MasterStartTime" : 1432752607527,
>         "component_name" : "HBASE_MASTER",
>         "service_name" : "HBASE"
>       },
> {code}
> I'm attaching a file with the output of two different clusters at the cus=
tomer site.  In both cases, the average load was not 0, but it shows up tha=
t way in the JSON.  Also notice that for one of the clusters the IsActiveMa=
ster is false, and one is true.  It seems like there is a disconnect in wha=
t comes back in that query URL.
> I reproduced this on a local cluster as follows (HDP 2.2.4 with Ambari 2.=
0.0):
> 1.  Started hbase service with 2 masters.  I observed that Average Load w=
as displaying the right (non-zero) value.
> 2.  I then restarted the current active master.  This shifted active to t=
he other one.  After a minute or so the Average Load went to 0.
> 3.  In one instance for some reason the problem did not happen right away=
.  I bounced ambari-server and then the problem happened.  I could restore =
the reading by shifting active back to the other master.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)