-
Notifications
You must be signed in to change notification settings - Fork 96
Add trace params #311
Add trace params #311
Conversation
Codecov Report
@@ Coverage Diff @@
## master #311 +/- ##
==========================================
+ Coverage 94.75% 94.79% +0.04%
==========================================
Files 114 114
Lines 7603 7663 +60
Branches 692 701 +9
==========================================
+ Hits 7204 7264 +60
Misses 399 399
Continue to review full report at Codecov.
|
@@ -70,4 +72,28 @@ export interface TracingConfig { | |||
logger?: Logger; | |||
} | |||
|
|||
/** Specify the deafault Tracer Paramaters */ |
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.
Can this commented code be removed?
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 saw this was marked as resolved - is the commented out code below intentional? (Or maybe just a commit not pushed yet?)
|
||
// } | ||
|
||
export interface TraceParameters { |
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.
Could you add a top level comment for this interface as a whole?
@@ -46,7 +46,14 @@ export class CoreTracer implements types.Tracer { | |||
sampler: samplerTypes.Sampler; | |||
/** A configuration for starting the tracer */ | |||
logger: loggerTypes.Logger = logger.logger(); | |||
|
|||
/** maxAnnotationEvents is max number of annotation events per span */ | |||
numberOfAnnontationEventsPerSpan?: number; |
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 storing the individual values here, could it just store something like traceParameters: TraceParameters = DEFAULT_TRACE_PARAMETERS
?
Then if we add one more parameter later on, we don't need to add it two places.
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 a question, do we assume that user won't configure the tracer with parameters having values more than their limit?
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.
Ah, I missed the logic of the builder pattern below that capped those values at their limits. If other languages have that cap, we should preserve it for Node I'd think.
In that case, I would recommend making these be top-level attributes (like you have) but be made readonly
to prevent changes to them once they are initialized.
@@ -81,6 +88,28 @@ export class CoreTracer implements types.Tracer { | |||
this.config = config; | |||
this.logger = this.config.logger || logger.logger(); | |||
this.sampler = SamplerBuilder.getSampler(config.samplingRate); | |||
if (config.traceParameters != null) { | |||
this.numberOfAnnontationEventsPerSpan = |
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 would you think about integrating the default values right in line here rather than abstracting it into a builder class?
It could just be something like:
this.numberOfAnnontationEventsPerSpan =
Math.min(MAX_NUMBER_OF_ANNOTATION_EVENTS_PER_SPAN,
config.traceParameters.numberOfAnnontationEventsPerSpan ||
MAX_NUMBER_OF_ANNOTATION_EVENTS_PER_SPAN)
and similar for the other parameters.
I personally think the builder pattern, while it makes sense for other languages is not needed in TypeScript.
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 agree with @draffensperger, builder pattern is not required here.
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.
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.
There is actually no builder pattern implemented here, but it does have the methods for creating traceParameters so I used the builder suffix for the method. Should I rename the method to something else?
Thanks for the contribution, great to have this moving ahead!! I left a number of nit-picky comments - feel free to explain if you disagree on any of these. |
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.
Could you please add a line in CHANGELOG.md
* span | ||
*/ | ||
numberOfAnnontationEventsPerSpan?: number; | ||
/** numberOfMessageEventsPerSpan is number of message events per span */ |
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.
nit: s/is number/is max number/
Same for attributes and links
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.
in the interface definition, it should just be number of
right?
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 is a maximum number allowed. So it is a max value.
@@ -42,11 +44,27 @@ export class CoreTracer implements types.Tracer { | |||
private endedTraces: types.RootSpan[] = []; | |||
/** Bit to represent whether trace is sampled or not. */ | |||
private readonly IS_SAMPLED = 0x1; | |||
/** Default Limit for Annotations per span */ | |||
private readonly DEFAULT_SPAN_MAX_NUM_ANNOTATIONS = 32; |
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.
Could you make these be top level constants rather than properties of the class (that would be set on each instance)?
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.
LGTM pending final comments. Thanks for your work on this!
@vigneshtdev is this ready to merge? |
Yeah, you can go ahead and merge it. I don't have merging rights |
Addresses #285.
Unit Tests included as well.