Please consider using prepend rather than alias_method

[rosenfeld]

Please, read this article from NewRelic on the subject. I feel that it will become more and more usual for people to use the prepend method introduced in Ruby 2.0 than keep using alias_method. Since you are starting this project recently, it would be a good time to change the approach to prefer prepend over alias_method:

https://blog.newrelic.com/2016/12/15/ruby-agent-module-prepend-alias-method-chains/

Thanks for building tracebin! I've been thinking about building my own APM solution for quite some time but never found the time to do that, so it's nice to see such projects being created :)

I haven't tried your solution yet, but I'm curious about one thing. I find it great that you store and start and end times and not only the duration. We have an special case in one of our expensive requests where we fetch multiple data from the database concurrently, using separate connections in separate threads to speed things up. It seems that out of the box it won't work with your solution or any other I'm aware of because usually you'll set those values in thread-local variables, which is fine. However, supposing I would instrument those queries run in separate threads manually, I'm curious how those would be presented in a transaction. I mean, I'd expect to see them like I see the static resources in Google Chrome's DevTools for example, in which I can see when each resource is starting and when they finish running. Simply summing all times to calculate the total duration would lead to a greater duration than the actual total request duration, of course, that's why it would be interested to see such requests in a timeline view. Does your UI support something like that?

[aastronautss]

Hi, thank you so much for your feedback! The next version will most likely use prepend (as you said, it's better to catch it early)--the main reason I chose alias_method for now was my familiarity with it. I plan on getting some more work done on the agent when as I get less busy!

Regarding concurrency within a transaction, you are correct in saying the current version doesn't provide a lot of support for it, but it's definitely something I've thought a lot about. I do expose a way to manually instrument anything, but that just appears as "other" in the UI (a purple bar in the waterfall chart). Assuming there is a way for async events to get accounted for, it wouldn't be too hard on the server side to make sure overlapping events don't get accounted for multiple times in the endpoint table. I already do something similar to this when accounting for DB events that happen during a View event--DB timings that take place inside a View process subtracted out of the total View timings. Also (again, assuming we've found a way to instrument concurrent events within the transaction), the waterfall diagram should work as intended with the current implementation. Here is an example of that waterfall diagram I have in the UI at this time. I'll get a live example up at some point this week so you can see it in action.

I think the trouble lies in getting async events to get accounted for in the transaction, since as you observed, transaction data gets stored in a thread local variable. I think the best way to do this with the current design is to hook in before the event begins, and to hook into the callback that runs after it ends. This way all the data stays in the same thread. I think then the idea would be to implement this pattern for the different asynchronous workflows, since we might be using something like PG::Connection#exec_async or something in Concurrent, or even pure Ruby.

Again, thank you so much for your feedback--it's given me a lot to think about for future iterations :D.

[rosenfeld]

That waterfall chart is exactly what I was looking for, thanks. Do I get the details when clicking or hovering those items? For example, with many database queries in parallel, I'd like to see the query details for each of those bars.

Regarding threads inside a transaction, maybe an alternative would be providing some alternative to Thread.start/new:

# original code:
[
  Thread.new{ fetch_tasks },
  Thread.new{ fetch_alerts },
].each &:join

# we could use something like:

[
  Tracebin.thread{ fetch_tasks },
  Tracebin.thread{ fetch_alerts },
].each &:join