Schedule icon
Query icon
Return icon
Switch icon
Log icon
SlackIncomingWebhook icon

Monitor ScyllaDB Multi-DC Topology and Schema Version Parity

Periodically query ScyllaDB cluster topology and system tables to detect cross-DC schema version drift and dispatch alerts via Slack.

Categories
DataInfrastructure

A multi-datacenter ScyllaDB or Cassandra cluster stays consistent only as long as every node can gossip with its peers and agrees on the current schema. When a cross-region link drops, a node partitions, or a schema change does not propagate everywhere, queries routed to the wrong replica return dirty or stale data - often with no error, because the cluster itself keeps answering reads from whatever it still has local. This blueprint turns a quick system.peers check into a scheduled, alerting watchdog so that kind of silent drift gets caught instead of discovered by a customer.

How it works

  1. daily_replication_watchdog (io.kestra.plugin.core.trigger.Schedule) runs once a day. Shipped disabled so you can validate a manual run first.
  2. check_topology_peers (io.kestra.plugin.cassandra.standard.Query) opens a native CQL connection to one coordinator node and runs SELECT peer, data_center, schema_version, host_id, rpc_address FROM system.peers. allowFailure: true means a connection or auth failure does not abort the execution - it is instead treated as a signal by the next task.
  3. classify_outcome (io.kestra.plugin.core.debug.Return) reduces the result to HEALTHY when check_topology_peers produced a rows output at all, or DEGRADED when it did not (the query failed and was swallowed by allowFailure).
  4. route_outcome (io.kestra.plugin.core.flow.Switch) branches on that status: HEALTHY just logs, DEGRADED posts a Slack alert naming the coordinator and datacenter that could not be checked. Any other value falls through to a default log line.
  5. The errors block catches failures outside that handled path - a malformed statement, a plugin error - and alerts separately from the expected DEGRADED branch.

What you get

  • A standing, scheduled check of ScyllaDB cross-DC peer visibility using the cluster's own system.peers table.
  • A clear two-state classification (HEALTHY / DEGRADED) instead of a raw query dump someone has to interpret at 2am.
  • A Slack alert that names the exact coordinator and datacenter that failed the check, and a separate alert if the flow itself breaks.
  • A status output other flows or dashboards can poll without re-running the query.

Who it's for

  • Platform and SRE teams operating a multi-region ScyllaDB or Cassandra deployment who need an early signal before replication drift becomes a customer-visible inconsistency.
  • Teams migrating from a single-DC to a multi-DC topology who want a guardrail in place from day one.
  • Anyone who has debugged a "why did this region return old data" ticket and wished something had paged them first.

Why orchestrate this with Kestra

cqlsh or a cron'd shell script can run the same query, but neither can branch on the result, alert only on the unhealthy case, retry or isolate failures from the check logic, or leave an execution history you can audit after an incident. Kestra supplies the schedule, the pass/fail branching, a dedicated failure channel separate from the alerting path, and a queryable record of every run - and because it is a flow, the same check can later fan out to PagerDuty or feed a dashboard by adding one task.

Prerequisites

  • A reachable ScyllaDB (or Cassandra) node on its native CQL port, default 9042.
  • For a genuine multi-DC test, at least two nodes in different datacenters joined via GossipingPropertyFileSnitch and matching cassandra-rackdc.properties dc=/rack= values - a single node will return an empty (not failing) system.peers result, which this check reports as HEALTHY since it is still a successful query. Treat a single-node dev cluster as a wiring test for this flow, not a validation of its alerting logic.
  • Quick local single-node smoke test: docker run --name scylla -d scylladb/scylla --smp 1 (add -p 9042:9042 to reach it from the Docker host, or put it on the same Docker network as the Kestra Worker and use the container name as scylla_host).
  • A Slack incoming webhook for alerts.

Secrets

  • SCYLLA_PASSWORD: native CQL password for the user named in scylla_username.
  • SLACK_WEBHOOK_URL: Slack incoming webhook used by both the DEGRADED branch and the errors block.

Inputs

  • scylla_host (STRING, default scylla): coordinator contact point hostname.
  • scylla_port (INT, default 9042): native CQL port.
  • local_dc (STRING, default datacenter1): local datacenter name for the driver's load-balancing policy.
  • scylla_username (STRING, default scylla): CQL username, paired with SCYLLA_PASSWORD.
  • max_schema_mismatches (SELECT: 0, 1, 5; default 0): reserved tolerance for a future schema-version comparison; not yet wired into classify_outcome.

Quick start

  1. Start or point at a ScyllaDB cluster and add the SCYLLA_PASSWORD and SLACK_WEBHOOK_URL secrets.
  2. Set scylla_host and local_dc to your coordinator node and its datacenter.
  3. Run the flow manually once and confirm status reads HEALTHY against a reachable node.
  4. Enable daily_replication_watchdog once the manual run is verified.

How to extend

  • Wire max_schema_mismatches into classify_outcome by comparing the distinct schema_version values across outputs.check_topology_peers.rows instead of only checking that the query returned.
  • Loop the check over every datacenter's coordinator with a ForEach, so one down datacenter does not depend on which node happens to be queried.
  • Replace the system.peers reachability check with nodetool status output (via a shell task) if you need actual per-node UP/DOWN state, since CQL system tables do not expose node liveness directly.
  • Route the DEGRADED branch to PagerDuty or an incident tool alongside Slack by adding a second notification task.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.