Add MetricProducerManager to keep track of all MetricProducers by mayurkale22 · Pull Request #253 · census-instrumentation/opencensus-node

mayurkale22 · 2018-12-21T00:08:37Z

Basically, the MetricProducerManager keeps a set of MetricProducers (MetricProducerForRegistry and MetricProducerForStats) that is used by exporters to determine the metrics that need to be exported. Next step is to rewrite all the stats exporters (Stackdriver and prometheus) to use data from MetricProducerManager instead of viewdata.

The MetricProducerManager, MetricsComponent and ExportComponent classes are same as Java's implementation of metrics package. https://github.com/census-instrumentation/opencensus-java/tree/master/api/src/main/java/io/opencensus/metrics/export

codecov-io · 2018-12-21T00:11:45Z

Codecov Report

Merging #253 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #253      +/-   ##
=========================================
+ Coverage   94.54%   94.6%   +0.05%     
=========================================
  Files         101     105       +4     
  Lines        7317    7397      +80     
  Branches      690     691       +1     
=========================================
+ Hits         6918    6998      +80     
  Misses        399     399

Impacted Files	Coverage Δ
src/stats/stats.ts	`97.91% <0%> (ø)`	⬆️
src/metrics/export/metric-producer.ts
src/metrics/metric-component.ts	`100% <0%> (ø)`
test/test-metric-producer-manager.ts	`100% <0%> (ø)`
src/metrics/export/metric-producer-manager.ts	`100% <0%> (ø)`
src/metrics/export/base-metric-producer.ts	`100% <0%> (ø)`
test/test-metric-component.ts	`100% <0%> (ø)`

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fed0ad4...96c5bba. Read the comment docs.

OsvaldoRosado · 2019-01-02T17:47:53Z

packages/opencensus-core/src/metrics/export/export-component.ts

+   * @return {MetricProducerManager}.
+   */
+  getMetricProducerManager(): MetricProducerManager {
+    return ExportComponent.METRIC_PRODUCER_MANAGER;


Is ExportComponent just to keep the MetricProducerManager as a singleton? I'm not sure this needs to be a class at all if that's the case (vs simply exporting a const).

SGTM, Done. PTAL

OsvaldoRosado · 2019-01-02T23:34:34Z

packages/opencensus-core/src/metrics/metrics.ts

+   *
+   * @return {MetricProducerManager}.
+   */
+  static getMetricProducerManager(): MetricProducerManager {


Depending on what getMetricRegistry does, you might be able to make these properties instead of getter methods (or even potentially replacing this class for a plain module with consts - just like the previous PR feedback).

The only reason to use getter here is to make apis consistent across other language libraries. WDYT? I am happy to change as per your suggestion.

Personally I'm not a fan of classes used only for namespacing, since Node modules already provide a namespace and classes that are the only export in a file end up causing double-namespacing for anyone using require instead of ES6 import syntax. That being said, I can understand the consistency argument.

One thing to note, if this were a plain module end users get some extra flexibility with importing, which might be beneficial. Eg:

Importing like this which provides similar syntax to the class implementation

import * as Metrics from '....metrics'; Metrics.metricProducerManager.add(…)

Or importing only what's needed to simplify code

import {metricProducerManager} from '....metrics'; metricProducerManager.add(…)

Just noticed your question might have been specifically just about .getMetricProducerManager() vs .metricProducerManager - rather than also the replacement of the class with consts 😄

I don't have a strong opinion either way, since both are incredibly similar to the end user. All things equal I'd lean to not having to do a function call vs having to do one.

OsvaldoRosado · 2019-01-02T23:36:04Z

packages/opencensus-core/src/metrics/export/metric-producer-manager.ts

+ * Keeps a set of MetricProducer that is used by exporters to determine the
+ * metrics that need to be exported.
+ */
+export class MetricProducerManager {


Should users be able to construct their own, or should only the singleton be used? If users don't need their own, we might not want to export this.

Should users be able to construct their own, or should only the singleton be used?

should only the singleton be used.

If users don't need their own, we might not want to export this.

Agreed, removed export and added MetricProducerManager interface type, which is implemented by BaseMetricProducerManager.

packages/opencensus-core/src/metrics/metric-component.ts

draffensperger

LGTM with a few more optional nits

draffensperger · 2019-01-07T16:22:28Z

packages/opencensus-core/src/metrics/export/metric-producer-manager.ts

+   * This method should be used by any metrics exporter that automatically
+   * exports data for MetricProducer registered with the MetricProducerManager.
+   *
+   * @return {MetricProducer[]} List of MetricProducers.


Should this be Set<MetricProducer>? More generally, what's the value of specifying types in JSDoc comments if they are already there in TypeScript? Does that help documentation generators?

Changed to Set<MetricProducer>. Mostly I follow https://google.github.io/styleguide/jsguide.html#jsdoc for JSDoc comments.

draffensperger · 2019-01-07T16:22:50Z

packages/opencensus-core/src/metrics/metrics.ts

 import {MetricRegistry} from './metric-registry';

+
+// Class for accessing the default MetricsComponent.


Should this be JSDoc?

draffensperger · 2019-01-07T16:23:47Z

packages/opencensus-core/src/metrics/metrics.ts

-  private static readonly METRIC_REGISTRY = Metrics.newMetricRegistry();
+  private static readonly METRIC_COMPONENT = new MetricsComponent();
+
+  /**


Optional nit: could this comment be simplified to /** @return {MetricProducerManager} The global MetricProducerManager. */ ?

draffensperger · 2019-01-07T16:24:29Z

packages/opencensus-core/src/metrics/metrics.ts

+    return metricProducerManagerInstance;
+  }

  /**


Similar comment here on optionally combining the English Returns .. and JSDoc @return and making it a single line.

mayurkale22 · 2019-01-07T19:26:59Z

Thanks for the reviews @draffensperger and @justindsmith

googlebot added the cla: yes label Dec 21, 2018

mayurkale22 requested review from OsvaldoRosado and justindsmith December 21, 2018 00:08

mayurkale22 mentioned this pull request Dec 28, 2018

Rewrite stats exporters to use Metrics instead of Stats (ViewData) #257

Open

2 tasks

OsvaldoRosado reviewed Jan 2, 2019

View reviewed changes

mayurkale22 force-pushed the MetricProducerManager branch from c7e6c86 to b0e2b76 Compare January 2, 2019 23:21

OsvaldoRosado reviewed Jan 2, 2019

View reviewed changes

OsvaldoRosado approved these changes Jan 2, 2019

View reviewed changes

OsvaldoRosado reviewed Jan 2, 2019

View reviewed changes

mayurkale22 force-pushed the MetricProducerManager branch from 852f84b to ccec80d Compare January 3, 2019 00:26

draffensperger reviewed Jan 4, 2019

View reviewed changes

packages/opencensus-core/src/metrics/metric-component.ts Outdated Show resolved Hide resolved

draffensperger approved these changes Jan 7, 2019

View reviewed changes

mayurkale22 added 5 commits January 7, 2019 10:21

Add MetricProducerManager to keep set of MetricProducer

aa04fe7

fix review comments

9a70667

fix review comments

b232d00

Fix JSDoc comments

96c5bba

mayurkale22 force-pushed the MetricProducerManager branch from c5c9d2f to 96c5bba Compare January 7, 2019 18:44

mayurkale22 merged commit 3e1a9a0 into census-instrumentation:master Jan 7, 2019

mayurkale22 deleted the MetricProducerManager branch January 7, 2019 22:40

mayurkale22 mentioned this pull request Jan 14, 2019

Add MetricProducer that can be registered for exporting using MetricProducerManager. #192

Closed

mayurkale22 mentioned this pull request Feb 12, 2019

chore(multiple): 0.0.9 release proposal #341

Merged

		import {MetricRegistry} from './metric-registry';


		// Class for accessing the default MetricsComponent.

Conversation

mayurkale22 commented Dec 21, 2018

Uh oh!

codecov-io commented Dec 21, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

OsvaldoRosado Jan 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

draffensperger left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mayurkale22 commented Jan 7, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov-io commented Dec 21, 2018 •

edited

Loading

OsvaldoRosado Jan 2, 2019 •

edited

Loading