Loki sink: Labels with "-" in them seemingly ignored.

[jaqb76]

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

It looks like labels with dash "-" in them are ignored by the loki sink. e.g.

application = '{{ kubernetes.pod_labels.app-name }}'

does not create the application label.

Actual Behavior

label.application is missing.

Expected Behavior

application = '{{ kubernetes.pod_labels.app-name }}'

Configuration

loki_sink:
        compression: gzip
        remove_label_fields: true
        encoding:
          codec: json
        endpoint: https://loki-xxxx
        inputs:
        - kubernetes_logs
        labels:
          clustername: test_cluster
          container: '{{ kubernetes.container_name }}'
          forwarder: vector
          host: '{{ kubernetes.pod_node_name }}'
          namespace: '{{ kubernetes.pod_namespace }}'
          pod: '{{ kubernetes.pod_name }}'
          app: '{{ kubernetes.pod_labels.app }}'
          application: '{{ kubernetes.pod_labels.app-name }}'
          release: '{{ kubernetes.pod_labels.release }}'
          pod_uid: '{{ kubernetes.pod_uid }}'
          region: us-east-2
          pod_labels: '{{kubernetes.pod_labels}}'
        type: loki

Version

INFO vector: Vector has started. debug="false" version="0.24.0" arch="x86_64" build_id="43267b9 2022-08-30"

Debug Output

No response

Example Data

Additional Context

References

No response

[spencergilbert]

👋

Hi there, try this template syntax instead:

- application = '{{ kubernetes.pod_labels.app-name }}'
+ application = '{{ kubernetes.pod_labels."app-name" }}

We've been updating how Vector looks up paths to be aligned with VRL, unfortunately it looks like the docs around template syntax and field path notation weren't updated at the time of the change. I'm writing a pull request to address that now, but it should be replaced by path expressions.

Additionally the compile time checking of these paths is incomplete and is tracked by #13033 which we are hoping to tackle this quarter.

Let me know if this doesn't solve the problem and I'll reopen the issue!