The dedicated executable that you are after is called the OpenTelemtry Collector.
The OpenTelemetry SDK for your language of choice should include many exporters, which describe the format and transport mechanism for the traces. The exporters can be installed separately from the core SDK. The OpenTelemetry Collector can then use an appropriate receiver to ingest those traces.
Here is a file based receiver for the collector:
https://github.com/open-telemetry/opentelemetry-collector-co...
The automatic instrumentation part is for tracing, which arguably is a _huge_ value add on top of logging, but is indeed more complicated to get setup.
Unfortunately I think OpenTelemetry doesn't do a great job in expressing the different parts of the project and how they all fit together (though this is the status quo in observability in general). I think third party vendor documentation tend to do a better job in explaining how to get started with it without needing to piece together the exporters, batchers, context managers, etc.
Disclaimer: I'm building hyperdx, an otel-based OSS observability tool, so I'm pretty biased in being pro-OpenTelemetry :)
What I got: The kubernetes of observability. Load a bunch of libraries that connect to the network from inside your app. If you can't use automatic instrumentation then now you have setup your exporters, providers, processors, and whatever. Everything feels too brittle. Its big surface area means I fear the next refactor where every setting will get a different name and functions get deprecated even if the actual telemetry format doesn't change.