Introduction

When people ask which JMX metric shows the status of a Kafka Connect connector, they often assume there is one perfect metric that says RUNNING, PAUSED, or FAILED. In practice, connector state is better observed through the Kafka Connect REST status endpoint, while JMX is more useful for supporting health, throughput, and failure signals.

Use the REST Status Endpoint for Actual Connector State

If your goal is to know whether a connector or one of its tasks is running, paused, failed, or unassigned, the clearest source is the status API.

curl http://connect-host:8083/connectors/my-source-connector/status

A typical response includes both connector-level and task-level state:

1{
2  "name": "my-source-connector",
3  "connector": {
4    "state": "RUNNING",
5    "worker_id": "connect-1:8083"
6  },
7  "tasks": [
8    {"id": 0, "state": "RUNNING", "worker_id": "connect-1:8083"}
9  ],
10  "type": "source"
11}

That is much more direct than trying to infer connector state indirectly from JMX counters.

What JMX Is Good At

JMX still matters in Kafka Connect monitoring. It is useful for worker metrics, task throughput, rebalance signals, and error-related indicators that help explain why a connector is unhealthy or degraded.

For example, JMX is a good place to track trends such as:

• task failures or dead-letter activity,
• source-record or sink-record throughput,
• batch sizes and processing latency,
• connector task counts on each worker.

These metrics help answer operational questions that the REST status endpoint does not cover well.

Combine State Checks with Metrics

A strong monitoring setup usually combines both interfaces:

1. Poll the REST endpoint for the actual connector and task states.
2. Use JMX metrics to observe volume, lag, failures, retries, and worker pressure.
3. Alert when the state changes or when metrics suggest a connector is degrading before it fully fails.

That model is better than looking for one magic JMX metric to do everything.

Example JMX Exposure Setup

To expose JMX from a Connect worker, you typically start it with JVM options similar to these:

export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=9999"

After that, a monitoring system such as JConsole, Prometheus JMX Exporter, or another collector can scrape worker metrics. The exact metric names you alert on will depend on the Connect version and your connector type, which is another reason state should come from the REST API first.

Monitor Tasks, Not Only the Connector Name

A connector can look healthy at a glance while one or more tasks are actually failing. That is why task-level visibility matters. Even when the connector object is present, the data pipeline can still be broken if a task is stuck, repeatedly failing, or never assigned.

Operationally, that means the best status view is usually:

• connector state from REST,
• task state from REST,
• error and throughput metrics from JMX,
• logs for root-cause details.

Common Pitfalls

• Searching for one JMX attribute that directly replaces the REST connector status API.
• Monitoring only connector existence and ignoring task-level state.
• Using throughput metrics as if they prove the connector is healthy.
• Forgetting that JMX metric names can vary by Connect version and connector implementation.
• Building alerts that only fire after total failure instead of watching degrading error and throughput signals.

Summary

• There is not one universally ideal JMX metric for connector RUNNING or FAILED state.
• Use the Kafka Connect REST status endpoint for actual connector and task status.
• Use JMX to monitor supporting health signals such as throughput, errors, and worker behavior.
• Task-level status matters as much as connector-level status.
• The most reliable monitoring setup combines REST state checks with JMX metrics and logs.