Does OpsCenter for Cassandra slow down Cassandra?

Question

I'm considering installing OpsCenter to monitor our 24 node Cassandra cluster that's running on RackSpace VMs. In the past I've heard that OpsCenter slowed down the cluster. I'm a little worried if OpsCenter will be using a lot of data over the wire to agents on the machines, or that the agents installed on each Cassandra node will use a lot of system resources. Has anyone else who uses OpsCenter experienced this? Are there reasons or situations where using OpsCenter is a bad idea?

Answer 1

Disclosure: I work on DataStax OpsCenter

OpsCenter is designed to have as little impact on the cluster as possible. We're very careful about not excessively using any resources. In particular, the agents are designed to almost never write to disk, use very little CPU and memory, and use the network minimally (agents only write to the local Cassandra node). Depending on usage, the main opscenterd daemon can use more memory, CPU, and network, so for that reason, we recommend that it run on a separate, dedicated node.

Over time, we've continuously lowered the impact that OpsCenter has on the cluster, so things that you've heard about it impacting the cluster might be a bit dated. However, since you asked if there are situations where using OpsCenter is a bad idea, I would say that you have to be careful when using it with a cluster that has many column families (perhaps 50+). The reason is that OpsCenter collects metrics for each column family (with the exception of CFs in the system and OpsCenter keyspaces) by default, and this can add up. There are a few ways to control this which are documented here: http://www.datastax.com/docs/opscenter/configure/data_collection#controlling-data-collection. In short, your options are to not collect metrics on some of the column families or to reduce the amount of time that metric data lives for.

Other than that, if you see anything resembling excessive resource consumption, please let us know so that we can make improvements accordingly.