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_KEYenvironment variable. This will ensure that the RPM gem can assign it to the
license_keyconfig as needed during initialization. Ensure this is present before Rails loads.
- Add the
log_file_path: STDOUTto 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
common: &default_settings app_name: MyAppName log_level: info log_file_path: STDOUT ssl: true development: <<: *default_settings monitor_mode: false test: <<: *default_settings monitor_mode: false production: <<: *default_settings
If your function is taking a lot of traffic, events should flow easily into New Relic. However you may need to help smaller applications by fusing the data manually. You can do that by using a Ruby
ensure block in your Lamby handler method. For example:
def handler(event:, context:) Lamby.handler $app, event, context, rack: :http ensure 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.