Opentelemetry-dotnet: Make SemanticConventions.cs Public

Created on 14 Dec 2020  路  6Comments  路  Source: open-telemetry/opentelemetry-dotnet

Feature Request

Is your feature request related to a problem?

I have had to copy the SemanticConventions constants class containing open telemetry attribute names because it is marked as internal.

Describe the solution you'd like:

Please make it public. I would like to add additional tags to my Activity. This may be difficult because it's a linked file in a lot of projects.

await-spec enhancement help wanted

Most helpful comment

I suggest switching to using the code generator (https://github.com/open-telemetry/build-tools/tree/master/semantic-conventions) instead of hand-coding the semantic conventions so that the names are consistent with other languages.

Since you asked for other languages, here is Java: https://github.com/open-telemetry/opentelemetry-java/blob/838be8ef8ee501a81fcd666812393955eddcde85/api/all/src/main/java/io/opentelemetry/api/trace/attributes/SemanticAttributes.java (generator script at https://github.com/open-telemetry/opentelemetry-java/blob/master/buildscripts/semantic-convention/generate.sh)

I think all languages should eventually expose semantic conventions, as it should be easy to use them. But note that unlike the Trace API spec, semantic conventions are not yet frozen in the spec (like the Trace SDK spec).

All 6 comments

Semantic conventions is not an API required by the spec, so it is currently not planned to released as public API.

Curious, is there any other language which is offering the semantic conventions as public API?

I suggest switching to using the code generator (https://github.com/open-telemetry/build-tools/tree/master/semantic-conventions) instead of hand-coding the semantic conventions so that the names are consistent with other languages.

Since you asked for other languages, here is Java: https://github.com/open-telemetry/opentelemetry-java/blob/838be8ef8ee501a81fcd666812393955eddcde85/api/all/src/main/java/io/opentelemetry/api/trace/attributes/SemanticAttributes.java (generator script at https://github.com/open-telemetry/opentelemetry-java/blob/master/buildscripts/semantic-convention/generate.sh)

I think all languages should eventually expose semantic conventions, as it should be easy to use them. But note that unlike the Trace API spec, semantic conventions are not yet frozen in the spec (like the Trace SDK spec).

Will revisit this when semantic conventions are marked stable.
If anyone wants to offer a PR to make this happen earlier, happy to help :)

Hey all,
I saw this and thought would be a nice thing to get started. I went ahead and started creating a Jinja template to generate the c# class. Just to make sure I'm going in the correct direction.. does this make sense? https://github.com/joaopgrassi/opentelemetry-dotnet/commit/bfe64edf504fdf811263c1f3b7a6ec5a816dcd72

The Java impl is more complex since it has the actual types and etc. Do we also want to achieve the same here? Or just get the const/enums in place?

Hey all,
I saw this and thought would be a nice thing to get started. I went ahead and started creating a Jinja template to generate the c# class. Just to make sure I'm going in the correct direction.. does this make sense? joaopgrassi@bfe64ed

The Java impl is more complex since it has the actual types and etc. Do we also want to achieve the same here? Or just get the const/enums in place?

Hey, thanks for starting this. I also started this today :) We are basically at the same point. Given that you actually provided a link to something viewable I'll let you take it.

I personally think we just need the const/enum values. So I think the class generation is basically fine. Ultimately I think we want to create a NuGet package for the various projects to reference called OpenTelemetry.SemanticConventions (unless someone has a better name). We want to expose the generated values in a NuGet package and remove the existing SemanticConventions class.

I see the generation happening on-demand locally first, dumping generated files into a new NuGet project, building the package, and testing it against the current projects. At that point, we could either generate the package on demand via a CI pipeline, passing it the released tag version of the spec, and publish the package. Or we can continue generating on-demand and checking the generated files via a normal PR.

The version of the new package should match the spec version we used to generate.

@pcwiese cool, sorry for maybe stepping into you on this. I think I have the generated class finished for trace attributes. Now will do for resources which should be similar.

So, to make sure I understand: The idea is to introduce a new NuGet package here and place these auto-generated files in there. Then the projects in the solution would just use this new package/project.

About the package generation, not sure what is best. Generating it in a "standalone" action would be best, but I wonder how we would test it against the other projects? Will probably need some guidance with this part :)

I'm on the Slack channel, would be great if we could have a chat there, maybe would make things easier.

Was this page helpful?
0 / 5 - 0 ratings