Debezium

Debezium is the standard open-source change-data-capture platform: connectors that tail a database’s transaction log and stream every row change into Kafka. When CDC breaks, it breaks quietly — the connector loses its database connection or falls behind the log, and downstream consumers simply see no changes, which looks exactly like no activity. This system type exists to make that silence loud.

Key: debezium · applied automatically to services emitting debezium-prefixed metrics.

Getting the telemetry

Debezium exposes its metrics over JMX on the Kafka Connect worker. Two routes into the Collector:

• the Collector’s jmx receiver, or
• the Prometheus jmx_exporter java agent on the Connect worker with Debezium’s documented exporter config, scraped by the prometheus receiver — the more common setup:

otel-collector-config.yaml (receivers)

receivers:
  prometheus/debezium:
    config:
      scrape_configs:
        - job_name: debezium
          scrape_interval: 30s
          static_configs:
            - targets: ["kafka-connect:9404"]   # jmx_exporter agent port

Wire it into a metrics pipeline with a resource processor setting a service.name, per Monitoring with the OpenTelemetry Collector.

What Sluicio detects

Metrics whose names start with debezium — the shape jmx_exporter produces from Debezium’s MBeans (debezium.metrics<...> attributes like Connected, MilliSecondsBehindSource, QueueRemainingCapacity).

Starter checks

Check	Condition	Severity	Why it matters
Connector disconnected	Connected < 1	Critical	The connector lost its database connection — change capture has stopped, and every downstream consumer is now silently stale.
Replication lag	MilliSecondsBehindSource > 60,000 ms	Warning	The connector is more than a minute behind the database’s log — downstream data is stale and the gap is growing.
Queue nearly full	QueueRemainingCapacity < 100	Warning	Debezium’s internal change-event queue is almost full — Kafka can’t absorb events as fast as the log produces them; lag comes next.

Verify the exported names

JMX-to-metrics naming is the least standardized link in this chain: the exact exported names depend on your jmx_exporter rules (or jmx receiver config), connector type and Debezium version. After applying the type, confirm each check’s metric name against what actually arrives in Sluicio’s metric catalog and adjust the rules on the service — the attribute names above (Connected, MilliSecondsBehindSource, QueueRemainingCapacity) are the stable part to grep for.

Tuning notes

• Disconnected is the page-worthy one. Keep it Critical and give it only a short duration (a connector bounce during a database failover is normal) — but not so long that an evening’s worth of changes goes uncaptured before anyone looks.
• Lag threshold depends on what consumes the stream: 60 s is tight for analytics replication and lax for cache invalidation. Also expect a large legitimate spike during snapshots — scope the check or pause it when re-snapshotting a table.
• Queue capacity compares against Debezium’s max.queue.size (default 8,192): the default check fires when ~99% full. If you’ve raised the queue size, raise the check’s floor proportionally.
• These metrics are per connector task — if you run many connectors on one worker, split the checks by the connector-name attribute so one lagging connector doesn’t hide behind a healthy fleet.