21 Problem Analysis #

This section covers common problems and how to analyze them.

21.1 Trento Server #

There are two tools you can use to analyze issues with Trento Server in a Kubernetes scenario. These tools collect information and data that can be useful when troubleshooting and analyzing the issue.

21.1.1 Trento Support Plugin #

The Trento support plugin automates the collection of logs and relevant runtime information on the server side. Using the plugin requires a host with the following setup:

The packages jq and python3-yq are installed.
Helm is installed.
The command kubectl is installed and connected to the Kubernetes cluster where Trento Server is running.

To use the plugin, proceed as follows:

Download the Trento support plugin script:
```
# wget https://raw.githubusercontent.com/trento-project/support/refs/heads/main/trento-support.sh
```
Note: Package available in SUSE Linux Enterprise Server for SAP applications 15 SP3 and higher
Customers of SUSE Linux Enterprise Server for SAP applications 15 SP3 and higher can install the trento-supportconfig-plugin package directly from the official SLES for SAP 15 repos using Zypper. The Containers Module is required for installation.
Make the script executable:
```
# chmod +x trento-support.sh
```
Make sure that kubectl is connected to the Kubernetes cluster where Trento Server is running and execute the script:
```
# ./trento-support.sh --output file-tgz --collect all
```
Send the generated archive file to support for analysis.

The Trento support plugin accepts the following options:

-o, --output: Output type. Options: stdout|file|file-tgz
-c, --collect: Collection options: configuration|base|kubernetes|all
-r, --release-name: Release name to use for the chart installation. "trento-server" by default.
-n, --namespace: Kubernetes namespace used when installing the chart. "default" by default.
--help: Shows help messages

21.1.2 Scenario dump #

The scenario dump is a dump of the Trento database. It helps the Trento team to recreate the scenario to test it. Using the script that generates the dump requires a host with the following setup:

The command kubectl is installed and connected to the Kubernetes cluster where Trento Server is running.

To generate the dump, proceed as follows:

Download the latest version of the dump script:

> wget https://raw.githubusercontent.com/trento-project/web/main/hack/dump_scenario_from_k8.sh

Make the script executable:
```
> chmod +x dump_scenario_from_k8.sh
```
Make sure that kubectl is connected to the Kubernetes cluster where Trento Server is running and execute the script as follows:
```
> ./dump_scenario_from_k8.sh -n SCENARIO_NAME -p PATH
```
Go to /scenarios/, collect all the JSON files and send them to support for analysis.

21.1.3 Pods descriptions and logs #

In addition to the output of the Trento Support Plugin and the Dump Scenario script, the descriptions and logs of the Trento Server pods can be useful for analysis and troubleshooting purposes. These descriptions and logs can be easily retrieved with the kubectl command. For this to work, you need a host where kubectl is installed and connected to the Kubernetes cluster running Trento Server.

List the pods running in Kubernetes cluster and their statuses. Trento Server currently consists of the following six pods:

> kubectl get pods
trento-server-prometheus-server-*
trento-server-postgresql-0
trento-server-web-*
trento-server-wanda-*
trento-server-rabbitmq-0

Retrieve the description of a pod as follows:
```
> kubectl describe pod POD_NAME
```
Retrieve the log of a pod as follows:
```
> kubectl logs POD_NAME
```
Monitor the log of a pod as follows:
```
> kubectl logs POD_NAME --follow
```

21.2 Trento Agent #

The first source to analyze issues with the Trento Agent is the Trento Agent status. It can be retrieved as follows:

> sudo systemctl status trento-agent

If further analysis is required, activate debug log level for the agent. A detailed log can be then retrieved from the journal:

Add parameter log-level with value debug to the /etc/trento/agent.yaml configuration file.
```
> sudo vi /etc/trento/agent.yaml
```
Add the following entry:
```
log-level: debug
```
Restart the agent:
```
> sudo systemctl restart trento-agent
```
Retrieve the log from the journal:
```
> sudo journalctl -u trento-agent
```