Status

Current state: Under Discussion

Discussion thread: here

JIRA: TBD

Voting thread: TBD

Released: TBD

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).


Scope

The scope of this CEP is to design a robust system how diagnostic events shoud be visible in virtual tables.

Goals

The goal of this effort is to be able to see diagnostic events in virtual tables so they can be queried by CQL. This CEP should design a way how to achieve that. This proposal is not designed to solve how to plug in other implementations which would enable diagnostic events to be published / pushed customly anywhere.

This document should also serve as a register of all other diagnostic events Cassandra should emit. Currently (shortly after 4.0 is out), there are diagnostic events published but the community believes that there should be more of them.

This CEP meets its goals if the below is possible to do:


* cql select all/multiple types (all sorted chronologically)

* enabling/disabling types

* getting newly implemented types in cql queries (without having to write new vtable implementations)

* getting the raw diagnostic map data into sparse vtable columns

Approach

Firstly, we need to design a way how to render diagnostic events in virtual tables from diagnostic events framework and how to show them in vtables.

After that  we would need to gather all relevant sources of diagnostic events and implement them (if they are not implemented already, of course).

Related JIRA tickets

JIRA(s): 


Motivation

Diagnostic events are currently retrievable by JMX only. It would be more appropriate for less technically savvy users to just use CQL to see what diagnostic events were emitted, lowering the barrier for Cassandra users to see more into Cassandra state as well as raise the overall observability capabilities Cassandra offers.

Audience

Devops, devs

Proposed Changes

TBD

New or Changed Public Interfaces

TBD

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
    • this feature should be turned off by default and turned on either in cassandra.yaml or subsequently off / on by a nodetool subcomman
  • If we are changing behavior how will we phase out the older behavior?
    • We are not changing behaviour, we are adding new feature
  • If we need special migration tools, describe them here.
    • not applicable
  • When will we remove the existing behavior?
    • not applicable

Test Plan

The implementation should be tested by standard means of unit tests and/or distributed tests when necessary.