|
| 1 | +--- |
| 2 | +title: Remap Reserved Attributes |
| 3 | +disable_toc: false |
| 4 | +further_reading: |
| 5 | +- link: "observability_pipelines/processors/edit_fields/" |
| 6 | + tag: "Documentation" |
| 7 | + text: "Learn more about the Edit Fields processor" |
| 8 | +- link: "observability_pipelines/processors/custom_processor/" |
| 9 | + tag: "Documentation" |
| 10 | + text: "Learn more about the Custom Processor processor" |
| 11 | +--- |
| 12 | + |
| 13 | +## Overview |
| 14 | + |
| 15 | +Observability Pipelines' processors enable you to add, edit, and remove log fields. Remapping attributes or rewriting values ensures your logs are processed and standardized properly. For the majority of processing use cases, use the Edit Fields processor to add, remap, or remove fields from your logs. For advanced use cases, use the Custom Processor to conditionally modify fields or rewrite a field's value. |
| 16 | + |
| 17 | +In Datadog, [reserved attributes][1] are log fields that are set aside for specific processing in the platform. Reserved attributes include ` host`, `source`, `status`, `service`, `trace_id`, and `message`. Reserved attributes are applied when routing logs to the following Observability Pipelines destinations: |
| 18 | + |
| 19 | +- Datadog Logs |
| 20 | +- Amazon S3 (for Log Archives) |
| 21 | +- Azure Blob Storage (for Log Archives) |
| 22 | +- Google Cloud Storage (for Log Archives) |
| 23 | + |
| 24 | +There are restrictions in Observability Pipelines on how you can modify reserved attributes. For example, reserved attributes cannot be renamed using the Rename Field processor, but must be remapped instead. This guide walks you through the steps to remap the value of reserved attributes. |
| 25 | + |
| 26 | +## Remap the value of reserved attributes |
| 27 | + |
| 28 | +To change or override the value of an existing reserved attribute field, Datadog recommends two approaches using Observability Pipelines. The first uses the Edit Fields processor, and the second uses the Custom Processor. |
| 29 | + |
| 30 | +### Use an Edit Fields processor for basic field assignments |
| 31 | + |
| 32 | +1. Use a **Remove field** processor to drop the reserved attribute from the log. |
| 33 | +2. Use an **Add field** processor to add the reserved attribute back to the log with your correct field name and value assignment. |
| 34 | + |
| 35 | +**Note**: In terms of the processor order, the **Add Field** processor should go immediately after the **Remove Field** processor to ensure correct field remapping. |
| 36 | + |
| 37 | +#### Example |
| 38 | +The **Remove field** processor image below removes the improperly named `service` field from the log. |
| 39 | + |
| 40 | +{{< img src="observability_pipelines/guide/remap_attributes/remove_field_remap.png" alt="A remove field processor that drops the service tag and an add field processor that adds the service field with the value payment-app" style="width:50%;" >}} |
| 41 | + |
| 42 | +The **Add field** processor image below re-adds the `service` field back with the correct value. |
| 43 | + |
| 44 | +{{< img src="observability_pipelines/guide/remap_attributes/add_field_remap.png" alt="A remove field processor that drops the service tag and an add field processor that adds the service field with the value payment-app" style="width:50%;" >}} |
| 45 | + |
| 46 | +### Use the Custom Processor for dynamic or manual assignments |
| 47 | + |
| 48 | +Use the **Custom Processor** to rewrite the reserved attribute's value. |
| 49 | + |
| 50 | +#### Dynamically assign the value using template syntax to reference another field's value. |
| 51 | + |
| 52 | +The following Custom Processor script rewrites the `service` field and dynamically assigns the value of `app_id` to the `service` field's value. |
| 53 | + |
| 54 | +``` |
| 55 | +.service = {{.app_id}} |
| 56 | +``` |
| 57 | + |
| 58 | +In the below example image, the input shows `service` with the value `wrongstatus`. After processing the log with the script, the output shows `service` with the value of `streaming-service`, which is `app_id`'s value. |
| 59 | + |
| 60 | +{{< img src="observability_pipelines/guide/remap_attributes/custom_processor_dynamically_assign.png" alt="A custom processor showing an input the incorrect status value and the output showing the correct status" style="width:100%;" >}} |
| 61 | + |
| 62 | +#### Manually rewrite the value of an attribute with a static name |
| 63 | + |
| 64 | +The following Custom Processor script sets the `status` field to the static value `info`. |
| 65 | + |
| 66 | +``` |
| 67 | +.status = "info" |
| 68 | +``` |
| 69 | + |
| 70 | +In the below example image, the input shows `status` with the value `wrongstatus`. After processing the log with the script, the output shows `status` with `info` as assigned. |
| 71 | + |
| 72 | +{{< img src="observability_pipelines/guide/remap_attributes/custom_processor_statically_assign.png" alt="A custom processor showing an input the incorrect status value and the output showing the correct status" style="width:100%;" >}} |
| 73 | + |
| 74 | +## Further reading |
| 75 | + |
| 76 | +{{< partial name="whats-next/whats-next.html" >}} |
| 77 | + |
| 78 | +[1]: /logs/log_configuration/attributes_naming_convention/#reserved-attributes |
0 commit comments