Skip to content
BleemeoBleemeo

Cassandra

Auto-Detection
Built-in Metrics

Bleemeo monitors Cassandra through automatic service detection and JMX metrics collection for cluster performance.

Glouton automatically detects Cassandra instances running on the system.

To enable metrics gathering, the Bleemeo agent must be installed with JMX enabled. See Java JMX Metrics for setup details.

Cassandra must also expose JMX over a TCP port:

  • Docker: Add environment variable JVM_OPTS=-Dcassandra.jmx.remote.port=7199.
  • Native package: No additional configuration is needed. Cassandra exposes JMX on port 7199 on localhost by default.
  • Other setups: Add -Dcom.sun.management.jmxremote.port=7199 -Dcom.sun.management.jmxremote.authenticate=false to the JVM options.

If auto-detected parameters are incorrect, you can override them manually.

Terminal window
sudo tee /etc/glouton/conf.d/99-cassandra.conf > /dev/null << 'EOF'
service:
# For a Cassandra running outside a container
- type: "cassandra"
address: "127.0.0.1"
port: 9042
jmx_port: 7199
jmx_username: "cassandra" # by default, no authentication is done
jmx_password: "cassandra"
# For an additional Cassandra running outside a container
- type: "cassandra"
instance: "NAME_ASSOCIATED_WITH_YOUR_ADDITIONAL_SERVICE"
address: "127.0.0.1"
port: 9043
jmx_port: 7200
jmx_username: "cassandra" # by default, no authentication is done
jmx_password: "cassandra"
# For a Cassandra running in a Docker container
- type: "cassandra"
instance: "CONTAINER_NAME"
address: "172.17.0.2"
port: 9042
jmx_port: 7199
jmx_username: "cassandra" # by default, no authentication is done
jmx_password: "cassandra"
EOF

Glouton automatically detects configuration changes.

MetricDescription
service_statusStatus of Cassandra
cassandra_bloom_filter_false_ratioBloom filter false positive ratio in percent
cassandra_jvm_gcNumber of garbage collections per second
cassandra_jvm_gc_utilizationGarbage collection utilization in percent
cassandra_jvm_heap_usedHeap memory used in bytes
cassandra_jvm_non_heap_usedNon-heap memory used in bytes
cassandra_read_requestsNumber of read requests per second
cassandra_read_timeAverage time of read requests in seconds
cassandra_sstableNumber of SSTables
cassandra_write_requestsNumber of write requests per second
cassandra_write_timeAverage time of write requests in seconds

Bleemeo supports detailed monitoring of specific Cassandra tables. To enable this, add detailed_items to your service configuration.

Terminal window
sudo tee /etc/glouton/conf.d/99-cassandra.conf > /dev/null << 'EOF'
service:
# For a Cassandra running outside a container
- type: "cassandra"
detailed_items:
- "keyspace1.table1"
- "keyspace2.table2"
# For a Cassandra running in a Docker container
- type: "cassandra"
instance: "CONTAINER_NAME"
detailed_items:
- "keyspace1.table1"
- "keyspace2.table2"
EOF

The following per-table metrics are gathered:

MetricDescription
cassandra_bloom_filter_false_ratioBloom filter false positive ratio in percent
cassandra_read_requestsNumber of read requests per second
cassandra_read_timeAverage time of read requests in seconds
cassandra_sstableNumber of SSTables
cassandra_write_requestsNumber of write requests per second
cassandra_write_timeAverage time of write requests in seconds

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The check only opens the TCP port — it sends no command — so it fails when the port is wrong (Connection refused), when a firewall drops the packets (connection timed out after 10 seconds), or when the configured address cannot be parsed (Invalid TCP address). A green check proves the port is open, and nothing more.

A passing check says nothing about the metrics: they are collected separately.

These metrics travel through JMX, which is a separate pipeline: Glouton writes /var/lib/jmxtrans/glouton-generated.json, jmxtrans connects to the JVM’s JMX port, and pushes the values back to Glouton. Every link has to be in place.

Check that the port is open and answers, from the machine where the agent runs. This only shows a JVM running on the host — for a containerized JVM, compare the address in discovery.txt with the ports the container itself listens on:

Terminal window
sudo ss -lntp | grep java
What you see Cause Fix
the bleemeo-agent-jmx package is missing jmxtrans is not installed sudo apt-get install bleemeo-agent-jmx (or yum) — see Java Monitoring with JMX
discovery.txt shows no JMX port for the service No JMX port Glouton reads it from the JVM command line — -Dcom.sun.management.jmxremote.port or -Dcassandra.jmx.remote.port. If neither is there, set jmx_port in the service configuration
connection refused by the JVM JMX authentication is enabled Set jmx_username and jmx_password
jmxtrans connects, then times out JMX answered with an RMI address jmxtrans cannot reach The JVM must advertise the address discovery.txt shows for the service, with -Djava.rmi.server.hostname
nothing at all, for a JVM in a container jmxtrans connects to the container address, not to a port published on the host Publishing the port does not help. The JMX and RMI ports have to answer on the container address, and -Djava.rmi.server.hostname has to be that address
the JVM has -Dcassandra.jmx.local.port=7199, which binds to loopback Cassandra uses its local-only JMX port Glouton auto-detects that option only when it reaches Cassandra on 127.0.0.1; otherwise switch Cassandra to -Dcassandra.jmx.remote.port

Glouton can only detect an option that actually reaches the JVM command line. Setting -Dcassandra.jmx.remote.port in SERVER_JVM_OPTS is not enough: it has to go in JVM_EXTRA_OPTS, which is a common reason for a Cassandra that stays without metrics while the option looks correctly set.

Per-table metrics are gathered only for the tables listed in detailed_items, each entry written as keyspace.table. Without them, only the cluster-wide values are collected — which is why a working JMX setup can still show fewer metrics than expected.