Generate a Mission Control support bundle

You can generate a Mission Control support bundle to assist with troubleshooting issues. The system automatically redacts sensitive information from your support bundle, such as passwords and tokens using built-in redactors. After you generate a support bundle, you can share it with IBM Support for troubleshooting assistance.

Use the CLI to create a support bundle

  1. Make sure kubectl is installed and configured with access to your cluster.

  2. Install the support-bundle kubectl plugin using one of the following methods:

    • Download the binary directly from the troubleshoot.sh releases.

    • Use Homebrew:

      brew tap replicatedhq/replicated
brew install support-bundle

  3. Create a support bundle:

    Online clusters

    If your server has internet access, run the following command to create a support bundle that is saved to your local machine:

    kubectl support-bundle LOCATION/kots-support-bundle-spec.yaml

    Replace LOCATION with the path to the kots-support-bundle-spec.yaml file.

    Airgapped clusters

    If your server doesn’t have direct internet access, do the following:

    1. Download the default kots.io support bundle specification.

    2. Upload the kots-support-bundle-spec.yaml file to the air-gapped server.

    3. Use the uploaded spec file to create a support bundle that is saved to your local machine:

      kubectl support-bundle LOCATION/kots-support-bundle-spec.yaml

      Replace LOCATION with the path to the kots-support-bundle-spec.yaml file.

  4. Find the generated support bundle, and then move it to a secure location.

    The support bundle is saved it your local machine in the current directory with a timestamped filename in the format support-bundle-YYYY-MM-DDThh_mm_ss.tar.gz.

    mv support-bundle-TIMESTAMP.tar.gz TARGET_LOCATION

  5. Share the generated support bundle with IBM Support for assistance.

Use the diagnostic collector

Use the open source diagnostic collector for Apache Cassandra® to collect diagnostic information from your Mission Control environment.

The diagnostic collector collects diagnostic support bundles from each node in your Mission Control cluster.

For complete diagnostic collector documentation, see the DataStax GitHub repository. For troubleshooting information, see Troubleshooting.

  1. Prepare the dependencies:

    • A running Mission Control cluster with healthy pods

    • make

    • kubectl configured with access to your cluster

    • Permission to access pods in the target namespace

  2. Download the latest collector release.

  3. Set your cluster details:

    export CLUSTER_NAME="CLUSTER_NAME"

    Replace CLUSTER_NAME with the Mission Control cluster name.

  4. Navigate to the extracted collector directory:

    cd ds-collector

  5. Find the correct pod name and namespace:

    Find all pods
    kubectl get pods -A | grep -i cassandra
    Search in a specific namespace
    kubectl get pods -n POD_NAMESPACE | grep -i cassandra

    Replace POD_NAMESPACE with the namespace where your pod runs.

  6. Verify that the pod exists and get its full details:

    kubectl get pod POD_NAME -n POD_NAMESPACE -o wide

    Replace the following:

    • POD_NAME: The name of the pod

    • POD_NAMESPACE: The namespace of the pod

      Look for a pod with a`Running` status, and note both the pod name and namespace.

      The pod must be in Running status for the diagnostic collector to work properly. If the pod shows Init:ImagePullBackOff or other error states, resolve the pod issues before proceeding.

  7. Configure the collector for Kubernetes mode:

    1. Create a working configuration file from the collector.conf.in template:

      cp collector.conf.in collector.conf

    2. Modify the copied template in collector.conf for your environment.

    3. Enable Kubernetes mode:

      sed -i.bak 's/#use_k8s="true"/use_k8s="true"/' collector.conf

    4. Update the namespace, replacing POD_NAMESPACE with the actual namespace where your pod runs.

      The k8s_namespace setting in collector.conf must match the actual namespace where your pod runs.

      		 
      sed -i.bak 's/#k8s_namespace="default"/k8s_namespace="POD_NAMESPACE"/' collector.conf

    5. Enable sudo:

      sed -i.bak 's/#skipSudo="true"/skipSudo="true"/' collector.conf

  8. Verify the configuration:

    ./ds-collector -T -f collector.conf -n POD_NAME

  9. Generate the support bundle

    ./ds-collector -X -f collector.conf -n POD_NAME

    The collector does the following to generate the support bundle:

    • Connects to your Mission Control cluster using kubectl.

    • Collects diagnostic information from all nodes in the cluster.

    • Generates a support bundle in the current directory or the configured base directory. The default is /tmp/datastax.

    • Names the bundle with a timestamp and your cluster name.

  10. Verify that the support bundle was created by checking the output directory (default /tmp/datastax):

    result of datastax_collector from POD_NAME
processing artifact ARTIFACT_NAME.tar.gz

    The collector names the artifacts with timestamps and cluster information, following the pattern artifacts.tar.gz.

  11. Share the generated support bundle with IBM Support for assistance.

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use |  Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM