Clarify @timestamp vs event.created

To quote the current readme from event.created:

event.created contains the date when the event was created. This timestamp is distinct from @timestamp in that @timestamp contains the processed timestamp.

If say we take a fake login pseudo-event: Jan 20 10:17:24 SERVER auth: username logged in

The user actually logged in at 10:17:24 for all we know. Based on this comment by @ruflin https://github.com/elastic/ecs/issues/8#issuecomment-393418791 it would seem that event.created is the time that whatever tool (logstash, beats, etc) reads the file or received the syslog event. I do not think Filebeats works this way, and I know Winlogbeats does not. It will set @timestamp to the time the event occurred or when it landed in the local logging system, which I view as correct.

Can what “processed” means here be clarified? To me, when the event was created is when it occurred, and processed is when some tool (which could be many, Beats, LS, ES, etc) received the event. My real-world use case allows for events collected by a management console to make the time an event happened and the time when it was processed to be several minutes apart.

[praseodym]

There is one disadvantage to this. Many log sources (especially syslog) do not use sub-second precision timestamps, which means that using a parsed value as @timestamp will cause Kibana to display events in the wrong order (the ordering within a second will be essentially random). In these cases, it might be better to use event.created as the time field in Kibana.

[mbrancato]

I think this sounds like a good plan. My goal was not to call for a renaming of event.created, just a clarification.

There are some data sources I see where an event happens on an endpoint, the management console for that tool collects the event a few minutes later, then passes it to Logstash. IMO the event happened when it happened, and that is the @timestamp. This lets me correlate that event with say network flows, or other data. However, the event may have been received a few minutes later, and I think that is a good candidate for event.created.

To use the Winlogbeats example. If the Winlogbeats service is stopped for a few minutes, and then restarted, it should not change the @timestamp of events in its backlog to process, but it might affect the event.created field.