docs: Add ioredis to instrumentation list

[naseemkullah]

Which problem is this PR solving?

• ioredis #535

Short description of the changes

• Mostly copy pasted from opencensus ioredis plugin and opentelemetry redis plugin.

[dyladan]

@naseemkullah I will take a look at this. Typically that particular failure is a sign that the span is not properly created. Often it is because it is not yet ended.

[naseemkullah]

Much appreciated @dyladan

[naseemkullah]

I'm going to take this to Gitter probably, but does one run npm run docs-test locally? I installed yarn and lerna but still get

% npm run docs-test
internal/modules/cjs/loader.js:797
    throw err;
    ^

Error: Cannot find module '../lib/utils/unsupported.js'
Require stack:
- /usr/local/lib/node_modules/npm/bin/npm-cli.js

[dyladan]

@naseemkullah no docs-test is typically only run in CI. It just makes sure there are no broken links before it is published. That said, they should be able to run locally so I'll take a look.

[naseemkullah]

ok thanks. david-dm.org links seems to be down

e.g.:

https://david-dm.org/open-telemetry/opentelemetry-js/dev-status.svg?path=packages/opentelemetry-types
https://david-dm.org/open-telemetry/opentelemetry-js?path=packages%2Fopentelemetry-types&type=dev

[dyladan]

@naseemkullah please try to avoid changing history on branches you've already pushed. it makes tracking changes harder

[naseemkullah]

My apologies @dyladan

[naseemkullah]

@naseemkullah no docs-test is typically only run in CI. It just makes sure there are no broken links before it is published. That said, they should be able to run locally so I'll take a look.

Pleas disregard this. My mistake, it works locally.

[codecov-io]

Codecov Report

Merging #558 into master will decrease coverage by <.01%.
The diff coverage is 94.1%.

@@            Coverage Diff             @@
##           master     #558      +/-   ##
==========================================
- Coverage   91.38%   91.37%   -0.01%     
==========================================
  Files         190      192       +2     
  Lines        9655     9905     +250     
  Branches      879      892      +13     
==========================================
+ Hits         8823     9051     +228     
- Misses        832      854      +22

Impacted Files	Coverage Δ
packages/opentelemetry-plugin-ioredis/src/enums.ts	100% <100%> (ø)
...ckages/opentelemetry-plugin-ioredis/src/ioredis.ts	100% <100%> (ø)
packages/opentelemetry-plugin-ioredis/src/utils.ts	84.21% <84.21%> (ø)
.../opentelemetry-plugin-ioredis/test/ioredis.test.ts	94.63% <94.63%> (ø)
...kages/opentelemetry-plugin-dns/test/utils/utils.ts	33.33% <0%> (-26.67%)	⬇️
...ages/opentelemetry-plugin-http/test/utils/utils.ts	33.33% <0%> (-26.67%)	⬇️
...ges/opentelemetry-tracing/src/NoopSpanProcessor.ts	66.66% <0%> (-8.34%)	⬇️
...entelemetry-exporter-jaeger/test/transform.test.ts	100% <0%> (ø)	⬆️
...opentelemetry-base/test/resources/resource.test.ts	100% <0%> (ø)	⬆️
packages/opentelemetry-tracing/src/config.ts	100% <0%> (ø)	⬆️
... and 21 more

[mayurkale22]

/cc @vmarchaud (who wrote the original module), it would be awesome if you can review this.

[mayurkale22]

I think this is probably good to go. Tracing connections is not all that important and pub/sub is its own can of worms.

At least we should document (README) this behavior/limitations instead of throwing it up in the air. WDYT?

[vmarchaud]

@dyladan I personally prefer having a quite simple first implementation and then iterate on it with feedback from users

[dyladan]

I think this is probably good to go. Tracing connections is not all that important and pub/sub is its own can of worms.

At least we should document (README) this behavior/limitations instead of throwing it up in the air. WDYT?

Didn't mean to sound flippant about it. Definitely limitations should be documented. I just meant that this is to the point where I think it is mergeable and we can iterate on it as we go. The pub/sub thing is a little different since it isn't a typical request/response rpc model so decisions need to be made about how we should trace it in a general case, not just redis.

@naseemkullah if tracing connect is relatively straightforward I would definitely prefer that we did that, but @mayurkale22 is right we should at least document limitations in the README.

[naseemkullah]

@dyladan As it stands, creating a client traces an info command somehow but not a connect command as one would hope. Further more client.quit() is traced as it is a redis command like any other but client.disconnect() is not

opentelemetry-js/packages/opentelemetry-plugin-ioredis/test/ioredis.test.ts

Lines 98 to 115 in b5f616f

	assert.strictEqual(endedSpans.length, 1);
	assert.strictEqual(endedSpans[0].name, `info`);
	assertionUtils.assertPropagation(endedSpans[0], span);
	assertionUtils.assertSpan(
	endedSpans[0],
	SpanKind.CLIENT,
	attributes,
	[],
	okStatus
	);
	span.end();
	assert.strictEqual(endedSpans.length, 2);
	assert.strictEqual(endedSpans[1].name, `test span`);
	client.quit(done);
	assert.strictEqual(endedSpans.length, 3);
	assert.strictEqual(endedSpans[2].name, `quit`);

I will look into getting a proper span for connect !

[naseemkullah]

Tracing connect has been added via 3b47e26

But there is a lot of duplicated code between traceSendCommand and traceConnection that could potentially be refactored.

[dyladan]

I don't see any issue with this minor duplication

[dyladan]

@naseemkullah what currently happens when you call subscribe? Does it create a short span just for the time it takes to set up the subscription? I assume for publish the span works as you would expect.

[OlivierAlbertini]

LGTM

[naseemkullah]

@dyladan pubsub test added, please see it for more info on behaviour 7b3a94e

[naseemkullah]

@mayurkale22 I think this is ready for merging now.