What I wanted: Small library that just prints to stdout in a standard format. No network code in that library. A separate executable that actually sends the logs to wherever needed, and whose vulnerabilities can be fixed independently from my app.
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.
The small library you want is likely the standard (or popular) logging library in your language/framework. For example in Node.js that might be Pino or Winston.
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 :)
OpenTelemetry is a large suite of software, that supports many use cases. I think you got what you wanted but didn't realise it!
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.
Comments
What I wanted: Small library that just prints to stdout in a standard format. No network code in that library. A separate executable that actually sends the logs to wherever needed, and whose vulnerabilities can be fixed independently from my app.
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.
The small library you want is likely the standard (or popular) logging library in your language/framework. For example in Node.js that might be Pino or Winston.
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 :)
OpenTelemetry is a large suite of software, that supports many use cases. I think you got what you wanted but didn't realise it!
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...