> That is a pretty dark view on almost 1/5th of humanity
The CCP does not represent 1/5 of humanity.
> and a nation with a track record of giving the world important innovations: paper making, silk, porcelain, gunpowder and compass to name the few.
Utter nonsense. It wasn't the CCP who invented gunpowder.
If you are willing to fool yourself into believing that somehow all developments that ever originated by people who live in a geographic region are due to the ruling regime, you'd have a far better case in praising Taiwan.
> Most posts of such format I have seen are "we did this and got this", not "we tried this, it failed because of this, then we figured out something else might work and it worked after these modifications".
That doesn't resemble anything remotely related to teaching how to think. You're just logging your trial and error process, which is exactly what each and every single developer goes through on a daily basis.
> Guess I am unqualified to say that folks who say metrics, logs, and traces are the definition of telemetry is mistaken.
I think you're confused. A set of specialized telemetry types is telemetry, and the definition of telemetry is not limited to a subset of soecialied telemetry types. You know, a cat is an animal but the definition of what's an animal is not "a cat".
I recommend you read over the topic. As you seem to complain about anything related to OpenTelemetry, perhaps reading the same answer from other vendors of telemetry systems might spark an epiphany.
> That's fair but I'll say that the time and number of concepts you have to deal with before going into the code, per the docs; is quite big (...)
That's ok. It's the same for any domain you're just starting to learn. If anyone wishes to, say, onboard onto Cloudwatch or Azure Application Insights they will say exactly the same thing.
> Right, the point I’m making is logs, metrics, traces, these concepts are views of data (...)
Not really. Logs are fundamentally different than operational metrics, which are fundamentally different than business/behavioral metrics, which are fundamentally different than traces, etc etc etc.
This is not a matter of "view". It's the result of completely different system requirements. They are emitted differently, they are processed/aggregated differently, they are stored differently, they are consumed differently.
Even within business metrics types, which is already a specialized type of metrics, you have fundamentally different system requirements. Click stream metrics mix traits of tracing with logging and metrics, and have very specific requirements regarding data protection.
They are all distinct observability features. They are not the same. At all. This is not up for debate.
> This is my main gripe too. I don't understand why {traces, logs, metrics} are not just different abstractions built on top of "events" (blobs of data your application ships off to some set of central locations).
By design, they cannot be abstractions of the single concept. For example, logs have a hard requirement on preserving sequential order and session and emitting strings, whereas metrics are aggregated and sampled and dropped arbitrarily and consist of single discrete values. Logs can store open-ended data, and thus need to comply with tighter data protection regulations. Traces often track a very specific set of generic events, whereas there are whole classes of metrics that serve entirely different purposes.
Just because you can squint hard enough to only see events being emitted, that does not mean all event types can or should be treated the same.
> Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example.
The comment section of that issue gives out contrarian vibes. Apparently the problem is that the Python SDK maintainers refuse to support a use case that virtually all other SDKs support. There are some weasel words that try to convey the idea that half the SDKs are with Python while in reality the ones that support the choices followed by the Python SDK actually support all scenarios.
From the looks of it, the Python SDK maintainers are purposely making a mountain out of a molehill that could be levelled with a single commit with a single line of code.
> IMO this boils down how one gets paid to understand or misunderstand something.
I completely agree. The most charitable interpretation of this blog post is that the blogger genuinely fails go understand the basics of the problem domain, or worst case scenario they are trying to shitpost away the need for features that are well supported by a community-driven standard like OpenTelemetry.
The CCP does not represent 1/5 of humanity.
> and a nation with a track record of giving the world important innovations: paper making, silk, porcelain, gunpowder and compass to name the few.
Utter nonsense. It wasn't the CCP who invented gunpowder.
If you are willing to fool yourself into believing that somehow all developments that ever originated by people who live in a geographic region are due to the ruling regime, you'd have a far better case in praising Taiwan.