As a Standard Stack user, you can make sure that Acrolinx works correctly through continuous monitoring and error detection. If you notice issues with your Acrolinx Kubernetes deployment or in the application functionality, you can provide several types of files to Acrolinx Support to help troubleshoot issues with the Acrolinx Platform. There are two ways to generate them:
Generate a support package via the Dashboard.
Run the support package script.
Users need a role with the appropriate privilege Download support package to use this feature.
Compile all of the necessary files into one package that you can download and send to Acrolinx Support via the Dashboard. To generate this, open the Dashboard and go to Maintenance > Support Package.
You can run this script to help Acrolinx provide support and resolve issues. This simple executable shell script collects information about your Kubernetes cluster at the time of execution.
The support package script has various
kubectl command procedures. Acrolinx uses these to gather info about the current Kubernetes resources and read logs from running pods. When you run the script, it shouldn’t affect your Acrolinx instance or cause downtime. Let Acrolinx Support if you run into any problems when you use the script.
Download the support package script here or with the following:
curl https://acrolinx.github.io/helm/resources/core-platform/tools/support-package.sh > support-package.sh
Be sure to run the support package script frequently. That way, you can capture relevant logs and events when something goes wrong with your deployment.
To run the script, do the following:
Run the following command so you can execute
chmod +x support-package.sh
Assuming you have a Standard Stack installation in the
acrolinx-systemnamespaces, execute the script to collect evidence:
$ ./support-package.sh -n acrolinx -s acrolinx-system
When you run the script, it creates an archive of the collected data from your Kubernetes cluster. This includes details about the existing resources (
ConfigMaps, ... ) related to the Acrolinx deployment. You can find this archive in the script execution directory to check the collected output.
The script doesn't collect any
The support package archive's naming format is
support-package-<timestamp_ISO_8601> with extension
Find the generated support package archive:
ls -la // Output drwx------. 6 ec2-user ec2-user 4096 Mar 19 08:31 . drwxr-xr-x. 4 root root 38 Mar 16 08:58 .. -rw-rw-r-- 1 ec2-user ec2-user 124818 Mar 19 12:33 support-package-20210319T123333Z.tar.bz2 -rwxrwxr-x 1 ec2-user ec2-user 5102 Mar 19 11:34 support-package.sh
In this example output, you’ll see the following:
By default, the collected data and
kubectl outputs are written into a directory and archived. When the script exists, it deletes this temporary directory. Use the
-Z flag to instruct the script not to create an archive and leave the created directory on the host after the execution finishes. See more about run modifiers in the
Run Options section.
support-package.shfile is executable.
The first column shows the permission on a file or directory. (
xmeans execute permission)
This includes the data and logs collected by the script.
You can use the supported run modifier options to configure the script execution do the following:
get information from specific namespaces (in case your Acrolinx deployment is in a namespace other than
continue without archiving the collected details
-h flag to print help:
You should see the output in your console:
Usage: ./support-package.sh [options] Options: -h Print this help message and exit. -o <directory> Output directory (defaults to '.') -n <namespace> Acrolinx namespace (defaults to current namespace: default) -s <namespace> Operator installation namespace (defaults to acrolinx-system) -v Verbose -Z Don’t create an archive, and don’t delete the support archive directory.