> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/processors/dynatrace-enrichment.md). # Dynatrace Enrichment The Dynatrace Enrichment processor sets the Dynatrace primary fields (security context, cost center, product) and primary Grail tags on telemetry bound for Dynatrace. Each value is a literal string or an ordered list of source fields, and every enrichment is written as a resource attribute so it lands on the Dynatrace side as a primary field or tag. Use it ahead of a Dynatrace destination. Bindplane recommends it automatically on every Dynatrace destination in a configuration. #### Supported Telemetry Types | Logs | Metrics | Traces | | ---- | ------- | ------ | | ✓ | ✓ | ✓ | The processor runs on the signals you select in **Choose Telemetry Type**. One set of enrichments applies to every selected signal; there are no per-signal sections. #### Configuration **Basic Configuration**
You pick which Dynatrace fields to set and, for each one, where its value comes from. A field you leave empty is never added to the data. | Parameter | Type | Required | Default | Description | | --------------------- | ------------------ | -------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Choose Telemetry Type | Telemetry Selector | No | `Logs`, `Metrics`, `Traces` | The signals this processor applies to. The same enrichments are applied to every selected signal. | | Condition | OTTL Condition | No | (empty) | An OTTL condition that must be true for the processor to run. Empty applies it to every record of the selected signals. | | Security Context | Source rows | No | (empty) | Sets `dt.security_context`, which controls who can access the data in Dynatrace. A literal value or an ordered list of source fields (see Source Entries). | | Cost Center | Source rows | No | (empty) | Sets `dt.cost.costcenter` for Dynatrace cost allocation. A literal value or an ordered list of source fields. | | Product | Source rows | No | (empty) | Sets `dt.cost.product` for Dynatrace cost allocation. A literal value or an ordered list of source fields. | | Primary Tags | Tag rows | No | (empty) | Customer-defined organizational tags such as `team`, `app`, `stage`, or `env`. Each row has a plain key and its own source rows; the processor writes it as `primary_tags.`. Keys must be unique within the processor. | Every enrichment is written as a **resource attribute**: `resource.attributes["dt.security_context"]`, `resource.attributes["dt.cost.costcenter"]`, `resource.attributes["dt.cost.product"]`, and `resource.attributes["primary_tags."]`. **Source Entries** Each value (a primary field or a tag) is an ordered list of source rows. A row is one of two kinds: | Entry type | Fields | Behavior | | ---------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Field | Context (`attributes` / `resource`) + Key | Copies the field's value. The source field is kept. If the field is absent on a record, the row is skipped for that record. | | Literal | Value | A fixed string. Leading and trailing whitespace is trimmed. Always present, so it works as the fallback when placed last. | Rows are evaluated in order and the **first source present on a record wins**. If no row resolves on a record, the enrichment is not set on that record: the field is never written as an empty string or `null`. The `primary_tags.` prefix is applied by the processor. Type the plain key (`env`, not `primary_tags.env`). Tag keys may contain letters, digits, and `_ . : / -`. #### Examples **Security context from the Kubernetes namespace, with a fallback**
Multi-tenant clusters usually key access on the namespace. Listing `resource` / `k8s.namespace.name` first and a literal `shared` last sets `dt.security_context` to the namespace on Kubernetes telemetry and to `shared` on everything else, so no record leaves the pipeline without a security context. Cost Center is a fixed literal, and the `env` tag is copied from whichever cloud tag the record carries. **Coalesce an environment tag from several cloud providers** The same `env` tag may arrive as `aws.tags.env` on EC2 hosts and `azure.tags.env` on Azure VMs. Listing both as field rows writes `primary_tags.env` from whichever one the record carries, and skips the tag on records that carry neither. ```yaml apiVersion: bindplane.observiq.com/v1 kind: Processor metadata: name: dynatrace-env-tag spec: type: dynatrace_enrichment parameters: - name: telemetry_types value: - Logs - Metrics - Traces - name: primary_tags value: - key: env sources: - type: field context: resource key: aws.tags.env - type: field context: resource key: azure.tags.env - key: team sources: - type: literal value: observability ``` #### Configuration Tips **Order is priority** * Rows are evaluated top to bottom and the first source present wins. Put the most authoritative source first and a literal last if you want a guaranteed value. * A value that is entirely field rows is skipped on records where none of the fields exist. Add a literal row when the field must always be set. **Security context is an access boundary** * `dt.security_context` decides who can see the data in Dynatrace. A typo, or a value that happens to match a broader policy, puts records in the wrong access boundary. Prefer a literal, or a source field whose values you control; avoid fields that carry arbitrary user-supplied text. * Leaving Security Context empty leaves `dt.security_context` unset on the record; Dynatrace then treats the record as data with no security context. **Cost center and product** * Cost Center and Product accept any text. Values registered later in Dynatrace cost allocation still match as long as they are spelled the same. #### Troubleshooting **A field or tag is missing in Dynatrace** **Symptoms:** Records arrive in Dynatrace but `dt.security_context`, `dt.cost.*`, or a `primary_tags.*` tag is absent on some or all of them. **Solutions:** 1. Confirm at least one source row resolves on those records: right context (`attributes` vs `resource`) and the exact key. Use a snapshot to check which fields the record actually carries at the processor's position in the pipeline. 2. Add a literal row at the end of the list if the value must be set on every record. 3. If a Condition is set, confirm it evaluates true for the records you expect to enrich. 4. Confirm the processor is on the pipeline that feeds the Dynatrace destination, and that the selected telemetry types include the signal you are looking at. **The value is wrong or in the wrong access boundary** **Symptoms:** Records land with an unexpected `dt.security_context` or cost center. **Solutions:** 1. Check row order. An earlier field row that resolves wins over a later literal. 2. Check for whitespace differences in Dynatrace policy names; literal values are trimmed, values copied from fields are not. 3. If a source field is populated by upstream processors, confirm the enrichment processor runs after them. **Save fails with a duplicate or invalid tag key** **Symptoms:** The processor cannot be saved and a tag key is highlighted. **Solutions:** 1. Tag keys must be unique within one processor. Merge the two rows, adding the extra sources to the surviving row. 2. Keys may contain only letters, digits, and `_ . : / -`. Remove spaces and quotes, and do not include the `primary_tags.` prefix. #### Standalone Processor ```yaml apiVersion: bindplane.observiq.com/v1 kind: Processor metadata: name: dynatrace-enrichment spec: type: dynatrace_enrichment parameters: - name: telemetry_types value: - Logs - Metrics - Traces - name: condition value: "" - name: security_context value: - type: field context: resource key: k8s.namespace.name - type: literal value: shared - name: cost_center value: - type: literal value: team-obs-platform - name: cost_product value: - type: literal value: payments-api - name: primary_tags value: - key: env sources: - type: field context: resource key: aws.tags.env - type: field context: resource key: azure.tags.env - key: team sources: - type: literal value: observability ``` #### Recommendations When a configuration has a Dynatrace destination, Bindplane recommends: * **Enrich for Dynatrace** on the destination: this processor, with no fields pre-filled. * **Detect Resources for Dynatrace** on each source that is not a Dynatrace ActiveGate or Bindplane Gateway source: the Resource Detection processor with the `system` detector, so host telemetry carries the resource attributes Dynatrace uses for entity mapping. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.bindplane.com/integrations/processors/dynatrace-enrichment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.