Public Dto objects locked down with internal constructors - Outside Code Review

[kccarter76]

I have been learning about open telemetry by building some instrumentation from the context up. I have now started looking at how I can integrate with the OtelCollectors. This is where things got rough. I soon discovered that the LogMessage Dto does not have a public default constructor. I would have to resort to reflection to instantiate a message. as a systems architect I do not condone hacks in order to accomplish something, because of the risk of breakage in future versions of an SDK.

I started a code review of the open telemetry api. I have discovered a few things.

1. You have tightly coupled the API with the Microsoft diagnostics objects.
2. You have overused the word internal to the point that. 3rd party instrumentation, will have to resort to hacks or rebuilding from the ground up from the versioned dto contracts for the Grpc and Http clients.

• actually found some comments on a internal constructor, do not modify we have a lot of users calling this via reflection.

3. In looking at the code I have seen that the intention was to be open to implementation, but at the last minute minds were changed.

as a consumer of this software, what I would like to see happen.

revisit all public facing data contracts and add a public default constructor, this will make it easy and not a hack to map from 3rd party log, trace, metrics to an open telemetry signal contract.

open up the transformers and exporters so we can export our 3rd party signal and transform it into a open telemetry signal.

• K

[cijothomas]

how I can integrate with the OtelCollectors. This is where things got rough. I soon discovered that the LogMessage Dto

Can you elaborate on this? OTLPExporter from this repo allows exporting to OTel Collector already. What is it missing?

[kccarter76]

I will share with you some snap shots, but keep in mind this all started with a tracing system that does not use system.diagnotics.activity and was implemented from the ground up based on our understanding of the W3C open telemetry and trace context white papers. we started to implement our own ILoggerProvider and wanted be able to export to an otel collector. we learned that we will need to transform what the Microsoft logger outputs to a protobuf request.

are first attempt involved instantiating the OtlpLogExporter, then instantiating an instance of OpenTelemetry.Logs.LogRecord so we could map the log record. this is where it becomes impossible to use OtlpLogExporter without resorting to hacking the log record.

there is no public constructor available and I refuse to resort to reflection to initialize a class from a SDK. because it means that class can change at any time and then I will have to refactor and rebuild. I think it is still funny that you have an obsolete internal constructor that states, don't remove because implementations are calling this via reflection.

the one thing you could do to make this work for me and probable everyone else. is visit each of your OtlpExporters and make it so we have the ability transform our own object into the protobuf service request for the signal that is being exported. and not hard code us to object conventions that microsoft has used. not everyone is onboard with the one family framework.

even turning the LogRecord into ILogRecord and give us a public interface that can be passed to the exporter would meet the needs and still have your code locked down nice and tight and all internalized.

[cijothomas]

One can pass pretty much anything to Scope, but we specially recognize couple of types. Anything else is stored as-is, and it is upto exporters to decide what to do. Most likely exporters do simple ToString()

https:/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry/Logs/LogRecordScope.cs#L44-L58

[cijothomas]

and trace activity source that is NOT system.diagnostics.activity

No, and not planned either. OTel .NET has decided long ago to recognize system.diagnostics.activity as the official Tracing API. Can you tell what is "other activity source"?

[kccarter76]

The company I work for has me working within a very restricted technical stack, and getting them to adopt open telemetry collect information about our cloud of microservices, is a fight I have to do piece meal. I have already demonstrated that I could record selective input using stack frames to collect data about inputs and returns from methods that we needed more information from to help diagnose issues.

Is there any documentation on building custom exporters, for the LogProvider, TraceProvider and MetricsProvider? I need to implement a system that will collect telemetry but I am restricted in what I can log it to. I want to implement a way forward, so I can switch to an OtelCollector at the flip of switch. But until then I am limited to very dated services for logging, trace and metrics data. this is where my requirement comes from in not using the diagnostics activity object.

[cijothomas]

Is there any documentation on building custom exporters, for the LogProvider, TraceProvider and MetricsProvider?

Docs:
https:/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/extending-the-sdk#exporter
https:/open-telemetry/opentelemetry-dotnet/tree/main/docs/trace/extending-the-sdk#exporter
It is often easier to look at example exporters as well.

[kccarter76]

thank you for your back and forth discussion on this. I have since reset our first start of tracing tools and will be refactoring from the ground up using open telemetry. but for the time being I will be implementing custom exporters to make use of our existing tech stack.

then when we actually configure an OtelCollector setting we will only need to configure the OtlpExporterOptions and the toolset will switch over to OtelCollectors instead of what we currently have in production.