Distinguish between physical and logical operations

[danielkhan]

It'll be helpful to clarify whether this is a physical operation or logical one. My suggestion: only mark SpanKind = Client for the actual physical operation, for logical operation use SpanKind = Internal.

For example, the user would have requests.get('https://www.wikipedia.org/wiki/Rabbit'), which results in two physical HTTP requests - one 301 redirection, another 200 okay. The expected result is:

Span(SpanKind = Internal, http.status_code = 200, ...)
    Span(SpanKind = Client, http.status_code = 301, ...)
    Span(SpanKind = Client, http.status_code = 200, ...)

Please refer to census-instrumentation/opencensus-python#627 for more background.

Originally posted by @reyang in #82

[untitaker]

My issue is that at the moment there exists no httplib instrumentation in Python, so by applying this sort of rule you would effectively remove all Client spans. Even if we had one, requests' default adapter can be swapped out for something that is not instrumented. Based on that I don't believe that sdks should choose the spankind based on whether they expect there to be child spans (created by a not necessarily related instrumentation).

(EDIT: I just realized I assumed the physical spans to come from a different instrumentation)

By the same argument I could also say that the httplib span should be marked as Internal as the only true physical operation is the socket write.

IMO it would make sense to have a freeform field to specify which exact instrumentation created this span (with the possible values "python-requests" and "python-httplib" in @danielkhan's example). This should clear the confusion and also serve as a string to search for if the user has to dive into code to understand why a span was created in the first place

[Oberon00]

which exact instrumentation created this span

You will be pleased to find out that this is covered in open-telemetry/oteps#16. 😃 Although I'm not sure if this can or should be used to solve that problem.

[jmacd]

Related: #51

[tedsuo]

Since we have merged in #263 I would like to close this for now, please reopen if you feel your concerns have not been addressed.

[untitaker]

Do I understand it correctly that http client instrumentation is supposed to create a single http-type span regardless of the amount of redirects (specifically referring to the OP example)

If I really want to represent the raw network operations with parsed HTTP data, should I just make up my own component identifier and reuse the existing http.* tags?

[jmacd]

I don't think so @untitaker. I see this as a question about how to set SpanKind when redirects take place.

[untitaker]

right @jmacd I think we're roughly on the same page wrt what the question is. It's just unclear to me what the answer is.

[carlosalberto]

Bumping it to a future milestone.

[tigrannajaryan]

Do we still believe this is a must-have for GA? It is a guidance to instrumentation. If changed after GA it will not break any API or end-user code but may result in different trace composition. I think trace composition is not something we should consider part of our stability guarantees, hence I suggest we don't attempt to finalize such behavior before GA.
Given above reasoning I propose to remove release:required-for-ga label.