Apache Cassandra

The Apache Cassandra integration collects request, task, and storage metrics that highlight the load on an instance. Optionally, the integration can also collect general JVM metrics related to memory and garbage collection. The integration also collects system, debug, and garbage-collection logs. These logs are parsed into a JSON payload, which includes fields for the message, Java class, and line number.

For more information about Cassandra, see the Apache Cassandra documentation .

Prerequisites

To collect Cassandra telemetry, you must install the Ops Agent :

For metrics, install version 2.6.0 or higher.
For logs, install version 2.5.0 or higher.

This integration supports Cassandra versions 3.11 and 4.0.

Configure your Cassandra instance

To expose a JMX endpoint, you must set the com.sun.management.jmxremote.port system property when starting the JVM. We also recommend setting the com.sun.management.jmxremote.rmi.port system property to the same port. To expose a JMX endpoint remotely, you must also set the java.rmi.server.hostname system property.

By default, these properties are set in a Cassandra deployment's cassandra-env.sh file.

To set system properties by using command-line arguments, prepend the property name with -D when starting the JVM. For example, to set com.sun.management.jmxremote.port to port 7199 , specify the following when starting the JVM:

-Dcom.sun.management.jmxremote.port=7199

Configure the Ops Agent for Cassandra

Following the guide to Configure the Ops Agent , add the required elements to collect telemetry from Cassandra instances, and restart the agent .

Example configuration

The following commands create the configuration to collect and ingest telemetry for Cassandra and restart the Ops Agent.

  # 
  
 Configures 
  
 Ops 
  
 Agent 
  
 to 
  
 collect 
  
 telemetry 
  
 from 
  
 the 
  
 app 
  
 and 
  
 restart 
  
 Ops 
  
 Agent 
 . 
 set 
  
 - 
 e 
 # 
  
 Create 
  
 a 
  
 back 
  
 up 
  
 of 
  
 the 
  
 existing 
  
 file 
  
 so 
  
 existing 
  
 configurations 
  
 are 
  
 not 
  
 lost 
 . 
 sudo 
  
 cp 
  
 / 
 etc 
 / 
 google 
 - 
 cloud 
 - 
 ops 
 - 
 agent 
 / 
 config 
 . 
 yaml 
  
 / 
 etc 
 / 
 google 
 - 
 cloud 
 - 
 ops 
 - 
 agent 
 / 
 config 
 . 
 yaml 
 . 
 bak 
 # 
  
 Configure 
  
 the 
  
 Ops 
  
 Agent 
 . 
 sudo 
  
 tee 
  
 / 
 etc 
 / 
 google 
 - 
 cloud 
 - 
 ops 
 - 
 agent 
 / 
 config 
 . 
 yaml 
 > 
 / 
 dev 
 / 
 null 
 << 
 EOF 
 metrics 
 : 
  
 receivers 
 : 
  
 cassandra 
 : 
  
 type 
 : 
  
 cassandra 
  
 endpoint 
 : 
  
 service 
 : 
 jmx 
 : 
 rmi 
 : 
 ///jndi/rmi://127.0.0.1:7199/jmxrmi 
  
 service 
 : 
  
 pipelines 
 : 
  
 cassandra 
 : 
  
 receivers 
 : 
  
 - 
  
 cassandra 
 logging 
 : 
  
 receivers 
 : 
  
 cassandra_system 
 : 
  
 type 
 : 
  
 cassandra_system 
  
 cassandra_debug 
 : 
  
 type 
 : 
  
 cassandra_debug 
  
 cassandra_gc 
 : 
  
 type 
 : 
  
 cassandra_gc 
  
 service 
 : 
  
 pipelines 
 : 
  
 cassandra 
 : 
  
 receivers 
 : 
  
 - 
  
 cassandra_system 
  
 - 
  
 cassandra_debug 
  
 - 
  
 cassandra_gc 
 EOF 
 sudo 
  
 service 
  
 google 
 - 
 cloud 
 - 
 ops 
 - 
 agent 
  
 restart 
 sleep 
  
 60

Configure logs collection

To ingest logs from Cassandra, you must create a receiver for the logs that Cassandra produces and then create a pipeline for the new receiver.

To configure a receiver for your cassandra_system logs, specify the following fields:

Field	Default	Description
`exclude_paths`		A list of filesystem path patterns to exclude from the set matched by `include_paths` .
`include_paths`	`[/var/log/cassandra/system*.log]`	A list of filesystem paths to read by tailing each file. A wild card ( `` ) can be used in the paths; for example, `/var/log/cassandra/system.log` .
`record_log_file_path`	`false`	If set to `true` , then the path to the specific file from which the log record was obtained appears in the output log entry as the value of the `agent.googleapis.com/log_file_path` label. When using a wildcard, only the path of the file from which the record was obtained is recorded.
`type`		This value must be `cassandra_system` .
`wildcard_refresh_interval`	`60s`	The interval at which wildcard file paths in `include_paths` are refreshed. Given as a time duration , for example `30s` or `2m` . This property might be useful under high logging throughputs where log files are rotated faster than the default interval.

To configure a receiver for your cassandra_debug logs, specify the following fields:

Field	Default	Description
`exclude_paths`		A list of filesystem path patterns to exclude from the set matched by `include_paths` .
`include_paths`	`[/var/log/cassandra/debug*.log]`	A list of filesystem paths to read by tailing each file. A wild card ( `` ) can be used in the paths; for example, `/var/log/cassandra/system.log` .
`record_log_file_path`	`false`	If set to `true` , then the path to the specific file from which the log record was obtained appears in the output log entry as the value of the `agent.googleapis.com/log_file_path` label. When using a wildcard, only the path of the file from which the record was obtained is recorded.
`type`		This value must be `cassandra_debug` .
`wildcard_refresh_interval`	`60s`	The interval at which wildcard file paths in `include_paths` are refreshed. Given as a time duration , for example `30s` or `2m` . This property might be useful under high logging throughputs where log files are rotated faster than the default interval.

To configure a receiver for your cassandra_gc logs, specify the following fields:

Field	Default	Description
`exclude_paths`		A list of filesystem path patterns to exclude from the set matched by `include_paths` .
`include_paths`	`[/var/log/cassandra/gc.log.*.current]`	A list of filesystem paths to read by tailing each file. A wild card ( `` ) can be used in the paths; for example, `/var/log/cassandra/system.log` .
`record_log_file_path`	`false`	If set to `true` , then the path to the specific file from which the log record was obtained appears in the output log entry as the value of the `agent.googleapis.com/log_file_path` label. When using a wildcard, only the path of the file from which the record was obtained is recorded.
`type`		This value must be `cassandra_gc` .
`wildcard_refresh_interval`	`60s`	The interval at which wildcard file paths in `include_paths` are refreshed. Given as a time duration , for example `30s` or `2m` . This property might be useful under high logging throughputs where log files are rotated faster than the default interval.

What is logged

The logName is derived from the receiver IDs specified in the configuration. Detailed fields inside the LogEntry are as follows.

The cassandra_system logs contain the following fields in the LogEntry :

Field	Type	Description
`jsonPayload.javaClass`	string	Java class where the log originated
`jsonPayload.level`	string	Log entry level
`jsonPayload.lineNumber`	string	Line number of the source file where the log originated
`jsonPayload.message`	string	Log message, including detailed stacktrace where provided
`jsonPayload.module`	string	Module of cassandra where the log originated
`severity`	string ( `LogSeverity` )	Log entry level (translated).

The cassandra_debug logs contain the following fields in the LogEntry :

Field	Type	Description
`jsonPayload.javaClass`	string	Java class where the log originated
`jsonPayload.level`	string	Log entry level
`jsonPayload.lineNumber`	string	Line number of the source file where the log originated
`jsonPayload.message`	string	Log message
`jsonPayload.module`	string	Module of cassandra where the log originated
`severity`	string ( `LogSeverity` )	Log entry level (translated).

The cassandra_gc logs contain the following fields in the LogEntry :

Field	Type	Description
`jsonPayload.level`	string	Level of the log entry
`jsonPayload.message`	string	Log message
`jsonPayload.pid`	string	Process ID of the Java process logging the message
`jsonPayload.tid`	string	Thread ID of the Java process logging the message
`jsonPayload.timeStopped`	string	Seconds the JVM was stopped for garbage collection
`jsonPayload.timeStopping`	string	Seconds the JVM took to stop threads before garbage collection
`jsonPayload.uptime`	string	Seconds the JVM has been active
`severity`	string ( `LogSeverity` )	Log entry level (translated).

Configure metrics collection

To ingest metrics from Cassandra, you must create a receiver for the metrics that Cassandra produces and then create a pipeline for the new receiver.

This receiver does not support the use of multiple instances in the configuration, for example, to monitor multiple endpoints. All such instances write to the same time series, and Cloud Monitoring has no way to distinguish among them.

To configure a receiver for your cassandra metrics, specify the following fields:

Field	Default	Description
`collect_jvm_metrics`	`true`	Configures the receiver to also collect the supported JVM metrics.
`collection_interval`	`60s`	A time duration value, such as `30s` or `5m` .
`endpoint`	`localhost:7199`	The JMX Service URL or host and port used to construct the service URL. This value must be in the form of `service:jmx:<protocol>:<sap>` or `host:port` . Values in `host:port` form are used to create a service URL of `service:jmx:rmi:///jndi/rmi://<host>:<port>/jmxrmi` .
`password`		The configured password if JMX is configured to require authentication.
`type`		This value must be `cassandra` .
`username`		The configured username if JMX is configured to require authentication.

What is monitored

The following table provides the list of metrics that the Ops Agent collects from the Cassandra instance.

Metric type

Kind, Type
Monitored resources

Labels

workload.googleapis.com/cassandra.client.request.count

CUMULATIVE , INT64
gce_instance

operation

workload.googleapis.com/cassandra.client.request.error.count

CUMULATIVE , INT64
gce_instance

operation
status

workload.googleapis.com/cassandra.client.request.range_slice.latency.50p