Nate Cole created AMBARI-3459:
---------------------------------
Summary: Move metrics property definitions to stack
Key: AMBARI-3459
URL: https://issues.apache.org/jira/browse/AMBARI-3459
Project: Ambari
Issue Type: Sub-task
Reporter: Nate Cole
Assignee: Nate Cole
Metrics properties are currently internalized into ganglia_properties(_2).json
and jmx_properties(_2).json. In order to allow authors to define their own,
the following change is proposed:
* Make $SERVICE_HOME/metrics.json (or xml)
* Contents will be similar to existing file
{noformat}
{
"HBASE_MASTER": {
"component" : [
{
"type": "jmx",
“properties”: {
“port”: “60010”
}
"metrics": {
"metrics/rpc/RpcSlowResponse_num_ops": {
"metric":"rpc.rpc.RpcSlowResponse_num_ops",
"pointInTime":true,
"temporal":true
},
"metrics/process/proc_total": {
"metric":"proc_total",
"pointInTime":true,
"temporal":true
}, ...
}
},
{
"type": "ganglia",
“properties”: {
“ganglia_cluster”: “HDPHBaseMaster”
}
"metrics": { ... }
},
{
"type": "org.apache.ambari.server.controller.spi.PropertyProviderImpl",
“properties”: { … }
"metrics": { ... }
}
],
"host": [ ... ]
},
"HBASE_REGIONSERVER": {
}, ...
}
{noformat}
Type is either a known type (jmx, ganglia) or can be a specified class. If
that is the case, then the custom class will be instantiated when it is
required to actually fetch properties. This instantiation can either invoke a
public constructor or check for a static getInstance() method to enable
singleton/factory. The metrics object elements are lifted from the current
files to avoid having to re-design the entire JSON structure.
The properties object elements are name/value pairs that are used by the
provider class. Use case: Each component’s JMX data is fetched from the
server holding the component. Each component uses a different port number. So
the properties for, say, HBASE_REGIONSERVER may be: “port”: “60030”, and for
HBASE_MASTER: “port”: “60010”. Each provider understands what to do with its
own properties.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
