Ambari Server can be used to manage a few tens of nodes to 1000+ nodes. In large clusters, or clusters with sub-optimal infrastructure, capturing Ambari Server performance can be useful for tuning the server as well as guiding future performance optimization efforts. Through this feature, a Metrics Source-Sink framework has been implemented within the AmbariServer which facilitates fine grained control of the various metric sources as well as eases addition of future metrics sources.
Specifically, Ambari server JVM and database (EclipseLink) metric sources have been wired up to send metrics to AMS, and visualized through Grafana dashboards.
| Name | Functionality | Interface | Implementation(s) |
|---|---|---|---|
| Metrics Service |
| org.apache.ambari.server.metrics.system.MetricsService | org.apache.ambari.server.metrics.system.impl.MetricsServiceImpl |
| Metric Source |
| org.apache.ambari.server.metrics.system.MetricsSource | org.apache.ambari.server.metrics.system.impl.JvmMetricsSource org.apache.ambari.server.metrics.system.impl.DatabaseMetricsSource |
| Metric Sink |
| org.apache.ambari.server.metrics.system.MetricsSink | org.apache.ambari.server.metrics.system.impl.AmbariMetricSinkImpl |
| Config Name | Default Value | Explanation |
|---|---|---|
source.jvm.class | org.apache.ambari.server.metrics.system.impl.JvmMetricsSource | Class used to collect JVM Metrics. |
source.jvm.interval | 10 | Interval, in seconds, used to denote how often metrics should be collected. |
The EclipseLink PeformanceMonitor has been extended to support a custom Ambari Database Metrics source. It provides us with monitoring data per entity and per operation on the entity.
The Performance Monitor provides 2 kinds of metrics -
For example, some of the metrics being collected tothe Database Metrics Source.
Counter.ReadObjectQuery.HostRoleCommandEntity.readHostRoleCommandEntity
Timer.ReadAllQuery.StackEntity.StackEntity.findByNameAndVersion.ObjectBuilding
In addition to the Counter & Timer metrics collected from EclipseLink, a computed metric of Timer/Counter (divided by) is also sent. This metrics provides the average time taken for an operation across time.
For example, if
Counter Metric : Counter.ReadAllQuery.HostRoleCommandEntity = 10000
Timer Metric : Timer.ReadAllQuery.HostRoleCommandEntity = 50
Computed Metric (Avg time for the operation) : ReadAllQuery.HostRoleCommandEntity = 200 (10000 div by 50)
As seen above, the computed metric name will be the same as the Timer & Counter metric except without the 'Timer.' / 'Counter.' prefix.
To enable this source, add "database" to the metric.sources config in metrics.properties and restart Ambari Server.
| Config Name | Default Value | Explanation |
|---|---|---|
source.database.class | org.apache.ambari.server.metrics.system.impl.DatabaseMetricsSource | Class used to collect Database Metrics from extended Performance Monitor class - org.apache.ambari.server.metrics.system.impl.AmbariPerformanceMonitor. |
source.database.performance.monitor.query.weight | HEAVY | EclipseLink Performance monitor granularity : NONE / NORMAL / HEAVY / ALL |
source.database.monitor.dumptime | 60000 | Collection interval in milliseconds |
source.database.monitor.entities | Cluster(.*)Entity,Host(.*)Entity,ExecutionCommandEntity, ServiceComponentDesiredStateEntity,Alert(.*)Entity,StackEntity,StageEntity | Only these entities' metrics will be collected and tracked. (org.apache.ambari.server.orm.entities). |
source.database.monitor.query.keywords.include | CacheMisses | Include some metrics which have the keyword even if they are not part of requested Entities. |
Ambari database metrics have been represented in 2 Grafana dashboards.
These dashboard graphs are meant to provide an example of how to create graphs to query specific entities or operations in an Ad Hoc manner.
ambariserver.metrics.disable=true