Note: This feature is experimental. Use at your discretion, and let New Relic know how it works for you!
Starting in version 2.9.0 of the Ruby agent, you can use
mongrel_rpm to start a daemon accepting HTTP requests with performance data that is forwarded to the New Relic servers. This allows non-Ruby applications to send metric data to New Relic using simple GET requests.
Requirements are a valid New Relic license at Professional product level (or you will not be able to view the metrics) and a rubygems installation.
Install the latest Ruby gem using the gem command.
sudo gem install newrelic_rpm
Once the gem is installed, find a working directory where you will run the daemon. The agent logfile and configuration file ("newrelic.yml") will live in that directory.
In that working directory execute:
This will create a default
newrelic.yml file for use with the daemon. Edit that file and insert your license key in the
Now you are ready to start up the daemon.
You can use the daemon with any Rack adapter. New Relic supplies a default mongrel adapter called
mongrel_rpm. You can invoke mongrel_rpm with several options:
Usage: mongrel_rpm [options] \[app_name\] -p, --port=port default: 3000 --[no-]logging turn off request logging --license=rpm_license_key override license key --install install a newrelic.yml template
With no options it will run on port 3000 and read the license key from the
Note: You must specify an application name either on the
mongrel_rpm command line or in the configuration file. This is where you will find the metrics on the New Relic site.
You can use the daemon to submit metric values to New Relic using an HTTP GET request. Invoking the GET request correlates to what the Ruby agent does automatically whenever an instrumented method call is invoked:
Once the daemon is running, you can view a status page in a browser by opening the '/' page:
To submit a value, invoke a GET request with the following format:
where NAME is the metric name, and NNN is a numeric value.
Choose your metric names carefully. This is your main point of leverage in organizing the data for viewing in New Relic. Over time we may establish more conventions for metric naming that will provide extra context for displaying in custom views, such as encoding different metric types in the name, like counters and utilization numbers, as well as latencies.
Avoid encoding actual data in the metric name, like customer or account names. This will explode the number of metrics being managed and impact overall performance of the New Relic UI. In addition, at some point our metric collectors may enforce a limit on the number of unique metrics collected by an agent in order to avoid metric grouping issues.
FacebookRequest/profile/get?value=250 # timed RPM call Transactions/skirt/sales?value=15.00 # single skirt sale Wholesaler/Orders/skirts?value=256 # order for 256 cases
One user login took 125 ms. You may not be as interested in the time as just keeping a count of users. The count is kept implicitly in the 'call count' of the metric and can be plotted as something like 'calls per minute' to see the user login activity.
A user looks at a product description of a skirt after being logged in for 35 seconds.
A user purchases a skirt for $9.95
Track cache behavior by recording the latency of hits and misses in ms. Note that the overhead of measuring a cache hit might be counter-productive but this is the only way to calculate your cache hit ratio. Also, the hit/miss count is implicit in the 'call count' so all you need to record is the latency for a single hit.
If you still have problems, submit a support ticket (for fastest service) or email support @ New Relic. Also, you may be able to find support from the community at Stack Overflow. Tag your post with