Hi all, I got my own tracing analysis systems in my team and recently worked on code refactoring refer to opentracing api (include cpp, go, java and nodejs), during which a few questions confused me.
- Apis among these programming languages are not exactly the same, even for simple ones. For example, GetTracer exists in go and cpp but not in java, and everyone gets a forEachBaggageItems execept nodejs.
- Lack of Getters. Getters like GetTag, GetTraceId and GetSpanId are sometimes very useful, e. g. we want to bind trace_id and span_id with user-specified resources like local logs, or just print them for debug. And sometimes we do need to get tags out after SetTag.
Are the points above designed on purpose or just some mistakes? Can someone help me? Thanks a lot.
Hi there! FYI I'm working to integrate Opentracing-Python into Debian: https://salsa.debian.org/python-team/modules/opentracing-python
I'm looking to adopt OpenTracing for several of our internal services and I had a question I was hoping to get some guidance on. Our clients for our internal services set an x-request-id header when they submit requests. I'm trying to understand if there are any considerations for correlating that id with a trace or span id? Would it make sense to make it a tag, if so I don't see any relevent tag in the Semantic Conventions. Thanks in advance for any guidance that can be provided.
There is only
start()
What are the plans for
java-spring-cloud support for Spring Cloud Hoxton (Boot 2.2.1)? Has anyone run against it? I am doing so against RC2 (GA is not yet available for Hoxton but its soon). So far looks good. I do see a few warn/errors but am just starting to dig through them. Just wanted to touch base here before I do though.
Using
opentracing-spring-jaeger-cloud-starter to automatically trace restTemplate calls and JDBC traffic for a Quartz job. Was trying to aggregate all the spans into an overall transaction span by using Span span = GlobalTracer.get().buildSpan("quartzJob").start() when kicking off the job but this returns an individual span as well. Anyway to mix manual span creation in with auto generated ones?
Nevermind. This works now
Scope scope = GlobalTracer.get().scopeManager().activate(span, false) although I don't really understand why. Is the pattern to start a span then register it with the scope manager such that downstream methods know it is active and thus can be children?
Hey :) Having an issue with Span deactivation on a netty thread. Looks like the scopemanager utilizes threadlocal, but from what I can tell, the activation on my span happens on a different thread than my deactivation, causing it to never be deactivated. Anyone know if this is a known issue or am if I'm missing something here? thanks!
As an overview, we're using reactor for our incoming (and outgoing) requests, which then call graphql execution. im trying to make my span in a graphql instrumentation. span starts before execution and finishes after execution
when I do this, the span will finish, but never be deactivated. and so each subsequent call gets nested further and further in the trace
presumably because the thread changes between the code in
beginExecution and the code called in onCompleted
So basically
Scope is not intended to passed between threads (that's why in the last version we even removed Scope.span() )
You'd have:
public InstrumentationContext<ExecutionResult> beginExecution() {
Span span = ...;
return new SimpleInstrumentationContext<ExecutionResult>() {
@Override
public void onCompleted(ExecutionResult result, Throwable t) {
if (t != null) {
span.setTag(Tags.ERROR, true);
}
span.finish();
}
};
}
im just writing this hook via the interface they provide
i.e.
thanks for the help :)
no worries :)