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 > >
