remap host metrics not working

[lake2]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

timezone: 'Asia/Shanghai'
log_schema:
    host_key: 'vector.host'
    source_type_key: 'vector.source'
    timestamp_key: 'vector.timestamp'

sources:
    host_metrics:
        type: host_metrics
        collectors: ['memory']
        scrape_interval_secs: 5

transforms:
    host_metrics_json:
        type: remap
        inputs:
            - host_metrics
        source: |
            .a = "========"
            log(.) # <======== object not change here
sinks:
    debug:
        inputs:
            - host_metrics_json
        type: 'console'
        encoding:
            codec: 'json'
            # json:
            #     pretty: true
            timestamp_format: 'rfc3339'

output:

{"name":"memory_swapped_in_bytes_total","namespace":"host","tags":{"collector":"memory","host":"553e058dca01"},"timestamp":"2025-12-25T15:24:38.192509810Z","kind":"absolute","counter":{"value":0.0}}

command:

docker run -it --rm \
  --name vector-dev \
  --network log \
  -v /proc:/host/proc:ro \
  -v /sys:/host/sys:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v $PWD/vector2.yaml:/etc/vector/vector.yaml:ro \
  -e PROCFS_ROOT=/host/proc \
  -e SYSFS_ROOT=/host/sys \
  timberio/vector:0.52.0-alpine \

Configuration

Version

0.52.0

Debug Output

Example Data

No response

Additional Context

No response

References

No response

[byronwolfman]

This is somewhat expected, as Vector has an opinionated data model for metrics: https://vector.dev/docs/architecture/data-model/metric/

Unlike other tools, metrics in Vector are first class citizens, they are not represented as structured logs. This makes them interoperable with various metrics services without the need for any transformation.

Vector’s metric data model favors accuracy and correctness over ideological purity. Therefore, Vector’s metric types are a conglomeration of various metric types found in the wild, such as Prometheus and StatsD. This ensures metric data is correctly interoperable between systems.

Adding/modifying .a doesn't change the the metric because there's no such field in the metric data model. Arbitrary key-value data would usually go into tags:

  transforms:
      host_metrics_json:
          type: remap
          inputs:
              - host_metrics
          source: |
-             .a = "========"
+             .tags.a = "========"
              log(.)

Given the "interoperable" data model, this will submit a as a tag to sinks like datadog_metrics, or as a label for sinks like prometheus_exporter. The other fields in the link above can also be modified, depending on the result you're going for. If you're dealing with a destination that needs a more flexible data model, then it's possible you may need/want to use metric_to_log since logs can have practically any arbitrary field, and whether the destination treats them as a log or a metric or something else is up to the strictness of the destination/vendor itself.

[lake2]

This is somewhat expected, as Vector has an opinionated data model for metrics: https://vector.dev/docs/architecture/data-model/metric/

Unlike other tools, metrics in Vector are first class citizens, they are not represented as structured logs. This makes them interoperable with various metrics services without the need for any transformation.

Vector’s metric data model favors accuracy and correctness over ideological purity. Therefore, Vector’s metric types are a conglomeration of various metric types found in the wild, such as Prometheus and StatsD. This ensures metric data is correctly interoperable between systems.

Adding/modifying .a doesn't change the the metric because there's no such field in the metric data model. Arbitrary key-value data would usually go into tags:

transforms:
host_metrics_json:
type: remap
inputs:
- host_metrics
source: |

•         .a = "========"
  

•         .tags.a = "========"
          log(.)
  

Given the "interoperable" data model, this will submit a as a tag to sinks like datadog_metrics, or as a label for sinks like prometheus_exporter. The other fields in the link above can also be modified, depending on the result you're going for. If you're dealing with a destination that needs a more flexible data model, then it's possible you may need/want to use metric_to_log since logs can have practically any arbitrary field, and whether the destination treats them as a log or a metric or something else is up to the strictness of the destination/vendor itself.

Thanks. That helps a lot