Files
nexus/knowledgebase/csd-wiki/ICSD/How-to-automatically-collect-SLT-logs-for-troubleshooting_688988287.md

1.8 KiB

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 -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

8. Run the following command to disable the tenant setting:
./set_tenant_settings.sh -T -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_ WHERE flag0 & 1 = 1) TO '<Temp/SQL_result.csv>' CSV HEADER;