• /
  • EnglishEspañolFrançais日本語한국어Português
  • 로그인지금 시작하기

Java agent logs in context settings

|View as Markdown (English)

Logs in context settings configure application log forwarding, log decoration, and the agent's own logging behavior.

팁

Back to the full settings index: Java agent configuration

Logs in context

Starting with Java agent version 7.6.0, support for logs in context has been added to the agent, making it easy to use for supported logging frameworks. For tips on using the Java agent for logs in context, see Java logs in context.

Changing these settings in your local agent configuration file happens dynamically and doesn't require a restart of the agent for those changes to take effect. An example configuration:

application_logging:
enabled: true
forwarding:
enabled: true
max_samples_stored: 10000
labels:
enabled: false
exclude:
context_data:
enabled: false
include:
exclude:
log_level_denylist: debug
metrics:
enabled: true
local_decorating:
enabled: false

Set the logs in context configuration in the application_logging section. This can be overridden with a newrelic.config.application_logging prefixed system property. The only option available is:

Log forwarding

If you're using a supported logging framework and want to use the agent to send your application logs to New Relic, you can control that through settings under the forwarding section. These settings can be overridden by the newrelic.config.application_logging.forwarding prefixed system property. Options available are:

Log labels (tags)

The Java agent supports adding custom labels (tags) to agent-forwarded logs. Labels are sourced from the labels section at the top level of the agent configuration. This feature can be enabled within the labels section, nested under the forwarding section. You can override these settings using the newrelic.config.application_logging.forwarding.labels prefixed system property. Available options include:

Log context data

The Java agent can capture context data (Mapped Diagnostic Context in logback/slf4j, ThreadContext in log4j2) and add its contents as attributes in the logs forwarded to New Relic. You can control that through settings in the context_data section, nested under the forwarding section. These settings can be overridden by the newrelic.config.application_logging.forwarding.context_data prefixed system property. Options available are:

Log Level Denylist

The Java agent can omit specific log levels from generating LogEvents that get forwarded to New Relic.

You can control that through the log_level_denylist config option, nested under the forwarding section. This setting allows you to define a comma separated list of strings representing log levels (e.g. log_level_denylist: "info, debug") that should not have log events forwarded. Log level names are case-insensitive but otherwise must be an exact match. These settings can be overridden by the newrelic.config.application_logging.forwarding.log_level_denylist prefixed system property. The only available option is:

Log metrics

In addition to allowing you to decorate and send individual log lines, the Java agent can capture logging metric data. You can find this data in the logs chart in the New Relic UI. You can configure log metrics settings in the metrics section. You can override these settings with the newrelic.config.application_logging.metrics prefixed system property. The only available option is:

Log decorating

You can configure the log decorating settings in the local_decorating section. You can use this to control how local log lines are decorated. You can override these settings with a newrelic.config.application_logging.local_decorating prefixed system property. The only option available is:

Logging configuration

These are part of the general configuration variables. They are broken out here because they are frequently tweaked for debugging.

Some of the logging configuration variables are dynamic and do not need a host restart for them to take effect. For instance, if log files are growing too quickly, log_level can be set to a less verbose setting to reduce the reporting rate.

Here is the order of precedence and explanation for configuration variables affecting log rotation.

  • If log_daily is true:
    • A log_limit_in_kbytes value greater than zero will result in a composite triggering policy, where logs will roll once per day or when the defined size is reached, retaining up to log_file_count files
    • A log_limit_in_kbytes value of zero will result in logs rolling once per day retaining up to log_file_count files
  • If log_daily is false and log_limit_in_kbytes > 0, a sized based policy will be configured, where logs will roll when the defined size is reached, retaining up to log_file_count files
  • If log_daily is false and log_limit_in_kbytes = 0, no log file rolling logic will be configured

Depending on the growth rate, it is possible for the log file size to exceed the configured value by a small amount.

Copyright © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.