cisco_aironet: add ECS mapping for event.severity #11105
Conversation
|
Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices) |
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
|
There was a problem hiding this comment.
The pipeline test is failing because it is expecting event.severity to be a long but is currently a string. We could either add a type annotation to the grok or add a convert processor. I don't have strong opinions either way.
- grok:
field: _temp_.full_message
ignore_failure: true
patterns:
- "%{DATA:event.provider}-%{INT:event.severity:long}-%{DATA:event.action}: %{DATA}:%{INT} %{GREEDYDATA:message}"
- "%{DATA:event.provider}-%{INT:event.severity:long}-%{DATA:event.action}: %{GREEDYDATA:message}"
Once that change is made, sample_event and readme also have to be regenerated.
|
Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
[git-generate] cd packages/cisco_aironet elastic-package test pipeline -g && elastic-package test system -v -g && elastic-package build
…gs-event-severity
🚀 Benchmarks reportTo see the full report comment with |
|
💚 Build Succeeded
History
cc @zmoog |
|
@taylor-swanson Can you please take another look. I addressed your comment in b0f92da. |
|
Package cisco_aironet - 1.14.2 containing this change is available at https://epr.elastic.co/package/cisco_aironet/1.14.2/ |
The problem is that the `ecs@mappings` component template (introduced in >=8.13.0) does not perform type coercion to long when the value was a string. In this specific integration scenario, the `event.severity` value was provided as a string. So the dynamic mapping never matched, which left `event.severity` with the default 'keyword' mapping type, which does not comply with ECS. This change adds back the static mapping for `event.severity` and modifies the grok pattern to perform conversion to long. Relates: elastic#10848 --------- Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
The problem is that the `ecs@mappings` component template (introduced in >=8.13.0) does not perform type coercion to long when the value was a string. In this specific integration scenario, the `event.severity` value was provided as a string. So the dynamic mapping never matched, which left `event.severity` with the default 'keyword' mapping type, which does not comply with ECS. This change adds back the static mapping for `event.severity` and modifies the grok pattern to perform conversion to long. Relates: #10848 --------- Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
The problem is that the `ecs@mappings` component template (introduced in >=8.13.0) does not perform type coercion to long when the value was a string. In this specific integration scenario, the `event.severity` value was provided as a string. So the dynamic mapping never matched, which left `event.severity` with the default 'keyword' mapping type, which does not comply with ECS. This change adds back the static mapping for `event.severity` and modifies the grok pattern to perform conversion to long. Relates: elastic#10848 --------- Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Proposed commit message
Add ECS mapping for the
event.severityfield.If a field has a string value, Elasticsearch maps it as a
keyword. This happens even on stack versions 8.13+ because ecs@mappings does not perform type coercion.According to the
sample_event.jsonfile, theevent.severityfield has a string value, so Elasticsearch maps it as akeywordinstead of along:By adding the
event.severityfield to the filefields/ecs.ymlwe ensure it has the expected ECS mapping.IMPORTANT: To fully resolve the issue, the input/integration owner should update it so that they can use the expected value to leverage ecs@mappings.
Checklist
changelog.ymlfile.Related issues