Skip to content
This repository has been archived by the owner on Oct 3, 2023. It is now read-only.

Add support for overriding sampling per span #394

Merged

Conversation

mayurkale22
Copy link
Member

@mayurkale22 mayurkale22 commented Mar 6, 2019

Specs: https://github.com/census-instrumentation/opencensus-specs/blob/master/trace/Sampling.md#how-can-users-control-the-sampler-that-is-used-for-sampling

The logic for allocating traceId moved in tracer class. This helps to make sampling decision first and depending on decision we can then create either RecordRootSpan(RootSpan) or NoRecordRootSpan instead of always creating RootSpan(just to get traceId for sampling decision) and discarding it later.

This introduces signature changes to internal RootSpan class, But I think this won't be breaking change for users.

Fixes #391

*/
constructor(tracer: types.Tracer, context?: types.TraceOptions) {
constructor(
tracer: types.Tracer, name: string, kind: types.SpanKind, traceId: string,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these new parameters be optional to make this less of a breaking change? If we keep them, could you modify the change list to include a mention of it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible. On the other hand, this is internal API and won't affect users in any way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I see, this does not change the RootSpan interface type, just the implementations. In OpenCensus Web, I create spans directly from performance timings, but it seems like the instrumented Node libraries use the helper utilities in Tracer to create, start and end spans. So makes sense this is not really part of the exported API.

@@ -232,6 +232,8 @@ export interface TraceOptions {
spanContext?: SpanContext;
/** Span kind */
kind?: SpanKind;
/** Determines the sampling rate. Ranges from 0.0 to 1.0 */
samplingRate?: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a Sampler instance per the specs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy to change here, but the global sampler takes the same input

To keep things consistent I use number. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm OK with that, but could you create an issue to track changing it in both places to bring it closer to the specs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure.

*/
constructor(tracer: types.Tracer, context?: types.TraceOptions) {
constructor(
tracer: types.Tracer, name: string, kind: types.SpanKind, traceId: string,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I see, this does not change the RootSpan interface type, just the implementations. In OpenCensus Web, I create spans directly from performance timings, but it seems like the instrumented Node libraries use the helper utilities in Tracer to create, start and end spans. So makes sense this is not really part of the exported API.

@mayurkale22 mayurkale22 merged commit 36ec183 into census-instrumentation:master Mar 7, 2019
@mayurkale22 mayurkale22 deleted the sampling_per_span branch March 7, 2019 22:53
@mayurkale22 mayurkale22 added this to the Release 0.0.10 milestone Mar 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants