[jira] [Updated] (AMBARI-17589) Capture & visaulize metrics for Ambari Server

["Aravindan Vijayan (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMBARI-17589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aravindan Vijayan updated AMBARI-17589:
---------------------------------------
    Description: 
Ambari's architectural design is based on having a single master server with multiple agents.  Each agent sends a heartbeat every X seconds to the server to report its status; the server may reply with a list of commands to be run by each agent.

An operational cluster may have up to 2000-4000 agents and Ambari needs to be robust and performant at such scale.  Often times, Ambari's overall performance is subject to the cluster’s environment like network latency and stability, Ambari database call latency, etc. In such environments, detecting the cause of the Ambari’s sluggish performance and/or instability have proven to be difficult in practice.

Ambari should intercept and store the time and resources taken for serving requests.  This information can be then presented to the end user on Ambari Web and/or Grafana. 

Optionally, this work can be extended to have Ambari Web persist time taken to process the response of each API call and other performance characteristics.  Such performance data on Ambari Web can be again presented to the end user via Ambari Web and/or Grafana. 

> Capture & visaulize metrics for Ambari Server
> ---------------------------------------------
>
>                 Key: AMBARI-17589
>                 URL: https://issues.apache.org/jira/browse/AMBARI-17589
>             Project: Ambari
>          Issue Type: Epic
>    Affects Versions: 3.0.0
>            Reporter: Aravindan Vijayan
>            Assignee: Yusaku Sako
>            Priority: Critical
>             Fix For: 3.0.0
>
>
> Ambari's architectural design is based on having a single master server with multiple agents.  Each agent sends a heartbeat every X seconds to the server to report its status; the server may reply with a list of commands to be run by each agent.
> An operational cluster may have up to 2000-4000 agents and Ambari needs to be robust and performant at such scale.  Often times, Ambari's overall performance is subject to the cluster’s environment like network latency and stability, Ambari database call latency, etc. In such environments, detecting the cause of the Ambari’s sluggish performance and/or instability have proven to be difficult in practice.
> Ambari should intercept and store the time and resources taken for serving requests.  This information can be then presented to the end user on Ambari Web and/or Grafana. 
> Optionally, this work can be extended to have Ambari Web persist time taken to process the response of each API call and other performance characteristics.  Such performance data on Ambari Web can be again presented to the end user via Ambari Web and/or Grafana. 



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