Cassandra's monitoring revolves around continuously monitoring a wide range of Cassandra performance metrics. These metrics measure different elements of the database and can help reveal issues that could impact overall performance and slowdowns. By monitoring Cassandra's performance, you can identify slowdowns, hiccups, or pressing resource limitations—and take swift action to correct them. There are the following types of monitoring available:

JMX-Based Monitoring: Java Management Extensions (JMX) is a specification for monitoring and managing Java applications. It enables a generic management system to monitor your application; raise notifications when the application needs attention, and change the state of your application to remedy problems. You have the following metric groups in JMX Based Monitors:

• Cassandra Compaction Stats
• Cassandra
• Cassandra Service
• Cassandra Request
• Cassandra Network
• Cassandra Internal
• Cassandra Database Cache
• Cassandra Database
• Cassandra Buffer Pool
• Cassandra CQL
• Cassandra Cache
• Cassandra Client
• Cassandra Client Request
• Cassandra Client Request Latency
• Cassandra Column Family
• Cassandra Connection
• Cassandra Inbound Connection
• Cassandra Index
• Cassandra Memtable Pool
• Mbean Cassandra Thread Pool V2
• Cassandra Read Repair
• Cassandra Node Stats
• Cassandra Threadpool Msg Stats
• Cassandra Thread Pool Stats V1

Note: You can see the monitor information for specific monitors by clicking on the Information icon provided alongside to the monitor type.

Platform Supported

• Ubuntu (Version:16,20)

Prerequisites

1. The machine agent (CMON) should be running on the target server i.e. the machine from where you want to get OS related data.

   To check the CMON status, execute the following command:  /etc/init.d/cmon status
   If CMON is running successfully, you will get an output like this: cmon is running with PID(<pid_number>)

2. Host and port of the machine are needed where the application is installed.
3. The JMX_RMI should be configured in the JMX Connection URL option.

Monitor Group Configuration

Configuration For Cassandra Deployment

To successfully configure Cassandra Monitor, you are required to fill in the following fields:

• Agent Type: We have two types of Agents: Machine agents and Application agents. Mainly Machine agent type is used. It is a mandatory field.
• Instance Name: The instance name is the node under which the monitors are shown in the metric tree. It is user-defined. It is a mandatory field.
• Connect Using Host/Port: The medium through which the application is connected. It is a mandatory field. In case the user selects Host/Port we have the following fields:
  • Host: In this field, you have to provide the Server IP or Server Name where the application is installed.
  • JMX Port: In this field, you have to provide the port on which the connection will be made along with the hostname/IP.
• Connect using Process ID: In this field, you have to provide the medium through which the application is connected. In case you select Process ID you have the following options:
  • Process ID: In this field, you have to provide the process id of the process.
  • Process ID File: In this field, you have to provide the filename for the process id.
  • Search Pattern (not applicable for Windows): In this field, you have to provide the pattern which is to be searched.

Advance Setting

You can also apply the following advanced settings which are optional:

• Username: In this field, you have to provide the username for the server by which user can access the monitor. It is an optional field.
• Password: In this field, you have to provide the password for the server by which you can access the monitor.
• JMX Connection URL: In this field, you have to provide the URL which you will use for the JMX connection. JMX_RMI remoting is used for monitoring.

SSL Configuration

• Trust Store Filepath: A trust store contains the signer certificates (also known as certificate authority certificates) that the endpoint trusts. Enter the Truststore file path in this field.
• Trust Store Password: The value of the trust store Password is the password required to access the contents of the trust store.
• Trust Store Type: The Truststore typerequires a truststore for use by the integration serve and must be a password-protected truststore in a JKS or PKCS12 format.
• Key Store Filepath: The path or location where the Keystore file is kept or stored.
• Key Store Password: The password of the Keystore file for protection.

Note: If you want to established two-way communication, then select “Enable Client Authentication” checkbox.

Common Configuration

All metrics in both monitors have the following common fields which are optional:

• Frequency: Each sample will come in a selected frequency in the graph. It can be 10 secs, 10 minutes, 1 hour, 4 hours, or 1 day.
• Other Arguments: It is for enabling debug mode or passing any extra argument JSON.

Monitor Group-Specific Configuration

The following monitor groups have additional configuration fields:

Cassandra Thread Pool Stats V1: Have an additional field of filter settings. Filter settings have two options:

• Positive Filter: It is used to show the data which is coming from the response on the dashboard.
• Negative Filter: It is used to hide (if we don’t want to show the data on the dashboard) the data which is coming from the response on the dashboard.

Deploy Monitors

Deploy the configured monitors using our machine agent. The following fields need to be filled in to deploy:

• Tier: Tier is used to select the tier on which the monitor(s) will be deployed. Select the required tier from the drop-down list.
• Server: You can select the server(s) of the selected tier on which the configured monitor(s) will get deployed.

Based on the requirement, you can select any one of the following:

• All: Deploy the configured monitors on all the servers of the selected tier.
• Any: Select any one of the servers where monitors will be deployed.
• Specified Server: Select one or multiple servers of the chosen tier on which the monitor(s) will be deployed. It means that with monitors whether we require all servers, any server, or a specified server.
• Exclude Server: In this field, you have to select one or more servers that you want to exclude.
• Exclude Tier: In this field, you have to select one or more tiers that you want to exclude.

Notes:

• If you want to add more tiers and servers, then you can click on the Add Agent Tier-Server
• Once you have selected all the fields, you have to click on the Add Add button to add the tier and server.
• On clicking the add button, the tier server will be added in the table.
• You can perform the following actions in the table which are listed below:
  1. Edit: In edit option, you can edit the configuration. To perform this operation, you have to click on the Edit Monitor Configuration Once you have edited the configuration, you have to click on the Update Update button to update the table. You can also click on the
     Cancel Cancel button if you don’t want to edit the window.
  2. Delete: In delete, you can delete the configuration. To perform this operation, you have to click on the Delete button
  3. Test Monitor:
     • In test monitor, you have to select tier, server, frequency, and duration from the dialog box and then click on the Test Monitor Once you click on the test button, the test will start and the Open Dashboard Open Dashboard button will be enabled and the monitor log will be displayed.
     • Once you click on the open dashboard button, a new dashboard will open in a separate tab where you can see the data.

Validation

Once the Cassandra monitors are configured, you can validate by either checking the monitor homepage where a section for Cassandra monitors along with details like total, running, and failed monitors is given, or check for the configured monitors from the metric tree, against the tier/server/instance for which this metric is configured.