Observe instantaneous events

[jonatan-ivanov]

This issue is for having a discussion and gathering feedback about the ability of observing instantaneous events using the Observation API.
Right now, an Observation needs to be started and stopped and it also has a duration. There are use-cases where the event we are observing is instantaneous or we don't care about its duration.

One fictitious example could be a repair shop where we can measure each step of repairing something (with duration) but as tools used in a step can worn out, they need to be replaced during the process. This "replace-the-tool" even can be instantaneous and we probably want to record the fact that a tool got replaced during the process.

A more real-life scenario could be listening to security events like these. This tracks through a scenario when a user can "authenticated", this authentication can be replaced (elevated) and the user can lose its "authenticated" status.
As an output we can log, count, and annotate spans with these events.

Another interesting scenario can be structured logging for security events. A common ask for security libraries (/cc @jzheaux) is logging out security events in a well-defined and structured format (CEF, LEEF). These events are by nature instantaneous, also multiple events (even multiple instances of the same event) can happen in a single call (request). Being able to observe instantaneous events would cover this use-case also, it would make it easy to extend the logging functionality with recording counters and/or annotating spans.

[jzheaux]

Other possible examples from the security space:

SessionCreatedEvent - It's valuable to know when sessions are created, how many were created over a span of time, if several were created from a given IP address, etc. Oftentimes, sessions are abandoned, so it's not ideal to wait for a session destroyed event to close the observation. There would likely be numerous orphaned timers.

It's not yet clear to me that Micrometer is ideal for simplifying security audits. But if so, then we also don't want to wait until a session is destroyed to find out a session was created, from an incident response perspective.

AccountLockedEvent - This is a consequence of potentially disparate conditions and is not tied to any particular request. For example, a user has tried too many times with an incorrect password. Or, an admin locks the account manually. Or, when an application is listening on a background topic for security events, it makes a decision to lock several accounts to automatically guard against a discovered threat.

Instead of needing to parse how many account locks happen across disparate timers of varying business cases, each of these applications can simply fire an AccountLockedEvent and Spring Security can record the event using Micrometer.

[shakuzen]

See previously raised related issues: #2125 #1097 #581