OpenTracing alignment for agents

[watson]

Following is a list of rules that our OpenTracing bridges should adhere to:

Tags

• If the bridge sees one of our predefined special purpose tags, it should use the value of the tag to set the associated value, but the tag it self should not be stored. Example: The tag user.id should not be stored as a tag, but instead be used to populate context.user.id on the active transaction
• If no type tag is provided, the current span/transaction should use whatever their default type normally is

Logs

• If a "log" is set on a span with an event field containing the value error, the bridge should do one of the following:
  • If the log contains an error.object field, expect that to be a normal error object and log that however the agent normally logs errors
  • Alternatively, if the log contains a message field, log that however the agent normally logs plain text messages

Formats

• Tracers should support the text format. The value should be the same format as the http header value
• Tracers should not support the binary format. Bridges should implement it as a no-op and optionally log a warning the first time the user tries to use the binary format

Parent/Child relationships

• Tracers should only support a single "child-of" relationship
  • If a span is given a list of more than one parent relationship, use the first that is of type "child-of"
  • If the provided list of parent relationships doesn't contain a "child-of", the span should be a root-span
  • Optionally log a warning the first time an unsupported parent type is seen or if more than one parent is provided

@elastic/apm-agent-devs If there's any other unanswered questions, put them in comments below and we'll update this list as they get answered.

[alvarolobato]

Thanks @watson

cc. @roncohen

[gtrevg]

Related to this, https://opentelemetry.io/ will be the merging of OpenCensus and OpenTracing and is targeting a June 2019 Java reference release and September 2019 release for other languages. It would be great to have an elastic compatible "exporter" that would allow us to instrument using OpenTelemetry and point it to the elastic backend. Should I open up an issue to support OpenTelemetry? Thanks

[axw]

@gtrevg thanks for the note!

We're aware of OpenTelemetry, and we're keeping abreast to ensure we have a path forward from OpenTracing. I've created #98 to track this feature. If there's anything in there that I missed, we'd appreciate your input.

[gtrevg]

@axw Awesome, thanks so much!