This documentation corresponds to an earlier product version. Make sure this document corresponds to your version.

Latest OpsCenter documentation | Earlier OpsCenter documentation


This section lists some common problems experienced with OpsCenter and solutions or workarounds.

Internet Explorer web browser not supported

If you try to load the OpsCenter client in Microsoft Internet Explorer, a dialog displays informing you that it is not supported.

OpsCenter is only supported on the latest versions of:
  • Apple Safari
  • Google Chrome
  • Mozilla Firefox

The SSTables in this snapshot '<tag>' are not compatible

If you receive an error message that includes "The SSTables in this snapshot '<tag>' are not compatible with the current version of Cassandra", it means you must upgrade your snapshot to the current major version of Cassandra or DSE.

How to
  1. Log in to each node.
  2. Run the sstableupgrade script for every keyspace and column family you wish to restore, passing it the keyspace, column family, and OpsCenter snapshot tag that you got from the error message.

    How you run the script depends on how you installed Cassandra or DSE.

  3. Retry the restore from OpsCenter.

OpsCenter data growing too large

A bug, which has been fixed in 3.2.1, was not setting a TTL on metrics data being collected for a managed cluster. Depending on your enviornment, this could cause some column families in the OpsCenter keyspace to grow too large. The most common offenders will be the pdps (raw data points) and rollups60 (1m data points) column families.

If any of the column families have grown too large, you can truncate them to reclaim the space. If you are not comfortable losing historical data for that granularity (for example, 1m), please contact DataStax support.

Cannot create a keyspace

Due to a Python 2.6 or earlier bug, some users experience a problem adding a keyspace using Data Modeling OpsCenter features. OpsCenter cannot save a newly created keyspace.

Upgrading Python generally fixes this problem.


Occurs when OpenSSL 1.0.0 is installed on RHEL 5.x, CentOS 5.x, OEL 5.5, Debian, or Ubuntu systems:


To fix, you can do either of the following:

  • nstall OpenSSL 0.9.8:
    1. RHEL-based systems: sudo yum install openssl098
    2. Debian-based systems: sudo apt-get install libssl0.9.8
  • Install Python libssl 1.x:
    1. Remove all OpenSSL modules from the OpsCenter installation lib directory. You do not have to remove them globally.

      Packaged installs: /usr/share/opscenter/content/lib

      Binary installs: <install_location>/lib

      You can easily find these directories using:

      find . -name OpenSSL -type d | xargs rm -rf
    2. Install the latest pyOpenSSL module:

      Debian-based systems: apt-get install python-openssl

      RHEL-based systems: yum install python-openssl

    3. Start or restart opscenterd.

Python used to run OpsCenter not built with SSL

In order to protect your AWS credentials when launching EC2 instances, OpsCenter needs to use HTTPS, but if the version of Python that is running opscenterd was not compiled with SSL support OpsCenter will not run even if SSL has been disabled in the configuration file.

To resolve the issue, first ensure that OpenSSL 0.9.8 is installed on your system. If you have compiled Python manually, it is recommended that you install Python 2.6+ through your package manager. On CentOS and RedHat Enterprise Linux, this is most easily done through EPEL packages.

If you must compile Python manually, make sure that SSL support is enabled. This blog post explains the process for Python 2.5, but the same steps will work for Python 2.6 or 2.7.

OpsCenter agent port setting conflict

If you have a problem with OpsCenter, check for conflicts in port settings. The OpsCenter Agent uses port 7199 by default. If you have not changed the default port, check that Cassandra or another process on the node, is not set up to use this port.

If you set the OpsCenter Agent port to a host name instead of an IP address, the DNS provider must be online to resolve the host name. If the DNS provider is not online, intermittent problems should be expected.

Limiting the metrics collected by OpsCenter

If you have many column families, the number of metrics OpsCenter collects can become quite large. For information about how to reduce the number keyspaces or column families that are monitored, see Controlling data collection.

Java not installed or JAVA_HOME environment variable not set

If Java is not installed or if OpsCenter cannot find JAVA_HOME, you may see an error such as:

/usr/share/opscenter-agent/bin/opscenter-agent: line 98:exec: -X: invalid option
 exec: usage:  exec [-cl ] [-a name ] [ command [arguments ... ]] [redirection ... ]

To correct this problem, install Java or set JAVA_HOME:export JAVA_HOME =<path_to_java>

Insufficient user resource limits errors

Insufficient resource limits may result in an insufficient nofiles error:

2012-08-13 11:22:51-0400 [] INFO: Could not accept new connection  (EMFILE )

See Recommended settings under Insufficient user resource limits errors in the Cassandra documentation.

Problems with provisioning

General troubleshooting steps

Ensure firewalls are properly opened between the opscenterd machine and each node.

Check the following files (on any of the nodes having problems) for any errors:
  • /var/log/cassandra/system.log
  • /var/log/opscenter-agent/agent.log

Verify that Cassandra (or DSE) was not previously installed on any of the machines; if it was, all binaries, configuration files, logs, etc. must be cleared out first.

Invalid repository credentials

Invalid repository credentials


When installing DSE, if you enter invalid values for DataStax Credentials, an error dialog displays text along the lines of:

Installation stage failed: Installation failed on node 'apt-get update' failed.

Clicking Details displays the entire output from both stdout and stderr. If, in this output, you see the "401 Unauthorized", it means that the credentials entered were invalid.


When installing DSE, if you enter invalid values for DataStax Credentials, an error dialog displays text along the lines of:

Installation failed on node 'yum install' failed.

Clicking Details displays the entire output from both stdout and stderr. If, in this output, you see "The requested URL returned error: 401", it means that the credentials used were invalid.

Timed out waiting for Cassandra to start

If you receive this error, it most likely means that the Cassandra process failed to start on one or more nodes. You should look in /var/log/cassandra/system.log for any errors that may need to be resolved.

The following packages are already installed

If you receive an error that starts with this message, it means Cassandra (or DSE) is already installed on the system. OpsCenter provisioning requires that any instances of Cassandra (or DSE) be completely removed or purged before provisioning a new cluster.

Agents cannot connect to opscenterd

If you receive an error message that includes "The installed agent doesn't seem to be responding", there is most likely a firewall issue preventing the installed agent from connecting to the opscenterd machine. You should ensure that port 61620 is open on the opscenterd machine and check the agent logs.

Removing all Cassandra or DSE files after failed provisioning

If you provision a new cluster or add a node to an existing cluster via the OpsCenter UI and an error occurs, you can retry the request, but before you retry you must remove all traces of Cassandra or DSE packages from the nodes in the cluster. You can also remove simply remove the files if you do not wish to retry the provisioning.