[
https://issues.apache.org/jira/browse/HTRACE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484567#comment-14484567
]
Colin Patrick McCabe commented on HTRACE-69:
--------------------------------------------
I am concerned that if we sample within an individual operation, we will not be
able to reconstruct the history of that entire operation. If there is a long
delay in an HBase span, how will you know whether it is due to something in
HBase, or to a call to HDFS that is not traced? Any kind of filtering also
increases the amount of configuration complexity, which is already high, and
opens up another way to configure things incorrectly. Sampling within an
individual operation is also not mentioned in the Dapper paper that Google
released, which makes me suspect that it's unnecessary.
While I wouldn't rule this out, I don't think we should implement it until we
have exhausted all the other options. In particular, I think we should start
by looking at how we can reduce the number of spans HDFS generates to a
manageable level (for example, by HDFS-8088).
> Filtering child spans by sampler
> --------------------------------
>
> Key: HTRACE-69
> URL: https://issues.apache.org/jira/browse/HTRACE-69
> Project: HTrace
> Issue Type: New Feature
> Reporter: Masatake Iwasaki
> Assignee: Masatake Iwasaki
>
> Trace#startSpan respect the sampler given as argument only when there is no
> ongoing span (i.e. when creating new root span).
> {code}
> public static TraceScope startSpan(String description, Sampler<TraceInfo>
> s, TraceInfo tinfo) {
> Span span = null;
> if (isTracing() || s.next(tinfo)) {
> {code}
> Adding API starting span if {{(isTracing() && s.next(tinfo))}} enables
> filtering of child spans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
