Closed vitaliidm closed 4 days ago
Pinging @elastic/response-ops (Team:ResponseOps)
@vitaliidm The field mappings for kibana.alert.original_event.*
are defined here: x-pack/plugins/security_solution/common/field_maps/8.0.0/alerts.ts and owned by security solution. ignore_above
can be added to the field definition in order to get it added to to mapping
@ymao1 , thanks for pointing out on that file. By adding ignore_above
, I was able to fix the first case.
But still, experience failures with the second one, where mapping in event.*
do not have ignore_above
and after the research look like, some of event.*
fields are not ECS compliant.
event.action
- in ECS schema it should have ignore_above:1024
. Reference
But it does not have in alerts index.
Same goes for event.kind
- refer to ECS schemaAnd I think, the reason for it, these mappings are getting overridden somewhere in alerting framework. I was able to find this template, where the wrong mappings possibly originated
event.original
in ECS schema is not indexable at all.
"original": {
"doc_values": false,
"index": false,
"type": "keyword"
},
But code that reads ECS properties does not account for that field
So, event.original
in alerts index becomes
"original": {
"type": "keyword"
},
and susceptible to error due to Lucene symbols limit
Looks like those are here: packages/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts
. It looks like you have a PR open to address the original_event
fields. Feel free to update the event.kind
and event.action
fields as well in that PR. I will open an issue to see if we can perform a check to ensure any re-defined ECS fields use the same field map definition.
Regarding event.original
, if we make index:false
, it might potentially break customer's workflows, where any search query relies on event.original
being indexed and searchable.
So, in order not break anything and fix current issue, do you think it make sense to add into file packages/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts
event.original
too? Where we can put ignore_above
similarly to the rest of fields
event.original
in the original ECS field mapping does not have an ignore_above
value so you're saying you want to override that mapping to include an ignore_above
? I agree that at this point, we probably don't want to put index: false
on that field.
event.original in the original ECS field mapping does not have an ignore_above value so you're saying you want to override that mapping to include an ignore_above?
Yes, it does not have ignore_above
, but not indexed instead (so it would work for large values over 32766)
While, we don't want to make it not indexed, putting ignore_above
there, would align this field with the rest of event fields and would prevent Lucene symbols limit error while indexing.
Sure, that sounds reasonable.
Closed with https://github.com/elastic/kibana/pull/187673
kibana.alert.original_event.*
keyword fields are mismatched with the original event’s mapping in many cases - the ignore_above attribute is not specified in kibana.alert.original_event.*.For example, the event.module mapped as
where as
kibana.alert.original_event.module
mapped asSame event object mappings
Most of the properties have "ignore_above", but some of them like
event.action
not.This leads to issues like https://github.com/elastic/kibana/issues/187630, where user can potentially save long text in event.module and everything will work fine as long as ignore_above is specified. If keyword field does not have ignore_above attribute (like kibana.alert.original_event.module) ES will throw an error when user will try to store huge text into that field. The limit is 32766 bytes which is a Lucene’s term byte-length limit https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html
We would like to have mappings of all event fields to include
ignore_above
, to prevent hitting the limit of 32766.