Skip to content

Reconsidering what semantic conventions code generation should produce #551

@lmolkova

Description

@lmolkova

Context

Today every (or almost every) language SIG generates semantic conventions from yaml files using Jinja templates.
Each SIG separates attributes based on the signal they appear on in one way or another:

  • resource attributes vs all other attributes
  • resource, spans, logs/events

While there are some deviations, most of jinja templates and codegen configurations are mostly consistent across SIGs.

Problem

We want attributes to be used across signals. E.g. user_agent.original is a span attribute on server and resource attribute in browser.
Code generation was already broken and is patched to keep the status quo until we find a better solution.

Questions to Otel SIGs:

How language SIGs see the 'perfect' outcome of code generation tooling?

  1. How do we group attributes? Do we group them at all or generate all in one class?
  2. How do we work with experimental vs stable attributes? Should we separate them into stable and preview artifacts?
  3. Do we want semconv libs to have consistent approach/api across languages?
  4. How do we guarantee that YAML refactoring or code generation tweaks would not change stable public API of semconv libs in the future even if we reconsider approach in the p1?
  5. Do we even want to ship stable semantic convention libraries in each language?
  6. anything else?

Language SIGs that generate semconv with Jinja templates:

  • Java: separates resource vs all other attributes. @open-telemetry/java-maintainers
  • JS: separates resource vs all other attributes @open-telemetry/javascript-maintainers
  • Python: separates resource vs all other attributes @open-telemetry/python-maintainers
  • .NET: separates resource vs trace @open-telemetry/dotnet-maintainers
  • Go: separates resource, events, traces @open-telemetry/go-maintainers
  • Collector: separates resources vs spans @open-telemetry/collector-maintainers
  • Rust: separates resource vs all other @open-telemetry/rust-maintainers
  • C++: separates resource vs all other attributes @open-telemetry/cpp-maintainers
  • Erlang: separates resource, logs, traces @open-telemetry/erlang-maintainers
  • Ruby: separates resource, traces @open-telemetry/ruby-maintainers
  • PHP: separates resources vs all other @open-telemetry/php-maintainers
  • Swift: separates resources vs all other @open-telemetry/swift-maintainers

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions