-
Notifications
You must be signed in to change notification settings - Fork 155
Node.js: Update examples #579
Node.js: Update examples #579
Conversation
[myTagKey], | ||
'my view' | ||
); | ||
globalStats..registerView(view); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't look right globalStats..
, double dots "..". Were you able to run this code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I ran the example and it works as expected.
// And register it | ||
stats.registerExporter(exporter); | ||
globalStats.registerExporter(exporter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we changing this to globalStats
? What's up with stats
? Other languages use the same or is another stats
used somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Earlier we used to create Stats instance (new Stats()
) and used in the application. With new release, we have changed it to a global singleton Stats instance (globalStats
). This behavioral change is introduced to match other language implementation. (The name globalStats
is specific to Node library).
|
||
// Let's create an instance of our just created exporter | ||
var exporter = new MyConsoleTraceExporter(); | ||
const exporter = new MyConsoleTraceExporter(); | ||
// And start tracing with it | ||
tracing.registerExporter(exporter).start(); | ||
|
||
// Now, lets create a simple HTTP 2 server |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/HTTP 2/HTTP/2/g
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
|
||
var exporter = new instana.InstanaTraceExporter(); | ||
const tracing = require('@opencensus/nodejs'); | ||
const { InstanaTraceExporter }= require('@opencensus/exporter-instana'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems spurious, perhaps just keep the const
change and then as it was before i.e.
const instana
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally think the destructuring import is fine as that is a fairly common pattern in JS and then it saves you referencing it via the namespace below (i.e. you don't need to say const exporter = new instana.InstanaTraceExporter();
you can just say const exporter = new InstanaTraceExporter();
)
var core = require('@opencensus/core'); | ||
var tracing = require('@opencensus/nodejs'); | ||
var jaeger = require('@opencensus/exporter-jaeger'); | ||
const { logger } = require('@opencensus/core'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps let's make this style consistent: in some place we have const { objectName } = require(<import>)
and in others const objectName = require(<import>)
for example
const tracing = require('@opencensus/nodejs');
while here
const { logger } = require('@opencensus/core');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const { objectName } = require(<import>)
i.e. destructuring import is preferred wherever it is feasible.
const { PrometheusStatsExporter } = require('@opencensus/exporter-prometheus'); | ||
|
||
// Add your port and startServer to the Prometheus options | ||
const exporter = new PrometheusStatsExporter({ | ||
port: 9464, | ||
startServer: false | ||
startServer: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What changed here from startServer: false
to startServer: true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So earlier, it was like two step approach
- Don't start the Prometheus exporter server i.e.
startServer: false
- Explicitly call
startServer
method to start the Prometheus exporter server i.e.
exporter.startServer(function callback() {
// Callback
});
This can be possible by passing startServer: true
option.
}); | ||
and then for our corresponding `prometheus.yaml` file: | ||
|
||
```shell |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff including this!
var tracing = require('@opencensus/nodejs'); | ||
var zipkin = require('@opencensus/exporter-zipkin'); | ||
const tracing = require('@opencensus/nodejs'); | ||
const { ZipkinTraceExporter } = require('@opencensus/exporter-zipkin'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mixing const tracing
and const { ZipkinTraceExporter }
|
||
// Create and Register the view | ||
const view = globalStats.createView( | ||
'my/view', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional: what would you thin about adding comments for the name and description values e.g.
const view = globalStats.createView(
/* name */ 'my/view',
measure,
AggregationType.LAST_VALUE,
[myTagKey],
/* description */ 'my view'
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|
||
var exporter = new instana.InstanaTraceExporter(); | ||
const tracing = require('@opencensus/nodejs'); | ||
const { InstanaTraceExporter }= require('@opencensus/exporter-instana'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally think the destructuring import is fine as that is a fairly common pattern in JS and then it saves you referencing it via the namespace below (i.e. you don't need to say const exporter = new instana.InstanaTraceExporter();
you can just say const exporter = new InstanaTraceExporter();
)
}); | ||
and then for our corresponding `prometheus.yaml` file: | ||
|
||
```shell |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be yaml
instead of shell
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Thanks for working on this and for tagging me @mayurkale22! I'll humbly defer to @draffensperger since he has new Node.js expertise and is familiar with the new syntax than I am. |
Is this good to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @mayurkale22 for the work and @draffensperger for the reviews!
This PR contains the following changes.
var
->const
.