Thank you both for the answers, really appreciate it. My concern is that there would be "too much data" in them and it might grow and grow as a node is live, however, that being said, I think there is currently a hardcap like 200 events per event type in the current implementation (1). Hence I see that it is somehow limited even for now which might be just fine. Nevertheless that limit might be at least configurable (at runtime).
Ideally, there should be some kind of way to persist them anywhere, not only to some in-memory structure so virtual tables and bin logs are clearly two candidates to do this. So when I extend this idea, it should be just pluggable or some kind of extension point should be there. I will give it a second thought how that might be generalised and I'll try to come up with CEP covering this. Thank you once again for the response. (1) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/diag/store/DiagnosticEventMemoryStore.java#L39 On Wed, 21 Jul 2021 at 18:22, Jeremiah D Jordan <jeremiah.jor...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
