question

@vkayanala_42513 Querying the system.local table is a good way to do an end-to-end check on the availability of a node:

• confirms that the services are operational
• node is listening for requests from clients
• confirms reads are working for a specific node because the table is local to each node

It is also very performant because there is only ever 1 partition in the table (partition key local). And for what it's worth, one of its authors @alexandre.dutra is one of the leading engineers for drivers and tools here at DataStax.

If the check is slow, it might indicate a problem with read latency on the node (it's busy serving lots of requests) or the network between your app servers(s) and the cluster is slow so check for those. Cheers!

Hi, querying system.local is usually very fast, but indeed we cannot guarantee that such a query will always be fast.

While Erick is right when he says that this is a good way to check the availability of one node, this is definitely NOT the right thing to do to check the availability of the cluster as a whole.

As a matter fo fact, we are right now rethinking Spring Boot's health check mechanism, see JAVA-2472. The idea is to replace that check by a token ring inspection. This would give us a much more accurate picture of the cluster health, and has the advantage of not requiring executing any query.

This enhanced health check should be released soon.

In the meanwhile:

there's no way to tell Spring via configuration to not include it

Actually there is: add this line to your application.properties:

management.health.cassandra.enabled=false