A few users reported mapping errors on a few integrations. We suspect these problems may be related to integrations that migrated to ecs@mappings with recent updates.
Here is the list of fields with mapping issues:
| Field |
Previous mapping |
Current mapping |
Data Stream |
Status |
Root Cause |
Notes |
Issues / PRs |
client.geo.location |
geo_point |
object |
logs-azure.graphactivitylogs-* |
Reproduced |
integration-mapping-problem |
I believe this is an integration-mapping-problem |
#11102 |
source.geo.location |
geo_point |
object |
logs-azure.graphactivitylogs-* |
Reproduced |
integration-mapping-problem |
I believe this is an integration-mapping-problem |
#11102 |
destination.port |
long |
keyword |
logs-cisco_aironet.log-* |
Needs sample docs |
ecs@mappings+type-coercion |
Probably an ecs@mappings+type-coercion issue, but I don't have a sample document to double-check; probable, but still a hypothesis. |
#11103 |
event.duration |
long |
keyword |
logs-azure.activitylogs.log-* |
Needs sample docs |
ecs@mappings+type-coercion |
Probably an ecs@mappings+type-coercion issue, but I don't have a sample document to double-check; probable, but still a hypothesis. |
#11104 |
dns.authorities |
|
|
|
|
|
|
|
dns.id |
long |
keyword |
logs-logstash.tpot-* |
|
|
|
|
error.code |
keyword |
long |
logs-system.security-* |
Unclear |
integration-update |
PR changed the value type to string with the PR https://github.com/elastic/integrations/pull/10529/files ; expected field mapping in ECS is keyword https://www.elastic.co/guide/en/ecs/current/ecs-error.html#field-error-code |
|
event.severity |
long |
keyword |
logs-cisco_aironet.log-* |
Reproduced |
ecs@mappings+type-coercion |
ecs@mappings+type-coercion, I found the following sample doc in the integration test files: {"event.severity": "4"}; ECS expected type is long https://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-severity |
#11105 |
http.request.body |
object |
flattened |
logs-apm.error-* |
|
|
|
|
http.request.headers |
flattened |
object |
logs-apm.error-* |
|
|
|
|
http.response.headers |
flattened |
object |
logs-apm.error-* |
|
|
|
|
input |
object |
keyword |
logs-logstash.tpot-* |
|
|
|
|
log.offset |
long |
keyword |
logs-microsoft_exchange_server.httpproxy-* |
Reproduced |
integration-update |
PR https://github.com/elastic/integrations/pull/9560/files added an explicit mapping to keyword |
|
observer.ip |
ip |
keyword |
logs-ti_abusech_latest.dest_malware-* |
|
|
|
|
request |
text |
object |
logs-logstash.tpot-* |
|
|
|
|
response |
text |
object |
logs-logstash.tpot-* |
|
|
|
|
session |
|
|
|
|
|
|
|
sip.uri |
|
|
|
|
|
|
|
status |
keyword |
long |
logs-logstash.tpot-* |
|
|
|
|
threat.indicator.first_seen |
date |
keyword |
logs-ti_abusech.malware-* |
Reproduced |
ecs@mappings+date_detection:false |
|
elastic/elasticsearch#112444 |
threat.indicator.last_seen |
date |
keyword |
logs-ti_abusech.malwarebazaar-* |
Reproduced |
ecs@mappings+date_detection:false |
|
elastic/elasticsearch#112444 |
timestamp |
|
|
|
|
|
|
|
user_agent |
object |
keyword |
logs-cisco_asa.log-* |
Unclear |
|
object is the expected mapping for user_agent; see https://www.elastic.co/guide/en/ecs/current/ecs-user_agent.html |
|
Root Causes
| Cause |
Summary |
Solution |
| ecs@mappings+type-coercion |
Mapping changed because ecs@mappings does not perform type coercion |
Set the right value type in the input/pipeline, or restore explicit mapping in fields/ecs.yml file |
| ecs@mappings+date_detection:false |
Setting date_detection: false cause a few fields to not be mapped as date |
Set date_detection: true or update ecs@mappings |
| integration-mapping-problem |
Incorrect mapping in the integration |
Review the change and fix the mapping, in necessary. |
| integration-update |
Explicit change in integration |
Probably deal with this breaking change if the outcome is in line with ECS |
| fieldless-search |
On 8.13.x ECS fields are no longer included in index.query.default_field, so they are not available in fieldless search |
As of today, restoring the fields/ecs.yml for 8.13.x users can restore fieldless searches. Users on > 8.14.x are not affected since index.query.default_field is * |
ecs@mappings+type-coercion
The ecs@mappings component template does not perform type coercion, so if the value is a string, ES maps it as a keyword.
Here is an example, if I perform the following requests using the Dev Tools:
DELETE _data_stream/logs-whatever-sdh5075
POST logs-whatever-sdh5075/_doc
{
"@timestamp": "2024-08-20T16:58:01+02:00",
"destination": {
"port": "8080"
}
}
GET logs-whatever-sdh5075/_mapping/field/destination.port
I get the following result:
{
".ds-logs-whatever-sdh5075-2024.08.22-000001": {
"mappings": {
"destination.port": {
"full_name": "destination.port",
"mapping": {
"port": {
"type": "keyword",
"ignore_above": 1024
}
}
}
}
}
}
ecs@mappings+date_detection:false
When date_detection is disabled, the following fields aren’t mapped correctly:
threat.indicator.first_seen
threat.indicator.modified_at
threat.enrichments.indicator.modified_at
threat.enrichments.matched.occurred
threat.enrichments.indicator.first_seen
threat.enrichments.indicator.last_seen
threat.indicator.last_seen
integration-mapping-problem
We probably need to change mappings in the integration to something similar (like most other integrations do):
- name: client.geo.location
external: ecs
- name: source.geo.location
external: ecs
Or remove these mappings and only use ecs@mappings.
integration-update
Mapping changed due to integration updates.
A few users reported mapping errors on a few integrations. We suspect these problems may be related to integrations that migrated to ecs@mappings with recent updates.
Here is the list of fields with mapping issues:
client.geo.locationgeo_pointobjectlogs-azure.graphactivitylogs-*source.geo.locationgeo_pointobjectlogs-azure.graphactivitylogs-*destination.portlongkeywordlogs-cisco_aironet.log-*event.durationlongkeywordlogs-azure.activitylogs.log-*dns.authoritiesdns.idlongkeywordlogs-logstash.tpot-*error.codekeywordlonglogs-system.security-*keywordhttps://www.elastic.co/guide/en/ecs/current/ecs-error.html#field-error-codeevent.severitylongkeywordlogs-cisco_aironet.log-*{"event.severity": "4"}; ECS expected type islonghttps://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-severityhttp.request.bodyobjectflattenedlogs-apm.error-*http.request.headersflattenedobjectlogs-apm.error-*http.response.headersflattenedobjectlogs-apm.error-*inputobjectkeywordlogs-logstash.tpot-*log.offsetlongkeywordlogs-microsoft_exchange_server.httpproxy-*keywordobserver.ipipkeywordlogs-ti_abusech_latest.dest_malware-*requesttextobjectlogs-logstash.tpot-*responsetextobjectlogs-logstash.tpot-*sessionsip.uristatuskeywordlonglogs-logstash.tpot-*threat.indicator.first_seendatekeywordlogs-ti_abusech.malware-*threat.indicator.last_seendatekeywordlogs-ti_abusech.malwarebazaar-*timestampuser_agentobjectkeywordlogs-cisco_asa.log-*objectis the expected mapping foruser_agent; see https://www.elastic.co/guide/en/ecs/current/ecs-user_agent.htmlRoot Causes
fields/ecs.ymlfiledate_detection: falsecause a few fields to not be mapped asdatedate_detection: trueor update ecs@mappingsindex.query.default_field, so they are not available in fieldless searchfields/ecs.ymlfor 8.13.x users can restore fieldless searches. Users on > 8.14.x are not affected sinceindex.query.default_fieldis*ecs@mappings+type-coercion
The ecs@mappings component template does not perform type coercion, so if the value is a string, ES maps it as a
keyword.Here is an example, if I perform the following requests using the Dev Tools:
I get the following result:
{ ".ds-logs-whatever-sdh5075-2024.08.22-000001": { "mappings": { "destination.port": { "full_name": "destination.port", "mapping": { "port": { "type": "keyword", "ignore_above": 1024 } } } } } }ecs@mappings+date_detection:false
When date_detection is disabled, the following fields aren’t mapped correctly:
integration-mapping-problem
We probably need to change mappings in the integration to something similar (like most other integrations do):
Or remove these mappings and only use ecs@mappings.
integration-update
Mapping changed due to integration updates.