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

Why and how GitHub is adopting OpenTelemetry

github.blog

Post reply on HN
Print view View original

91–100 of 113 posts

Re: Why and how GitHub is adopting OpenTelemetry

#91

Post by kortex »

weberer wrote: post #89
kortex wrote: post #66

Mandatory "do some research before jumping to freaking out at GitHub for 'spyware.'" Yes technically you could use OT to exfiltrate data; guess what, you can do it with http headers, too. Been using OpenTelemetry for python and golang. It's great. I really like using Jaeger for tracing across small ML webapps. We have users on the scale of dozens so I just trace everything without sampling. Way, way easier than going…

They problem is that Microsoft continuously used the term "telemetry" as a euphemism for the dystopian corporate spyware they shipped with Windows 10. So now to the average end user, the two concepts are the same. This is compounded by the fact that Github is now a Microsoft company and Microsoft has been caught in the past hiding "telemetry" in programs compiled with Visual Studio. https://old.reddit.com/r/cpp/comme…

I get what you are getting at, but It's not really a euphemism. Telemetry means literally "distant measurement." You can use telemetry to track sensors in a rocket, a request across a service mesh, a traceback from a crash in a user program, fine-grained details about everything a user does in Windows, or a straight-up keylogger. All are forms of telemetry.

The VS telemetry injection is scary as hell though.

Telemetry is like a knife. Context and location matters. Great in the kitchen, bad when lodged in your back.

Sharing this from myself downthread:

Telemetry is the in situ collection of measurements or other data at remote points and their automatic transmission to receiving equipment (telecommunication) for monitoring. The word is derived from the Greek roots tele, "remote", and metron, "measure".

All spyware is, by definition, telemetry. Heck, the whole field of spycraft ( espionage ) is telemetry of sorts. Not all telemetry is spyware.

Re: Why and how GitHub is adopting OpenTelemetry

#92

Post by kortex »

jonatan-ivanov wrote: post #75

It's an interesting move given that OTel is not stable yet. :o

Why is this controversial? OT is great but it's not totally production ready imho. I tried integrating it last year in Python and had almost weekly breaking changes to the internal API calls. I mean, it was a 0.x, so they were well within their liberty, also they don't owe me anything. But it was a bit of a false start for me.

Finally they released a 1.0 and the interfaces are more stable, but the docs are still incomplete or stale in some places. I currently use it in a minor way.

Frankly I can't wait because I love the tools and ecosystem, but I personally would be hesitant to put it into full blown production at such a big company.

Re: Why and how GitHub is adopting OpenTelemetry

#93

Post by kortex »

yannoninator wrote: post #90
scrollaway wrote: post #59

Earlier quoted context omitted.

You're getting downvoted because you are complaining about something you don't understand, which puts into question the "after reading this" part of your post. Jumping on the first opportunity to rant about telemetry without even checking what the article is talking about will do that.

then why name it open "telemetry" in the first place? you know it has an extremely bad connotation to spyware. > which puts into question the "after reading this" > without even checking what the article is talking about will do that. please don't do that, this is against the HN guidelines. https://news.ycombinator.com/newsguidelines.html

Telemetry is the in situ collection of measurements or other data at remote points and their automatic transmission to receiving equipment (telecommunication) for monitoring. The word is derived from the Greek roots tele, "remote", and metron, "measure".

Why name it the precise thing that it literally is?

Telemetry is used everywhere: rockets, drones, airplanes, boats, water meters, microservices, applications, and yes spyware, bots, viruses, and keyloggers. All spyware is telemetry by definition: "remote measuring." Not all telemetry is spyware.

Re: Why and how GitHub is adopting OpenTelemetry

#94

Post by drewbug01 »

jonatan-ivanov wrote: post #75

It's an interesting move given that OTel is not stable yet. :o

One of our goals with early adoption is to contribute back the things needed to make it stable, performant, and useful for everyone. It might make things more difficult for us at times, but we feel we can manage the burden.

It’s obviously not our only goal, but we are in a position to help make the system better for everyone and sincerely wish to do so.

Re: Why and how GitHub is adopting OpenTelemetry

#95

Post by devops000 »

speedgoose wrote: post #84
devops000 wrote: post #83

What are good solutions for charts and alerting for data sent from OpenTelemetry?

Is OpenTelemetry the right tool ? In my team, we started using it but we kept Prometheus and Grafana to have charts and alerts.

Why not using Datadog?

Re: Why and how GitHub is adopting OpenTelemetry

#96

Post by bassdropvroom »

hendry wrote: post #82
bassdropvroom wrote: post #80

Earlier quoted context omitted.

Opentelemetry is a lot more than that. It can handle traces across services.

You can log and use a tool like AWS LogInsights to see the trace across services.. No code changes needed.

Great, so now link each request across services, combined with the timings of each individual component within each service. LogInsights is for logging, not tracing. Logging is not a replacement for tracing.

Re: Why and how GitHub is adopting OpenTelemetry

#97

Post by speedgoose »

devops000 wrote: post #95
speedgoose wrote: post #84

Earlier quoted context omitted.

Is OpenTelemetry the right tool ? In my team, we started using it but we kept Prometheus and Grafana to have charts and alerts.

Why not using Datadog?

We are in the health care industry, so we are not keen about sending our data to third parties. We also prefer open-source technologies.

Re: Why and how GitHub is adopting OpenTelemetry

#98

Post by ungzd »

jeffbee wrote: post #19
StreamBright wrote: post #10

I think it would be great to show the performance impact of these SDKs because it is one of the really important aspects of monitoring (being non-intrusive).

I've noticed that orgs where I've worked vary between being totally insensitive to observability cost to being real hardasses about it. But I think most smaller shops are falling into the former category. I've even heard in meetings crazy shit like "It's very low overhead, only about 5%" which would get you laughed out of the office at, say, Google. Unfortunately (to me) the focus on ease-of-use has meant that OpenTe…

> Unfortunately (to me) the focus on ease-of-use has meant that OpenTelemetry concepts are structured in such a way to preclude even the possibility of a very efficient implementation

Looks like Opentelemetry (at least its precedessor, OpenCensus) is originated from Google. From OpenCensus website (https://opencensus.io/):

> OpenCensus and OpenTracing have merged to form OpenTelemetry

> OpenCensus originates from Google, where a set of libraries called Census are used to automatically capture traces and metrics from services.

Original internal Google tracing system was probably designed for scale. And opentelemetry's design is probably based on that internal system.

So, maybe poor performance is just an implementations issue.

Re: Why and how GitHub is adopting OpenTelemetry

#99

Post by jeffbee »

ungzd wrote: post #98
jeffbee wrote: post #19

Earlier quoted context omitted.

I've noticed that orgs where I've worked vary between being totally insensitive to observability cost to being real hardasses about it. But I think most smaller shops are falling into the former category. I've even heard in meetings crazy shit like "It's very low overhead, only about 5%" which would get you laughed out of the office at, say, Google. Unfortunately (to me) the focus on ease-of-use has meant that OpenTe…

> Unfortunately (to me) the focus on ease-of-use has meant that OpenTelemetry concepts are structured in such a way to preclude even the possibility of a very efficient implementation Looks like Opentelemetry (at least its precedessor, OpenCensus) is originated from Google. From OpenCensus website ( https://opencensus.io/ ): > OpenCensus and OpenTracing have merged to form OpenTelemetry > OpenCensus originates from G…

OpenCensus bears no resemblance whatsoever to Google Census, except for the name. Census at Google is wired tight as hell. Any time it showed up on the first page of fleet-wide profiles it would get hammered back down. At the same time it also has more capabilities than its open source successors. Unfortunately, nothing has ever been published about it.

Re: Why and how GitHub is adopting OpenTelemetry

#100

Post by dgildeh »

I did a blog on using OpenTelemetry with Python/Google Cloud Run and source code here if anyone is interested:

https://davidgildeh.com/2021/03/08/running-python-openteleme...

I need to update the code as I didn't use the BatchSpanProcessor and as a result all my calls are taking 2-3 seconds vs. a more reasonable 300ms.

My only issue so far is the stability and maturity of the project. Now they're at V1 stability of the main SDK looks better, but the instrumentation libraries are still all over the place and need some cleaning up/maturing.

I like the vision though and we're keeping an eye on the project as it matures.

Post reply on HN