# How-to-automatically-collect-SLT-logs-for-troubleshooting_688988287
## Problem

When running into an SLT issue, customers may not be able to consistently reproduce it, and by the time it reoccurs, relevant information has been rolled back. Therefore, troubleshooting becomes difficult. These steps can be used to collect data and logs when the issue occurs.

## Solution

1\. Run the following command to enable the tenant setting:  
./set\_tenant\_settings.sh -T <TENANTID> -A enable -S ESS\_BACKUP\_FLAG8

2\. Create a temporary log path /tmp/slt in the NFS path.

3\. In backup\_log.sh, change the SOURCE\_FOLDER parameter to the current offline pod NFS log path.  
For example: /mnt/nfs/var/vols/itom/itsma/global-volume/logs/xservices/platform/itom-xruntime-platform-offline-7b76665769-gvlz2-2024-02-08/maas

4\. Create an out.txt file in the same directory as backup\_log.sh. Then, execute the script with the following command:  
nohup sh backup\_log.sh>out.txt &.

5\. If the offline pod is restarted during step 4, repeat step 3 and 4.

6\. The issue should be reproduced within one month.

7\. Execute the following commands to stop backup\_log.sh.  
Find process: ps -ef | grep 'sh backup\_log.sh'  
Kill process: kill -9 <Pid>

8\. Run the following command to disable the tenant setting:  
./set\_tenant\_settings.sh -T <TENANTID> -A disable -S ESS\_BACKUP\_FLAG8

9\. Collect logs in the log path created in step 2.

10\. Run the following command to collect all SLT transaction\_context data:  
COPY (SELECT transaction\_id, correlation\_id, locking\_time, merged\_entity, relation, transaction\_type, operation, transaction\_data, transaction\_timestamp, flag0, flag1, flag3, flag4 FROM transaction\_context\_<TENANTID> WHERE flag0 & 1 = 1) TO '<Temp/SQL\_result.csv>' CSV HEADER;
