[RFC] Faas fields - stage 1

[AlexanderWert]

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process?
• If submitting code/script changes, have you verified all tests pass locally using make test?
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes?
• Is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
• Have you added an entry to the CHANGELOG.next.md?

[ebeahan]

Stage 1 criteria

• Opened pull request for this proposal revising the existing strawperson
• Identified “sponsor” at Elastic who will participate in RFC process and take ownership of the change after the process completes
• Outlined initial field definitions
• High-level description of examples of usage
• High-level description of example sources of data
• Identified potential concerns and implementation challenges/complexity
• Subject matter experts identified and weighed in on the high level utility of these changes in the pull request
• ECS team weighed in on appropriateness of these changes in the pull request

[ebeahan]

I propose instead of nesting at _.origin.*, the existing top-level field set represents the origin. The target would be nested at _.target.* as proposed.

This approach continues the pattern adopted for the user field set: user.* and user.target.*. The user/service/entity performing the main action is captured under the top-level with the user/service/entity affected by the action residing at _.target.*.

Example :

{
  "service": {
    "name": "origin-service",
    "target": {
      "name": "target-service"
    }
  }
}

Using the existing top-level fields for the event "doer" lets users continue using existing queries. For example, only querying service.name instead of needing to account for both service.name and service.origin.name.

[Mpdreamz]

origin is in addition to service.name, it gives more context as to where the function was invoked from.

CALLEE -> FUNCTION INVOCATION -> OUTGOING CALL

the proposal allows us to set information for all three stages:

service.origin.name -> service.name -> service.target.name

With service.* always being present and relating the the do'er or FUNCTION INVOCATION itself.

[ebeahan]

Thanks, @Mpdreamz, for the follow-up. I also reviewed the trigger examples from elastic/apm#470, and those examples also helped me to understand these FaaS use cases better.

I'm still hesitant that introducing the _.origin.* nestings could create confusion. For example, when a user should select service.name or cloud.service.name versus service.origin.name or cloud.origin.service.name. However, if we define the difference clearly in the ECS docs, we can hopefully avoid confusion between the two.

I have no objection to moving forward with the _.origin.* nestings as proposed. However, can we please summarize what we discussed here as a potential concern in the Concerns section?

[ebeahan]

Noted a potential concern to capture in #1542 (comment), otherwise LGTM.

[Mpdreamz]

Thank you @ebeahan!, I've amended the PR with the a note of the concerns raised. Let me know if I did your concerns justice 🙂

[ebeahan]

LGTM - thanks! I'll set the Date: to today's date and merge.