> 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/rename-fields.md).
# Rename Fields
Renames resource, attribute, or log body fields on the records flowing through a pipeline. Each row maps an existing field name to a new name. Body fields are renamed on logs only; resource and attribute fields are renamed on metrics, logs, and traces.
### Supported Telemetry
| Metrics | Logs | Traces |
| ------- | ---- | ------ |
| ✓ | ✓ | ✓ |
### Configuration
**When to apply**
| Parameter | Type | Required | Default | Description |
| --------------------- | ------------------ | -------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Choose Telemetry Type | Telemetry Selector | No | Logs, Metrics, Traces | The signal types this instance acts on. Rename runs on each selected signal. |
| Condition | OTTL Condition | No | *(empty)* | An OTTL condition that must evaluate to true for a record to be renamed. When empty, the processor applies to all telemetry. |
**Fields**
| Parameter | Type | Required | Default | Description |
| --------- | ---------- | -------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fields | Field list | Yes | *(empty)* | The fields to rename. Each row has a field type (Resource, Attribute, or Body), the existing field name, and the new field name. Add one row per field. **Body is logs-only**: a Body row is ignored on metrics and traces. |
Each Fields row carries three values:
| Row value | Description |
| ---------- | ---------------------------------------------------------------------------------- |
| Field Type | Where the field lives: Resource, Attribute, or Body. Body applies to logs only. |
| Old Name | The existing field name to rename. Matched exactly (anchored), not as a substring. |
| New Name | The replacement field name. |
### Examples
#### Rename an attribute field
Rename the `host` attribute to `host.name` on all signals. Attribute renames apply to metrics, logs, and traces, so leave all three telemetry types selected.
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: rename-fields
spec:
type: rename_fields_v2
parameters:
- name: telemetry_types
value:
- Logs
- Metrics
- Traces
- name: fields
value:
- fieldType: attributes
key: host
value: host.name
```
#### Rename a resource field
Rename the `service` resource field to `service.name`. Resource renames also apply across all signals.
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: rename-fields
spec:
type: rename_fields_v2
parameters:
- name: telemetry_types
value:
- Logs
- Metrics
- Traces
- name: fields
value:
- fieldType: resource
key: service
value: service.name
```
#### Rename several fields at once, logs only
Rename a log body field, an attribute field, and a resource field in a single instance, gated by a condition so only error logs are touched. Because a Body row is included, this instance runs on logs only.
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: rename-fields
spec:
type: rename_fields_v2
parameters:
- name: telemetry_types
value:
- Logs
- name: condition
value: severity_number >= SEVERITY_NUMBER_ERROR
- name: fields
value:
- fieldType: body
key: status
value: status_code
- fieldType: attributes
key: host
value: host.name
- fieldType: resource
key: service
value: service.name
```
### Configuration Tips
* Body fields are renamed on logs only. A Body row in an instance that also targets metrics or traces is silently ignored for those signals; keep Body renames in a logs-only instance to avoid confusion.
* Old Name is matched exactly (anchored to the full field name), not as a partial match. To rename several similarly-named fields, add a row for each.
* The rename operates on the field key, not on nested paths. Renaming a top-level field does not move or restructure its children.
### Troubleshooting
#### A field is not renamed
Symptoms: the record still shows the old field name after the processor runs.
Solutions:
1. Confirm the Field Type matches where the field actually lives (Resource vs. Attribute vs. Body). A field in attributes will not be renamed by a Resource row.
2. Verify Old Name matches the existing field name exactly. The match is anchored, so trailing or surrounding characters cause it to miss.
3. Check the Condition. If it does not evaluate to true for the record, the rename is skipped.
#### A body field rename does nothing on metrics or traces
Symptoms: a Body row has no effect on metric or trace telemetry.
Solution: Body fields exist only on logs. Use Resource or Attribute field types for metrics and traces, or move the Body rename into a logs-only instance.
#### Two fields collide after renaming
Symptoms: a renamed field overwrites another field with the same target name.
Solution: New Name produces a field with that key. If a field by that name already exists, the result depends on downstream handling. Choose target names that do not already exist on the record.
### Standalone Processor
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: rename-fields
spec:
type: rename_fields_v2
parameters:
- name: telemetry_types
value:
- Logs
- Metrics
- Traces
- name: condition
value: ""
- name: fields
value:
- fieldType: attributes
key: host
value: host.name
- fieldType: resource
key: service
value: service.name
- fieldType: body
key: status
value: status_code
```
### Related Resources
* [Transform Processor — OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md)
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.bindplane.com/integrations/processors/rename-fields.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.