community

We've had this for a while now: https://github.com/open-telemetry/community/blob/main/polici...

IMO this boils down how one gets paid to understand or misunderstand something. A telemetry provider/founder is being commoditized by an open specification in which they do not participate in its development -- implied by the post saying the author doesn't know anyone on the spec committee(s). No surprise here. Of course implementing a spec from the provider point of view can be difficult. And also take a look at all the names of the OTEL community and notice that Sentry is not there: https://github.com/open-telemetry/community/blob/86941073816.... This really isn't news. I'd guess that a Sentry customer should just be able to use the OTEL API and could just configure a proprietary Sentry exporter, for all their compute nodes, if Sentry has some superior way of collecting and managing telemetry. IMO most library authors do not have to wor

TBH this sounds more like perf's implementation is bad. I'm waiting for this to happen: https://github.com/open-telemetry/community/issues/1918

otel is working on their events spec https://github.com/open-telemetry/community/issues/1688

1. Agreed. It's the sink and the house attached to it, and the docs are thin and confusing as a result. 2. I had a similar experience to you. I wanted to implement a simple heartbeat in our desktop app to get an idea of usage numbers. This is surprisingly not possible, which greatly confuses me given the name of the project. The low engagement on my question put me off and I abandoned my OpenTelemetry planning completely [1][2]. [1] https://github.com/open-telemetry/community/discussions/1598 [2] https://github.com/open-telemetry/semantic-conventions/issue...

Oh nice, thank you (and also solumos) for the links! It looks like oteps/pull/171 (merged June 2023) expanded and superseded the opentelemetry-proto/pull/346 PR (closed Jul 2022) [0]. The former resulted in merging OpenTelemetry Enhancement Proposal 156 [1], with some interesting results especially for 'Phase 2' where they implemented columnar storage end-to-end (see the Validation section [2]): * For univariate time series, OTel Arrow is 2 to 2.5 better in terms of bandwidth reduction ... and the end-to-end speed is 3.1 to 11.2 times faster * For multivariate time series, OTel Arrow is 3 to 7 times better in terms of bandwidth reduction ... Phase 2 has [not yet] been .. estimated but similar results are expected. * For logs, OTel Arrow is 1.6 to 2 times better in terms of bandwidth reduction ... and the end-to-end speed is 2.3 to 4.86 t

Disclaimer: I work on OpenTelemetry specification and Collector. I don't contribute to Go implementation but I encourage you to submit the feedback to https://github.com/open-telemetry/opentelemetry-go or https://gitter.im/open-telemetry/opentelemetry-go You can also attend Go SIG meetings and provide the feedback directly. SIG meetings are open for attendance: https://github.com/open-telemetry/community#special-interest... I am sure the Maintainers of Go implementation will appreciate your feedback.

It's getting started soon: https://github.com/open-telemetry/community/blob/master/comm... We have a very performant prototype! One usde case I am excited about: taking the OpenTelemetry C++ SDK, and binding it to the OpenTelemetry interfaces in other languages, such as Ruby and Python. Some runtimes may see a performance boost by running the observability code independently from the GIL, GC, etc.