New to Kestra?
Use blueprints to kickstart your first workflows.
Periodically query ScyllaDB cluster topology and system tables to detect cross-DC schema version drift and dispatch alerts via Slack.
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.
daily_replication_watchdog (io.kestra.plugin.core.trigger.Schedule) runs once a day. Shipped disabled so you can validate a manual run first.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.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).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.errors block catches failures outside that handled path - a malformed statement, a plugin error - and alerts separately from the expected DEGRADED branch.system.peers table.HEALTHY / DEGRADED) instead of a raw query dump someone has to interpret at 2am.status output other flows or dashboards can poll without re-running the query.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.
9042.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.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).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.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.SCYLLA_PASSWORD and SLACK_WEBHOOK_URL secrets.scylla_host and local_dc to your coordinator node and its datacenter.status reads HEALTHY against a reachable node.daily_replication_watchdog once the manual run is verified.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.ForEach, so one down datacenter does not depend on which node happens to be queried.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.DEGRADED branch to PagerDuty or an incident tool alongside Slack by adding a second notification task.