Phase 1: Monitor DSE & Baseline Before Migration
Before migrating anything, install monitoring on the existing DSE cluster and record baseline metrics. Establishing what "normal" looks like before data movement begins provides something concrete to compare the target cluster against during validation. Monitoring also provides a safety net: continuous visibility throughout the migration makes problems detectable the moment they appear rather than after cutover.
This phase changes no Cassandra data; it adds observability alongside the running cluster.
Why monitoring comes before data migration
Section titled “Why monitoring comes before data migration”OpsCenter supports DSE only and stops working the moment a DSE node is replaced by an open-source Cassandra node. If OpsCenter is the only operational tooling, visibility is lost at exactly the point in the migration where it is most needed. Installing a monitoring solution that supports both DSE and open-source Cassandra up front means one monitoring platform covers the source cluster, the target cluster, and the mixed state in between.
How AxonOps helps
AxonOps monitors DSE and open-source Cassandra simultaneously, so it can run across both sides of the migration and remain in place as the permanent replacement for OpsCenter afterwards. The steps below describe installing it on the DSE cluster; adapt them to whichever monitoring solution is adopted.
- Install the monitoring agent on each DSE node.
- Configure the agent to connect to the monitoring backend (SaaS or self-hosted).
- Configure Cassandra to load the metrics-collection agent.
- Perform a rolling restart of Cassandra, then restart the agent services. Restart one node at a time and confirm the node has rejoined and stabilised before proceeding to the next.
- Verify that all nodes appear in the dashboard with metrics flowing.
- Capture baseline metrics over a representative period (ideally covering both peak and quiet traffic).
Roll restarts one node at a time
Any rolling restart of a production cluster must proceed node by node. After
each node restart, confirm the node has returned to UN (Up/Normal) in
nodetool status and that metrics are flowing before proceeding to the next
node. If a node does not rejoin or fails to reach UN, halt the rolling restart
and investigate before restarting any further node. Nodes must not be restarted
concurrently; doing so risks losing quorum for some token ranges.
Baseline metrics to capture
Section titled “Baseline metrics to capture”Record at least the following, per node where applicable, as the pre-migration baseline:
| Metric | Notes |
|---|---|
| Read latency (p50, p99) | Per table for the busiest tables |
| Write latency (p50, p99) | Per table for the busiest tables |
| Throughput (ops/sec) | Reads and writes |
| Disk usage per node | GB used, and headroom |
| CPU usage per node | Sustained and peak |
| Heap usage per node | And GC behaviour |
| GC pause times | p99 pause duration |
| Pending compactions | Sustained backlog, if any |
| Dropped mutations | Should be at or near zero |
| Read/write timeouts | Should be at or near zero |
Keep the baseline
Store these numbers somewhere durable. In Phase 4: Validation, the target Cassandra cluster is compared against them to confirm it performs at least as well as DSE did. A migration that completes but regresses p99 latency is not a successful migration.
Go / No-Go
Section titled “Go / No-Go”Go: all DSE nodes are visible in the monitoring dashboard with metrics flowing, and baseline metrics are documented.
Rollback: uninstall the monitoring agents. There is no impact to the DSE cluster, because the agents are additive.