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 and the exisiting diagnostic solution shows just the most crucial events.
Approach
Firstly, we need to design a way how to persist 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.
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.