The current tsconfig.json seems to disable important compiler checks. They should be enabled as per Google's guidelines on TypeScript style.

Readme says that it is for Tracing

Source is for stats

I have a very simple HTTP server and am trying to use the Zipkin Exporter.

Here is a reproduction of my code:

const port = process.env.PORT || 3000;
const upstream_uri = process.env.UPSTREAM_URI || 'http://time.jsontest.com/';
const service_name = process.env.SERVICE_NAME || 'opencensus-test-1-v1';

const tracing = require('@opencensus/nodejs');
const propagation = require('@opencensus/propagation-b3');
const b3 = new propagation.B3Format();
const zipkin = require('@opencensus/exporter-zipkin');

const exporter = new zipkin.ZipkinTraceExporter({
  url: 'http://localhost:9411',
  serviceName: 'test',
});

tracing.start({
  propagation: b3,
  samplingRate: 1.0,
  bufferSize: 1,
  bufferTimeout: 1,
  exporter
});

const express = require('express');
const app = express();
const request = require('request-promise-native');

app.get('/', async(req, res) => {
  await request({url: upstream_uri});
  res.end(`done`);
})

app.listen(port, () => {
  console.log(`${service_name} listening on port ${port}!`);
})

Unfortunately, traces are never sent to Zipkin and eventually the Node process dies with:
socket hang up

The same code with the default console.log exporter or the Jaeger exporter works fine. Not sure why Zipkin is broken. It does successfully connect to the Zipkin server in some capacity, because if I give the wrong port or url, it will immediately throw a connection error.

I tried running Zipkin both native and in Docker, neither works.

After a fresh repo clone, I see lots of test failures.

...
...
...
> @opencensus/[email protected] posttest /Users/ofrobots/src/opencensus/opencensus-node/packages/opencensus-exporter-zipkin
> npm run check


> @opencensus/[email protected] check /Users/ofrobots/src/opencensus/opencensus-node/packages/opencensus-exporter-zipkin
> gts check

lerna ERR! test Errored while running script in '@opencensus/exporter-stackdriver'
lerna ERR! execute callback with error
lerna ERR! Error: Command failed: npm run test
lerna ERR! npm ERR! code ELIFECYCLE
lerna ERR! npm ERR! errno 3
lerna ERR! npm ERR! @opencensus/[email protected] test: `nyc -x '**/test/**' --reporter=html --reporter=text mocha 'build/test/**/*.js'`
lerna ERR! npm ERR! Exit status 3
lerna ERR! npm ERR!
lerna ERR! npm ERR! Failed at the @opencensus/[email protected] test script.
lerna ERR! npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
lerna ERR!
lerna ERR! npm ERR! A complete log of this run can be found in:
lerna ERR! npm ERR!     /Users/ofrobots/.npm/_logs/2018-06-12T03_47_42_203Z-debug.log
lerna ERR!
lerna ERR! > @opencensus/[email protected] pretest /Users/ofrobots/src/opencensus/opencensus-node/packages/opencensus-exporter-stackdriver
lerna ERR! > npm run compile; cp -r ./test/fixtures ./build/test/
lerna ERR!
lerna ERR!
lerna ERR! > @opencensus/[email protected] compile /Users/ofrobots/src/opencensus/opencensus-node/packages/opencensus-exporter-stackdriver
lerna ERR! > tsc -p .
lerna ERR!
lerna ERR!
lerna ERR! > @opencensus/[email protected] test /Users/ofrobots/src/opencensus/opencensus-node/packages/opencensus-exporter-stackdriver
lerna ERR! > nyc -x '**/test/**' --reporter=html --reporter=text mocha 'build/test/**/*.js'
...
...
...

I have some code that looks like this:

app.get('/', async(req, res) => {

  const childSpan = tracing.tracer.startChildSpan({name: 'test child span'});
  childSpan.end();

  await request({url: upstream_uri});

  res.end('done');

})

When I use the default console.log exporter, I get the following output:

opencensus-test-1-v1 listening on port 3000!
RootSpan: {traceId: 38f127856e05411980d7dc0286790a90, spanId: 196971686205996, name: / }
        ChildSpans:
                {spanId: 28067301146857, name: [object Object]}
                {spanId: 125660749885830, name: GET undefined}

However when I use the Jaeger exporter, I get the following error:

[debug] "2018-08-23T00:20:59.963Z"  'onEndSpan: adding rootSpan: /'
[debug] "2018-08-23T00:20:59.965Z"  'successful append for : 0'
[debug] "2018-08-23T00:20:59.965Z"  'JeagerExporter: set timeout'
[debug] "2018-08-23T00:20:59.966Z"  'adding to buffer /'
[error] "2018-08-23T00:20:59.967Z"  'failed to add span: error converting span to Thrift: BufrwInvalidArgumentError: invalid argument, expected string, null, or undefined'
[debug] "2018-08-23T00:20:59.968Z"  'successful append for : 0'
[debug] "2018-08-23T00:20:59.968Z"  'adding to buffer GET undefined'
[debug] "2018-08-23T00:20:59.974Z"  'successful flush for : 2'

The key error is:

[error] "2018-08-23T00:20:59.967Z"  'failed to add span: error converting span to Thrift: BufrwInvalidArgumentError: invalid argument, expected string, null, or undefined'

I don't understand why in the console.log output, it is giving name: [object Object]. I feel this is what is causing the span to fail when converting to Thrift and causing Jaeger to fail.

What is wrong with my child span that is causing this?

After finishing #38, Please use that util to replace gke_container with k8s_container in Stackdriver exporter with new resource labels.

More Info:
The names of the monitored resource types used by Kubernetes have changed. Link: https://cloud.google.com/monitoring/kubernetes-engine/migration#resource_type_changes

Current (old) release type: gke_container, Beta (new) release type: k8s_container

Resource label changes: The labels in the new monitored resource types are slightly different from the labels used in the current support. Examples: namespace_id -> namespace_name, pod_id -> pod_name and zone -> location.

Counterpart in java: census-instrumentation/opencensus-java#1467

Creating a Probability Sampler does not respect the configured probability. It is always choosing to sample the trace (returning true).

Easy to reproduce:

const tracing = require("@opencensus/nodejs");
tracing.start({
  logLevel: 4,
  samplingRate: 0.000001
});

tracing.tracer.startRootSpan({}, () => {});
tracing.tracer.startRootSpan({}, () => {});
tracing.tracer.startRootSpan({}, () => {});
tracing.tracer.startRootSpan({}, () => {});
tracing.tracer.startRootSpan({}, () => {});

Notice in the logging output that the rootSpan is created for every attempt, which shouldn't happen for such a low probability.

I think the issue is that the sampler is using the Number.MAX_VALUE (1024-bits), which is far too large a number to be using to compare to 16 character hex string (64-bits). This is creating an "upper bound" that is very high and all traceIds meet the threshold.

👋

I'm exploring integrating a Node.js server with the packages here. Looks like the @opencensus/exporter-zpages has been published to npm without templates:

$ cat node_modules/@opencensus/exporter-zpages/package.json| jq .version                                                                               
"0.0.2"
$ tree node_modules/@opencensus/exporter-zpages
├── LICENSE
├── README.md
├── build
│   └── src
│       ├── index.d.ts
│       ├── index.js
│       ├── zpages-frontend
│       │   ├── controllers
│       │   │   ├── traceconfigz.controller.d.ts
│       │   │   ├── traceconfigz.controller.js
│       │   │   ├── tracez.controller.d.ts
│       │   │   └── tracez.controller.js
│       │   ├── latency-bucket-boundaries.d.ts
│       │   ├── latency-bucket-boundaries.js
│       │   ├── page-handlers
│       │   │   ├── traceconfigz.page-handler.d.ts
│       │   │   ├── traceconfigz.page-handler.js
│       │   │   ├── tracez.page-handler.d.ts
│       │   │   └── tracez.page-handler.js
│       │   ├── routes.d.ts
│       │   └── routes.js
│       ├── zpages.d.ts
│       └── zpages.js
└── package.json

5 directories, 19 files

Perhaps a new version could be published?

Add a way to override metric name prefix. Today, OpenCensus only supports "custom.googleapis.com" (

Counterpart in Java: https://github.com/census-instrumentation/opencensus-java/blob/master/exporters/stats/stackdriver/src/main/java/io/opencensus/exporter/stats/stackdriver/StackdriverExporterWorker.java#L250

Equivalent to census-instrumentation/opencensus-java#1057..

The Stackdriver Exporter package's tsconfig.json is missing this line:

"extends": "./node_modules/gts/tsconfig-google.json"

After adding it, there appears to be a number of compilation errors. We should fix this before the first release.

Currently it seems like opencensus-core doesn't support Node 6 because of its reliance on async_hooks. We should fix this so #6 can land (and we cover our supported versions).

The OC-Agent Node exporter should:

1. Act as a client of the Trace RPC service of OC-Agent;
2. Grab current Spans from OpenCensus-Node library, transform them to Span proto, and apply the incoming Config from Agent.

For reference, please see OC-Agent Go Exporter and OC-Agent Python Exporter.

/cc @justindsmith

See the original discussion on #165 (comment).

We should replace all unsupported characters (e.g '/') with '_' for Prometheus metric names. Example in Go: https://github.com/census-instrumentation/opencensus-go/blob/master/internal/sanitize.go. Java: https://github.com/prometheus/client_java/blob/master/simpleclient/src/main/java/io/prometheus/client/Collector.java#L186-L196.

https://github.com/census-instrumentation/opencensus-node/blob/master/packages/opencensus-exporter-prometheus/README.md.

Example of implementation in python https://github.com/census-instrumentation/opencensus-python/blob/master/opencensus/trace/exporters/stackdriver_exporter.py

If a new root span is created by startRootSpan, but the decision is made not to sample it, the rootSpan is not passed on (instead null is passed). This results in the propagation code attempting to dereference null to read a spanContext (propagating an unsampled span context is valid behaviour I believe, so that the no-sample decision is passed on).

see:
opencensus-core/src/trace/model/tracer.ts:132
and:
instrumentation-http/build/src/http.js:186

The instrumentation handler should probably be more cautious, but the root span creation should also be passing on the new span.

On a fresh clone, running npm install exits with an error

lerna ERR! execute Error occured with '@opencensus/exporter-zpages' while running 'npm run prepare'
{ Error: Command failed: npm run prepare
npm ERR! missing script: compile;
...}

Trying to test @opencensus/exporter-jaeger but it doesn't seem to appear in npm at present. Is that on purpose?

I am using B3 header propagation to trace our Micro Services (more than 150 microservices). It is working out of the box. I am pushing the logs to Jaeger and also to ElasticSearch for further analysis.

I have another scenario where I have to propagate an additional header, "x-web-page-id", to all the upstream services.

The rationale behind this is, when loading a web page, it can make multiple AJAX calls. At the moment, each request gets its own trace id. So, I am not able to group them together. If I can pass another header, "x-web-page-id", then I can find all the upstream requests triggered by that web page.

The other use case is, we are planning to use Istio. It requires all the services to propagate its header (x-request-id).

Could you please provide support for custom headers, that can be included along with Trace/Span Ids?

Without this feature, we have to update all the services to propagate these headers, which is sort of rewriting this module for our needs.

https://github.com/w3c/distributed-tracing

Hi there,

I'm brand new to both OpenCensus and TypeScript so apologies ahead of time if there's something I'm misunderstanding.

After npm i-ing @opencensus/core (which resolved to 0.0.4), I encountered an issue where the enum-s in build/src/stats/types.d.ts aren't represented in build/src/stats/types.js which lead to runtime errors like

Cannot read property 'KBYTE' of undefined

I pulled the opencensus-node project, and executed npm run compile, and the resulting types.js included code for those enum-s.

My initial thought is that @opencensus/core simply needs a new version published after a successful build. So, I wanted to submit an issue for discussion on this.

Repro

• Wire up tracing per below code snippet
• Start application & make a request

Expected

traces show up in stackdriver

Actual

no traces show up in stackdriver and the application crashes w/ the error snippet below a minute or so after receiving a few requests

of note, if I remove propagation traces DO show up in stackdriver so it's something related to the use of @opencensus/propagation-stackdriver

code snippet

const tracing = require('@opencensus/nodejs')
const stackdriverKeyFile = require('/stackdriverKeyFile.json')
const propagation = require('@opencensus/propagation-stackdriver')
const exporter = require('@opencensus/exporter-stackdriver')

tracing.start({
  exporter: new exporter.StackdriverTraceExporter({
    projectId: stackdriverKeyFile.project_id
  }),
  logLevel: 4,
  propagation: propagation.v1
})

error snippet

Error: socket hang up
    at createHangUpError (_http_client.js:335:15)
    at TLSSocket.socketOnEnd (_http_client.js:428:23)
    at TLSSocket.emit (events.js:185:15)
    at endReadableNT (_stream_readable.js:1101:12)
    at process._tickCallback (internal/process/next_tick.js:114:19)
Emitted 'error' event at:
    at TLSSocket.socketOnEnd (_http_client.js:428:9)
    at TLSSocket.emit (events.js:185:15)
    at endReadableNT (_stream_readable.js:1101:12)
    at process._tickCallback (internal/process/next_tick.js:114:19)

Hi guys, Is there any plan for adding Prometheus exporter, just like the opencensus-go does?

The opencensus-proto repository holds the canonical reference proto files for types as well as services. We are beginning to have a need to use those protos to communicate with the OCAgent (#124, #128) and need to use those protos to communicate.

There is some work in #128 to move the proto files into the opencensus-node repo (with associated types), but that work should:

1. Live in the opencensus-proto repo to be closer to the source
2. Should be auto-generated instead of manually typed.

Using those generated types where appropriate internally will lead to easier integration with the broader set of OC implementations down the line.

/cc @songy23

After finishing #38, please use that util to get the monitored resource for Stackdriver Trace exporter, and add the resource labels to the uploaded Spans as Attribute. The format of attribute key is g.co/r/<resource_type>/<label>, for example g.co/r/aws_ec2_instance/aws_account.

Counterpart in Java: census-instrumentation/opencensus-java#1243.

Hey im getting the above error seems super weird.
`
import * as tracing from '@opencensus/nodejs';
import { StackdriverTraceExporter } from '@opencensus/exporter-stackdriver';
import * as propagation from '@opencensus/propagation-stackdriver';
//...
export const exporter = new StackdriverTraceExporter({
projectId: GOOGLE_PROJECT_ID
});

tracing.start({
exporter,
logLevel: 4,
propagation: propagation.v1,
// always sample traces, because sampling rate is > 1.0
samplingRate: 1,
});
`

Currently, there is no way to create nested spans:

Root Span
      Child Span
             Grandchild Span

In the type definition, startChildSpan has the following signature:

startChildSpan(name?: string, type?: string, parentSpanId?: string): Span;

However, if you look at the actual function implementation:

/**
   * Starts a span.
   * @param name The span name.
   * @param type The span type.
   * @param parentSpanId The parent span ID.
   */
  startChildSpan(name?: string, type?: string): types.Span {
    let newSpan: types.Span = null;
    if (!this.currentRootSpan) {
      this.logger.debug(
          'no current trace found - must start a new root span first');
    } else {
      newSpan = this.currentRootSpan.startChildSpan(name, type);
    }
    return newSpan;
  }

Even though the @param parentSpanId is present in the JavaDoc tags, it isn't actually used in the actual function!

This means that the parentSpanId is always set to the rootSpanId, which means nesting spans is impossible.

The simple workaround is to just override the parentSpanId attribute of the grandchild span to the child span id. I've tested this and it seems to work fine.

i.e:

const childSpan = tracing.tracer.startChildSpan('Child Span')

const grandChildSpan = tracing.tracer.startChildSpan('Child Span')
grandChildSpan.parentSpanId = childSpan.id

I think the the code above could be fixed with the following:

/**
   * Starts a span.
   * @param name The span name.
   * @param type The span type.
   * @param parentSpanId The parent span ID.
   */
  startChildSpan(name?: string, type?: string, parentSpanId?: string): types.Span {
    let newSpan: types.Span = null;
    if (!this.currentRootSpan) {
      this.logger.debug(
          'no current trace found - must start a new root span first');
    } else {
      newSpan = this.currentRootSpan.startChildSpan(name, type);
    }
    if (parentSpanId) {
      newSpan.parentSpanId = parentSpanId;
    }
    return newSpan;
  }

On another note, there really should be the option of passing in an object to the createChildSpan function instead of three arguments.

Some dependencies are currently fixed:

• @types/node
• grpc

The current plugin implementation might not correctly unpatch all versions of the same module. Though this is a rare case (it involves a combination of wanting to unpatch, and also having multiple versions of the same module), we should fix this for correctness' sake.

See #153 (comment).

Hi all,

I believe there was an intention to release v0.0.5 (#118), however v0.0.4 is still the latest.

I apologize if I misunderstood and this issue is in error. Thanks!

Let's make sure our dependencies are up to date.

I'm playing with this library and see how the correlation context is propagated through http request.
Here is the snippet

const tracing = require('@opencensus/nodejs');
const ConsoleExporter = require('@opencensus/core');
const propagation = require('@opencensus/propagation-tracecontext');

const traceContext = new propagation.TraceContextFormat();

const tracer = tracing.start({propagation: traceContext}).tracer;
const exporter = new ConsoleExporter.ConsoleExporter({
    bufferSize: 1,
    bufferTimeout: 1,
    logger: console
});
tracing.registerExporter(exporter);

const http = require('http');

http.get('http://www.google.com', (resp) => {
    let data = '';
    resp.on('data', (chunk) => {
        data += chunk;
    });

    resp.on('end', () => {
        console.log(`Response end, data length is ${data.length}`);
    });
}).on("error", (err) => {
    console.log("Error: " + err.message);
});

const stdin = process.openStdin();
stdin.addListener("data", () => {});

If I don't add the propagation context, the http instrumentation would successfully create a span for the outgoing request. But if I add the propagation context, it gives me this error. Did I missed anything?

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at ClientRequest.setHeader (_http_outgoing.js:469:11)
    at Object.setHeader (D:\OpenCensus\node\node_modules\@opencensus\instrumentation-http\build\src\http.js:182:29)
    at TraceContextFormat.inject (D:\OpenCensus\node\node_modules\@opencensus\propagation-tracecontext\build\src\tracecontext-format.js:109:20)
    at D:\OpenCensus\node\node_modules\@opencensus\instrumentation-http\build\src\http.js:187:29
    at contextManager.runAndReturn (D:\OpenCensus\node\node_modules\@opencensus\core\build\src\trace\model\tracer.js:111:20)
    at AsyncHooksNamespace.runAndReturn (D:\OpenCensus\node\node_modules\@opencensus\core\build\src\internal\cls-ah.js:51:21)
    at CoreTracer.startRootSpan (D:\OpenCensus\node\node_modules\@opencensus\core\build\src\trace\model\tracer.js:84:36)
    at Object.outgoingRequest [as get] (D:\OpenCensus\node\node_modules\@opencensus\instrumentation-http\build\src\http.js:159:42)
    at Object.<anonymous> (D:\OpenCensus\node\test.js:17:6)
    at Module._compile (internal/modules/cjs/loader.js:689:30)

Add utils to automatically detect monitored resources based the environment that the application is running in, according to OpenCensus MonitoredResource specs. This util should be independent of specific exporters, since it's supposed to be share between Stackdriver Stats exporter and Stackdriver Trace exporter.

Counterpart in Java: https://github.com/census-instrumentation/opencensus-java/tree/master/contrib/monitored_resource_util.

LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT, SED DO EIUSMOD TEMPOR
/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/node_modules/prom-client/lib/counter.js:62
throw new Error('Invalid metric name');
^

Error: Invalid metric name
at new Counter (/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/node_modules/prom-client/lib/counter.js:62:10)
at PrometheusStatsExporter.registerMetric (/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/node_modules/@opencensus/exporter-prometheus/build/src/prometheus-stats.js:74:26)
at PrometheusStatsExporter.updateMetric (/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/node_modules/@opencensus/exporter-prometheus/build/src/prometheus-stats.js:102:29)
at PrometheusStatsExporter.onRecord (/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/node_modules/@opencensus/exporter-prometheus/build/src/prometheus-stats.js:49:18)
at Stats.record (/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/node_modules/@opencensus/core/build/src/stats/stats.js:107:26)
at Interface. (/Users/prakritibansal/Desktop/Fifth Semester/OpenCensus/node-app-2/repl.js:77:9)
at emitOne (events.js:116:13)
at Interface.emit (events.js:211:7)
at Interface._onLine (readline.js:280:10)
at Interface._normalWrite (readline.js:422:12)

Looking into the package.json for opencensus-core, it seems the package name is: @opencensus/opencensus-core. Why not @opencensus/core? I want to make sure this is a conscious decision and the pros/cons are documented somewhere.

Requires othiym23/async-listener@e0c269a .

process.hostname and process.ip are not being set in the final spans. I suspect this is true for any other tags passed in to the constructor.

Negative values are currently not supported by any of the backends that we support and have histograms (Stackdriver and Prometheus). We have decided to implement a backwards incompatible change and drop negative values in the Record API (We will start with logging an error for few versions then throw an exception).

This could be a breaking change if users are recording negative value for any measure. We planned to implement this change asap in all the libraries and explain this behaviour to the current users very clearly.

Counterpart in Java: census-instrumentation/opencensus-java#1499 and census-instrumentation/opencensus-java#1525

Example https://opencensus.io/guides/exporters/supported-exporters/node.js/stackdriver-trace/
Raises the error:
if (this.configLocal.exporter) { ^ TypeError: Cannot read property 'exporter' of null at Tracing.registerExporter (/usr/local/google/home/isaikevych/g/opencensus-node/packages/opencensus-nodejs/build/src/trace/tracing.js:89:34)

#150 (comment)
"""One high-level comment: I think a better way may be:
For every onRecord, still generate timeSeries synchronously.
Buffer the timeSeries in an array and export them to backend every 1 minute (or other configured delay) asynchronously.
Export should go in parallel with onRecord, i.e shouldn't block each other.
This is what we did in other languages. What do you think?"""

After updating to 0.0.5 I am getting this error when trying to sendTraces:

[error] 2018-10-24T09:24:58.218Z sendTrace error: Invalid value at 'traces.traces[0].spans[0].span_id' (TYPE_FIXED64), "125aee19018a78dd"

It seems that the type of the spanId is invalid. I believe the issue is because the spanId is a hex string instead of a int64 string.

I think this error is caused by this update #126.

Hi, I am trying to collect metrics using the Prometheus exporter and get the following error when creating a new measure:

const mLatencyMs = stats.createMeasureDouble("repl/latency", MeasureUnit.MS, "The latency in milliseconds per REPL loop");
                                                                         ^

TypeError: Cannot read property 'MS' of undefined
    at Object.<anonymous> (/Users/prakritibansal/Desktop/node-app/repl.js:18:74)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3

MeasureUnit is undefined, even though I have imported it.
const { Stats, AggregationType, MeasureUnit } = require('@opencensus/core');

Full code is available here.
Thank for any help! @odeke-em

Add Metrics package and below classes based on metrics.proto. Although Metrics proto is still being finalized, We think it is safe to start working on value classes like LabelKey, TimeSeries, Point etc.

• Metrics: Add LabelKey and LabelValue.
• Metrics: Add Value and Point.
• Metrics: Add TimeSeries.
• Metrics: Add MetricDescriptor.
• Metrics: Add Metric.
• Metrics: Add Summary and Distribution.
• Metrics: Produce and store Metrics in Stats impl.

Counterpart classes available in Java for reference : https://github.com/census-instrumentation/opencensus-java/tree/master/api/src/main/java/io/opencensus/metrics

Hi all,

I am writing a tutorial on instrumenting a Node gRPC server with @opencensus-node/instrumentation-grpc, and unfortunately none of the application files are included in the NPM package.

Thank you for the work on the Node.js implementation!

I just noticed a weird discrepancy in the NPM package names.

For tracing, we need:

var tracing = require('@opencensus/nodejs');

For stats, we need:

var opencensus = require('@opencensus/core');
var stats = new opencensus.Stats();

What's the rhyme and reason behind the Node.js package names? nodejs as a suffix doesn't strike me as related to tracing, neither does core relate to stats. I ask because currently on the website we've got https://opencensus.io/guides/exporters/supported-exporters/node.js/ and I plan on writing many guides as well as actual framework and package integrations but would just like to get some clarity before embarking on that quest.

Hi all,

Thanks for providing such an amazing library.

I noticed that the Stackdriver tracing exporter on Github translates a span's attributes, but the version on NPM does not.

When will the latest version on Github be published to NPM?

I wrote a quickstart tutorial using the stackdriver tracing exporter and included the usage of attributes. I made a note that it is not currently found in the NPM module. [PR for tutorial] [image]

Cheers,
Henry

I've had success getting Stackdriver tracing to work with Go, but with NodeJS/Typescript it's not creating any http/https trace events for me. I'm using ExpressJS, but figured it would work with the http/https plugins. Tried to enable all debug logging, but am only getting 1 log entry on startup. Here's the code I'm using to bootstrap stuff (just trying everything at this point):

import { StackdriverTraceExporter } from '@opencensus/exporter-stackdriver';
import * as tracing from '@opencensus/nodejs';
import { logger } from '@opencensus/opencensus-core';
import * as propagation from '@opencensus/propagation-stackdriver';

const opencensusLogger = new logger.ConsoleLogger({ level: 'debug' });
export const exporter = new StackdriverTraceExporter({
  logger: opencensusLogger,
  projectId: GOOGLE_PROJECT_ID,
});

  tracing.start({
    exporter,
    logLevel: 4,
    logger: opencensusLogger,
    plugins: {
      http: '@opencensus/opencensus-instrumentation-http',
      https: '@opencensus/opencensus-instrumentation-https',
    },
    propagation: propagation.v1,
    // always sample traces, because sampling rate is > 1.0
    samplingRate: Number.MAX_VALUE,
  });

This is all I see in the logs, and nothing else gets logged on HTTP requests:

[debug] "2018-06-22T14:56:55.988Z"  'config: { logLevel: 4,\n  maximumLabelValueSize: 150,\n  plugins:\n   { http: \'@opencensus/opencensus-instrumentation-http\',\n     https: \'@opencensus/opencensus-instrumentation-https\' },\n  bufferSize: 100,\n  bufferTimeout: 20000,\n  samplingRate: 1.7976931348623157e+308,\n  exporter:\n   StackdriverTraceExporter {\n     failBuffer: [ [length]: 0 ],\n     projectId: \'fr-travis-test\',\n     logger:\n      ConsoleLogger {\n        level: \'debug\',\n        logger:\n         LogDriver {\n           levels:\n            [ \'silent\', \'error\', \'warn\', \'info\', \'debug\', \'silly\', [length]: 6 ],\n           level: \'debug\',\n           silent:\n            { [Function]\n              [length]: 0,\n              [name]: \'\',\n              [arguments]: null,\n              [caller]: null,\n              [prototype]: [Object] },\n           error:\n            { [Function]\n              [length]: 0,\n              [name]: \'\',\n              [arguments]: null,\n              [caller]: null,\n              [prototype]: [Object] },\n           warn:\n            { [Function]\n              [length]: 0,\n              [name]: \'\',\n              [arguments]: null,\n              [caller]: null,\n              [prototype]: [Object] },\n           info:\n            { [Function]\n              [length]: 0,\n              [name]: \'\',\n              [arguments]: null,\n              [caller]: null,\n              [prototype]: [Object] },\n           debug:\n            { [Function]\n              [length]: 0,\n              [name]: \'\',\n              [arguments]: null,\n              [caller]: null,\n              [prototype]: [Object] },\n           silly:\n            { [Function]\n              [length]: 0,\n              [name]: \'\',\n              [arguments]: null,\n              [caller]: null,\n              [prototype]: [Object] } } },\n     exporterBuffer:\n      ExporterBuffer {\n        resetTimeout: false,\n        bufferTimeoutInProgress: false,\n        queue: [ [length]: 0 ],\n        exporter: [Circular],\n        logger:\n         ConsoleLogger {\n           level: \'debug\',\n           logger:\n            LogDriver {\n              levels: [Array],\n              level: \'debug\',\n              silent: [Function],\n              error: [Function],\n              warn: [Function],\n              info: [Function],\n              debug: [Function],\n              silly: [Function] } },\n        bufferSize: undefined,\n        bufferTimeout: undefined } },\n  logger:\n   ConsoleLogger {\n     level: \'debug\',\n     logger:\n      LogDriver {\n        levels:\n         [ \'silent\', \'error\', \'warn\', \'info\', \'debug\', \'silly\', [length]: 6 ],\n        level: \'debug\',\n        silent:\n         { [Function]\n           [length]: 0,\n           [name]: \'\',\n           [arguments]: null,\n           [caller]: null,\n           [prototype]: { [constructor]: [Circular] } },\n        error:\n         { [Function]\n           [length]: 0,\n           [name]: \'\',\n           [arguments]: null,\n           [caller]: null,\n           [prototype]: { [constructor]: [Circular] } },\n        warn:\n         { [Function]\n           [length]: 0,\n           [name]: \'\',\n           [arguments]: null,\n           [caller]: null,\n           [prototype]: { [constructor]: [Circular] } },\n        info:\n         { [Function]\n           [length]: 0,\n           [name]: \'\',\n           [arguments]: null,\n           [caller]: null,\n           [prototype]: { [constructor]: [Circular] } },\n        debug:\n         { [Function]\n           [length]: 0,\n           [name]: \'\',\n           [arguments]: null,\n           [caller]: null,\n           [prototype]: { [constructor]: [Circular] } },\n        silly:\n         { [Function]\n           [length]: 0,\n           [name]: \'\',\n           [arguments]: null,\n           [caller]: null,\n           [prototype]: { [constructor]: [Circular] } } } },\n  propagation:\n   { extract:\n      { [Function: extract]\n        [length]: 1,\n        [name]: \'extract\',\n        [prototype]: extract { [constructor]: [Circular] } },\n     inject:\n      { [Function: inject]\n        [length]: 2,\n        [name]: \'inject\',\n        [prototype]: inject { [constructor]: [Circular] } },\n     generate:\n      { [Function: generate]\n        [length]: 0,\n        [name]: \'generate\',\n        [prototype]: generate { [constructor]: [Circular] } } } }'

The Go app where tracing is working is running in the same GKE project.

Per census-instrumentation/opencensus-service#134 we need to validate that exporters all behave consistently. Work is being tracked for each library:

• census-instrumentation/opencensus-java#1408
• census-ecosystem/opencensus-go-exporter-ocagent#18
• census-instrumentation/opencensus-python#333

This issue is to track checking the Node implementation and determining what, if anything, needs to be done.

/cc @songy23