feat: add a NewSpan method which can create a span from all existed info

[xbsura]

Which problem is this PR solving?

• Resolves Support externally-provided trace/span IDs #397

Short description of the changes

• add a New Method: NewSpan

[yurishkuro]

I don't want to support this kind of function. It completely bypasses normal span creation in tracer.startSpanInternal(), which will lead to bugs and unclear outcomes (e.g. what happens with span pooling, with metrics, etc.)

[xbsura]

yeah, I understand what are you saying, here I just want to make it clear that, when we are saying Client, there are two meaings:

1. a client, which is able to create, and upload a standard opentracing trace to agent, as we all know what is trace, what is span, operate name, start/end time, tags and so on, but the data format for all system is different, so a client, transfer this content to format in system is one kind of client
2. a client, which is easy to use by language using jaeger trace, just like this agent here, it offers StartSpan and so on, all internal info is hidden

In fact, these two client, we all need it in different scenes, for us, a async rpc is used in our system, this async means no response exists for request, all rpc are request, the releationship exists in content of rpc but not the format of rpc, so sometimes we can not get response time directly, so analyze the log, and create legal trace info, and upload it to jaeger agent is a way usging jaeger trace

yes, span pooling, with metrics and other things must be ok, I will try make it better, but I really need this feature, which allow people create a span, all with existed info(including spanId and so on), other wise, We can not use it in our envirment

Thanks!

[yurishkuro]

if you're assembling spans offline from logs, have you considered submitting them directly to collectors in thrift or protobuf format? That does not require any changes to this library.

[xbsura]

if you're assembling spans offline from logs, have you considered submitting them directly to collectors in thrift or protobuf format? That does not require any changes to this library.

yeah, I can do that

But I must do some work which jaeger agent have done now, such as sampler, buffer, flush time, reconnect and so on, maybe cost too much

And all of this have been done in jaeger agent, so maybe I will still use jaeger-client-go, but I have to fork a private branch

Please consider this pr, as I know, jaeger python client allow new a span all by myself, maybe we can learner from it (if resonable)

thanks!

[dm03514]

@xbsura I have a need for this too (loading a span from existing/offline context).

If this is not possible to support in master, I would be happy to help you maintain a private branch of this.

@yurishkuro Would you consider this change if we ensure that span pooling, metrics, (everything you're concerned about) is addressed?

[yurishkuro]

As a I mentioned in the earlier comment, I am not opposed to a public constructor, but it needs to fit naturally in the implementation, not be a copy-n-paste of the code that already exists in this repo. It's doable with some refactoring, but not how this PR is done.

[yurishkuro]

See #397 (comment) for alternative solution proposal

[xbsura]

OK, I will keep following this issue

[yurishkuro]

a better solution was implemented in #411.