elastic/ecs

Remove mapping for field `faas.trigger`

gsantoro opened this issue · 3 comments

Summary

I would like to remove the mapping for the field faas.trigger of type nested.

Motivation:

  • The field faas.trigger can only accept a single object like you can see in the apm code at here
  • Nested documents and queries are typically expensive
  • the field faas.trigger is an object in ECS but it maps to a single string in Otel like documented at issue and in the Otel docs
  • Avoiding unnecessary nested fields should make it easier to support subobjects: false in the project Logs+ for default o11y mappings.

Detailed Design:

Provide additional details around the design of the proposed changes.

  • Field names: faas.trigger
  • Example values for the fields
"trigger": {
          "request_id": "10",
          "type": "http"
      }
  }
  • Suggested appropriate datatypes

suggested mapping. Notice the change

{
    "mappings": {
        "properties": {
            "faas": {
                "type": "object"
            },
            "mappings": {
                "properties": {
                    "trigger": {
                        "type": "object"
                    },
                    "mappings": {
                        "properties": {
                            "request_id": {
                                "type": "keyword"
                            },
                            "type": {
                                "type": "keyword"
                            }
                        }
                    }
                }
            }
        }
    }
}
  • Any example events that map to the proposed use case(s)
{
    "faas": {
        "trigger": {
            "request_id": "10",
            "type": "http"
        }
    }
}

or

{
    "faas.trigger.request_id": "10",
    "faas.trigger.type": "http"
}

Can we incorporate this change and feedback into a Stage 3 PR for the faas.* RFC? Seems like a sensible change we want to incorporate before making the faas.* fields GA in the schema, and it'd be great to advance and finalize that RFC.

hello @ebeahan , after a discussion with @AlexanderWert we are thinking to add the change into stage 2 still to prevent to go GA yet.

After the ECS changes get merged, please also adjust the dynamic ECS mappings in elastic-package: https://github.com/elastic/elastic-package/blob/6904fbc9f58d4f967819d09f71675637e47391a6/internal/builder/_static/ecs_mappings.yaml#L450-L453