Open nicpenning opened 1 year ago
@jamiehynds - Can we get some eyes on this? This is posing a field conflict for us still and I am not sure the direction Elastic wishes to go.
My gut reaction is to just remove the mapping entirely but not sure if there are any dependencies on this field.
Any updates here?
👀Checking in for updates on how to proceed here. I am leaning towards removing these fields since they are not ECS.
Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale
to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1
. Thank you for your contribution!
The Cassandra integration may need to be a bit overhauled as it is using 2 fields with improper field mappings that contradict other integrations that contains it.
name: log.flags type: long description: This field contains the flags of the event.
These fields are not found in ECS so they need to be addressed. The O365 and MISP Integration does not specify these fields, therofore, in our environment they are being created with the default mapping of keyword.
I am not sure if the solution is changing these longs to keywords or just removing them entirely and letting Elasticsearch create the mappings on ingest with the default keyword value. I figured I would create the issue before submitting any changes as I don't know how required that these fields need to exist in their current form versus changing them to cassandra.log.offset and cassandra.log.flags as custom fields. Please advise!