Opentelemetry-specification: Investigate and submit an OTEP on how other semantic conventions can be adopted

[tigrannajaryan]

For example ECS defines a rich set of fields that serve a similar purpose as the OpenTelemetry semantic conventions.

Similarly, there are other sets of conventions ("other convention") that will useful to look at (e.g. Stackdriver, DataDog, Dynatrace) and see if they can be adopted fully or partially by OpenTelemetry. This will enhance OpenTelemetry's convention significantly.

Questions to answer:

• Are there any conflicting definitions between the other conventions and existing OpenTelemetry conventions? Decide if there is a way to resolve the conflicts.
• What portion of other conventions makes sense to be adopted by OpenTelemetry?
• How to map the representation used in other conventions to OpenTelemertry's conventions (for example ECS uses nested objects, but OpenTelemetry uses dot notation for namespacing - how do we map these?).

[bogdandrutu]

Not sure why ECS is more important than other conventions and need to treat them specially, same argument can be made for Stackdriver, DataDog, Dynatrace, etc. Can you clarify why ECS vs the others?

Also in the comment there are a lot of topics to discuss, and will be better to split them. Thinks like "semantic convention namespace regulation" is a different topic than adopting ECS model, so probably separate issues will be better.

[tigrannajaryan]

Moved the second part to https://github.com/open-telemetry/opentelemetry-specification/issues/585

[tigrannajaryan]

Updated this issue to make ECS one of many conventions to consider.

[tigrannajaryan]

@roncohen would you be interested in tackling this? You already did lots of comparison work between ECS and OpenTelemetry conventions for https://github.com/tigrannajaryan/rfcs/pull/4 so this would be a natural continuation.

[Oberon00]

Since Dynatrace was mentioned: Due to the way our SDKs work, we do not have semantic conventions but very concrete API definitions for each operation kind that could be used to derive semantic conventions from them. You can look e.g. at the Node.js documentation: https://github.com/Dynatrace/OneAgent-SDK-for-NodeJs/#features. The C/C++ docs may not be as nice to read but may sometimes contain more details should you be interested in them: https://dynatrace.github.io/OneAgent-SDK-for-C/modules.html