-
Notifications
You must be signed in to change notification settings - Fork 59
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
Allow using custom Recorder and add option to always record spans #158
Conversation
in Brave we solve this with sampledLocal internal flag then the zipkin "recorder" would look at if it is supposed to act as default (only send ones remote sampled), or wildcard send (alwaysSampleLocal) Note: something slightly different what you are doing vs alwaysSampleLocal used in secondary sampling.. in secondary sampling how netflix use it, they add a comma-separated tag "sampled_keys" so that their firehose proxy can decide what to do vs decide in-process. Ex. if that tag includes "b3" they know it was sampled because of b3 vs wildcard or some overlay. https://github.com/openzipkin-contrib/zipkin-secondary-sampling/blob/master/docs/design.md#the-sampled_keys-tag If making the decision in-process you don't need to add a tag, just route it to another sender based on logic you deploy. |
Doing something similar here would mean adding a new |
And I see you have the same |
yeap sampledlocal is true when sampled is true or if alwaysReportSpans is set. (later you can get fancy and conditionally set sampledLocal based on http headers) alwaysReportSpans is a tracer-scoped flag where sampledLocal is a span/context scoped flag |
@drolando thanks for this. I am reluctant to expose the Recorder to the user, mostly because I always saw it as an internal type and making it customizable would create some weird API surface (starting by the fact that we pass the reporter as a parameter already and it is supposed to be included in the recorder aswell). I'd prefer the approach @adriancole suggests by using the sampledLocal flag. @adriancole I got a question, to summarize what we could do is:
|
9271bde
to
dabaf31
Compare
$span->finish(); | ||
|
||
$tracer->flush(); | ||
$spans = $reporter->flush(); |
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 don't fully understand why we are using another word. Ex alwaysReportSpans would make sense to have reporter report. alwaysEmitSpans would makes sense to have emitter emit :)
here's a related post on naming the TL;DR; being that we make enough words at this point https://publicobject.com/2020/06/06/synonyms-are-bad/
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.
oh yeah that's a better name
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 think the use case is valid.. made a comment about naming (bikeshed but I think worth thinking for a sec)
regardless, probably copying some of the doc from here might help!
@jcchavezs any comment on this? Does it look good? |
Sorry for the delay @drolando. It looks good to me, only one note:
`isSampled` in the recording span would always be Boolean by the time it is
reported. No need to be nullable.
Also, do we need some docs or notes around what alwayaRecordSpans would
cause? Like I know Tracing builder does not have docs for methods but maybe
this is a good one to start with?
Other than that I like it!
…On Wed, 24 Jun 2020, 02:58 Daniele, ***@***.***> wrote:
@jcchavezs <https://github.com/jcchavezs> any comment on this? Does it
look good?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXOYASOBFMQM4NLKFAKEQLRYFFUHANCNFSM4N4ZANAA>
.
|
@@ -156,7 +163,8 @@ public static function createFromContext(TraceContext $context, Endpoint $localE | |||
$context->getSpanId(), | |||
$context->isDebug(), | |||
$context->isShared(), | |||
$localEndpoint | |||
$localEndpoint, | |||
$context->isSampled() |
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.
ps one slight thing here is that in brave the "handler" has 2 arguments. since it has the context as one of the args, we don't need to also copy isSampled to the span.
@Override public boolean end(TraceContext context, MutableSpan span, Cause cause) {
if (!alwaysReportSpans && !Boolean.TRUE.equals(context.sampled())) return true;
--snip--
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'm not saying to change this, just mentioning a reference. it is fine to also copy it to the span, just it should be immutable (appears to be the case!)
b4c1854
to
98adc64
Compare
This isn't always true, at least in tests. If I create the context with |
Yes but when making it a span then the sampling decision happens. Anyways I am going to merge this and then investigate that and rebase onto #163. EDIT: I need some input. As I mentioned when we turn a context with null sampled into span, we force to make the sampling decision and theoretically it will never happen that the reporter receives an unsampled |
private function __construct( | ||
string $traceId, | ||
?string $parentId, | ||
string $spanId, | ||
bool $debug, | ||
bool $shared, | ||
Endpoint $localEndpoint | ||
Endpoint $localEndpoint, | ||
?bool $isSampled = false |
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 will also move this before endpoint as we changed the order already.
@@ -85,4 +86,58 @@ private function randomBool() | |||
{ | |||
return (bool) mt_rand(0, 1); | |||
} | |||
|
|||
public function testAlwaysEmitSpans() |
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 will also change this test into alwaysReportSpans
.
Thanks for the great work @drolando ! |
on the sampled null part. Indeed currently in brave a span must have a sampling decision, but since the context is independent of the span, and it could nave a null decision, then we have to allow it null. At some point we wanted to have "incognito mode" or "pass through" where you don't interfere with anything in the context, but let it be passed across. Especially in that case it could pass around null , but even now it is possible even if not normal. |
*/ | ||
public function isSampled(): bool | ||
{ | ||
return $this->isSampled === true; |
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.
Got a question here @adriancole @drolando: what we are saying here is whether this is sampled or not (and then dispatch the span to different reporters accordingly) but what about debug? if something is sampled=false but debug=true then we will dispatch it to the local sampled reporter, isn't?
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.
Probably it is better we change this into shouldRecord
which also checks the debug flag?
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.
Giving a second thought, I think it is responsability of the user to decide what to do when sampled=false and debug=true.
sampled explicitly false and debug true is a nonsense value..the only
nonsense choice so I wouldnt put much thought into it. depends on the
order set. for example we set sampled when debug is set (debug is
effectively a boosted sample decision)
here's a similar chat about it being a nonsense value
openzipkin/b3-propagation#31 (comment)
…On Sun, Jul 5, 2020, 10:35 PM José Carlos Chávez ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/Zipkin/Recording/Span.php
<#158 (comment)>:
> @@ -225,6 +233,14 @@ public function setRemoteEndpoint(Endpoint $remoteEndpoint): void
$this->remoteEndpoint = $remoteEndpoint;
}
+ /**
+ * @return bool
+ */
+ public function isSampled(): bool
+ {
+ return $this->isSampled === true;
Giving a second thought, I think it is responsability of the user to
decide what to do when sampled=false and debug=true.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAPVV3SPCODYRZ2Q44NUZDR2CFTDANCNFSM4N4ZANAA>
.
|
This will let me implement "firehose mode", similar to what we have in
py_zipkin.
Basically what I need is a way to call 2 different Reporters:
This cannot be accomplished with just one Reporter, because once we're
inside the reporter we've lost any info on whether the trace was sampled
or not.
I can almost do this in zipkin-php, there are only 2 things missing.
inform the tracer that I always want to create a RealSpan
own.
Once those 2 things are supported, I can write my own Recorder subclass
that calls the right Reporters as needed with minimal changes to the
core zipkin-php code.
cc @adriancole