Loading Profile...
Support for Rails Metal
Just upgraded our app to Rails 2.3 RC2 and have our first Rails Metal bits in production. Working out great, except for that those requests are now invisible to NewRelic. It would be useful to have performance data on them.
4
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has this in progress.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?It's an idea we're investigating. Can you describe how you would like it to appear in the UI? How would you identify the response times of requests handled with metal? How would you distinguish them?
-
Inappropriate?I'd like to see it appear like a controller action currently does and figure into calculations similarly. It could be rendered as Metal#metal_app_name. Seems like that should be adequate. -
Inappropriate?Is there any new info on this? We'd like to convert some parts of our applications to Rails Metal, and move certain things into the middleware layer. Will we lose all RPM data for those parts if we do so? -
Inappropriate?Yes I'm actually pretty close to automatic Metal support. However in the current edge agent, you can easily get full visibility into your metal apps, by adding a custom metric call. This is still an early version but if you'd like to try it out, check out the docs on the new controller instrumentation method "perform_action_with_newrelic_trace"
http://newrelic.github.com/rpm/classe...
Or if you want to instrument a single method like it's a controller action, use "add_transaction_tracer"
http://newrelic.github.com/rpm/classe...
If you try it out, let us know how it goes. Report any feedback to support@newrelic.com.
Thanks!
I’m hopeful
-
Inappropriate?Hey Bill,
Thanks for the update. I tried this out locally, but the edge agent seems to crash after the first request. I'm trying to setup a trace like this:
perform_action_with_newrelic_trace(:path => 'endpoint/call', :category => :web_transaction) do
It runs through the first time I request a page, but all subsequent requests raise the following error:
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.transaction_name=
vendor/plugins/rpm/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:308:in `perform_action_with_newrelic_trace'
Thanks,
-Joe -
Inappropriate?Okay, I need to update github with my changes from last weekend. I'll try to push something out today or tomorrow. The perform_action api will probably change--I removed the :path arg in favor of :name. It will all be in the rdoc.
-
-
Inappropriate?I followed up on this Bill, for Joe. I was able to get the latest version of rpm agent working with our Metal.
-
Inappropriate?Hey Bill,
We just deployed a release of our app that includes the new Rack instrumentation. Everything works great, except that it counts every hit to the app as a hit to the metal class - even those that aren't processed. Most calls to a metal class are ignored and processed by the rest of the app, so it's difficult to get accurate performance readings.
If a metal class returns 404, it means the dispatcher should handle the request, similar to Rack's Cascade. Would it make sense to have a NewRelic::Agent::Instrumentation::Cascade module that ignored calls that returned 404?
Thanks,
-Joe -
Inappropriate?Joe I think this is a good increment. I will put this in the backlog. It's not trivial because I don't have a mechanism to ignore a method based on a return value right now. By the time you can determine if it should be ignored, it's already too late. You can look at the rack instrumentation module and think about how this might work.
Meanwhile you can work around it by instrumenting the block manually. I updated the doc to give an example of this. Check out the section on chaining calls at http://newrelic.github.com/rpm/classe...
EMPLOYEE
