[Pause] Identify integration fields lists that rely on ordering and duplication #10900
Labels
Integration:All
Applies to all integrations [Integration not found in source]
Team:Cloud-Monitoring
Label for the Cloud Monitoring team
Team:Elastic-Agent-Data-Plane
Label for the Agent Data Plane team [elastic/elastic-agent-data-plane]
Team:obs-ds-hosted-services
Label for the Observability Hosted Services team [elastic/obs-ds-hosted-services]
Team:Obs-InfraObs
Label for the Observability Infrastructure Monitoring team [elastic/obs-infraobs-integrations]
Team:Security-Deployment and Devices
Deployment and Devices Security team [elastic/sec-deployment-and-devices]
Team:Security-Linux Platform
Linux Platform Security team [elastic/sec-linux-platform]
Team:Security-Service Integrations
Security Service Integrations Team [elastic/security-service-integrations]
Team:Stack Monitoring
Stack Monitoring team [elastic/stack-monitoring]
Description
With the upcoming LogsDB release, data is stored without the original _source, and this means that arrays can be reordered and de-duplicated. There are fields where order matters to end-users, such as
process.args
. Some fields do not function if de-duplication occurs within the array.A similar issue has been created for standard ECS fields to identify and flag fields that might be affected by relying on ordering or deduplication.
Our goal is to identify integration fields that rely on ordering or duplication. The integrations that could potentially be affected by this limitation within LogsDB are listed below. Code owners have been added as a checklist; if you are listed below, please:
@elastic/security-service-integrations
@elastic/sec-deployment-and-devices
@elastic/sec-linux-platform
@elastic/obs-infraobs-integrations
@elastic/obs-ds-hosted-services
@elastic/obs-cloudnative-monitoring
@elastic/stack-monitoring
@elastic/elastic-agent-data-plane
@elastic/ecosystem
The text was updated successfully, but these errors were encountered: