Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve stackdriver logs sink #22374

Open
fbs opened this issue Feb 5, 2025 · 1 comment
Open

Improve stackdriver logs sink #22374

fbs opened this issue Feb 5, 2025 · 1 comment
Labels
type: feature A value-adding code addition that introduce new functionality.

Comments

@fbs
Copy link

fbs commented Feb 5, 2025

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

Use Cases

The stackdriver sink support only a small set of the fields Google supports. Useful fields like labels and the trace correlation fields are not supported

Attempted Solutions

Proposal

The sink currently seems to have two ways of setting fields:

  • resource are fields in the sink config, the name is fixed but the value can be templated. To avoid having them also in the actual jsonPayload encoding.except_fields needs to be used. E.g.
# example data
 { "message": "some log message", "resources": { "namespace": aaa}}

# sink
gcp:
  type: gcp_stackdriver_logs
  inputs:
  - remap_gcp
  encoding:
    except_fields:
    - resource
  resource:
    type: k8s_container
    namespace: "{{ .resource.namespace }}"
  • severity, which fetches and removes the value from the log message,
# example data
 { "message": "some log message", "severity": 1}

# sink
gcp:
  type: gcp_stackdriver_logs
  inputs:
  - remap_gcp
  encoding:
    except_fields:
    - resource
  severity_key: severity

Both approaches seem like they can work, but neither is ideal. I'd prefer it if the sink would be opinionated and performs fixed format/mapping from the input to LogEntry.
However doing that has 2 issues:

  1. it introduces a 3rd way of working, but fixing the others would be a breaking change
  2. its a breaking change, as it potentially removes fields that used to end up in the jsonPayload.

What way does best fit the Vector?

References

Version

v0.44.0

@fbs fbs added the type: feature A value-adding code addition that introduce new functionality. label Feb 5, 2025
@fbs
Copy link
Author

fbs commented Feb 5, 2025

I'm interested in implementing this, but need some guidance on how the config should look (VRL&sink).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature A value-adding code addition that introduce new functionality.
Projects
None yet
Development

No branches or pull requests

1 participant