Both fields are almost equivalent in nature, and are potentially pretty big.

Distinction between them makes log.original sound like a temporary debugging field, whereas event.original is the field is meant to capture the original untouched event, used for determining log integrity.

I think we should keep only one, with the purpose of capturing the original untouched event, to determine log integrity. I think the other one should go away and be captured in a custom field by data sources that need it.

I've personally been going back & forth which one I think makes the most sense to keep around ultimately. So which one we deprecate for future removal is up for debate. Feedback welcome.

Remove "event.original" and keep "log.original"

Pros

• I consider log.* to be a place for low level details, and I think log.original fits well in that philosophy

Cons

• This would make it a double breaking change, in a sense. This not only removes event.original, but moves its current definition around to log.original
• Not all events are logs. E.g. capturing a third party metric and having its original event captured in log.original may sound a bit weird to users.

Remove "log.original" and keep "event.original"

Pros

• The event.original field retains its current definition
• It's the guidance I've provided most often when people asked which one to use to capture the untouched log. As such, I think Beats uses mostly event.original (to be confirmed), so removing log.original would therefore be less painful down the line.

Cons

• I consider event.* a place to capture higher level details (often very short fields), and having a big payload in there feels a bit out of place.