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

override sampling decision #338

Conversation

kyessenov
Copy link
Contributor

Clients of opencensus may want to delay the sampling decision until after the span has been created.
For example, at the time envoyproxy decides whether a request is a health check or not, it may already have started recording the span:

  1. Envoy receives a request.
  2. Envoy creates a child span for an external authorization sub-request.
  3. Envoy applies a health check blacklist, may want to stop sampling the span and its children.
  4. Envoy proceedes forwarding the request.

To support this use case, other tracers expose a setSampling override. I think it's sufficient to stop recording the span for this case, e.g. only override the sampling decision to false.

Signed-off-by: Kuat Yessenov [email protected]

Signed-off-by: Kuat Yessenov <[email protected]>
@kyessenov
Copy link
Contributor Author

cc @objectiser

@g-easy
Copy link
Contributor

g-easy commented Jul 1, 2019

BTW we discussed this in census-instrumentation/opencensus-specs#218

@@ -224,6 +224,8 @@ const SpanContext& Span::context() const { return context_; }

bool Span::IsSampled() const { return context_.trace_options().IsSampled(); }

void Span::StopRecording() { span_impl_ = nullptr; }
Copy link
Contributor

Choose a reason for hiding this comment

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

This approach will not work, it prevents Span::End from doing:

exporter::RunningSpanStoreImpl::Get()->RemoveSpan(span_impl_);

(i.e. leaks memory)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ouch. I was not aware of the mechanics of memory management here

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm sorry. I wish things were simple.

@g-easy
Copy link
Contributor

g-easy commented Jul 1, 2019

How about this approach: #339

@bogdandrutu what do you think?

@kyessenov
Copy link
Contributor Author

I'm fine with either approach. The health checking trace noise is the most visible impact of not having span abandonment, which should be possible to fix with #339.

@kyessenov kyessenov closed this Aug 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants