Make OpenTelemetry DTOs public

[joshmouch]

Would it be possible to make the classes generated in OpenTelemetry.Exporter.OpenTelemetryProtocol public? I'm referring to TraceData, ResourceSpans, ScopeSpans, etc.
These are useful classes to have access to.

[reyang]

@joshmouch would you provide the following info?

Feature Request

Before opening a feature request against this repo, consider whether the feature
should/could be implemented in the other OpenTelemetry client
libraries. If so, please open an issue on
opentelemetry-specification
first.

Is your feature request related to a problem?

If so, provide a concise description of the problem.

Describe the solution you'd like:

What do you want to happen instead? What is the expected behavior?

Describe alternatives you've considered.

Which alternative solutions or features have you considered?

Additional Context

Add any other context about the feature request here.

[joshmouch]

Sorry, I'm not sure what you mean by other client libraries. For .Net, I see this one, the contrib library, and the instrumentation library.

Describe the solution you'd like:
I'd like to be able to deserialize JSON files containing OpenTelemetry data using existing DTOs from the OpenTelmetry libraries.

Describe alternatives
I could copy the GRPC definition files from this library, modify them to exclude the API definitions, and generate the DTOs myself, but versioning would become an issue.

[cijothomas]

I'd like to be able to deserialize JSON files containing OpenTelemetry data using existing DTOs from the OpenTelmetry libraries.

What is the end goal here? Providing an API to support deserializing json with otel data is not a goal of OpenTelemetry...

[joshmouch]

I'm not sure what you mean. But I think you're saying the intention is for end users to use the git submodules feature to check out and maintain the opentelemetry-proto repository and generate DTOs from the .proto files stored there using the protoc tool rather than the more traditional .NET/C# approach of using a package manager. Is that accurate? The confusion is I was expecting a package with a name like OpenTelemetry.Exporter.OpenTelemetryProtocol to have those available without using extra tools.
Thanks!

[cijothomas]

was expecting a package with a name like OpenTelemetry.Exporter.OpenTelemetryProtocol to have those available without using extra tools

Unfortunately, that is not true! That package is to export OpenTelemetry data following the OTLP format to an endpoint accept OTLP. It is an exporter, as defined in OTel specification, and nothing more.

(Also, I am not clear what is your end goal. If you describe that, maybe we can suggest some alternatives)

[joshmouch]

I think the end goal would be to have the DTOs needed for an OTLP endpoint without the extra steps.

However, my goal, specifically is:
I want to write telemetry to disk during integration test runs and then after the tests are complete, have a different process read that telemetry from disk to perform analysis on it.
The only way I've found to do this is to include the OTEL-collector to perform the disk writing. Ideally OTEL-collector wouldn't be needed, but it can export to disk, and the .NET implementation doesn't have a file exporter yet.
The OTEL-collector exports to file as a JSON file that matches the data structure in the .proto files.

(Maybe I should create a feature request for the .NET file exporter. :) )

[Kielek]

@joshmouch, in Automatic Instrumentation we are doing integration tests you have described.
The solution is to keep own copy of proto files. Runing OTLP server and analysis happens in testrs process. Instrumentation happens in testing, external application executed from tests. For traces you can check OTLP server. To start full analysis you can check e.g. SmokeTests class.

Hopefully it will help you.

BTW OTLP protocol is stable now, you should not expect often changes.

[martinjt]

The way I do this is override the handler in the HTTPClientFactory of the exporter, and write the protobuf to disk.

Since the protobuf format is available, you can deserialize the protobuf files in your code using the protobuf files (as a submodule is the best way to maintain it).

What you don't get is the ability to assert against Activity objects, but I don't see that as an issue personally.

For generalised tests, using OpenTelemetry.Exporter.InMemory is a better approach, as you can assert directly in your tests.

All that said, what you're proposing is essentially exactly what TraceTest does, so it might be better to look at that. It does what your suggesting specifically for deployed/running application versions.

[martinjt]

I'm going to close this as I think there's a way forward that doesn't require code changes. Feel free to add more context and reopen though!

[dersia]

I know this is an older issue that is closed, but this comes closest to what I am looking for. Basically I need the same as the OP, but for different reasons.

we have the issue, that the Otel Endpoint where we are sending the data to, only supports apikeys and we don't want to leak those in our frontend application. so we have configured our (angular) frontend to send the data to our backend using a oauth token. the goal here is to "deserialize" the otel payload from the frontend so we can forward it to the provider using grpc. everything works, I even used JsonElement and the ResourceBuilder to create the resources, but I can't find any .net type for scopeSpans. it would be much nicer if I could just deserialize the json payload and forward it directly.