Yes, I think it would make sense to have the events available in a virtual table, especially if we are trying to move our operational management in that direction.
But, why does it need to be bin log or virtual tables? Why not both? The virtual tables could even return the data stored in the bin log making them persistent if wanted. -Jeremiah > On Jul 21, 2021, at 7:45 AM, Paulo Motta <pauloricard...@gmail.com> wrote: > > I'm not very familiar with diagnostic events, but I think there's great > value in providing a Virtual Table implementation to diagnostic events, > since this will help in the long term objective of providing a unified > interface to node monitoring, so +1 from my side. I think it would > definitely help to write a CEP to detail the proposal and cast a vote if > there are no objections. > > In case you are not aware, Apache has the concept of lazy consensus < > https://community.apache.org/committers/lazyConsensus.html>, so as long as > nobody opposes your proposal you're good to move forward with it, so people > not caring to even dropping an e-mail can actually be a good thing. ;) > > Em qua., 21 de jul. de 2021 às 03:39, Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> escreveu: > >> Hi, >> >> should I create CEP first or people just absolutely do not care to >> even drop an email and it does not make sense to them? >> >> Regards >> >> On Mon, 19 Jul 2021 at 15:32, Stefan Miklosovic >> <stefan.mikloso...@instaclustr.com> wrote: >>> >>> Hi, >>> >>> I wonder if people would be interested in having diagnostic events in >>> virtual tables? >>> >>> I put something together here (heavy wip) (1) but that is the idea I >> have. >>> >>> I know that Stefan Podkowinski did a spectacular job under >>> CASSANDRA-12944 and the possibility to persist locally was elaborated >>> on in (2) where the conclusion was made that maybe it is more suitable >>> to put it into chronicle queues via BinLog path and so on. >>> >>> The benefits of bin log is that we have events persisted and they can >>> be inspected further when node is offline. >>> >>> While data in virtual tables cease to exist after nodes are down, one >>> nice benefit of having it in virtual tables is that we can query it >>> comfortably via CQL and I think that this solution is more suitable to >>> have on an every day basis from operator's point of view. There is >>> still a way to dump it somewhere else anyway if one is really >>> interested in doing so. >>> >>> Do you think that the bin log solution is overall superior to the >>> virtual tables approach and we should just forget about having it in >>> virtual tables? >>> >>> If that is the case, what I would like to see is to have some >>> pluggability here so I might implement this on my own and configure a >>> node to put it to virtual tables for me, it does not necessarily have >>> to be the part of Cassandra code base if we are strongly against that. >>> >>> (1) >> https://github.com/instaclustr/cassandra/commit/0dd60dc0a847619fdb704b700154e624b21a0c35 >>> (2) https://issues.apache.org/jira/browse/CASSANDRA-13460 >>> >>> Regards >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
