hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "HADOOP-6728-MetricsV2" by LukeLu
Date Mon, 23 Aug 2010 22:33:39 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "HADOOP-6728-MetricsV2" page has been changed by LukeLu.
The comment on this change is: Fix some inconsistencies..
http://wiki.apache.org/hadoop/HADOOP-6728-MetricsV2?action=diff&rev1=2&rev2=3

--------------------------------------------------

- ''This page keeps the design notes for [[https://issues.apache.org/jira/browse/HADOOP-6728|HADOOP-6728]]
only. Current dev/user documentation for metrics system should be kept elsewhere.''
+ ''This page keeps the design notes for [[https://issues.apache.org/jira/browse/HADOOP-6728|HADOOP-6728]]
only. Current dev/user documentation for metrics system should be kept elsewhere (say, package.html
and/or package-info.java in respective packages).''
  
  == Scope ==
  
@@ -15, +15 @@

  
  In the v2 framework, metrics sources are where the metrics are generated/updated, and metrics
sinks consume the records generated by the metrics sources. A metrics system would poll the
metrics sources periodically and pass the metrics records to metrics sinks (Figure 1). The
source getMetrics interface allows lockless implementations of metrics instrumentation (with
volatile metrics values). The sink interface is simple, where the putMetrics method would
be called with an immutable metrics record (Figure 2), so that plugin implementers don't have
to worry about thread safety. 
  
- ||<tablewidth="99%">{{https://issues.apache.org/jira/secure/attachment/12452696/metrics2-uml-r2.png|Metrics
system overview}}||
+ ||<tablewidth="99%">{{https://issues.apache.org/jira/secure/attachment/12452869/metrics2-uml-r2.png|Metrics
system overview}}||
  ||<:>Figure 1: Metrics system overview||
  
  Figure 1 is a [[http://martinfowler.com/bliki/UmlAsSketch.html|UML sketch]] class diagram
illustrating the involved passive objects (different colors indicating different kinds of
driving threads in discussion): !MetricsSource (in cyan) is driven by a timer thread (for
getMetrics()) and !MetricSink (in green) is driven by a thread for each Sink. The !MetricsFilter
objects (in orange) can be used either to filter the metrics from sources in the timer thread
or to filter metrics per sink in its respective thread. The metrics system expects that the
getMetrics call would return fairly quickly (i.e., latency smaller than the polling period).
The !MetricsSinkQueue is a nonblocking queue with preconfigured size (tolerance of sink latency:
n * period). New metrics records would be lost if the queue is full. The JMX MBean interface
would be implemented to allow existing JMX clients (JConsole, jManage etc.) to stop and start
the metrics system at run time.
@@ -95, +95 @@

    public int getMyMetric() { return 42; }
  
    // Recommended helper method
-   public MyMetric registerWith(MetricsSystem ms) {
+   public MyPojo registerWith(MetricsSystem ms) {
      return ms.register("MyPojo", "MyPojo metrics", this);
    }
  }
@@ -114, +114 @@

  
    // Recommended helper method
    public MyMetrics registerWith(MetricsSystem ms) {
-     return ms.register("MyMetrics2", "MyMetrics2 description", this);
+     return ms.register("MyMetrics", "MyMetrics description", this);
    }
  }
  }}}
@@ -125, +125 @@

  Initialize the metrics system:
  {{{#!java
  // Somewhere in your app's startup code, initialize the metric system.
- DefaultMetricsSystem.initialize("jobtracker");
+ DefaultMetricsSystem.initialize("JobTracker");
  
  // Create the metrics source object
  MyMetrics myMetrics = new MyMetrics().registerWith(DefaultMetricsSystem.INSTANCE);
@@ -135, +135 @@

  myMetrics.bar.incr();
  }}}
  
- Note, for simple metrics sources, using annotations make things declarative and concise.
For more advanced metrics source implementations, you might need to explicitly implement the
MetricsSource interface and override the getMetrics method and use the metrics builder API
(Figure 6.):
+ Note, for simple metrics sources, using annotations make the code declarative and concise.
For more advanced metrics source implementations, one might need to explicitly implement the
MetricsSource interface and override the getMetrics method and use the metrics builder API
(Figure 6.):
  
  {{{#!java
  class MyMetricsSource implements MetricsSource {

Mime
View raw message