Allow resources as span attributes

[Oberon00]

See #263 (comment).

For some types of spans (e.g. HTTP server) there is potentially a lot of information that can be different from span to span, but there is only a low number of combinations for each process. For example, it would make sense to have http.app_info attribute the value of which is a resource that contains information such as an application root, server name, application name, server port (see linked PR).

[bogdandrutu]

Please clarify what an "Application" is. Is that a "http.route"?

[Oberon00]

See my new comments: #263 (comment)

[Oberon00]

Some clarifications (from #263 (comment)):

Basically the problem with the app attributes is that in many scenarios (admittedly, probably most) they will have the same values every time they are set. However, I think there are scenarios in which there are multiple apps within the same process, and that's why I disagree with your statement that these attributes "clearly" belong to resources. In these cases we can't use the resources concept which is process-wide, because we have no way to indicate which app the span belongs too.

My goal with #274 would be to have just a single attribute "http.app_info" or similar the value of which is a (reference to a) process-wide app resource. Then you can use the process-wide resources to enumerate all the apps in the process and still know to which app the span belongs. Logically, I think that the app attributes would be perfectly fine as-is, but from a performance-perspective I can see that having them grouped together or transferred as a resource reference can have advantages.

Of course that attribute would not be inherited, just like a string attribute is not inherited.

[carlosalberto]

Hey @Oberon00 what's the state of this? can we close it? If not, what remains to be done?

[Oberon00]

Well, #421 and open-telemetry/oteps#66 could both be helpful when designing a solution, but nothing has been done explicitly to solve this issue and the initial description still applies.

I think of this primarily as a potential solution to #335, which I would still love to be solved.

[jmacd]

Related proposal: open-telemetry/oteps#78

[carlosalberto]

Moving this to the next milestone.

[tsloughter]

This sounds more like having complex values for attributes and not necessarily resources?

I like @jmacd's otep. For a simpler approach I was going to propose being able to attach a Resource to either the context or named tracer.

[Oberon00]

@tsloughter Why complex values? This is only about not needing to send the data for each Span but only once per batch (or less).

[tsloughter]

@Oberon00 ah, didn't consider batching since it would be on individual spans. Now I get it why it is more than just key/value pairs for the value of an attribute.

I'd like something like this, or jmacd's otep (or just tie the resource to a context so all spans in that context use it). My use is processes in Erlang nodes that are long lived and can represent their own "service". So would want to have spans created in that process have a resource with serivce.name specific to the process.