By all means they should change but I hope not to the interest of very vocal tech minority, who are already elite in their own counties, and to the detriment of other deserving groups.
> OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
You can absolutely categorize telemetry into these high-level pillars, true. But the specifics on how that data is captured, exported, collected, queried, etc. is necessarily unique to each pillar, programming language, backend system, organization, etc.
That's because telemetry data is always larger than the original data it represents: a production request will be of some well-defined size, but the metadata about that request is potentially infinite. Consequently, the main design constraint for telemetry systems is always efficiency.
Efficiency requires specialization, which is in direct tension with features that generalize over backends and tools, e.g.
> Traces, Metrics, Logs -- Create and collect telemetry data from your services and software, then forward them to a variety of analysis tools.
and features that generalize over languages, e.g.
> Drop-In Instrumentation -- OpenTelemetry integrates with popular libraries and frameworks such as Spring, ASP.NET Core, Express, Quarkus, and more! Installation and integration can be as simple as a few lines of code.
I think OTel treats these goals -- which are very valuable to end users!! -- as inviolable core requirements, and then does whatever is necessary to implement them. But these goals are not actually valid, and so the resulting code is often inefficient, incoherent, or even unsound.
Thats correct, in my previous company, we had a full internal infrastructure that provides daily or hourly perforamnce of advertisements that hits all major social media APIs.
I work in adtech and yeah if there is a discrepancy the advertiser will 100% contact their account manager about it. Same goes for the supply side, publishers maintain what they expect to be paid and will raise any discrepancies as well.
Usually it is just a misunderstanding of the metrics, but if there is an issue they will always open a ticket with the engineering teams. They also expect some level of discrepancy since the volume of data is so large.
a random aside, I truly thank you for your course. You're the teacher I wish I had in my bachelor's 8 years back. Singlehandedly revived my interest in learning databases. :).
Through your course, I reached a stage where I can help OSS projects and its features.
