-
Notifications
You must be signed in to change notification settings - Fork 803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(plugin): add grpc plugin #215
feat(plugin): add grpc plugin #215
Conversation
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.
Look good. Added few comments. methods and properties (private and protected) should be prefixed with "_"
|
||
export class GrpcPlugin extends BasePlugin<grpc> { | ||
static readonly component = 'grpc'; | ||
static readonly ATTRIBUTE_GRPC_KIND = 'grpc.kind'; // SERVER or CLIENT |
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 move to AttributeNames, WDYT?
// TODO: Delete if moving internal file loaders to BasePlugin | ||
// --- Note: Incorrectly ordered: Begin internal file loader --- // | ||
// tslint:disable-next-line:no-any | ||
protected internalFilesExports: { [key: string]: any }; |
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 be prefixed by _
// TODO: Remove this once issue is resolved | ||
// https://github.com/open-telemetry/opentelemetry-js/issues/193 | ||
this._logger = new NoopLogger(); | ||
this.internalFilesExports = this.loadInternalFiles(); |
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 can be removed pending discussion #216
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 is a great start :) Added a few comments, during initial glance. Will add more once ready for review.
@@ -247,29 +237,23 @@ export class GrpcPlugin extends BasePlugin<grpc> { | |||
const self = this; | |||
|
|||
const spanName = `grpc.${name.replace('/', '')}`; | |||
const parentSpan = plugin._getSpanContext(call.metadata); |
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.
Is this calling a private function on the plugin? If so, why does it need to do that?
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.
It only needs it because it needs the binary format parser which is a member of this._tracer
. I suppose it could be made a helper function similar to your other proposal, but a tracer (or the binary format parser directly) would need to be passed in instead. What do you think?
* Convert a grpc status code to an opentelemetry Canonical code. For now, the enums are exactly the same | ||
* @param status | ||
*/ | ||
private static _grpcStatusCodeToCanonicalCode( |
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.
Rather than making this private static
, what would you think about just having it be a non-exported function
in the file? I personally find that cleaner for helper functions than attaching them to a class
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.
+1
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 have an existing utils.ts
already. Maybe I can just move them inside there?
@@ -6,7 +6,7 @@ | |||
"types": "build/src/index.d.ts", | |||
"repository": "open-telemetry/opentelemetry-js", | |||
"scripts": { | |||
"test": "nyc ts-mocha -p tsconfig.json test/**/*.ts", | |||
"test": "nyc ts-mocha -p tsconfig.json test/**/*.test.ts", |
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'd suggest to keep it standardized everywhere, either change all packages script to test/**/*.test.ts
or keep it test/**/*.ts
. WDYT?
packages/opentelemetry-plugin-grpc/src/enums/grpcAttributeNames.ts
Outdated
Show resolved
Hide resolved
* Convert a grpc status code to an opentelemetry Canonical code. For now, the enums are exactly the same | ||
* @param status | ||
*/ | ||
private static _grpcStatusCodeToCanonicalCode( |
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.
+1
packages/opentelemetry-plugin-grpc/test/utils/SpanAuditProcessor.ts
Outdated
Show resolved
Hide resolved
packages/opentelemetry-plugin-grpc/test/utils/SpanAuditProcessor.ts
Outdated
Show resolved
Hide resolved
metadata: grpcModule.Metadata; | ||
status: GrpcStatus; | ||
// tslint:disable-next-line:no-any | ||
request?: any; |
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.
Would it work for this to be of unknown
type?
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.
Changed to unknown
type (and a few other places where it made sense)
* limitations under the License. | ||
*/ | ||
|
||
// Equivalent to lodash _.findIndex |
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.
Thanks for writing this utility rather than pulling in lodash itself! (I have seen vulnerabilities on it recently and wouldn't want to expose OpenTelemetry customers to that risk)
LGTM. @OlivierAlbertini @bg451 @danielkhan Could you please approve this one, if everything looks good, Thanks :) |
A note about this and #216, I intend to complete this PR and then stub out the |
|
||
plugin._logger.debug( | ||
'patch func: %s', | ||
JSON.stringify(spanOptions) |
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.
out of curiosity/ignorance, will this json.stringify be executed when logging is not DEBUG?
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, it would be executed and then passed to a noop function. Seems wasteful so I'll put this (and anything similar I find) behind an if.
edit: AFAIK the current logging "level" is not implemented/exposed anywhere? If so, I will make this change in a separate PR.
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.
LogLevel
is already implemented and exposed here :
logLevel?: LogLevel; |
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 will be called even if the log level is not matched. This is an expensive call, let's address this in a separate PR.
Which problem is this PR solving?
Short description of the changes
TODOs
https://github.com/open-telemetry/opentelemetry-specification/blob/master/work_in_progress/opencensus/gRPC-stats.md
PluginConfig