[feature request] Official file exporter

[DrEsteban]

Package

None

Is your feature request related to a problem?

No response

What is the expected behavior?

It would be nice if there were an "official" filesystem exporter for traces/logs/metrics in .NET. I find it useful for local debugging, as well as job-based workloads where the logs could be exported or further processed.

Which alternative solutions or features have you considered?

I've copy/pasted the implementation of the ConsoleExporter(s) and simply updated the WriteLine() method in the base class to write to a FileStream instead of the console.

This is fine for most cases, (aside from the annoyance of having to copy/paste/adapt), but it's obviously in a very human-readable format. It'd be nice if there were perhaps 2 official implementations or modes: One to output in a similar human-readable format, and one that's serialized for a more machine-readable format.

Additional context

#5231

[cijothomas]

Once open-telemetry/opentelemetry-specification#4183 lands, this is doable.

[martinjt]

The relevant one is this: open-telemetry/opentelemetry-specification#3817

Whether that will become a thing is a different question. From stdout you should be able to pipe the data though, and in all other scenarios, a collector with the file exporter would likely be the more efficient way to do this.

I suppose we'll see whether this becomes a requirement, but until then, there are other ways this can be achieved and therefore I don't think we should leave this open.

[DrEsteban]

@martinjt What do you mean by "there are other ways this can be achieved"? (And therefore this issue should be closed.)

Regardless of whether it's possible to create an output file by doing things like stdout redirection, I still think there's value in having an in-process way of creating an output file. Something that doesn't require additional environment setup to achieve. There are plenty of situations where that type of additional setup isn't possible.

[martinjt]

This isn't something that we'd build as part of the core of OpenTelemetry-dotnet since the recommended approach is to use OTLP. What you would need to do for this is propose a contrib component and find a maintainer for it.

Alternatively, it would be petitioning the OpenTelemetry Specification committee's to add this as a requirement to all languages. There have been discussions and the general consensus was that stdout redirection is sufficient for the edge cases where this is to be used over using OTLP and potentially a collector.

Unfortunately, the project can't maintain lots of different components, and where there is a Specification precedence, we follow that. I can understand that this is functionality that other frameworks have provided over the years as well, however, we're trying to set an example of modern telemetry, and that should involve OTLP at it's core.