Public vs Internal - Make sure we limit the things that are public initially

By looking at the code-base I’d say there are too many things that are public.

E.g. on ITransaction there is a public Spans array, and this is an example why this can be a problem in user code:

class MySpan : ISpan
{
  //...all the ISpan stuff
}
		
public static void MyMethod()
{
   Agent.Tracer.CurrentTransaction.Spans[0] = new MySpan { Id = -1 , Duration = -10};
  //leave everything else empty, and send id -1 and everything else as empty values...
}

The server won’t like this…And there are many other examples.

I’d say generally for the first release we should make sure we only make things public that 100% should be public. Adding things later won’t break, so if there is something missing we can add it later easily. On the other hand removing things would break.

Therefore: I’ll go on and make sure that we only have things in public that will very-very likely remain public forever, and make things that are questionable internal, just to be on the safe side.

[gregkalapos]

My explaining seems confusing, in fact I’m not sure if I expressed my thoughts correctly 🤣 in general, what we want is:

1. Interact with OpenTelemetry APIs only (Like ILogger)
2. Suitable for most cases (IServiceProvider)
3. Create different glue libs for different stacks, and those initialization processes should be able to be merged in service initialization (E.g. Microsoft.Extensions.Logger.Console, Microsoft.Extensions.Logger.Debug, etc.)

So what we want to have is an ILogger-like lib - IServiceProvider only, easy for other vendor to integrated with, users use some facade APIs when needed.

Not sure if it’s related, but recently I started prototyping an OpenTelemetry exporter. I guess that’d be the ultimate solution for you, right?

Here is the branch with the code.

In this file you can see how it’s configured for ASP.NET Core. Only this part is ElasticApm related:

services.AddSingleton<ElasticApmExporter>((p) =>
{
   var exportComponent = p.GetService<ISpanExporter>();
   return new ElasticApmExporter(exportComponent);
});

Everything else is just OpenTelemetry.

Here is another sample, that’s a simple console app. Similarly, only this part is ElasticApm related, all the tracing stuff is independent from it, and just by replacing that line you can export to any other APM backend that supports OpenTelemetry. Here is how the prototype looks in Kibana.

How does this look? This is not something we planned for, it’s more like me exploring new things while vacationing, so no promises or timeline here, but if it’s something that helps people I’m sure we’ll consider putting more effort into it.

[yhvicey]

Cool! I guess that’s exact the ultimate solution we’re looking for, thanks for your work! I’ll keep watching your repo and all Telemetry/ElasticApm related works, wish you a good vacation!