opentracing/specification

A place to document (and discuss) the OpenTracing specification. 🛑 This project is DEPRECATED! https://github.com/opentracing/specification/issues/163

The OpenTracing Specification repository

OpenTracing Specification Official Website: http://opentracing.io/spec.

The opentracing/specification repository is a place to document (and discuss) the OpenTracing specification itself (independent of any particular language or platform).

Historically this activity took place on the docs repo (github.com/opentracing/opentracing.io), but that became awkward since trivial website presentation and highly non-trivial semantic discussions were happening under the same namespace. The specification repository was thus proposed as part of opentracing.io#144.

What's here

There are two important files in this repository:

Specification

specification.md, a versioned description of the current pan-language OpenTracing standard

Semantic Conventions

semantic_conventions.md, a document describing conventional Span tags and log keys for common semantic scenarios

License

By contributing to OpenTracing Specification repository, you agree that your contributions will be licensed under its Apache 2.0 License.

specification's Issues

Wire format for MockTracer

Currently, MockTracer impls are using different wire formats. It would be good to normalize on something.

We could use something like this:
ot-mock-<object> object=[spanid,traceid,baggage]

Component hostname

After going through the changes in the specification for tags, I noticed there is no tag defined for the hostname of the component which generated the span? There is a component tag, but something like component.hostname would be useful.

How to process a nested RPC framework?

@adriancole @yurishkuro @bensigelman

In distributed system, this is a common scenario: a RPC framework nested in another RPC framework.

for example:

A simple RPC call A ----> B , uses a rpc framework (such as dubbox, popular in China), and this framework can provides rest service. And rest service provided by httpclient and tomcat lib.

The workflow is like this:

duboox_client  ---> httpclient ---> tomcat ---> dubbox-server
|<---------JVM1------------>|      |<--------JVM2----------->|

As Instrumenting Frameworks mentioned, OpenTracing can throw errors when an extract fails due to no span being present, so make sure to catch the errors that signify there was no injected span and not crash your server.

So, let us suppose, dubbox framework and tomcat support OpenTracing, and httpclient not, tomcat can't extract context ( extract/inject only match in dubbox ), for sure, and will create a new tracer. This will conflict with dubbox-server extract result.

This will happen sooner or later, What can I do in this scenario?

What's your opinion?

@yurishkuro , Also from Chinese Open Source Community. I find it hard to decide. Some options as following:

1. After dubbox-server extract, override the new tracer (from tomcat)
2. Enforce the lib match at two sides, client and server. Seems hard.

How to record casual relationships / sequencing between sibling spans

EDIT: decided below to re-focus this issue on the sequencing of sibling spans. Original title was "Provide example of reporting "middleware" hops"

Suppose we have an RPC call from Service A to Service B. In classic Zipkin service A starts a "client" span, and service B joins that span as "server". This results in a single span in the storage demarcated by cs->sr->ss->cr anotations. The new opentracing API advocates using different spans for client and server, but that's besides the point.

The question is what happens if there is some middleware between A and B that can also enrich the trace (for example, haproxy, or Hyperbahn). There may also be more than one hop through the middleware until the request reaches service B. There are two ways to represent this in the span-based tracing model

Nested spans

 client span (Service A)
+----------------------------------------------------------------------------+

    +---------------------------------------------------------------------+
     hop 1      
               +----------------------------------------------------------+
                hop 2
                          +-------------------+
                           server  (Service B)

Issue 1: when building service dependency graph, this trace will produce a dependency A->MW->MW->B. If there are many dependencies like this, the diagram will look like everything depends on MW, and MW talks to everything, but the A->B dependency is lost.

Possible solution: mark the "hop" spans with a special attribute indicating middleware, and handle them specially when building dependency diagram.

Issue 2: if the middleware is implemented as a proxy, it makes sense that a "hop" span does not complete until the server span is complete. However, if the middleware is implemented as a messaging system, the above trace does not make sense, it should look like below.

Stacked sibling spans

 client span (Service A)
+----------------------------------------------------------------------------+
    +------+   +------+   +-------------------+ +----------+ +------------+
     hop 1      hop 2      server                back-hop-2   back-hop-1

Issue: in order to display the trace as shown above, especially in light of clock skews, the UI needs to know that there is a strong happened-before relationships between spans. The current DCP API does not capture that relationship, and it's not clear if it can be captured via span annotations since each stacked span knows nothing about its siblings. In contrast, X-Trace API explicitly captured these relationships by means of using pushDown and pushNext operations.

Rework the formal key and field guidance as an .md file

The .yaml file was a nice idea, but since there turns out to be language-specific logic (e.g., for errors). I think we should create an .md file to document these tags/fields, then make the yaml file really just the data (i.e., without comments and guidance on that front).

Introduce peer.address standard tag

Continuing the discussion from opentracing/opentracing.io#116

cc: @yurishkuro @bensigelman @dkuebric @cwe1ss

Define incubation process for proposed specification changes

In the last OTSC meeting (2017/03/24) we discussed that it would be good to define a process for incubating new features being suggested for the specification, such as #57. It should probably be defined in the project_organization.md document.

Some of the guidelines that come to mind:

• languages like Java that support method overloading are very suitable for defining the proposed extension as an optional interface in opentracing-contrib that can be implemented by the tracers to allow the extended functionality (e.g. #62)
• the incubating project can provide a downgrade wrapper for tracers that do not support the new functionality. For example, #62 suggests adding a new "log level" argument to the log methods. It can provide a wrapper that implements the new extension methods by delegating to the official API in some way, e.g. by moving the log level from an argument to a tag.
• if it 's demonstrated that at least three existing OT implementations support the incubating specification change it can be considered for becoming a part of the official API

Decide on a naming scheme for "important" iterations on the OpenTracing specification

This has come up a few times, most recently here. Using semver for the OpenTracing spec itself would be excessively confusing... there would be (a) the semver for the OT spec, (b) the semver for the particular OT language API, and (c) the semver for the tracing implementation. Too many numbers!

I would rather come up with an ordered naming scheme for "important" (*) OpenTracing specification iterations... maybe alphabetical nouns in a given category. (C.f. Ubuntu's naming scheme or whatever)

(*): Not sure what "important" means... doesn't just have to be "breaking" changes to the spec.

Standard(s) for in-process propagation

OpenTracing 1.x leaves the question of in-process context propagation entirely in the hands of the applications themselves, which substantially reduces the usefulness of the standard since different frameworks instrumented with OT do not have a way to exchange context.

Standards for in-process context propagation inevitably have to be specific to individual languages. This is more of a placeholder issue. It is also somewhat similar to #22 (possible part of it), but can be done independently.

Consolidate common tags definition and auto-generate language bindings

... continued from opentracing/opentracing.io#76

cc: @yurishkuro @bensigelman

Renovate OpenTracing project organization

Issue by bensigelman
Wednesday Oct 26, 2016 at 22:33 GMT
Originally opened as opentracing/opentracing.io#144

---

OpenTracing has come a long way in less than a year! We hit a 1.0 spec, have a shiny website, linked up with CNCF, and so on. Certain things that we've been doing "out of habit" probably ought to be changed now that things are a little more stable. This issue is a proposal about same.

Briefly, these are the problems I'd like to solve:

• the "docs repo" (i.e., this github repository) is an odd place to discuss big semantic things, yet that's where those discussions take place
• the "weekly meeting" (sic) has been less-than-weekly lately given the lack of urgent topics to discuss; it's also at an inconvenient time for folks in many TZs (esp Europe)
• we don't have a good place to make changes that affect the semantics / reserved tags / etc of the downstream repos

My proposal is to...

• create a new repo called github.com/opentracing/common
• migrate all non-docs-site issues in this (github.com/opentracing/opentracing.io) repo over to opentracing/common... there's a script for that, hopefully it works
• actually make good on opentracing/opentracing.io#76 and add some .yaml-style data to opentracing/common as well
• generally try to conduct consequential discussions via Github Issue, linking from Gitter where appropriate
• for things that are hard to decide about via Github, we will push agenda items onto a "monthly OT committer call"
  • (for more urgent matters, ad hoc hangout calls are fine, etc)
• keep up with quarterly calls for anyone who cares about OT, even if they're just in an adjacent project

Concerns about the above? Errors of omission? Other thoughts?

alphabetical cc: @adriancole @basvanbeek @beberlei @bg451 @cwe1ss @dawallin @dkuebric @jmacd @lookfwd @michaelsembwever @oibe @slimsag @yurishkuro

clarify the definition of a "Trace" w.r.t. Spans and References

Per https://gitter.im/opentracing/public?at=58332e4c2db9526704625011

Opt-in vs Opt-out & security on propagation at the system boundaries

What's the recommended practice for the following scenarios:

• someone makes a request to my public webserver and includes fake trace headers. It might even contain fake baggage that would be propagated within my system. I can't just not implement extract-functionality because I might use an OpenTracing enabled load balancer in front of it etc.
• an internal application sends a http request to some 3rd party system. How do I make sure I don't send my trace headers/baggage here?

In other words, who is responsible for making sure that headers are validated for its boundaries? AFAIK an application developer does not have a way to manipulate spans through the OpenTracing API. Also, hoping that a tracer might offer this functionality seems troublesome - especially when you want to switch tracers.

Or is this an additional out-of-scope hook that must be provided by the http library / web framework? E.g. they will manage their own whitelist/blacklist and just not call inject/extract if it matches.

Key Metrics for Tracing Systems

Hello,

not an issue, but rather a question. Could people share some numbers on what tracing bandwidths they observe 𝐺𝑏𝑦𝑡𝑒𝑠/hour peak/average? Is there something like average/typical span size per application/per server? What are key metrics that really matter for a tracing system? Are there some taxonomies for applications e.g. lyft/envoy typically creates 12kb/trace while a typical web application generates ~30kb/trace?

What should we be specifying?

Opened up a conversation in Gitter, was recommended by @clutchski to open up an offline, trackable discussion here.

We have a ton of different systems, implemented in all manners and languages (go, c, c++, perl, python, java, scala, elixir, erlang). You name it, we have it.

We believe that the main value to opentracing has to do with creating an industry standard around the following:

• Inter-process propagation. This can be by any means (HTTP being the most common). Standard way to pass the payload so to speak. This includes all shapes and manners of flags in addition to baggage (or even if baggage goes inter-process)
• "Wire" format for the actual span data so it can be easily consumed. For example, in XML there would be an XSD. In JSON, we can provide a schema for guidance. Same with avro.
• Sampling implications - there is the standard "shouldSample: true | false", but there may be the need for dynamic sampling algorithms. I would love to explore these use cases and that would help pound out some of the additional inter-process propagation stuff

Once you have a standard way to propagate through all of the things, and you have a standard way to "emit" spans so they can be analyzed / stored, then the world opens up for all kinds of systems to be built up from that standard.

---

A little background, just conveying these thoughts wrt "we should standardize on in-process propagation", which imo is less valuable than the above.

For an instrumentation library to be widely supported, it would have to have "adapters" to each of the inbound/outbound propagation formats (as well as emission formats for sending actual span data). If we all talked the same way, then I could write my library once.

Tracing is not all that difficult, there are just subtle rules to play by.

For example, it is great if I have a java web server and can use a jax-rs or servlet filter to parse the incoming trace context.

For a smaller system / microservice, I may have a few endpoints, talk to one backend and a database. It is very trivial in that instance to do my own tracing thing.

If I am writing an akka-http application, I might have a custom directive for parsing headers. For a finch application, similarly easy to have an Endpoint I can compose to pull out the trace.

My point is, I can imagine a thousand small libraries, many of which overlap with slightly different usage. Having a standard interchange format and output format (or rules) makes the development of those libraries easier while at the same time facilitating the rest of the ecosystem around collectors, aggregators, storage layers, visualization, and applications.

Example application

I think it would be great to have a demo app in contrib org. I have divided app goals from app requirements.

App goals:

• demonstrate OpenTracing features: baggage, find a bottleneck...
• show how the app can be instrumentation

App requirements:

1. distributed polyglot app
2. HTTP and RPC communication
3. instrumentation
   • explicit
   • framework integration
   • agent
4. database instrumentation
5. simple way to change tracing backed

The app could be deployed with docker-compose. Add more requirements/goals please.

Is OpenTracing suitable for streaming/publish-subscribe systems?

Suppose that there is a service A that emits some messages.
Another service B can subscribe to the messages from service A, process them and emits another messages. Another service C can subscribe to the messages from service B, process them and emits another messages and so on.
Could i use OpenTracing for tracing span that starts in service A and will be finished in probably another service(s) (where processing of source message may ends)?
It seems to be that OpenTracing was created only for request/response patterns and is not suitable for streaming of publish-subscribe systems. Isn't it?

Duplicate

See opentracing/opentracing.io#66 and comment here: #9

Standard Interchange Format for OpenTracing

There is some debate of whether there should be standard or "official" OpenTracing wire format. Sidestepping that debate, a smaller and hopefully less contentious starting point would be an out-of-band format for sharing trace data.

This has come up repeatedly in the following areas:

• allow OT-compliant tracers to import/extort data between each other.
• enable more specialized analysis tools that do not amount to complete tracing solutions.
• enable tooling for development and testing.

Ideal qualities for this interchange format:

• Human readable.
• Easy to parse in many languages.
• Compresses reasonable well.

As a straw-man to kick it off, I propose a comma separated list of JSON-formatted spans.

What say you?

Should OpenTracing be defined as layered architecture?

... continued from opentracing/opentracing.io#111

cc: @yurishkuro @bensigelman @adriancole @rfonseca @maxwindiff

How can a tracer append data to an existing span, i.e. span ID that was created in another process

Issue by yurishkuro
Friday Jan 15, 2016 at 15:43 GMT
Originally opened as opentracing/opentracing.io#22

---

A use case we're working on right now is we want haproxy to add Logs to the current trace that's passing through it. We already have something in place that can sniff headers from passing requests and write the out to kafka along with some timers. The plan is to have a custom reader of that kafka topic that will extract the timestamps and trace IDs of when the request was passing through haproxy and create additional span Logs that will be saved to Cassandra via somewhat of a back door. It would be nice to have a clean OpenTracing way of doing that, which requires not only the ability to inject the timestamps into Logs externally (per #20), but in our case do that without starting/finishing the span. I know Ben you will be against that last part :-), and say we could just create a new span instead, but doing so would require modifying in-flight request inside haproxy to replace the client trace/span ID with haproxy span ID, and that is much more intrusive way of doing it vs. just adding logs.

Clarify error "logs" as optional practice

In the current data spec, it appears as though key/value logging is required to support logging:

https://github.com/opentracing/specification/blob/master/data_conventions.yaml#L127

According to @yurishkuro, this isn't quite the case:

The minimum recommended level of marking errors (although I don't think it's explicitly written anywhere) is error: true tag , which seems to be supported by most implementations. I think it makes sense to state this more explicitly in the spec - (cc @bhs) - as part of describing "the semantics of transactions in distributed systems". Logging of the error is to provide additional (optional) information beyond the Boolean marker on the span. If instrumentation only logs the errors, I think it's incomplete. The fact that log(event: 'error') is called should not be interpreted by the tracer as "span has failed".

I think the spec should be adjusted and all contrib instrumentation updated to ensure KV logging isn't accidentally needed to support errors

provide a read API to access *all* baggage items

(Not just accessing them by a foreknown key)

This has already been done in Go: opentracing/opentracing-go#85

We would need to make changes to opentracing.io/spec as well as the remainder of the per-platform APIs.

Soliciting OpenTracing CI requirements for Inclusive Integration with CNCF Projects

"CNCF is helping develop a cloud native software stack that enables cross-cloud deployments. Cross-project CI that ensures ongoing interoperability is especially valuable." - Dan Kohn Executive Director CNCF

[cncf-ci-public] CNCF CI Goals
[cncf-ci-public] Soliciting CI requirements via Project GitHub Issues

This github issue is to provide a highly visible invite to be part of creating a cross-cloud cross-project CI within the diverse software communities of the Cloud Native Compute Foundation.

To fully understand our needs and expectations, some help documenting the current state of the OpenTracing CI and ongoing requirements of the OpenTracing community would be useful.

https://github.com/cncf/wg-ci/blob/master/projects/opentracing.mkd

As we collect OpenTracing and other project CI requirements, we'll use the @cncf/cncf-ci-working-group issue at cncf/wg-ci#12 and encourage you to join the discussion on the cncf-ci Mailing List

Supporting Linux Perf events with Opentracing

This issue is to discuss a proposal on adding perf events support within a span. Perf events (https://perf.wiki.kernel.org/index.php/Tutorial#Events) are platform side counters which can provide valuable insights on what is happening inside a span and can help us in identifying resource bottlenecks.

We would like to hear your thoughts and suggestions on the same.

We did a small proof-of-concept implementation with opentracing-go and zipkin-go-opentracing to show how the eventual integration may look.

Opentracing-go api will have a PerfString event as an addition to the span creation function. And, the backend Zipkin collector will be responsible for starting, reading, logging and closing the required counter.

To try out the opentracing-go with perfevents, this commit can be used :
platform-tracing/opentracing-go@9391ff1
And, to try out zipkin with perfevents, this commit can be used :
platform-tracing/zipkin-go-opentracing@1f9fb2a

A "perfevents" library has been added to zipkin-go-opentracing which assists in creating, maintaining and reading the perf events like cpu-cycles, instructions, cache-misses etc. An example usage in a sample application:
var eventName opentracing.PerfString
eventName = "cpu-cycles"
parent := tracer.StartSpan("Parent", eventName)

And, we can see the output as shared in the attachment.

Build OpenTracing reviewer team?

From @pavolloffay on git.

Other thing I would find it useful if there were defined teams in ot-contrib(for reviews and ask in issues). People may wonder who should review their PR. It would be good if there were teams (one for spec and then per language probably)

Create team of spec and languages reviewers. More important, let people know who to ask and discuss.
@adriancole @bensigelman @yurishkuro @michaelsembwever

Add a log level [and namespace] in the API

Hi,

I'm a developer of the Trace Compass trace analyzer/viewer and I usually use LTTng for Tracing. I've been looking at the Open Tracing API to see how we can use that in the Trace Compass code.

The main interest I see in this API is that it gives structure and semantics to the various points of interest in the code and it can greatly simplify the analysis of the traces afterwards.

But what I feel is missing in this API to be useable for an application like Trace Compass is a log level, and optionally a namespace. From what i understand, now, you either trace the application, or you don't and if you do, all tracepoints will be logged. With a log level, you can fine-tune the amount of data that will be logged, depending on what you want to achieve with tracing. And a namespace allows to trace only the components of interest.

Trace Compass is a java application and we are using JUL for tracing. We use a wrapper that does something similar to the Open Tracing API, but takes the JUL logger (provides a namespace) and log level, so we obtain semantically equivalent traces. We would like to use a known API, but without level and namespace, the interest is limited.

Any opinion on that? Would it be possible to add optional log levels and namespace to the API?

Cheers,
Geneviève

Tracer extract ambiguous handling of corrupted span context

Hello,

API in different languages define different behavior when extracting corrupted span context from a carrier.

E.g. javadoc say to throw an exception if the context is corrupted. Comment in JS say to return null if no span context could be found but it's not talking about corrupted one.

It would be good to clarify this is the specification.

If the span context is corrupted should be an exception thrown or started new trace? This could depend on tracer configuration.

I run into this when looking at brave-ot: https://github.com/openzipkin/brave-opentracing/pull/14/files#r97917595
Also see @adriancole comments here: openzipkin-contrib/brave-opentracing#14 (comment)

Extract in the specification:
Spec: https://github.com/opentracing/specification/blob/master/specification.md#extract-a-spancontext-from-a-carrier

Extract in APIs:
Java: https://github.com/opentracing/opentracing-java/blob/master/opentracing-api/src/main/java/io/opentracing/Tracer.java#L76
JS: https://github.com/opentracing/opentracing-javascript/blob/master/src/tracer.js#L177
Python: https://github.com/opentracing/opentracing-python/blob/master/opentracing/tracer.py#L108
Go: https://github.com/opentracing/opentracing-go/blob/master/tracer.go#L112

Running multiple tracing implementations simultaneously

Continuing the discussion from opentracing/opentracing.io#66

cc: @yurishkuro @bensigelman

non-RPC spans and mapping to multiple parents

Issue by adriancole
Sunday Jan 17, 2016 at 01:59 GMT
Originally opened as opentracing/opentracing.io#28

---

One of my goals of working in OpenTracing is to do more with the same amount of work. For example, when issues are solved in OpenTracing, and adopted by existing tracers, there's a chance for less Zipkin interop work, integrations and maintenance. Zipkin's had a persistent interoperability issue around non-RPC spans. This usually expresses itself as multiple parents, though often also as "don't assume RPC".

In concrete terms, Zipkin V2 has a goal to support multiple parents. This would stop the rather severe signal loss from HTrace and Sleuth to Zipkin, and of course address a more fundamental concern: the inability to express joins and flushes.

In OpenTracing, we call certain things out explicitly, and leave other things implicit. For example, the existence of a span id at all is implicit, except the side-effect where we split the encoded form of context into two parts. We certainly call out features explicitly, like "finish", and of course these depend on implicit functionality, such as harvesting duration from a timer.

Even if we decide to relegate this to an FAQ, I think we should discuss multiple parents, and api impact. For example, are multiple parents tags.. or attributes? Does adding parents impact attributes or identity? Can an HTrace tracer be built from an OpenTracing one without signal loss? Are there any understood "hacks" which allow one to encode a multi-parent span effectively into a single-parent one? Even if we say "it should work", I'd like to get some sort of nod from a widely-used tracer who supports multiple parents.

The practical impact of this is that we can better understand in Zipkin whether this feature remains a zipkin-specific interop story with, for example HTrace, or something we leverage from OpenTracing.

For example, it appears that in AppNeta, adding a parent, or edge is a user-level task, and doesn't seem to be tied with in-band aka propagated fields? @dankosaur is that right?

In HTrace, you add events and tags via TraceScope, which manages a single span, which encodes into its id a single primary parent. You can access the "raw" span, and assign multiple parents, but this doesn't change the identity of the span, and so I assume doesn't impact propagation. @cmccabe is that right?

I'm sure there are other multiple-parent tracers out there.. I'd love to hear who's planning to support OpenTracing and how that fits in with multiple parents.

Add a relationship to a span part-way through

Current APIs only seem to support adding relationships to a span at construction time.

However, it would be useful to add relationships part-way through a span.

For example, communication between two spans, such as receiving an RPC response, or streaming packets.

This would also enable baggage to be propagated inside communication between two long-running spans.

non-RPC spans and mapping to multiple parents

Issue by adriancole
Sunday Jan 17, 2016 at 01:59 GMT
Originally opened as opentracing/opentracing.io#28

---

One of my goals of working in OpenTracing is to do more with the same amount of work. For example, when issues are solved in OpenTracing, and adopted by existing tracers, there's a chance for less Zipkin interop work, integrations and maintenance. Zipkin's had a persistent interoperability issue around non-RPC spans. This usually expresses itself as multiple parents, though often also as "don't assume RPC".

In concrete terms, Zipkin V2 has a goal to support multiple parents. This would stop the rather severe signal loss from HTrace and Sleuth to Zipkin, and of course address a more fundamental concern: the inability to express joins and flushes.

In OpenTracing, we call certain things out explicitly, and leave other things implicit. For example, the existence of a span id at all is implicit, except the side-effect where we split the encoded form of context into two parts. We certainly call out features explicitly, like "finish", and of course these depend on implicit functionality, such as harvesting duration from a timer.

Even if we decide to relegate this to an FAQ, I think we should discuss multiple parents, and api impact. For example, are multiple parents tags.. or attributes? Does adding parents impact attributes or identity? Can an HTrace tracer be built from an OpenTracing one without signal loss? Are there any understood "hacks" which allow one to encode a multi-parent span effectively into a single-parent one? Even if we say "it should work", I'd like to get some sort of nod from a widely-used tracer who supports multiple parents.

The practical impact of this is that we can better understand in Zipkin whether this feature remains a zipkin-specific interop story with, for example HTrace, or something we leverage from OpenTracing.

For example, it appears that in AppNeta, adding a parent, or edge is a user-level task, and doesn't seem to be tied with in-band aka propagated fields? @dankosaur is that right?

In HTrace, you add events and tags via TraceScope, which manages a single span, which encodes into its id a single primary parent. You can access the "raw" span, and assign multiple parents, but this doesn't change the identity of the span, and so I assume doesn't impact propagation. @cmccabe is that right?

I'm sure there are other multiple-parent tracers out there.. I'd love to hear who's planning to support OpenTracing and how that fits in with multiple parents.

If I want to define a record like zipkin's service name, which tag i should select?

Hi, I am implementing a full opentraing sdk but a problem puzzle me.
If I want to define a record like zipkin's service name, which tag i should select? I find there is not tag field available, some opentracing api implementation (for example jaeger-client-go) define it in struct Tracer(https://github.com/uber/jaeger-client-go/blob/master/tracer.go) but it is not opentracing's convention.

I think define tag field for service name is necessary.

Define more standard tags in the future?

... continued from opentracing/opentracing.io#104

cc: @dominikh @yurishkuro

Different licenses

What license should be used for OpenTracing? Apache 2.0/MIT?

• https://github.com/opentracing/specification/blob/master/LICENSE Apache 2.0
• https://github.com/opentracing/opentracing-ruby/blob/master/LICENSE Apache 2.0
• https://github.com/opentracing/opentracing-java/blob/master/LICENSE Apache 2.0
• https://github.com/opentracing/opentracing-python/blob/master/LICENSE MIT Uber
• https://github.com/opentracing/opentracing-javascript/blob/master/LICENSE MIT
• https://github.com/opentracing/opentracing-go/blob/master/LICENSE MIT OT
• https://github.com/opentracing/opentracing-objc/blob/master/LICENSE MIT OT
• https://github.com/opentracing/opentracing-cpp/blob/master/LICENSE MIT OT
• https://github.com/opentracing/opentracing-csharp/blob/master/LICENSE MIT OT

Clarification of HTTP_HEADERS format requirements

... continued from opentracing/opentracing.io#113

cc: @yurishkuro @bensigelan @cwe1ss

TraceId / SpanId data types

The current GO OT implementations define both traceId and spanId as uint64: https://github.com/opentracing/basictracer-go/blob/master/context.go

This is not specifically addressed in the spec and I would like to raise it since I find this very limiting for no obvious gain. A "string" would be a way more flexible data type for both of them. A lot of software out there utilises already concepts like 'transaction id' or 'correlation id' which are arbitrary formats, mostly uuids. All those are not directly portable to OT because of the above implementations.

What is the current thinking on this?

API for minimizing no-tracer / non-sampled overhead

Continuing the discussion from opentracing/opentracing.io#31

cc: @dkuebric @bensigelman @bogdandrutu @yurishkuro

Distributed context propagation as foundation for OpenTracing

Currently OpenTracing implements baggage as a feature on top of tracing. Rodrigo Fonseca proposed a different layered approach he calls "tracing plane" (slides) where instrumentation and context propagation is done by the lower level, with distributed tracing being one of the higher order functions.

Redirection, fault tolerance, circuit breaker, etc patterns

General question to see what the feeling is regarding capturing information in the trace data about such situations in a standard way (tags/references).

As mentioned by @adriancole in opentracing-contrib/java-apache-httpclient#2 (comment), where the redirection is currently recorded in log data, it would be good practice for any distinct communication to be represented in a separate span - although I don't think this is stated in the spec anywhere - should this be added as a guideline, or a requirement?

Taking into account fallbacks aswell, it may be good to highlight that a redirection or fallback is related to a previous SpanContext (i.e. via reference) to facilitate later understanding of what actually occurred at runtime.

Similarly with circuit breaker pattern - I think it might be good to have the fact that it occurred recorded in some standard way.

Add an KEY CODE(integer value) for each tag/log-field key

By so many acronyms or abbreviations existed in tags or log fields, I want to propose about adding an KEY CODE(integer value) for each key. e.g. db.instance keyCode=10; db.statement keyCode=11. Like other spec code, we can retain some code(0-10000) for OT official keys.

After we have these, all platform implementations, can use the integer to judge. In my tracer implementations, we have an analysis backend, analysis the service-flow by some tags, right now, it must be based on String.equal() and consider char-case... I hope we can improve on that.

@bhs @objectiser thoughts?

What to do about Span.info() / Span.error()?

Issue by yurishkuro
Sunday Jan 17, 2016 at 21:03 GMT
Originally opened as opentracing/opentracing.io#30

---

To fork from a different discussion in #26, the questions here are:

1. should we expect the message argument to info() and error() methods to be parameterized by referring to portions of the payload, just like the logging APIs do?
2. if so, do we converge to a single cross-platform syntax or use common patterns from the respective platforms, i.e. span.Info("oops we found %+v", payload) in Go vs. span.info("oops we found {}", payload) in Java?

Encourage response instrumentation

At the workshop, we discussed how some non-tracing use cases could need baggage propagated in responses.

Should OpenTracing encourage propagating contexts back from children to parents?

To do this would entail being able to add a relationship mid-way through a span, eg a 'CHILD_FINISH' relationship (see #42 )

What to do about Span.info() / Span.error()

Continuing the discussion from opentracing/opentracing.io#30

cc: @yurishkuro @adriancole @bensigelman @bcronin @dkuebric @michaelsembwever @wladekb @tschottdorf @atanasbalevski

New reference type to support batch scenarios

As mentioned by @bhs in #51 (comment), it would be useful to have a new reference type to identify when multiple Spans (generally in their own traces), are handled as a group (e.g. consumed as a batch from Kafka).

I would like to propose using GROUPED_BY as the reference type, rather than the batch focused names mentioned, so it is more general.

If accepted, then the 'message bus' scenario in the use cases doc opentracing/opentracing.io#189 could be updated to include a section on this, with example:

groupSpan = tracer.start_span(operation_name="Batch")
for message in batch:
    extracted_context = tracer.extract(
        format=opentracing.TEXT_MAP_FORMAT,
        carrier=message.headers
    )
    span = tracer.start_span(operation_name=operation, follows_from=extracted_context,
                             grouped_by=groupSpan.context)
    span.set_tag('message_bus.destination', message.destination)
    ....
    span.finish()

groupSpan.finish()

In Tracers that don't support multiple references, the GROUPED_BY reference could result in the group span id being stored in a tag/annotation.

error.description standard tag

Hello,

there is boolean error tag to denote that span is in an error state. Would it make sense to add string error.description standard tag to include more details about the error?

Could we standardize aspects of the sampling mechanism?

... continued from opentracing/opentracing.io#94

cc: @lookfwd @yurishkuro

Reference type to represent relationship between traces

As discussed here, we may need a new relationship type similar to Follows From, but that results in the Span initiating a new trace.

Should there be a `SpanContext.DebugCorrelationID` or similar?

Per opentracing/opentracing-cpp#3 as well as numerous misc discussions on Gitter.

Basically, most OT implementations have some sort of trace_id under the hood. There is practical value in exposing that, but there are also immediate problems:

1. There is nothing in the OT spec about any particular sort of "id" (trace, span, or otherwise); and even if there were, there is no way for OT to know the bitwidth of those ids or even whether they're strings/ints/whatever.
2. Since the OT spec allows for multiple parent spans, the "trace id" (sic) is not actually a single id / is not well-defined across the trace.

One option would be a SpanContext.DebugCorrelationID that would return a string and be a sort of "best-effort trace_id" for lack of a better word. I have mixed feelings about this but wanted to raise it for discussion and tracking.

feature request: inter-trace references

Continuing the discussion from opentracing/opentracing.io#119

cc: @RaduBerinde @yurishkuro @bensigelman @adriancole