Docs

Torch Log Service

Data collection FAQ

How to handle LogCollector maintenance failures

LogCollector version 2.3.1 and later supports creating three types of maintenance operations in the console: manual upgrade/downgrade, configuration modification, and restart.

After performing the corresponding maintenance operation, the operation may fail for certain reasons. You can refer to this document for troubleshooting and resolution.

Troubleshoot manual upgrade/downgrade failures

If the manual upgrade/downgrade operation fails when created in the console, refer to the following troubleshooting steps. After resolving the issue, you need to recreate the manual upgrade/downgrade task so that LogCollector instances in the failed task that were not executed or failed can retry the upgrade/downgrade.

Notice

TLS provides a LogCollector installation script, which supports downloading the script and running commands to upgrade or downgrade LogCollector. For details, see Manually upgrade LogCollector.

Check whether the LogCollector deployment environment is a physical machine

Manual upgrade/downgrade operations in the console are supported only for LogCollector deployed on physical machines.

Manual upgrade/downgrade operations in the console are not supported for LogCollector deployed in Kubernetes clusters. You can upgrade LogCollector using the installation script. For more information, see Upgrade LogCollector (Kubernetes cluster).

Check whether network issues are causing operation delivery timeout.

Go to the /usr/local/logcollector/data/ops/ directory.

Check whether there is a x.change_version file. x is the serial number, indicating the file for maintenance operation number x, for example, 1.change_version.

If the file does not exist, it indicates a network issue is preventing communication between LogCollector and the service point. Please check the server network.

Check the failure log message

Go to the /usr/local/filebeat-7.12.0/data/ops/ directory.

If the x.change_version file exists, you can check the corresponding x.change_version.fail file. Troubleshoot according to the information provided in the file.

Troubleshoot host group restart failures

Check whether network issues are causing operation delivery timeout.

Go to the /usr/local/logcollector/data/ops/ directory.

Check whether there is a x.restart file. x is the serial number, indicating the file for maintenance operation number x, for example, 1.restart.

If the file does not exist, it indicates a network issue is preventing communication between LogCollector and the service point. Please check the server network.

Troubleshoot configuration modification failures

Check whether network issues are causing operation delivery timeout.

Go to the /usr/local/logcollector/data/ops/ directory.

Check whether there is a x.modify_config file. x is the serial number, indicating the file for maintenance operation number x, for example, 1.modify_config.

If the file does not exist, it indicates that a network issue is preventing communication between LogCollector and the service endpoint. Please check the server network.

Check the log message for configuration modification failures.

Go to the /usr/local/logcollector/data/ops/ directory.

If the x.yml file exists, you can view the corresponding x.yml.fail file and troubleshoot according to the information provided in the file.

Notice

If the configuration modification is successful but incorrect configuration items cause LogCollector to fail to start:

Check the error messages in the /usr/local/logcollector/logs/logcollector-yyyymmdd.log file.

Modify the configuration items in x.yml according to the error messages.

After modifying the configuration items again in the console, re-issue the operations and maintenance task.

Last updated: 2026.06.25 16:39:47