event fields confuse what "event" refers to

[rsk0]

Description of the issue:
There are two different senses of the term "event" being used in this field set.

• an “event” is something that happened, like a client requesting a URL or a process starting on a host
• an “event” is a record of something that happened

The most natural common expectation for what "event" means is the first item here. An event is something that happens, and we can talk about that particular happening: when it occurred, how long it lasted, what exactly happened, etc. Most event fields are for this sense. I say it's a "common" expectation because it depends on context. Sometimes instead...

There is another useful sense, talking about "event" as the record of the happening. We care about this sense in certain contexts, like when we're dealing with the record of the event moving through our event capturing/recording pipeline. For this, fields like ingested and created help us know about movement through the pipeline of the record of the event. But note that we're not talking about "event" in the sense of the original thing that happened now. created is not talking about how or when the original process activation got "created". It's talking about this record.

Any additional context or examples:
This is maybe something of a small issue, or at least subtle and maybe inconvenient or awkward to try to resolve. I found myself temporarily boggling when trying to figure out the specific meanings of the various time-related fields until I realized we were talking about two different things. (My context here is trying to add pipeline processing timing metadata to event records.)

This is not a pipe.

[rsk0]

Additional discussion context in the Elastic community Slack channel for ECS

[rsk0]

Pardon me, is there a way to link additional relevant issues (outside of commenting)?

• [meta] Add support for pipeline details in ECS (#940)

[webmat]

Thanks for capturing your thoughts here @rsk0!

I agree that these two timestamps don't currently have the best names. They indeed stand out as very Elastic-centric amidst a lot of fields that are centered on actual event details.

This is indeed related to #940: when fleshing out how to capture pipeline information (including timings), we should find better names for these two fields. When those are available, we can deprecate the timestamp fields you're bringing up above.

I've added a reference to this issue in #940 to make sure we consider the points you're raised here, when we work on the pipeline details.

Are you ok if we close this issue?

[ebeahan]

Will continue pursuing in #940