Some input… We don't need a CEP for this: Diagnostic Events already exists, as do Virtual Tables. But if you want to take it to a CEP, that's to be encouraged :)
Virtual Tables should remain virtual, i.e. they shouldn't be backed by custom system_* tables solely for the sake of persisting the virtual table data. Furthermore, I'd avoid a) the write amplification this would cause, and b) putting queue data into a system table. (Let's not repeat the hints table). A big +1 to adding a virtual table that reads `DiagnosticEventPersistence. instance().getEvents(..)` That is, adding a virtual table for diagnostic events that honours the already existing backend store (whatever it is memory or binlog). This will be an effective and elegant solution to CASSANDRA-13472 (thank you for bringing this to light!) And, a big +1 to adding local persistence of diagnostic events using binlog (ChronicleQueue). > My concern is that there would be "too much data" in them and it might grow and grow as a node is live, … It is in the same category as auditing and fql. The limit is there as it is expected that a client is collecting these events, and that the store (memory or binlog) is not the permanent archive. Check out how Reaper collects and archives diagnostic events: https://github.com/thelastpickle/cassandra-reaper/blob/master/src/server/src/main/java/io/cassandrareaper/service/DiagEventPoller.java
