Rodrigo Rosenfeld Rosas

Preventing NewRelic RUM metrics for certain clients with Rails apps

Fri, 16 May 2014 15:56:00 +0000 (Updated at Thu, 07 Aug 2014 12:15:00 +0000)

We use the awesome Sensu monitoring framework to make sure our application works as expected. Some of our checks use a headless browser (PhantomJS) to explore parts of the application, like exporting search results to Excel or making sure no error is thrown from JS in our Single Page Application. We also use NewRelic and Pingdom to get some other metrics.

But since PhantomJS acts like a real browser, our checks will have influence over the RUM metrics we get from NewRelic, but we're not really interested in such metrics. We want the metrics from real users, not our monitoring system.

My initial plan was to check if I could filter some IP's from RUM metrics and asked NewRelic support about this possibility, for which they said it's not supported yet, unless you want to filter specific controllers or actions.

Since some monitoring scripts have to go through real actions, this was not an option for us. So I decided to take a look at the newrelic_rpm gem and could come with a solution that I've confirmed is working fine for us.

Since we have a single page application, I simply add the before-action filter to the main action, but you may adapt it to use in your ApplicationController if you will. This is what I did:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class MainController < ApplicationController
  before_action :ignore_monitoring, only: :index if defined? ::NewRelic

  def index
    # ...
  end

  private

  def ignore_monitoring
    return unless params[:monitoring]
    ::NewRelic::Agent::TransactionState.tl_get.current_transaction.ignore_enduser!
  rescue => e
    logger.error "Error in ignore_monitoring filter: #{e.message}\n#{e.backtrace.join "\n"}"
  end
end

The rescue clause is there in case the implementation of newrelic_rpm changes and we don't notice it. We decided to send a "monitoring=true" param to our requests performed by our monitoring scripts. This way we don't have to worry about managing and updating a list of monitoring servers and figure out how to update that list in our application without incurring in any down-time.

But in case you want to deal with this somehow, you might be interested in testing "request.remote_ip" or "request.env['HTTP_X_FORWARDED_FOR']". Just make sure you add something like this to your nginx config file (or a similar trick for your proxy server if you're using one):

1
2
3
location ... {
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
comments powered byDisqus