New Relic support?

112 views
Skip to first unread message

Mark Mulder

unread,
Nov 15, 2011, 5:23:13 AM11/15/11
to Goliath.io
Does anyone have experience with running the New Relic agent and
Goliath? I know it supports Rack and the readme says you can use it
for every Ruby application by adding the following code, but I was
wondering if anyone has tried it out yet!

require 'newrelic_rpm'
NewRelic::Agent.manual_start

Ilya Grigorik

unread,
Nov 15, 2011, 10:32:42 AM11/15/11
to golia...@googlegroups.com
The short answer is: likely won't work. 

1) You need to wrap the code to be async friendly (see some of the middleware we've provided)
2) Needs to use EM loop to push data to newrelic, otherwise it'll be a performance problem on its own.

ig

Adam Watson

unread,
Nov 15, 2011, 1:44:29 PM11/15/11
to Goliath.io
Hi Mark,

I've been actively working on this very problem recently in
conjunction with NewRelics' support engineers. I've made additions to
the rpm_contrib gem which allows Goliath to be auto-detected on app
startup, though so far it will only recognize it as a generic ruby app
(not rack-aware). Unfortunately, this is almost the full extent of
what I've been able to accomplish using the current newrelic agent
gem. Their agent is built to run in a non-event-driven context, so
it's not able to parse together the various fiber callbacks into a
cohesive transaction context.

The best I've been able to accomplish at this point is custom
reporting of various metrics from within specific methods. The problem
with this approach is that changes need to be made directly to the
Goliath codebase... which requires a fork and active merging of new
code in order to be sustained without a lot of maintenance. Also, this
approach does not afford metrics to be reported to the App Overview in
New Relic... instead, you have to create custom views for collected
data points.

For instance, you can instrument a custom metric for response time by
sending the result of "Time.now.to_f - @env[:start_time]) * 1000" used
to generate response time in Gollath::Request#post_process. But, this
is far from optimal in terms of what New Relic reporting and
instrumentation is all about.

If and when more breakthroughs are made, I'll let you know. I'm
contributing back to the rpm_contrib project, so you'll be able to
grab any progress we've made there.

Cheers,
Adam

Adam Watson

unread,
Nov 15, 2011, 1:48:22 PM11/15/11
to Goliath.io
Oh, by the way, if you'd like to see what I've added to rpm_contrib,
my fork is here: https://github.com/adamlwatson/rpm_contrib

Again, it only adds auto-detect capability. Method tracing is pretty
useless after this, because of the reasons I describe in my other
post.


Cheers,
Adam

On Nov 15, 2:23 am, Mark Mulder <markmul...@gmail.com> wrote:

Ilya Grigorik

unread,
Nov 15, 2011, 9:11:46 PM11/15/11
to golia...@googlegroups.com
Adam, this may or may not be what you're looking for, but there are a few facilities within goliath that could help with this integration -- without having to modify goliath core itself.

1) We ship a "trace" middleware and some helper methods right within Goliath. It requires manual instrumentation of the code, but it allows for easy debugging that we've utilized quiet a bit at PostRank. (It also emits an HTTP header, or can be part of the response)


2) There is the concept of a "plugin", which you can use to periodically emit metrics, etc. Take a look at the Ganglia example: you can collect metrics and then periodically emit a summary, or you can even combine this with tracer above.


ig

Adam Watson

unread,
Nov 15, 2011, 9:22:26 PM11/15/11
to Goliath.io
Thanks, Ilya... I'll check this out. It would definitely be better
if I can avoid modifying the Goliath core.

Cheers,
Adam

On Nov 15, 6:11 pm, Ilya Grigorik <igrigo...@google.com> wrote:
> Adam, this may or may not be what you're looking for, but there are a few
> facilities within goliath that could help with this integration -- without
> having to modify goliath core itself.
>
> 1) We ship a "trace" middleware and some helper methods right within
> Goliath. It requires manual instrumentation of the code, but it allows for
> easy debugging that we've utilized quiet a bit at PostRank. (It also emits
> an HTTP header, or can be part of the response)
>
> https://github.com/postrank-labs/goliath/blob/master/lib/goliath/env....
Reply all
Reply to author
Forward
0 new messages