Here's what I'd like to see: An end user with NO experience at all comes to the OpenTelemetry project looking to get observability for their application, will be presented with a consistent journey
Step 1: Here's that "all-in-one-solution", and it will do EVERYTHING for you, just plug into your application without changing code, point it to your backend and you are done.
Step 2: Learn how to mix that "all-in-one-solution" with manual instrumentation to "personalize" your observability.
Step 3: Realize that you don't need that "all-in-one-solution" for your application, you can peel it like an onion and eventually end with only the SDK, exporters, resource detectors, instrumentation libraries, etc, that are relevant to your application
Step 4: Understand that SDK & API are decoupled, so you can have dependencies that support otel natively and you can build those libraries with native otel support yourself.
Step 5: 😍 or 🤑
I am creating an issue here as I think that it can be addressed mainly by https://opentelemetry.io/ by structure, creating walkthroughs, etc.
Maybe we need some kind of diagram (mindmap?) that could illustrate what components are available via OTel? For example something more or less like: https://landscape.cncf.io/
related: #1731 -- what you quoted here, is how I think about the "Developer Journey"
also related: #1746 -- the sketch that @cartermp outlined should be the basis of that
By @svrnm here:
I am creating an issue here as I think that it can be addressed mainly by https://opentelemetry.io/ by structure, creating walkthroughs, etc.
Maybe we need some kind of diagram (mindmap?) that could illustrate what components are available via OTel? For example something more or less like: https://landscape.cncf.io/