Repository navigation
[feature request] Official file exporter #5920
Description
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.
Activity
[-][feature request] Official File exporter [/-][+][feature request] Official file exporter [/+]cijothomas commentedon Oct 23, 2024
Once open-telemetry/opentelemetry-specification#4183 lands, this is doable.
martinjt commentedon Nov 13, 2024
The relevant one is this: open-telemetry/opentelemetry-specification#3817
Whether that will become a thing is a different question. From
stdoutyou 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 commentedon Dec 30, 2024
@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
stdoutredirection, 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 commentedon Dec 31, 2024
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.
cijothomas commentedon Feb 5, 2025
Reopening as spec is still discussing whether this is required or not:
open-telemetry/opentelemetry-specification#3817
PadreSVK commentedon Mar 25, 2025
Hi, any updates on this? :)
cijothomas commentedon Mar 25, 2025
@PadreSVK None is actively working on this from what I know of. The best way to get this would be if you can contribute this. It can be a contrib repo component for now.
jingren1021 commentedon Nov 17, 2025
Hi, is there any contributor working on this?
cijothomas commentedon Nov 17, 2025
No, its still unassigned!
sgryphon commentedon Dec 29, 2025
I have a proposal related to this, for a developer-focused console export formatter #6391
The initial proposal is small based on just creating readable console logs (for a developer), so not exactly the same as this (it doesn't cover generic file, OTLP JSON format, etc). But it's a start.