“Wow, that’s so cool” exclaimed Ben after seeing the demonstration of the Cassandra agent. Ben worked as a database administrator. Recently, Ben’s company, which was growing rapidly, switched to the Cassandra database that could handle large amount of data.
When his organization started using the Cassandra database, Ben was concerned about how he would monitor its health. To ease his worries, he needed a software application that would alert him in case of any issues with the Cassandra database and also monitor its health.
One day, Ben accidentally read about the new Cassandra agent that IBMÂ® has included in its Application Performance Management offering. He was thrilled after he saw the demonstration of the Cassandra agent. This agent was just what he needed! He immediately rushed to talk to his management about it.
Do you want to know why Ben was excited?
The Cassandra agent helps database administrators like Ben to detect issues in the Cassandra database early on and prevent them. The agent monitors the availability, resource usage, and performance of the Cassandra database locally and remotely.
The agent collects the following information about the Cassandra database:
- Cluster details
- Node Details: keyspace, heap memory, thread pool, commitLog, pending compaction tasks, key cache, and row cache
- Keyspace Details: read latency, write latency, pending flush operations, and pending compaction operations
- Column Family Details: read latency, write latency, pending compaction operations, and pending flush operations
Administrators can view historical trends that are related to read latency, write latency, number of pending compaction operations, and number of pending flush operations of the column family and keyspace. Administrators can also view information, which the agent collects, in the various agent dashboards in the form of charts and tables. From the top-most level dashboard, which shows the consolidated status of Cassandra database resources, administrators can drill down to the overview and detail pages to identify the root cause of issues that occur in the Cassandra database.
For example, on the component page you can see that the Keyspace read latency (ms) is in critical state. You can click anywhere on the group widget to get more details.
On the Cluster Details dashboard, to further find out details about the critical status of keyspace read latency of a node, click the IP address.
The Node Details dashboard shows that for the system keyspace, read latency has exceeded its limits.
The agent also alerts administrators in case the values for the Cassandra database parameters exceed the threshold. Administrators can then take necessary corrective actions to bring the Cassandra database back to the normal working condition.
Ben is excited and looks forward to using the monitoring capabilities of the Cassandra agent. Would you like to join Ben and feel the excitement too? To know more about this agent, visit IBM Cloud Application Performance Management Knowledge Center.