Live data from Hacker News

AWS X-Ray – Distributed Tracing System

aws.amazon.com

71–80 of 104 posts

Re: AWS X-Ray – Distributed Tracing System

#71
post #70

Earlier quoted context omitted.

Yeah, there's a big difference between something that's pure distributed tracing (this) and something that does metrics/monitoring as well (TraceView, New Relic, ...). Sampling is a valid way to make distributed tracing scalable and performant, but it can also limit the use-cases for the data. I imagine this being used for episodic debug cases, where one could turn up the sample rate and pay only for the traces captu…

> difference between something that's pure distributed tracing (this) and something that does metrics/monitoring as well (TraceView, New Relic, ...) I don't see the distinction you're making, as neither seems to record all traces for accurate audit. Am I missing it?

I was speaking to a more general monitoring approach where you might want to know p99 latency, request volume, error rate, etc, for each service to use in alerting and trending. This is a common use-case for application monitoring that isn't addressed well by a pure tracing approach.

If you're looking specifically for the 100% audit trail case, I'd look at DynaTrace or potentially Instana.

Re: AWS X-Ray – Distributed Tracing System

#72
post #16

If you're interested in distributed system tracing there's a lot going on. As a starting point, I would recommend reading Google's paper on their project "Dapper." [1] It's essentially the core of most distributed tracing systems. At least those I've encountered. There's a lot of tooling out there that take their cues from Dapper. I've recently been looking into integrating OpenZipkin[2] with our systems. I see at as…

We've been instrumenting Zipkin in our environment over the last couple of months and it has been excellent to work with. While there are a couple of snags here and there, it is _amazing_ at how quickly it can bring bottlenecks and bad network calls to light.

Re: AWS X-Ray – Distributed Tracing System

#73
post #16

If you're interested in distributed system tracing there's a lot going on. As a starting point, I would recommend reading Google's paper on their project "Dapper." [1] It's essentially the core of most distributed tracing systems. At least those I've encountered. There's a lot of tooling out there that take their cues from Dapper. I've recently been looking into integrating OpenZipkin[2] with our systems. I see at as…

Those are the comments I come here for. I was reading this and dreaded the lock-in. Thanks for pointing out sane alternatives!

My masters thesis is X-trace derived, as well as a paper we published at ICPE a few years ago. I'm on mobile so don't have a link handy. You can probably guess my name from my username.

Re: AWS X-Ray – Distributed Tracing System

#74
post #64
post #32

Earlier quoted context omitted.

If your software was AGPL, we wouldn't use it, and hence wouldn't contribute patches. Plenty of other companies would be the same. That might or might not be a downside to you.

Plenty of companies would also use the non-AGPL software without any strings attached, and not contribute patches anyway . You may be lucky enough to get bug reports, though (and, in effect, become a free labor source for a corporation). So what's the point? Most of the time, this kind of position just comes across as a vague, empty posturing, to be quite honest. "I could definitely be a good friend to you, you see..…

I believe, respectfully, that you're reading posturing into my position where none exists.

In a typical scenario for us, we use some open source software for our SaaS platform. We need to extend it in ways that weren't envisaged, so we (a) add some hooks to allow extensions and (b) add the extensions themselves.

Our preference is to contribute both (a) and usually (b) back to the project. But sometimes for business reasons we can't contribute (b), or at least not until more people internally have their heads around it.

AGPL stops us from contributing (a) and not (b). So we just don't use AGPL software.

I wasn't trying to poison the well, I was just indicating what our decision making process is. Some people, like us, have valid business reasons for not using AGPL software, even though we love OSS.

I find it weird that this narrative thing pops up here. There's no narrative. If I was the owner of said AGPL software, I probably wouldn't give a rat's arse if anyone said they weren't going to use my software.

But my original post was a specific response to someone who said "Not sure what the downsides are." [of using AGPL].

So let me try again. Here's one possible downside - *you may miss out on some patches that you would have otherwise got, since your license is incompatible with some people's business needs".

Re: AWS X-Ray – Distributed Tracing System

#75
Some have mentioned is this full APM and does this compete with New Relic, Dynatrace, Stackify, Appdynamics, App Insights, etc.

Those products are primarily based on code profiling. For example, at Stackify we automatically profile key methods for dozens of common dependencies and frameworks to understand their usage and performance. Every SQL, NoSQL, caching, queuing providers and many other things. Plus app errors, logs, etc.

So the best I can tell from the AWS blog and docs is the answer is no its not a full APM. It appears to track how long a web request takes and any usage of the AWS services via their SDK. More of a lightweight service mapping of AWS services. So SQL database or HTTP calls probably aren't tracked.

In the future could they expand it? Sure. But for now it seems limited compared to a full blown APM product. Although this could be help for identifying performance problems with AWS services.

Matt - Founder of Stackify

Re: AWS X-Ray – Distributed Tracing System

#76
post #38
post #32

Earlier quoted context omitted.

If your software was AGPL, we wouldn't use it, and hence wouldn't contribute patches. Plenty of other companies would be the same. That might or might not be a downside to you.

As someone who writes AGPL software, I will say to most of us it isn't a downside: I would conceptialize that scenario as "your loss" and hope that my work helps give companies who are more friendly to the idea of community software at least a little bit of a competitive advantage over your company. In all seriousness: if you are intending to not contribute changes back (which is the only legitimate reason to avoid G…

Totally agree that it is indeed "our loss". No argument there.

I don't want to appear a kook, so I won't relitigate what I said in another reply. But essentially we do want to give back. We just aren't always able to give back everything (at least not right now).

AGPL, like GPL, is all or nothing in that way. I don't get the option of giving back something, then giving back more later (OSS is threatening to some people - I have frequent discussion at work re why we give anything at all back).

Your software, your rules. You have every right to take this all or nothing position! More power to you.

But assuming that anyone that doesn't like AGPL does so because they "want to use someone else's work while hoarding [their] own" is, respectfully, a simplistic and stereotyped point of view.

Re: AWS X-Ray – Distributed Tracing System

#77
post #16

If you're interested in distributed system tracing there's a lot going on. As a starting point, I would recommend reading Google's paper on their project "Dapper." [1] It's essentially the core of most distributed tracing systems. At least those I've encountered. There's a lot of tooling out there that take their cues from Dapper. I've recently been looking into integrating OpenZipkin[2] with our systems. I see at as…

Stackdriver Trace [1] is Google's external implementation of Dapper with additional analysis features. It's available for free, even for workloads not running on Google Cloud Platform.

(Disclosure: I work on it)

[1]: https://cloud.google.com/trace/

Re: AWS X-Ray – Distributed Tracing System

#78
post #16

If you're interested in distributed system tracing there's a lot going on. As a starting point, I would recommend reading Google's paper on their project "Dapper." [1] It's essentially the core of most distributed tracing systems. At least those I've encountered. There's a lot of tooling out there that take their cues from Dapper. I've recently been looking into integrating OpenZipkin[2] with our systems. I see at as…

And if you're curious about how this sort of thing could look on the client/browser side of things, check out https://opbeat.com/react

(I work on it)

Re: AWS X-Ray – Distributed Tracing System

#79
post #38
post #32

Earlier quoted context omitted.

If your software was AGPL, we wouldn't use it, and hence wouldn't contribute patches. Plenty of other companies would be the same. That might or might not be a downside to you.

As someone who writes AGPL software, I will say to most of us it isn't a downside: I would conceptialize that scenario as "your loss" and hope that my work helps give companies who are more friendly to the idea of community software at least a little bit of a competitive advantage over your company. In all seriousness: if you are intending to not contribute changes back (which is the only legitimate reason to avoid G…

The worry, places I've worked, is that the GPL would spread to proprietary stuff, like a kind of legal infection.

They worry that if they use an AGPL javascript library for the video player on their front page, they'll have to opensource the whole web application (I've even sat in on debates over weather using GPL3 programs means you have to opensource any source data you use them to process and publish the result).

A lot of this is silly, but a lot of it isn't. A large company I worked for stopped using Linux after they were forced by a court to opensource a custom video processing microchip because they ran Linux on the box and drove the chip through a kernel driver.

Re: AWS X-Ray – Distributed Tracing System

#80
post #72
post #16

If you're interested in distributed system tracing there's a lot going on. As a starting point, I would recommend reading Google's paper on their project "Dapper." [1] It's essentially the core of most distributed tracing systems. At least those I've encountered. There's a lot of tooling out there that take their cues from Dapper. I've recently been looking into integrating OpenZipkin[2] with our systems. I see at as…

We've been instrumenting Zipkin in our environment over the last couple of months and it has been excellent to work with. While there are a couple of snags here and there, it is _amazing_ at how quickly it can bring bottlenecks and bad network calls to light.

Are you guys using finagle?
Post reply on HN