Top-level tags: "operation_name" and/or "component"?

[dkuebric]

Per #61 , there's a question about the recommendation for contents of the operation_name tag as well as importance/role/value of a component tag. In order to close out other parts of that PR, I've opened this at @yurishkuro suggestion to continue the discussion.

Recap:

The only "required" span tag currently is, operation_name, which is valuable and currently a cornerstone of many UI displays. However, it seems to miss a step in the semantic pyramid--the step that defines what exactly is doing the operating. There's certain things we are expecting we can provide automatically via traces, like hostname, which will help localize where work is being done. component feels as though it ought to be one, though it's not one that I would expect most tracers to be able to fetch automatically as hostname. So if we think this is valuable, we would expect instrumentors to provide in the same way they provide op.

Additionally, operation_name has been elevated to a special status; I think for a combination of historical and practical reasons. I'm fine with trying to keep operation_name as some sort of operation name, and adding a concept of component separately, but conceptually it feels clearer to have the broader-strokes component as our elevated attribute.

At any rate, we will want to tighten on recommendations for operation_name.

It seems as though there's 4 categories of option:

1. Demote operation_name and strongly suggest both it and component
   • I don't think we want to remove all mandatory span labeling, so this is out.
2. Elevate component to equivalent (span.setComponentName and inclusion in constructors)
   • This is tempting to me. Would it be considered too onerous?
3. Replace operation_name with component and strongly suggest operation_name as a tag
   • This is the direction AppNeta went, though it's the opposite of Zipkin I believe? Potentially controversial.
4. Strongly suggest component as a tag
   • I suspect this will end up with weaker compliance than we want.

My vote is 2 or 3.

@bensigelman had expressed interest in pursuing 4 and a strong opposition to 1/3.
@yurishkuro had expressed interest in pursuing 4.

[dkuebric]

Examples of potential component vs operation_name distinction for discussion:

• HTTP client call
  • component: httplib
  • operation_name: GET | POST | ...
  • Other attributes like URL, status code, etc specified in extended tags
• Memcache client call
  • component: redis-py
  • operation_name: GET | HGETALL | APPEND | ...
• Template engine
  • component: jinja2
  • operation_name: profile.html | account.html | ...

[dkuebric]

@yurishkuro @bensigelman @adriancole

[bhs]

I still like (4) the most, at least for now... Mainly because instrumentation cost is the #1 (dammit github autolinking) barrier to distributed tracing adoption, and the more semantic complexity we add the more friction the instrumenting developer will feel. I would note that all of the examples given are in shared libraries: the sorts of things with thousands of github stars, etc. I think it's totally reasonable to SetTag("component", ...) in OT instrumentation PRs for stuff like that. What I want to avoid is a special – or, worse, required – SetComponent method that doesn't make intuitive sense for the lion's share (by line count) of instrumentation code which exists in application glue code: the stuff "in the private repo", to compare against the above.

[bhs]

We talked about this at the OpenTracing hangout this past wednesday... @dkuebric should correct me if I'm misrepresenting anything, but we decided to go forward with (4) for now. component is an important concept and should be encouraged for shared libraries, but there was concern about forcing programmers to choose component names for simple spans that just group other subspans, etc.

[beberlei]

I am +1 for (4) as well.

[dkuebric]

Yes, late to the update but agreed this sounds like the way to go per discussion. I'll reflect this in the PR, which is now #82.

@beberlei I noticed you submitted a more minimalist approach to this in #76. I'm thinking there's enough content to merit its own doc (started in #61, now #82) but we should definitely reference from spec.md as you have called out in #76. I added that to the existing work. Let me know what you think, since you've spent some time thinking about this topic as well.

[dkuebric]

Also: I think we are good to close this for now, feel free to reopen if I've preempted anything.