Elastic APM’s agents can automatically redact sensitive fields from event data, preventing PII from leaking into your observability data.
Here’s what that looks like in action. Imagine a user submitting a login form with their username and password. Without redaction, these credentials might end up in your APM traces.
{
"transaction": {
"name": "POST /login",
"type": "request",
"duration": {
"us": 150000
},
"request": {
"method": "POST",
"headers": {
"user-agent": "Mozilla/5.0"
},
"body": "username=testuser&password=supersecretpassword123"
}
},
"service": {
"name": "my-web-app"
}
}
By enabling redaction, the sensitive fields are replaced with asterisks.
{
"transaction": {
"name": "POST /login",
"type": "request",
"duration": {
"us": 150000
},
"request": {
"method": "POST",
"headers": {
"user-agent": "Mozilla/5.0"
},
"body": "username=***&password=***"
}
},
"service": {
"name": "my-web-app"
}
}
This protects sensitive data while still allowing you to trace requests and understand application behavior.
The core problem redaction solves is the accidental exposure of Personally Identifiable Information (PII) or other sensitive data in your application’s logs and traces. When developers add debugging information or when frameworks automatically include request/response bodies, sensitive data like API keys, passwords, credit card numbers, or personally identifiable user information can inadvertently be sent to your APM backend. This creates a significant security and compliance risk.
Elastic APM’s redaction mechanism works by inspecting the data being sent by the APM agent before it leaves the application. The agent has a configurable list of field names and patterns that it checks against. When a match is found, the value associated with that field is replaced with a redacted string (typically ***). This configuration can be done at the agent level, allowing you to tailor redaction rules to your specific application’s needs.
The primary lever you control is the capture_body setting in your APM agent configuration. This setting determines if and how request and response bodies are captured. The options are typically:
off: No request or response bodies are captured. This is the most secure but provides the least visibility into request/response payloads.errors: Request and response bodies are captured only for events that result in an error. This offers a balance between security and debugging capability.all: Request and response bodies are captured for all transactions. This provides maximum visibility but also the highest risk of sensitive data exposure if not properly redacted.
Beyond capture_body, you can fine-tune redaction using the body_exclude_fields (or similar, depending on the agent) configuration. This allows you to specify exact field names within the request or response body that should always be redacted, regardless of the capture_body setting. For example, if capture_body is set to all and you want to ensure password and api_key are always redacted, you’d configure:
# Example for Java agent
elastic-apm:
service-name: my-service
server-urls: http://localhost:8200
capture-body: all
body-exclude-fields:
- password
- api_key
This tells the agent to strip out any fields named password or api_key from the captured body.
It’s important to understand that redaction is applied after the body has been captured but before it’s sent to the APM Server. This means that if capture_body is set to all, the sensitive data does briefly exist in memory within your application’s agent. For extremely sensitive environments, the capture_body: off or capture_body: errors settings might be preferred, or you might implement application-level sanitization before the APM agent even sees the data.
The next challenge you’ll likely encounter is ensuring consistent redaction across different agents and language versions, especially in a polyglot environment.