open-telemetry
How do we document & promote non-collector & non-language projects?
We have a few projects within OTel that are currently not having a proper place within our docs (maybe mentioned somewhere put not as highlighted as the languages & collector):
- K8s operator + helm charts
- Lambda
- Demo
- OpAMP
- sql commenter
- flowmill / ebpf
- "middleware" instrumentation like Apache & Nginx within CPP Contrib
Let's have a case-by-case discussion if/how/when we want to have them included into the docs.
cc @open-telemetry/docs-approvers
Great question. Tough one too. I could see the k8s operator being something we document and promote here, especially since it's vendor-neutral. But serverless platforms, despite being prevalent, aren't vendor-neutral and so I'd have to think about how I feel about that.
I guess my initial feelings about what should be documented here:
- K8s operator + helm charts ✅
- Lambda
- Demo ✅
- OpAMP ✅
- sql commenter
- flowmill / ebpf
- "middleware" instrumentation like Apache & Nginx within CPP Contrib
Then there's cases like sql commenter, which isn't vendor-specific anymore. It's sort of like an autoinstrumentation package. So I guess that could be documented too, but not necessarily more prominently than anything else.
Yeah, the items on the list are not equal in the way how/if we should promote them.
I also had the feeling that K8s operator, demo & opamp deserve a prominent place. Those are the one we should focus on
Lambda: yes, I also don't know what a good approach is, maybe have a "serverless" section somewhere, that has all of them (including some of the content we had on knative?)
For sql commenter we could see if it helps to have it on a language level?
I was listing nginx & apache additionally not only because my teams have created them, but also because they point out that you can use opentelemetry to achieve native instrumentation for often-used pre-compiled software as well (envoy, haproxy, etc. would also come to mind), maybe worth a separate discussion.