ℹ️ 2021-07-06 - Updated code block with LambdaPunch asynchronous background job processing.
Custom Ink has been using Rails for as long as the framework has been around. For many of those years we have used New Relic's awesome Application Performance Monitoring (APM) tool to observe and debug dozens of our critical services.
In the past I have have shared on Twitter that that New Relic Ruby Agent did not work when using Rails on AWS Lambda. I think my assumption was based on how the agent's collector needed a daemon process on the server or was tightly coupled to certain web servers like Passenger and thus not compatible with Lamby's Rack adapter under API Gateway.
Thankfully I was wrong! Here is how we got New Relic & Rails working this past week with Lamby.
- Use the
NEWRELIC_LICENSE_KEY
environment variable. This will ensure that the RPM gem can assign it to thelicense_key
config as needed during initialization. Ensure this is present before Rails loads. - Add the
log_file_path: STDOUT
to your config yaml file. - Optionally, ensure that New Relic flushes your data after each request.
When your Lambda experiences a cold start, the agent should log that it too is starting and using Rack and whatever instrumentation hooks it finds within your application. Here is an example of the config/newrelic.yml
file.
common: &default_settings
app_name: MyAppName
log_level: fatal
log_file_path: STDOUT
ssl: true
development:
<<: *default_settings
monitor_mode: false
test:
<<: *default_settings
monitor_mode: false
production:
<<: *default_settings
Now add the LambdaPunch gem to your project and change the handler method to ensure data is flushed to New Relic after each request. LambdaPunch ensures this happens after your Rails application response is sent.
def handler(event:, context:)
Lamby.handler $app, event, context
ensure
LambdaPunch.push { NewRelic::Agent.agent.flush_pipe_data }
end
Lastly, thanks so much to the New Relic team for always improving their products and providing an awesome service.