Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The problem with OpenTelemetry

cra.mr

Post reply on HN
Print view View original

101–110 of 178 posts

Re: The problem with OpenTelemetry

#101

Post by zeeg »

riedel wrote: post #67
brunoqc wrote: post #59

Earlier quoted context omitted.

But not foss. It's using the BSL or FSL or whatever.

Although I do not like those licences, I would not care so much about 2yrs until it goes FOSS. Before all this rush development RRDTool and OpenTSDB was so slow, this whole thing seems rather ideological than substantial criticism. Now going down the licence rabbit hole based to criticise the original argument seems like a classical strawman.

Just want to say I appreciate your stance.

(also no one should feel like they have to contribute to our SDKs, but please file a ticket if somethings fucked up and we'll deal w/ it)

Re: The problem with OpenTelemetry

#102

Post by esafak »

This caught my eye:

> Logs are just events - which is exactly what a span is, btw - and metrics are just abstractions out of those event properties. That is, you want to know the response time of an API endpoint? You don't rewind 20 years and increment a counter, you instead aggregate the duration of the relevant span segment. Somehow though, Logs and Metrics are still front and center.

Is anyone replacing logs and metrics with traces?

Re: The problem with OpenTelemetry

#103

Post by zeeg »

arccy wrote: post #100
zeeg wrote: post #79

Earlier quoted context omitted.

It’s a bit deeper than that. The SDKs that library authors implement need to be extemely minimal. The collection libraries that vendors implement based on imo should also be minimal. OTLP imo doesn’t even need to be part of the spec. But minimal would also mean focusing on solving fewer problems as a whole. Eg OpenTracing plus OpenMetrics plus OpenLogs. I only need one of those things.

that just sounds like a branding problem though... OTLP has been quite useful especially in metrics to get a format that doesn't really have any sacrifices/limitations compared to all the other protocols.

It is! But to prove your point, OTLP is actually just the transport protocol (Open Telemetry Transport Protocol). Its one of _so many things_ its trying to address. All of those things might be probems, but not everyone has those same problems (vendors, customers, and lib authors), and bundling them all into one umbrella just screams for me.

I actually have no need for a standard metrics implementation, just as an example. I never have, and I'd argue Sentry (as a tech company) never has. We built our own abstraction and/or used a library. That doesnt mean others don't, and it doesnt mean it shouldnt be something people solve, but bundling "all telemetry problems" into one giant design committee is a fundamental misstep imo.

Re: The problem with OpenTelemetry

#104

Post by zeeg »

remram wrote: post #99
EdSchouten wrote: post #53

> Its not a hard problem, [...]. At its core its structured events that carry two GUIDs along with them: a trace ID and a parent event ID. It is just building a tree. I've always wondered, what's the point of the trace ID? What even is a trace? - It could be a single database query that's invoked on a distributed database, giving you information about everything that went on inside the cluster processing that query.…

I think they meant "an event ID and a parent event ID".

I actually meant trace ID and parent event ID (and ID was inferred). Parent comment is correct in that trace ID isnt technically needed, and is in fact quite controversial. Its an implementation level protocol optimization though, and unfortunately not an objective one. It creates an arbitrary grouping of these annotations - which is entirely subjective, and the spec struggles to reconcile - but its primarily because the technology to aggregate and/or query them would be far more difficult if you didn't keep that simple GUID.

It does have one positive benefit beyond that. If you lose data, or have disparate systems, its pretty easy to keep the Trace ID intact and still have better instrumentation than otherwise.

Re: The problem with OpenTelemetry

#105

Post by zeeg »

esafak wrote: post #102

This caught my eye: > Logs are just events - which is exactly what a span is, btw - and metrics are just abstractions out of those event properties. That is, you want to know the response time of an API endpoint? You don't rewind 20 years and increment a counter, you instead aggregate the duration of the relevant span segment. Somehow though, Logs and Metrics are still front and center. Is anyone replacing logs and m…

imo Honeycomb pioneered this, and its the right baseline. There are limitations to it of course, and certainly its been done before at BigCo's that can afford to build the tech, but its extremely powerful.

The main argument for metrics beyond traces is simply a technology implementation - its aggregation because you cant store the raw events. That doesnt mean though you need a new abstraction on those metrics. They're still just questions you're asking of the events in the system, and most systems are debuggable by aggregation data points of spans or other telemetry.

As for logs, they're important for some kinds of workloads, but for the majority of companies I dont think they're the best solution to the problem. You might need them for auditability, but its quite difficult to find a case where logs are the solution to debug a problem if you had span annotations.

Re: The problem with OpenTelemetry

#106

Post by ensignavenger »

brunoqc wrote: post #80
riedel wrote: post #67

Earlier quoted context omitted.

Although I do not like those licences, I would not care so much about 2yrs until it goes FOSS. Before all this rush development RRDTool and OpenTSDB was so slow, this whole thing seems rather ideological than substantial criticism. Now going down the licence rabbit hole based to criticise the original argument seems like a classical strawman.

I was supporting a variation in my head of the "Yeah but who wants to contribute to an SDK for a service that you need to pay for?" claim. You can self-host for free, so maybe @hahn-kev don't mind contributing to the SDK now. For me, I refuse to contribute to an open-source SDK for a non-foss product. And I refuse to self-host a non-foss product. Personally, I don't care if non-foss licenses speeds development. So ye…

https://glitchtip.com/ is an Open Source form of Sentry created after they went closed source, if you are interested in something like that.

Re: The problem with OpenTelemetry

#107

Post by dan-allen »

I keep checking in on OpenTelemetry every few months to see if the bits we need are stable yet. There’s been very little progress on the things we’re waiting for.

I don’t follow closely enough to comment on possible causes.

What I do know is that the surface area of code and infrastructure that telemetry touches means adopting something unfinished is a big leap of faith.

Re: The problem with OpenTelemetry

#109

Post by remram »

zeeg wrote: post #104
remram wrote: post #99

Earlier quoted context omitted.

I think they meant "an event ID and a parent event ID".

I actually meant trace ID and parent event ID (and ID was inferred). Parent comment is correct in that trace ID isnt technically needed, and is in fact quite controversial. Its an implementation level protocol optimization though, and unfortunately not an objective one. It creates an arbitrary grouping of these annotations - which is entirely subjective, and the spec struggles to reconcile - but its primarily because…

3 GUIDs then, event ID was inferred. I see.

Re: The problem with OpenTelemetry

#110

Post by doctorpangloss »

tnolet wrote: post #50
hahn-kev wrote: post #42

Earlier quoted context omitted.

Yeah but who wants to contribute to an SDK for a service that you need to pay for? That would be like if Oracle DB was open to contribution

Sentry is self hostable. https://develop.sentry.dev/self-hosted/

PostHog and Rudderstack say the same things. They're not really self hosted. But that's the rub, if someone authored a good operator for Sentry, Sentry as a commercial service would cease to exist. That's not good in my opinion, they do real innovative stuff.

It's tough. We should have never done "give away the software, charge for hosting." The market, in every sense, has been telling you that you're really building value for AWS, for years, by doing that.

Post reply on HN