Our services widely use SOAP over HTTP to communicate.
This is when SOAP envelope (xml) transfered as HTTP request body.
I wonder how should I inject context headers (uber-trace-id and others) in that case?
My point is:
HTTP is just a transfer. Frameworks like WCF (.NET Framework) transparently exract SOAP envelope and process SOAP message
So header should be in SOAP message headers.
I really like many of the key aspects with opentracing, I'm looking to take the principles of how you separate spans and traceID with the goal that if the MVP shows value I can write a prolog implementation.
Within the opentracing api, is it specified what a start or stop of a span should be?
Should it be a single service, if the service is fairly large would it make sense to find logical boundaries? In cases where a child span is in the same logical thread, seems like the only way to segment is through creation of child threads and storage in the thread context, or by modifing the current span.
Should each child span be aware of the spanID of the parent, or should only the parent span have awareness of the children?
guys, is it possible to find a span to use it as a context by name ?
I'm trying to build a binary that will report logs from a k8s deployed app to a remote jaeger server and don't want to lose context.
First call -> creates parent span with a unique name (tracer.start_span(operation_name=jaeger_parent_context) )
second call -> Finds the parent span by name and uses it as context for the child span it creates.
Is that possible?
@carlosalberto Currently not at my computer anymore with examples so Ill have to try, otherwise tomorrow Ill try again but some code.
I have been using the javaj-kafka-client in my scala stream application. I have create a tracer with the traceresolver, registered it with the global registery and added the producer/consumer interceptor classes in the stream config.
I actually see traces working and correctly connected to one and another by using code like
inputstream .aggregate(......)(intermidiate-topic-changlog) .mapValues() .to(outputtopic)
The spans generated are
1) from inputtopic -> to outputtopic
2) to intermediate-topic-changelog
So there is a separated trace that is triggered by an
aggregate step with a Materialized topic (...-changelog).
So the thing is the separated span on the intermediate topic which I would expect to actually be in between the other one