Pull request review commentopen-telemetry/opentelemetry-js-contrib

refactor: standardise implementation of non-official attributes

+/*+ * Copyright The OpenTelemetry Authors+ *+ * Licensed under the Apache License, Version 2.0 (the "License");+ * you may not use this file except in compliance with the License.+ * You may obtain a copy of the License at+ *+ *      https://www.apache.org/licenses/LICENSE-2.0+ *+ * Unless required by applicable law or agreed to in writing, software+ * distributed under the License is distributed on an "AS IS" BASIS,+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.+ * See the License for the specific language governing permissions and+ * limitations under the License.+ */+export enum ExpressLayerType {

I saw you moved this enum but didn't move enum.ts for the graphql, i think this should be consistent too. Is the goal to have all enums in enums/ ?

svrnm

comment created time in an hour

push eventopen-telemetry/opentelemetry-js-contrib

Severin Neumann

commit sha 2e085fbd6b0698dee200436da88a6f2421730019

fix: move faas_id and cloud_account_id to semantic conventions (#481)

view details

push time in an hour

PR merged open-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions internal

Just a minor thing: in the aws-lambda instrumentation two attributes have not been moved to semantic conventions.

+51 -129

3 commit in svrnm/opentelemetry-js-contrib/tree/aws-lambda-fix-attributes open-telemetry/opentelemetry-js-contrib/tree/main

6 comments

20 changed files

svrnm

pr closed time in an hour

issue commentopen-telemetry/opentelemetry-js-api

Errors in global registration are likely to be eaten

It also doesn't work for third parties that want to build in official support. If the mysql driver for example built in support for otel, they wouldn't want to peer depend on the API and cause warnings for their customers that don't use otel.

Rauno56

comment created time in 12 hours

Pull request review commentopen-telemetry/opentelemetry-js-api

feat: add tracer.startActiveSpan()

 export interface Tracer {    *     span.end();    */   startSpan(name: string, options?: SpanOptions, context?: Context): Span;++  /**+   * Starts a new {@link Span} and activates it in the current Context.+   *+   * @param name The name of the span+   * @param [options] SpanOptions used for span creation+   * @param [context] Context to use to extract parent+   * @param fn function called in the context of the span and receives the newly created span as an argument+   * @returns return value of fn+   * @example+   *   const something = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       span.setStatus({code: SpanStatusCode.OK});+   *       return something;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     } finally {+   *       span.end();+   *     }+   *   });+   * @example+   *   const span = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       return span;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     }+   *   });+   *   do some more work+   *   span.end();+   */+  startActiveSpan?<F extends (span: Span) => ReturnType<F>>(

Is it possible to use a base class for Tracer and implement it there once for all? Or should we avoid exposing classes instead interfaces?

naseemkullah

comment created time in 12 hours

Pull request review commentopen-telemetry/opentelemetry-js-api

feat: add tracer.startActiveSpan()

 export interface Tracer {    *     span.end();    */   startSpan(name: string, options?: SpanOptions, context?: Context): Span;++  /**+   * Starts a new {@link Span} and activates it in the current Context.+   *+   * @param name The name of the span+   * @param [options] SpanOptions used for span creation+   * @param [context] Context to use to extract parent+   * @param fn function called in the context of the span and receives the newly created span as an argument+   * @returns return value of fn+   * @example+   *   const something = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       span.setStatus({code: SpanStatusCode.OK});+   *       return something;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     } finally {+   *       span.end();+   *     }+   *   });+   * @example+   *   const span = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       return span;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     }+   *   });+   *   do some more work+   *   span.end();+   */+  startActiveSpan?<F extends (span: Span) => ReturnType<F>>(

Yeah I tend to agree with you. In the end it probably isn't a huge burden to add it to the interface. There won't be that many SDK implementations anyway.

naseemkullah

comment created time in 13 hours

issue commentopen-telemetry/opentelemetry-js-api

Errors in global registration are likely to be eaten

Yes they should surface with npm but some people can still use older npm version so thats not a catch all solution, just hoping it would in the future :)

Rauno56

comment created time in 13 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

feat: enhance RedisInstrumentationConfig (add dbStatementSerializer, responseHook, and requireParentSpan)

Codecov Report

Merging #478 (c762e46) into main (da42d01) will increase coverage by 0.82%. The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #478      +/-   ##
==========================================
+ Coverage   95.23%   96.05%   +0.82%     
==========================================
  Files         130       11     -119     
  Lines        8325      609    -7716     
  Branches      811      109     -702     
==========================================
- Hits         7928      585    -7343     
+ Misses        397       24     -373

Impacted Files	Coverage Δ
...entelemetry-instrumentation-pino/test/pino.test.ts
...e/opentelemetry-instrumentation-redis/src/utils.ts
...ges/opentelemetry-host-metrics/test/metric.test.ts
...ry-instrumentation-dns/src/enums/AttributeNames.ts
...opentelemetry-instrumentation-restify/src/utils.ts
...entelemetry-instrumentation-graphql/test/schema.ts
...metry-propagator-aws-xray/src/AWSXRayPropagator.ts
...opentelemetry-instrumentation-redis/src/version.ts
...de/opentelemetry-instrumentation-net/test/utils.ts
...s/opentelemetry-propagator-ot-trace/src/version.ts
... and 109 more

nozik

comment created time in 13 hours

created taglightstep/lightstep-tracer-javascript

tagv0.31.1

Lightstep distributed tracing library for Node.js and the browser

created time in 13 hours

push eventlightstep/lightstep-tracer-javascript

Matthew Wear

commit sha b738570f522b34216f83556ebd28dcf80356b67c

docs: update changelog for v0.32.0 release

view details

Matthew Wear

commit sha 28ac84820bb27dac1ce900526fd0bb00a7acbc7a

chore: rebuild dist

view details

Matthew Wear

commit sha 1cb546db03d97520102d58512e619cad54b5a5b0

0.31.1

view details

push time in 13 hours

Pull request review commentopen-telemetry/opentelemetry-js-api

feat: add tracer.startActiveSpan()

 export interface Tracer {    *     span.end();    */   startSpan(name: string, options?: SpanOptions, context?: Context): Span;++  /**+   * Starts a new {@link Span} and activates it in the current Context.+   *+   * @param name The name of the span+   * @param [options] SpanOptions used for span creation+   * @param [context] Context to use to extract parent+   * @param fn function called in the context of the span and receives the newly created span as an argument+   * @returns return value of fn+   * @example+   *   const something = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       span.setStatus({code: SpanStatusCode.OK});+   *       return something;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     } finally {+   *       span.end();+   *     }+   *   });+   * @example+   *   const span = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       return span;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     }+   *   });+   *   do some more work+   *   span.end();+   */+  startActiveSpan?<F extends (span: Span) => ReturnType<F>>(

I dont think having a function that requires a tracer would achieve the desired goal of simplicity IMO

naseemkullah

comment created time in 13 hours

Pull request review commentopen-telemetry/opentelemetry-js-api

feat: add tracer.startActiveSpan()

 export interface Tracer {    *     span.end();    */   startSpan(name: string, options?: SpanOptions, context?: Context): Span;++  /**+   * Starts a new {@link Span} and activates it in the current Context.+   *+   * @param name The name of the span+   * @param [options] SpanOptions used for span creation+   * @param [context] Context to use to extract parent+   * @param fn function called in the context of the span and receives the newly created span as an argument+   * @returns return value of fn+   * @example+   *   const something = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       span.setStatus({code: SpanStatusCode.OK});+   *       return something;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     } finally {+   *       span.end();+   *     }+   *   });+   * @example+   *   const span = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       return span;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     }+   *   });+   *   do some more work+   *   span.end();+   */+  startActiveSpan?<F extends (span: Span) => ReturnType<F>>(

Why? It's only needed to add the tracer to use as argument. Creating a tracer would require a tracer name + version.

naseemkullah

comment created time in 15 hours

Pull request review commentopen-telemetry/opentelemetry-js-api

feat: add tracer.startActiveSpan()

 export interface Tracer {    *     span.end();    */   startSpan(name: string, options?: SpanOptions, context?: Context): Span;++  /**+   * Starts a new {@link Span} and activates it in the current Context.+   *+   * @param name The name of the span+   * @param [options] SpanOptions used for span creation+   * @param [context] Context to use to extract parent+   * @param fn function called in the context of the span and receives the newly created span as an argument+   * @returns return value of fn+   * @example+   *   const something = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       span.setStatus({code: SpanStatusCode.OK});+   *       return something;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     } finally {+   *       span.end();+   *     }+   *   });+   * @example+   *   const span = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       return span;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     }+   *   });+   *   do some more work+   *   span.end();+   */+  startActiveSpan?<F extends (span: Span) => ReturnType<F>>(

That is not the experience I imagined. I was thinking api.trace.startActiveSpan

I would like this API too but it requires creating a tracer from the global tracer provider for every call (its totally doable though)

naseemkullah

comment created time in 17 hours

PR opened open-telemetry/opentelemetry-js-api

feat: debug log global registrations and logger overwrites

Currently, there's no visibility to global registration which is a relatively important operation. For example, there's no way to know if a logger has been overwritten or not which might mean the successive log messages/errors from other parts of the API might not be appearing without the developer's knowledge.

It relieves the immediate pain described in https://github.com/open-telemetry/opentelemetry-js-api/issues/56

+18 -8

1 commit in Rauno56/opentelemetry-js-api/tree/feat/add-global-debugging open-telemetry/opentelemetry-js-api/tree/main

0 comment

2 changed files

pr created time in 17 hours

Pull request review commentopen-telemetry/opentelemetry-js-api

feat: add tracer.startActiveSpan()

 export interface Tracer {    *     span.end();    */   startSpan(name: string, options?: SpanOptions, context?: Context): Span;++  /**+   * Starts a new {@link Span} and activates it in the current Context.+   *+   * @param name The name of the span+   * @param [options] SpanOptions used for span creation+   * @param [context] Context to use to extract parent+   * @param fn function called in the context of the span and receives the newly created span as an argument+   * @returns return value of fn+   * @example+   *   const something = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       span.setStatus({code: SpanStatusCode.OK});+   *       return something;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     } finally {+   *       span.end();+   *     }+   *   });+   * @example+   *   const span = tracer.startActiveSpan('op', span => {+   *     try {+   *       do some work+   *       return span;+   *     } catch (err) {+   *       span.setStatus({+   *         code: SpanStatusCode.ERROR,+   *         message: err.message,+   *       });+   *       throw err;+   *     }+   *   });+   *   do some more work+   *   span.end();+   */+  startActiveSpan?<F extends (span: Span) => ReturnType<F>>(

That is not the experience I imagined. I was thinking api.trace.startActiveSpan

naseemkullah

comment created time in 17 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

it's fine to just check them in here

svrnm

comment created time in 18 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

Ok, after cleaning up a few more things and making sure that (apparently) my repo is up to date, there are still 20 things to fix, so the rules of the linter have changed and those changes have not yet been applied:

https://github.com/svrnm/opentelemetry-js-contrib/commit/e7c9941d2aabe9d02c07fb9edfd3d2564e400cf0

Since this is not scope of this PR, what's best practice, just have it here or open another PR?

svrnm

comment created time in 19 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

@dyladan: I drank some coffee and run that command, thanks for the advice ☕ . Now I have 20 diffs after running npm lint:fix looks like the rules for the linter have changed.

svrnm

comment created time in 19 hours

Pull request review commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

 export class AwsLambdaInstrumentation extends InstrumentationBase {         kind: SpanKind.SERVER,         attributes: {           [SemanticAttributes.FAAS_EXECUTION]: context.awsRequestId,-          'faas.id': context.invokedFunctionArn,-          [CLOUD_RESOURCE.ACCOUNT_ID]: AwsLambdaInstrumentation._extractAccountId(+          [ResourceAttributes.FAAS_ID]: context.invokedFunctionArn,+          [ResourceAttributes.CLOUD_ACCOUNT_ID]: AwsLambdaInstrumentation._extractAccountId(

FWIW this line is the one lint is complaining about most likely (too long)

svrnm

comment created time in 19 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

most likely a version issue. run lerna clean -y && rm -rf node_modules && git clean -fdx && npm i && npm run compile && npm run lint:fix then go make yourself a coffee

svrnm

comment created time in 19 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

Not sure why lint fails. The error and the suggested changes are not applied when I run npm run lint:fix locally and they are also reverted when I apply them manually locally

svrnm

comment created time in 19 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

Codecov Report

Merging #481 (2671116) into main (da42d01) will increase coverage by 2.41%. The diff coverage is n/a.

:exclamation: Current head 2671116 differs from pull request most recent head f79954c. Consider uploading reports for the commit f79954c to get more accurate results

@@            Coverage Diff             @@
##             main     #481      +/-   ##
==========================================
+ Coverage   95.23%   97.64%   +2.41%     
==========================================
  Files         130        8     -122     
  Lines        8325      340    -7985     
  Branches      811       48     -763     
==========================================
- Hits         7928      332    -7596     
+ Misses        397        8     -389

Impacted Files	Coverage Δ
...entelemetry-instrumentation-restify/src/version.ts
.../opentelemetry-instrumentation-graphql/src/enum.ts
...opentelemetry-instrumentation-ioredis/src/utils.ts
...gator-grpc-census-binary/src/BinaryTraceContext.ts
...opentelemetry-instrumentation-mongodb/src/types.ts
...entelemetry-instrumentation-express/src/version.ts
...s/opentelemetry-propagator-aws-xray/src/version.ts
...opentelemetry-instrumentation-graphql/src/types.ts
...metry-instrumentation-mongodb/test/mongodb.test.ts
...ation-user-interaction/src/enums/AttributeNames.ts
... and 112 more

svrnm

comment created time in 19 hours

PR opened open-telemetry/opentelemetry-js-contrib

fix: move faas_id and cloud_account_id to semantic conventions

Just a minor thing: in the aws-lambda instrumentation two attributes have not been moved to semantic conventions.

+6 -4

1 commit in svrnm/opentelemetry-js-contrib/tree/aws-lambda-fix-attributes open-telemetry/opentelemetry-js-contrib/tree/main

0 comment

1 changed file

pr created time in 19 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

refactor: standardise implementation of non-official attributes

Codecov Report

Merging #480 (f3e5471) into main (da42d01) will increase coverage by 0.40%. The diff coverage is 100.00%.

:exclamation: Current head f3e5471 differs from pull request most recent head 36d7fcd. Consider uploading reports for the commit 36d7fcd to get more accurate results

@@            Coverage Diff             @@
##             main     #480      +/-   ##
==========================================
+ Coverage   95.23%   95.63%   +0.40%     
==========================================
  Files         130       69      -61     
  Lines        8325     3967    -4358     
  Branches      811      317     -494     
==========================================
- Hits         7928     3794    -4134     
+ Misses        397      173     -224

Impacted Files	Coverage Δ
.../opentelemetry-instrumentation-graphql/src/enum.ts	`100.00% <ø> (ø)`
...nstrumentation-graphql/src/enums/AttributeNames.ts	`100.00% <100.00%> (ø)`
...entelemetry-instrumentation-graphql/src/graphql.ts	`92.30% <100.00%> (+0.05%)`	:arrow_up:
...opentelemetry-instrumentation-graphql/src/utils.ts	`95.26% <100.00%> (+0.02%)`	:arrow_up:
...metry-instrumentation-graphql/test/graphql.test.ts	`100.00% <100.00%> (ø)`
...entelemetry-instrumentation-graphql/test/helper.ts	`100.00% <100.00%> (ø)`
...de/opentelemetry-instrumentation-hapi/src/types.ts	`100.00% <0.00%> (ø)`
...de/opentelemetry-instrumentation-hapi/src/utils.ts	`100.00% <0.00%> (ø)`
...opentelemetry-instrumentation-express/src/types.ts	`100.00% <0.00%> (ø)`
...entelemetry-instrumentation-hapi/test/hapi.test.ts	`100.00% <0.00%> (ø)`
... and 79 more

svrnm

comment created time in 20 hours

PR opened open-telemetry/opentelemetry-js-contrib

refactor: standardise implementation of non-official attributes

This is a companion PR to https://github.com/open-telemetry/opentelemetry-js/pull/2200

+260 -163

2 commit in svrnm/opentelemetry-js-contrib/tree/standardise-non-official-attributes open-telemetry/opentelemetry-js-contrib/tree/main

0 comment

37 changed files

pr created time in 20 hours

issue commentopen-telemetry/opentelemetry-js-api

Errors in global registration are likely to be eaten

So the thinking is, that:

OTel published packages only list the API under peerDependencies;
conflicts in API versions would be surfaced during the time of npm install?

That is a better way to handle it, I think. But it makes the implementation that takes into account and tries to juggle two different versions of the API even more conflicting. :thinking:

Rauno56

comment created time in 21 hours

Pull request review commentopen-telemetry/opentelemetry-js-contrib

chore: generalize the instrumentation file name

     "@opentelemetry/tracing": "0.19.0",     "@types/mocha": "7.0.2",     "@types/node": "14.14.44",+    "@types/restify": "^4.3.7",

Thanks! Put it back.

Rauno56

comment created time in 21 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

feat: router instrumentation

Interesting that the lint fails on a file that no longer exists.

Rauno56

comment created time in 21 hours

pull request commentopen-telemetry/opentelemetry-js-contrib

chore: generalize the instrumentation file name

Codecov Report

Merging #479 (5877e07) into main (da42d01) will increase coverage by 0.82%. The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #479      +/-   ##
==========================================
+ Coverage   95.23%   96.05%   +0.82%     
==========================================
  Files         130       11     -119     
  Lines        8325      609    -7716     
  Branches      811      109     -702     
==========================================
- Hits         7928      585    -7343     
+ Misses        397       24     -373

Impacted Files	Coverage Δ
...e/opentelemetry-instrumentation-koa/src/version.ts
...de/opentelemetry-instrumentation-hapi/src/utils.ts
...de/opentelemetry-instrumentation-net/test/utils.ts
...emetry-id-generator-aws-xray/src/platform/index.ts
...opentelemetry-instrumentation-redis/src/version.ts
...etry-instrumentation-hapi/test/hapi-plugin.test.ts
node/opentelemetry-instrumentation-dns/src/dns.ts
packages/opentelemetry-host-metrics/src/metric.ts
...umentation-user-interaction/src/userInteraction.ts
...entelemetry-instrumentation-ioredis/src/ioredis.ts
... and 110 more

Rauno56

comment created time in 21 hours

Pull request review commentopen-telemetry/opentelemetry-js-contrib

chore: generalize the instrumentation file name

     "@opentelemetry/tracing": "0.19.0",     "@types/mocha": "7.0.2",     "@types/node": "14.14.44",+    "@types/restify": "^4.3.7",

I think this reverts a part of #468

Rauno56

comment created time in 21 hours