Skip to content

Conversation

@Zawadidone
Copy link
Contributor

It helps when all fields that use the type digest are named digests, where possible. Depending on which search platform is used, e.g. Elasticsearch https://github.com/huntandhackett/ir-automation/blob/a005f5d2ea58a8beabe7c6ae0e25e0c0ae16ce85/logstash-dissect.conf#L54-L62, this field type must be stored as an object compared to the other field types that only contain one value (integer, string, etc.).

It helps when all fields that use the type `digest` are named `digests`,
where possible.
Depending on which search platform is used, e.g. Elasticsearch https://github.com/huntandhackett/ir-automation/blob/a005f5d2ea58a8beabe7c6ae0e25e0c0ae16ce85/logstash-dissect.conf#L54-L62,
this field type must be stored as an object  compared to the
other field types that only contain one value (integer, string, etc.).
@Schamper
Copy link
Member

While not a bad consistency change per se, I don't think it's a great idea to depend on the field names for that kind of functionality. E.g. just last week the SSH key fingerprints where added with the field name fingerprint: #673

Is this not something that can be structurally better solved within perhaps the Elastic adapter in flow.record?

@Zawadidone
Copy link
Contributor Author

Yes indeed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants