You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefan Podkowinski (JIRA)" <ji...@apache.org> on 2018/05/25 11:32:00 UTC

[jira] [Commented] (CASSANDRA-13460) Diag. Events: Add local persistency

    [ https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490583#comment-16490583 ] 

Stefan Podkowinski commented on CASSANDRA-13460:
------------------------------------------------

I've been trying several approaches to store events using chronicle queue (CQ) by now. Starting with CASSANDRA-14435 we now have a heap based buffer to make events available for later retrieval. I've updated the store's API to make it possible to switch to a CQ based implementation later. This would actually not be a big deal using the existing {{BinLog}}. But I'd still like to delay implementing this feature to a later point, mostly because of the marshaling aspect that it brings up. 

There are currently no limitations around classes extending {{DiagnosticEvent}}. We use to send a Map of Serializable values in CASSANDRA-14435, as returned by {{DiagnosticEvent.toMap()}}. But this isn't a solution to fully serialize/deserialize events. We first have to come up with an interface for that and decide which serialization API to use in general and which data types to allow. Also switching between in-memory and local disk based storage might be not ideal, as we should try to avoid serializing/deserializing instances for the in-memory store, which as a consequence needs some more careful API design.


> Diag. Events: Add local persistency
> -----------------------------------
>
>                 Key: CASSANDRA-13460
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Observability
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>            Priority: Major
>
> Some generated events will be rather less frequent but very useful for retroactive troubleshooting. E.g. all events related to bootstraping and gossip would probably be worth saving, as they might provide valuable insights and will consume very little resources in low quantities. Imaging if we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log of all relevant events-  provide a dump of all events as described in the [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst]. 
> This could be done by saving events white-listed in cassandra.yaml to a local table. Maybe using a TTL.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org