4.0 introduced a new event system based upon a ring buffer (MODE-2088), and this was shown to be noticeably faster. Unfortunately, the existing event-related metrics are not all a good fit, and need to be rethought. Perhaps these metrics:

• EVENT_COUNT - The number of events that have been sent into the system (e.g., captured by the ring buffer). This can be handled in the ring buffer by simply incrementing the metric for each entry. It is not continuous, as it will never decrease. (The windowing system will obtain metrics within each time slice.) This metric currently exists, but the description needs to be tweaked and the ring buffer or event bus needs to change to capture it.
• EVENT_QUEUE_SIZE - This is an existing metric that doesn't really have a corollary in the new system, but I think we can change it to represent the number of events that the slowest listener has yet to process. Again, this metric can be recorded via the ring buffer's cursor, which is already keeping track of the trailing position (to prevent the leading position from wrapping around it).
• EVENT_BUFFER_AVAILABILITY - This would be a new continuous metric that says how much space in the ring buffer is free; essentially it's the total size of the ring buffer minus the number of entries that the slowest trailer is behind the leader. For example, the value would be 100 if the leader is 100 entries behind the trailing position. On the other hand, this is 0 if the trailing consumer is so slow that the producer has to wait (and is providing back pressure). This can be implemented directly in the ring buffer's cursor.
• LISTENER_COUNT - This is an existing continuous metric that we should definitely be using, but it can probably be captured easiest in the local event bus implementation.

This is all that I can think of right now.