[
https://issues.apache.org/jira/browse/HADOOP-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910898#action_12910898
]
Luke Lu commented on HADOOP-6728:
---------------------------------
bq. The design is treating jmx and ganglia as first class citizen.
No, the design treats MetricsSource, MetricsSystem and MetricsSink interface as
first class citizens. The default metrics system *implementation* happens to
export all metrics source as JMX MBeans. A GangliaSink would be just another
(though bundled for historical reasons) MetricsSink plugin just as FileSink and
other Y internal plugins.
bq. it breaks existing API without real value to the customer who already use
jmx or MetricsContext api.
Currently only RPC and a portion of HDFS metrics are accessible via JMX. The
new framework enabled *all* metrics (including jvm (from JvmMetrics that
includes log4j category counts, not just system jvm stuff), mapred, ugi etc.)
to be accessible via jmx with reduced effort. The main value of the new
framework is to allow parallel nonblocking MetricsSinks and dynamic
reconfig/reload metrics plugins *without* server restart. Both (requirements
from Y ops) are impossible with the current AbstractMetricsContext approach. Y
ops already enjoy rerouting metrics to different backends dynamically without
restarting namenode (which takes a long time.) The whole metrics sub system
with substantial production config options can be restarted in a fraction of a
second.
bq. Why not web service REST api?
It's entirely possible to write a MetricsSink plugin that actually does that.
But it would be redundant as JMX is already available (as a pull model service)
and there're plenty of JMX to whatever tools available.
bq. I was thinking if the interface could be generalized...
The interface is almost as generalized as it can be. It's basically an
efficient key-value pair pubsub system. All the servers export metrics in a
consistent manner, albeit not via a web service which would be a very
inefficient way of doing metrics for thousands of datanodes and tasktrackers.
Instead, we can have highly efficient MetricsSink plugins to send compact UDP
packets to hierarchical metrics aggregators.
> Overhaul metrics framework
> --------------------------
>
> Key: HADOOP-6728
> URL: https://issues.apache.org/jira/browse/HADOOP-6728
> Project: Hadoop Common
> Issue Type: Improvement
> Affects Versions: 0.20.2
> Reporter: Luke Lu
> Assignee: Luke Lu
> Fix For: 0.22.0
>
> Attachments: hadoop-6728-y20.104.patch, metrics1-flow.png,
> metrics2-builder-r2.png, metrics2-builder.png, metrics2-flow.png,
> metrics2-mutable-r2.png, metrics2-mutable.png, metrics2-record-r2.png,
> metrics2-record.png, metrics2-uml-r2.png, metrics2-uml.png
>
>
> Per discussions with Arun, Chris, Hong and Rajiv, et al, we concluded that
> the current metrics framework needs an overhaul to:
> * Allow multiple plugins for different monitoring systems simultaneously (see
> also: HADOOP-6508).
> * Refresh metrics plugin config without server restart.
> ** Including filtering of metrics per plugin.
> * Support metrics schema for plugins.
> The jira will be resolved when core hadoop components (hdfs, mapreduce) are
> updated to use the new framework . Updates to external components that use
> the existing metrics framework will be tracked by different issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
