Core configuration options

A Boolean specifying if the agent should be recording or not. When recording, the agent captures HTTP requests, tracks errors, and collects and sends metrics. When not recording, the agent works as a noop, where it does not collect data or communicate with the APM server, except for polling the central configuration endpoint. This is a reversible switch, so the agent threads are not killed when deactivated, but they will be mostly idle in this state, so the overhead should be negligible.

Use this setting to dynamically disable Elastic APM at runtime.

Setting this to false will completely disable the agent, including instrumentation and remote config polling. If you want to dynamically change the status of the agent, use recording instead.

This is used to keep all the errors and transactions of your service together and is the primary filter in the Elastic APM user interface.

This is an optional name used to differentiate between nodes in a service. If this is not set, data aggregations are done based on a container ID (where valid) or on the reported hostname (automatically discovered).

A version string for the currently deployed version of the service. If you don’t version your deployments, the recommended value for this field is the commit identifier of the deployed revision, e.g. the output of git rev-parse HEAD.

This allows for the reported hostname to be manually specified. If this is not set, the hostname will be looked up.

The name of the environment that this service is deployed in, e.g. "production" or "staging".

Environments allow you to easily filter data on a global level in the APM app. It’s important to be consistent when naming environments across agents. See environment selector in the Kibana UI for more information.

By default, the agent samples every transaction (e.g. a request to your service). To reduce overhead and storage requirements, set the sample rate to a value between 0.0 and 1.0. The agent will still record the overall time and result for unsampled transactions, but no context information, labels, or spans will be recorded.

This setting can be changed after the agent starts.

This limits the amount of spans that are recorded per transaction. This is helpful when a transaction creates a very high amount of spans, for example, thousands of SQL queries. Setting an upper limit helps prevent overloading the Agent and APM server in these edge cases.

This setting can be changed after agent starts.

If set to true, the agent makes periodic requests to the APM Server to fetch the latest APM Agent configuration.

Sometimes, sanitizing, i.e., redacting sensitive data sent to Elastic APM, is necessary. This configuration accepts a comma-separated list of wildcard patterns of field names that should be sanitized. These apply to HTTP headers for requests and responses, cookies and application/x-www-form-urlencoded data.

The wildcard, *, matches zero or more characters, and matching is case insensitive by default. Prepending an element with (?-i) makes the matching case sensitive. Examples: /foo/*/bar/*/baz*, *foo*.

Please review the data captured by Elastic APM carefully to ensure it does not contain sensitive information. If you find sensitive data in your elasticsearch index, add an additional entry to this list. Setting a value here will overwrite the defaults, so be sure to include the default entries as well.

Cookie header sanitization:

The Cookie header is automatically redacted for incoming HTTP request transactions. Each name-value pair from the cookie list is parsed by the agent and sanitized based on the SanitizeFieldNames configuration. Cookies with sensitive data in their value can be redacted by adding the cookie’s name to the comma-separated list.

Labels are added to all events with the format key=value[,key=value[,...]]. Any labels set by the application via the agent’s public API will override global labels with the same keys.

Setting this option to true will enable span compression feature. Span compression reduces the collection, processing, and storage overhead, and removes clutter from the UI. The tradeoff is that some information such as DB statements of all the compressed spans will not be collected.

Consecutive spans that are exact match and that are under this threshold will be compressed into a single composite span. This option does not apply to composite spans. This reduces the collection, processing, and storage overhead, and removes clutter from the UI. The tradeoff is that the DB statements of all the compressed spans will not be collected.

Consecutive spans to the same destination that are under this threshold will be compressed into a single composite span. This option does not apply to composite spans. This reduces the collection, processing, and storage overhead, and removes clutter from the UI. The tradeoff is that the DB statements of all the compressed spans will not be collected.

Sets the minimum duration of exit spans. Exit spans with a duration lesser than this threshold are attempted to be discarded. If the exit span is equal or greater the threshold, it should be kept. In some cases exit spans cannot be discarded. For example, spans that propagate the trace context to downstream services, such as outgoing HTTP requests, can’t be discarded. However, external calls that don’t propagate context, such as calls to a database, can be discarded using this threshold. Additionally, spans that lead to an error can’t be discarded.

Setting this option to false will disable the OpenTelemetry Bridge. This will disable the use of the vendor-neutral OpenTelemetry Tracing API (the Activity API in .NET) to manually instrument your code, and have the Elastic .NET APM agent handle those API calls.