With our Ruby agent, you can get logs in context, which lets you see your app logs in the context of your other New Relic data. For general information on this feature, see APM logs in context.
You have three options to configure logs in context to send your app's logs and linking metadata automatically to New Relic.
This is the simplest approach, and it's a great choice for developers who may not have the access or interest in setting up a log forwarder, or for accounts that want to see the power of logs and other linking metadata in context of their apps, without a lot of overhead.
All you need to do is install an agent version with log forwarding capabilities (Ruby agent 8.6.0 or higher). If forwarding is disabled, you can use this configuration:
This option is enabled by default in version 8.7.0 and later. To disable log forwarding, you must set the value to false.
Optional adjustments:
Once this is enabled, you also have control over the maximum number of logs sent to New Relic every minute. The default value is 10,000. If more than 10,000 logs are received in a 60-second window, your logs will begin to be sampled.
Set it to a higher number to receive more logs. Set it to a lower number to receive fewer logs. Any integer up to 100,000 is valid.
If you have an existing log forwarding solution and are updating your agent to use automatic logs in context, be sure to disable your manual log forwarder. Otherwise, your app will be sending double log lines. Depending on your account, this could result in double billing. For more information, follow the procedures to disable your specific log forwarder.
Already have a log forwarder you like? We've got you covered! Language agents can decorate your logs with the linking metadata needed to provide access to automatic logs-in-context features.
This option should not be used with in-agent forwarding. Using an external log forwarder to send logs to New Relic while in-agent forwarding is enabled will cause your logs to be sent up twice to New Relic. Depending on your account, this may result in double billing.
This option should also not be used with the manual log decorating formatter. If you have references to the manual formatter in your codebase, please remove them before enabling this option.
If you want to use this option, make sure you have the in-agent forwarding configuration option disabled.
newrelic.yml:
application_logging:
forwarding:
enabled:false
Enable log decorating in your configuration, then relaunch the agent to start decorating your logs.
Our decorator adds five attributes to every log message: entity.guid, entity.name, hostname, trace.id, and span.id. Example:
This is my log message. NR-LINKING|{entity.guid}|{hostname}|{trace.id}|{span.id}|{entity.name}|
Some attributes may be empty if the log occurred outside a transaction or if they are not applicable to your application's context.
We recommend this option over the manual decorating formatter, NewRelic::Agent::Logging::DecoratingFormatter.
Before language agents had the ability to forward and decorate logs, you could enable logs in context by updating your application to use the NewRelic::Agent::Logging::DecoratingFormatter to send linking metadata.
This option is still supported, but is no longer encouraged. For instructions to use this approach, see Manual logs in context option.
Also, this method requires that you install a log forwarder before enabling logs in context. If you do not have a log forwarder, the New Relic UI will prompt you to use our infrastructure agent.
If you decide to use your existing log forwarding solution and later decide to update your agent to use automatic logs in context, be sure to disable your manual log forwarder. Otherwise, your app will be sending double log lines. Depending on your account, this could result in double billing. For more information, follow the procedures to disable your specific log forwarder.
Did this doc help with your installation?
Secure your data
Your logs may include sensitive information protected by HIPAA or other compliance protocols. By default we obfuscate number patterns that appear to be for items such as credit cards or Social Security numbers, but you may need to hash or mask additional information.
For more information, see our documentation about obfuscation expressions and rules. You can hash or mask your log data by using the New Relic UI or by using NerdGraph, our GraphQL API.
Explore your data
To make the most of your logging data:
On the APM Summary page, click your Web transaction time chart to view logs associated with a specific point in time.
Check your app's Errors inbox to view the logs associated with your errors.
Typically your logs will start to appear less than a minute after you enable logs in context. Check your app's Triage > Logs section. You will also start seeing log patterns related to the error there.
If you don't see any logs for errors or traces, there may not be any for your app. Try refreshing the UI page, or change the selected time period.
Disable automatic logging
APM logs in context automatically forwards APM agent log data and is enabled by default. This can have a negative impact on your security, compliance, billing, or system performance. For more information, or if you need to adjust the default setting, follow the procedures to disable automatic logging.
Manual logs in context option
If you need to use the manual process to set up logs in context for Ruby, follow these steps:
Make sure you have already set up logging in New Relic. This includes configuring a supported log forwarder that collects your application logs and extends the metadata that is forwarded to New Relic.
A logger you can customize by setting config.logger
A log formatter you can customize by setting config.log_formatter)
In most cases, you should configure logs in context by setting config.log_formatter to the DecoratingFormatter in your Rails application. For more information about Rails configuration, see the rubyonrails.org documentation.
In your application's config, require newrelic_rpm, then add the following line:
If setting the log_formatter option doesn't meet your needs, replace the entire Rails logger with an instance of the New Relic logger. Provide the parameters to the logger's constructor, like this:
The DecoratingLogger is a drop-in replacement for the Ruby standard ::Logger. Their constructors accept the same parameters.
To configure this extension with the lograge gem, follow standard procedures in this doc for Ruby on Rails configuration. No additional configuration is required for the lograge gem.
To use our logging extension with a different logging implementation or with your own custom logger, use the DecoratingFormatter. For example:
To verify that you have configured the log appender correctly, run your application, then check your log data in the New Relic UI using the query operator has:span.id has:trace.id.
If everything is configured correctly and your data is being forwarded to New Relic with the enriched metadata, your logs should now be emitted as JSON and contain trace.id and span.id fields.
If you have configured your logging in /config/application.rb or in /config/environments/development.rb, run your application locally and check its logging output. You should see some output like this: