Time to Complete
Sometimes it is helpful to be able to see the exact CQL queries that client applications are sending to your cluster. This is true when you have poorly performing queries that you need to analyze and try to optimize. Or perhaps you have queries that are producing results that are not what you expected. Full Query Logging was designed to help in these cases.
Full Query Logging is also useful as a way of capturing live query traffic against a cluster so that you can replay it at a later time, perhaps in a development or test environment.
Full Query logging is disabled by default in Cassandra. There are two ways to configure full query logging: dynamically using nodetool or statically using cassandra.yaml.
A configuration using nodetool overrides a configuration defined in cassandra.yaml and does not persist across server restarts.
The following properties under the
full_query_logging_options section in the
cassandra.yaml file are used to configure full query logging:
HOURLY(the default), or
(CASSANDRA-15066) This feature simply puts bounds on the number of unsent or unprocessed messages that can be in the messaging queues. Without this, a node's memory usage can grow unbounded and run out of memory. In general, the defaults can be used as currently set. Advanced users have the option to tune these settings based on the specific environment.Next: Virtual Tables for Messaging Metrics
With the introduction of virtual tables in 4.0, it’s easy to get access to messaging metrics. Within the system_views keyspace, there are two new virtual tables named internode_inbound and inernode_outbound. The inbound table contains these metrics:
The outbound table contains these metrics:
Let’s try out some of these improvements.
Learn how to enable full query logging in Cassandra and how to read the logs with fqltool
Cassandra 4.x full query logging enables you to get the exact CQL query strings used by your client applications. This information can be used for:
In this scenario you will: