Skip to main content

Collect diagnostics

When you open a support ticket, a set of diagnostics collected at the time of the problem lets support start on the cause rather than asking for it. The commands below gather it into one directory and pack it into a single archive. They assume the shell variables from Install with Helm (RELEASE, NAMESPACE) and read-only access to the namespace.

Quick start​

  1. Download the script. Save collect-diagnostics.sh to the machine where kubectl and helm are set up for the cluster. It needs read access to the release's namespace.

  2. Run it while the problem is happening, or as soon after as you can, since logs rotate and events expire after about an hour.

    Collect diagnostics
    chmod +x collect-diagnostics.sh
    ./collect-diagnostics.sh

    The script finds the Datastrato Enterprise release by itself. With more than one release in the cluster, name it:

    Collect diagnostics for a named release
    RELEASE="$RELEASE" NAMESPACE="$NAMESPACE" ./collect-diagnostics.sh

    Each step prints ok or FAILED. A step that fails, such as reading the server log when the server pod is not running, leaves the error in its file, and the rest still run. The script ends by writing diagnostics-{release}-{timestamp}.tar.gz.

  3. Check the archive. Open values-redacted.yaml and confirm no credential is left in it. The script replaces the value of any setting whose name contains password, secret, token, credential or key, and of any environment variable whose name does. It leaves names of Secrets, classes, files and endpoints visible, since support needs them. A credential stored under any other name needs removing by hand.

  4. Attach it to the ticket, with the time the problem started, what you were doing, and any error shown in the UI or returned to an engine.

What is collected​

FileContents
helm-list.txt, helm-history.txtChart and application versions, and the release's upgrade history
values-redacted.yamlYour values file, with credentials replaced
images.txtThe image each container is running
versions.txtThe kubectl and helm versions, and the cluster's Kubernetes version
resources.txtDeployments, StatefulSets, pods, Services, volumes and ingresses
events.txtKubernetes events in the namespace: scheduling, pulls, restarts, probe failures
pods-describe.txtEach pod's state, container restarts and last termination reason
nodes.txtThe cluster's nodes
logs-*.txtEvery container's recent output, including init containers and the previous run of a restarted container
gravitino-server.logThe last 5,000 lines of the server log
health-ready.jsonThe readiness check, including the metadata database
metrics.jsonThe server's metrics

What not to send​

  • The audit log. It records who did what, which may itself be sensitive. Support asks for specific records if they are needed.
  • Your unredacted values file or license file. The license key is passed on the command line and is part of the release's values; the redaction removes it from the copy above.
  • Database dumps. They hold your metadata. Support asks for one only in exceptional cases.

The server log and container output name metalakes, catalogs and other objects, and the identity of users making requests. Review the archive before sending it if those names are confidential.

Last updated on