Live data from Hacker News

OpenTelemetry

opentelemetry.io

61–70 of 72 posts

Re: OpenTelemetry

#61
post #2

I hate that this specification and most of the other ones use spans that have a beginning and end rather than events that start and end the span. What if it crashes before it sends out the span? What if it is taking a very long time to complete?

I think you are right and data model should have been event based rather than span based. https://medium.com/opentracing/open-for-event-based-tracing-... digs into that topic and basically says that distributed tracing is about causality & partial ordering which bring us back to the 70's with Lamport's logical clocks and all following work.

However, this design "flaw" is well known and seems assumed. I'm not able to find relevant GitHub issues right now, but I remember this topic being discussed on OpenTracing or OpenTelemetry bug tracker and the outcome was something like "Spans might not be the best data model, but people are now used to it and we have to ship the spec within a reasonable time, so let's stick to it".

Edit: https://github.com/open-telemetry/opentelemetry-specificatio... might be relevant to your concerns.

Re: OpenTelemetry

#62
post #25

Earlier quoted context omitted.

Yeah, OpenTelemetry was OpenCensus, and before that it was OpenTracing. The go client faces some of the same churn; metrics are in alpha and the API isn't documented, though spans and traces are on more solid ground than the Java client it seems. It's been a lot of change and I can't wait for things to settle down and for companies to stop trying to get their piece. I feel like everyone (Datadog, NewRelic, Google, et…

Lightstep was one of the originators of the combined spec -- but yes, the churn has been really painful, and we're sorry for the pre-1.0 pain. Now that the spec is 1.0 and most of the language SIGs have put out 1.0 API/SDK releases for tracing, hopefully that pain will reced.

Do you have an insight on the timeline for stabilizing the metrics and logging specs?

Re: OpenTelemetry

#63
post #57

I belive OpenTelemetry will make distributed tracing mainstream. Traces are the best tool to debug problems, yet as their are expensive (both in dev work and license) to implement they are way less popular than logs. Historicaly APM (application performance monitoring) also owned collection, vendor locked-in and didn’t evolve price per value. Open-source collection standard allows users to choose or switch to the bes…

I'm curious, who's your target customer? Should small teams be looking early on or is this more of a mid-sized company thing?

At almost $100 per GB of logs ingested, I think it’s targeted at SV startups.

Re: OpenTelemetry

#64

As someone not familiar with this project, and looking at the landing page, I have no idea what this does. I understand it has something to do with telemetry, but for what? And what would it help me with? How would I use it. I see a telescope. Is it space related? Telemetry of satellites? Just my two cents as someone not familiar with the project, and has no idea how to use it or how it would solve a problem I have.

Does this section here help? It’s below the fold on Mobile, but it is on the front page of the site.

> OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.

Re: OpenTelemetry

#65

As someone not familiar with this project, and looking at the landing page, I have no idea what this does. I understand it has something to do with telemetry, but for what? And what would it help me with? How would I use it. I see a telescope. Is it space related? Telemetry of satellites? Just my two cents as someone not familiar with the project, and has no idea how to use it or how it would solve a problem I have.

It's a collection of open standards and libraries for exporting/injesting Traces and Metrics from your applications (and logging is in the works)

Re: OpenTelemetry

#66
post #57

I belive OpenTelemetry will make distributed tracing mainstream. Traces are the best tool to debug problems, yet as their are expensive (both in dev work and license) to implement they are way less popular than logs. Historicaly APM (application performance monitoring) also owned collection, vendor locked-in and didn’t evolve price per value. Open-source collection standard allows users to choose or switch to the bes…

I'm curious, who's your target customer? Should small teams be looking early on or is this more of a mid-sized company thing?

Though Sumo Logic started by targeting mid-size to enterprise, recently it invests more in self-serve:

1. Free plan includes Tracing.

2. There is monthly self-serve subscription available.

Re: OpenTelemetry

#67
post #54

Anybody has a recommendation on litterature/blogs addressing the subject of observability? I’m contemplating an SRE job offer and although I have my share of knowledge, I am still out of my league whenever I glance at the cncf map in the observability category. I feel that the field has exploded with new components and new ways, and I’m sometimes afraid of taking the wrong path.

* Observability Engineering (Charity Majors, Liz Fong-Jones, George Miranda) * Software Telemetry (Jamie Riedesel)

Re: OpenTelemetry

#68
post #57

Earlier quoted context omitted.

I'm curious, who's your target customer? Should small teams be looking early on or is this more of a mid-sized company thing?

At almost $100 per GB of logs ingested, I think it’s targeted at SV startups.

It is ~$93 / month for 1 "GB per day" not per GB.

Re: OpenTelemetry

#69

Earlier quoted context omitted.

Lightstep was one of the originators of the combined spec -- but yes, the churn has been really painful, and we're sorry for the pre-1.0 pain. Now that the spec is 1.0 and most of the language SIGs have put out 1.0 API/SDK releases for tracing, hopefully that pain will reced.

Do you have an insight on the timeline for stabilizing the metrics and logging specs?

A good place to look at is the milestones on GitHub: https://github.com/open-telemetry/opentelemetry-specificatio...

Logging is still experimental in the spec. Metrics API is feature freeze and the protocol is stable, so it's more on language SDKs to stabilize their implementations. This is a focus for several of them right now.

Re: OpenTelemetry

#70
post #57

I belive OpenTelemetry will make distributed tracing mainstream. Traces are the best tool to debug problems, yet as their are expensive (both in dev work and license) to implement they are way less popular than logs. Historicaly APM (application performance monitoring) also owned collection, vendor locked-in and didn’t evolve price per value. Open-source collection standard allows users to choose or switch to the bes…

I'm curious, who's your target customer? Should small teams be looking early on or is this more of a mid-sized company thing?

In my experience Sumo is a mid to large solution. A startup can get by with their own stack to start. Then they might use something managed as they get big, and once they’re big enough to have dedicated teams, they can run something themselves again. Minus storage and data transfer (the bulk of expense) the hardware to run your own stack probably runs $20 a day or less on a cloud provider, and with a small team where communication about standards is easier it takes less engineering time. My professional opinion is that they should then switch to a managed solution like Sumo when the number of services they are supporting grows. Everyone, myself included, underestimates how many full time people you’re going to need to dedicate to running a serious OpenTel/Elk/Prometheus/Jaeger stack yourself. The pain of migration and upgrading, managing indexes and proper whitelists, even just working with teams to get onboarded and get their dashboards/alerts setup right, using spot instances to desperately claw back every dollar…at my current workplace our custom stack was supposed to be cheaper and ended up costing magnitudes more (under control now) during this learning curve. When I start at a new company I’m probably going to suggest we use Sumo, and this is coming from someone who used to say “we don’t buy solutions we build solutions”.

Lately I am leaning into managed more and more - I want to spend my time building great dashboards, or analyzing my data, or writing some code for something else entirely. If you run your own stack you are always keeping up not doing the really useful stuff. Getting a working baseline is hard enough, let alone shiny extras. You’ll watch the talks at whatever conference, you’ll read the single line “quick start docs”, it will sound amazing. Then you’ll find yourself deep in months later with a giant data transfer or storage bill and hours of painstaking tuning ahead of you.

If you’re really large, then you can go back to running it yourself.

Post reply on HN