Dynatrace Request Attributes: Capture Business Context Without Code Changes

The Problem: Traces Lack Business Context

Distributed traces show latency and errors, but they don't tell you which customer, tenant, or order triggered the request. Without that context, you can't alert on per-customer SLOs, correlate business impact during incidents, or feed Davis AI with meaningful entities for root-cause analysis. Dynatrace Request Attributes solve this by extracting identifiers from HTTP headers, query parameters, cookies, or method arguments at the agent level—no application code changes required.

How Request Attributes Work

Request attributes are defined centrally in the Dynatrace tenant (Settings → Server-side service monitoring → Request attributes). Each attribute specifies a data source and extraction rule. The OneAgent applies the rule when the instrumented process handles a request, attaching the extracted value to the trace and making it available for metric splitting, alerting, and Davis correlation.

Supported data sources:

• HTTP request header – e.g., x-customer-id, x-tenant-id
• Query parameter – e.g., ?customerId=123
• Cookie – e.g., session_tenant=acme
• Method argument – Java, .NET, Node.js, or PHP method parameters via getter or index

Attributes are evaluated per request at the service level. They appear in Distributed Traces → Request attributes panel, on service flow pages, and can be referenced in metric expressions like builtin:service.requestCount:splitBy("dt.request_attribute.customer_id").

Worked Example: Capture x-customer-id Header

Via the UI

1. Navigate to Settings → Server-side service monitoring → Request attributes.
2. Click Add request attribute.
3. Fill in:
   • Name: customer_id (this becomes the metric dimension key)
   • Data source: HTTP request header
   • Header name: x-customer-id
   • Type: String
4. Save. The rule takes effect within 2–3 minutes for new traffic.

Via the API (for IaC)

POST /api/config/v1/service/requestAttributes
{
  "name": "customer_id",
  "dataSource": "HTTP_REQUEST_HEADER",
  "headerName": "x-customer-id",
  "type": "STRING"
}

Export existing definitions with GET /api/config/v1/service/requestAttributes and manage them through Terraform (dynatrace_request_attribute resource) for version control.

Worked Example: Java Method Argument Capture

When the identifier isn't in the HTTP layer (e.g., internal service calls), capture it from a method argument.

1. In the same UI, choose Data source: Method argument.
2. Provide:
   • Class: com.shop.OrderService
   • Method: placeOrder
   • Argument index: 0 (zero-based)
   • Getter: getCustomerId() (optional; if the argument is an object with a getter)
3. Save. Requires OneAgent 1.265+ on the host running the JVM.

Risk: Refactoring the class, method signature, or getter breaks extraction silently. Validate after every deployment by checking a live trace for the attribute.

Using Attributes in Metrics and Alerts

Once defined, the attribute key is prefixed with dt.request_attribute.. Example metric expression for per-customer request count:

builtin:service.requestCount:splitBy("dt.request_attribute.customer_id")

Create a dashboard tile or an SLO that filters on customer_id=acme-corp. Davis AI automatically correlates the attribute during problem detection, so a latency spike on the placeOrder service shows the affected customers in the problem card.

Combining with Request Naming Rules

A common pattern: use Request naming rules (Settings → Server-side service monitoring → Request naming) to group raw endpoints into business transactions, then split by request attribute.

1. Create a naming rule: /api/orders/* → placeOrder.
2. Define customer_id request attribute as above.
3. Build a dashboard splitting builtin:service.response.time by dt.request_attribute.customer_id for the placeOrder service.

This yields per-tenant latency SLOs without changing application code.

Limits and Cardinality Protection

• Sampling: Attributes are captured per the service's request capture rate (default 100% for errors, configurable for success). Low-traffic services may not capture every successful request.
• Cardinality cap: Dynatrace truncates values exceeding ~1,000 unique values per minute per process group. High-cardinality keys (session IDs, request IDs, user emails) are silently dropped. Monitor builtin:service.requestAttributeCardinality to catch spikes before truncation.
• Not retroactive: Attributes apply only to traffic after creation. Historical traces cannot be re-enriched.
• Agent version dependency: Method argument capture requires OneAgent 1.265+ (Java), 1.255+ (.NET), or equivalent for Node.js/PHP. Older agents ignore the rule without error. Check Process Group → Properties → OneAgent version.
• PII compliance: Do not capture emails, IPs, or tokens. Hash or pseudonymize at the application layer before the header reaches Dynatrace.

Common Mistakes

Mistake	Impact	Fix
Using request ID or session ID as attribute	Metric explosion; values truncated	Use low-cardinality business keys: tenant, region, plan, customer tier
Assuming method argument capture survives refactors	Silent data loss after deploy	Add trace validation to CI/CD; check attribute presence in a sample trace post-deploy
Defining attribute in prod without test	No visibility until traffic arrives; typos go unnoticed	Create in non-prod tenant, send synthetic request with header, verify in Distributed Traces within 3 minutes
Confusing with OpenTelemetry span attributes	Duplicate effort; span attributes not usable in Dynatrace metric expressions	Use request attributes for business keys; reserve span attributes for technical context (DB statement, cache key)

Verification Checklist

1. Create the attribute in a non-production tenant.
2. Send a test request containing the header/parameter (e.g., curl -H "x-customer-id: test-123" https://app.example.com/api/orders).
3. Open Distributed Traces, find the trace, and confirm customer_id=test-123 appears in the Request attributes panel.
4. Run GET /api/config/v1/service/requestAttributes and verify the JSON matches your definition.
5. Check builtin:service.requestAttributeCardinality for the service after 10 minutes of load; ensure it stays well below 1,000.
6. Confirm OneAgent version on the target process group meets the minimum for your data source type.

Kubernetes Note

With the Dynatrace OneAgent Operator, the agent is injected automatically into pods. Request attribute definitions live in the tenant and apply cluster-wide—no per-cluster configuration needed. Ensure the Operator version supports your OneAgent version (Operator 0.12+ for OneAgent 1.265+).