| Table of Contents |
|---|
How can I collect support data?
If you have detected a bug or need to contact Kiuwan support, you can collect valuable information that will help us diagnose your problem by executing:
| Code Block | ||
|---|---|---|
| ||
cd [INSTALLER_DIR]/support
sudo ./collect-support-info.sh |
This will gather all relevant diagnose data and store it under [INSTALLER_DIR]/support/[yyyyMMddhhmmss], where the folder name corresponds to the current timestamp.
Note that the needed time to collect all data depends on the size of your data and could take some minutes.
As the included files may contain sensible information, you can check if anything that should not leave your organization must be removed from the files before sending them to Kiuwan support.
Once the support files have been collected, compress the folder into a single zip file (please replace the [yyyyMMddhhmmss] with the name of the folder created by the script:
| Code Block | ||
|---|---|---|
| ||
zip -r support-info.zip [yyyyMMddhhmmss] |
Where are logs stored?
The following table shows where logs are stored for each Kiuwan On-Premises services:
| Service | Location | Folder | File name pattern | Description |
|---|---|---|---|---|
| apacheloadbalancer | [VOLUMES_DIR]/data-local/ApacheLoadBalancer | logs | *.log | Apache logs |
| wildflykiuwan-f[n] | [VOLUMES_DIR]/data-local/generatedConfig | front/kwf[n]/logs/server | server.log[.yyyy-MM-dd] | Wildfly fronts servers logs |
| wildflykiuwan-a[n] | analyzers/kwa[n]/logs/server | Wildfly analyzers servers logs | ||
| wildflykiuwan-s[n] | schedulers/kws[n]/logs/server | Wildfly schedulers servers logs | ||
| wildflykiuwan-f[n] | [VOLUMES_DIR]/data-local/generatedConfig | front/kwf[n]/logs/kiuwan/logs | *.log.[n] | Kiuwan fronts webapp logs |
| wildflykiuwan-a[n] | analyzers/kwa[n]/logs/kiuwan/logs | Kiuwan analyzers webapp logs | ||
| wildflykiuwan-s[n] | schedulers/kws[n]/logs/kiuwan/logs | Kiuwan schedulers webapp logs | ||
| wildflykiuwan-a[n] | [VOLUMES_DIR]/data-local/generatedConfig | analyzers/kwa[n]/logs/kiuwan/logs/analysisLogs/kiuwanadmin-2/analysis | *.log | Kiuwan analysis server logs |
| updaterkiuwan | [VOLUMES_DIR]/data-local/updater | logs/install | [yyyyMMdd_hhmmss]/*.log | Kiuwan installation log |
| logs/upgrade/data | Kiuwan data upgrade log | |||
| logs/upgrade/database | Kiuwan database upgrade log | |||
| logs/upgrade/qmm | Kiuwan models manager upgrade log | |||
| logs/updaterManager | updaterManagerTool.log | Kiuwan upgrade tools log | ||
| mysqlkiuwan | [VOLUMES_DIR]/data-local/MySql | logs | error.log | MySQL error log |
How can I free space on my server?
Before purging any file, make sure that no analysis are running and Kiuwan services are stopped by issuing this command:
| Code Block | ||
|---|---|---|
| ||
cd [INSTALLER_DIR]
sudo ./stop-all.sh |
The following files can be purged without affecting the normal operation of Kiuwan On-Premises:
- Unneeded stored logs (refer to Where are logs stored? for a complete list of log files).
- Local repository data found in [VOLUMES_DIR]/data-local/generatedConfig:
- front/kwf[n]/repos/kiuwanLocalRepository/kiuwanadmin-2
- analyzers/kwa[n]/repos/kiuwanLocalRepository/kiuwanadmin-2
- schedulers/kws[n]/repos/kiuwanLocalRepository/kiuwanadmin-2
- Central repository data of already processed analyses found in [VOLUMES_DIR]/data-shared/repos/kiuwanCentralRepository:
- kiuwanadmin-2/reports
| Warning |
|---|
| Note that when removing the data shown above, historical data relevant for diagnisis and support will not be available. Please consider backuping your data before removing files. |
Once the data has been purged, restart Kiuwan services:
| Code Block | ||
|---|---|---|
| ||
cd [INSTALLER_DIR]
sudo ./start-all.sh
|
My Kiuwan On-Premises local IP address has changed and Redis is not responding anymore
If you have used the default configuration to install your Kiuwan On-Premises (that is, running all the default containers in a single host), it is recommended to keep a fixed IP in the host machine.
Kiuwan On-Premises default installation uses a Redis Cluster made up of six nodes, all running in the same host. Each one of these nodes needs to know the IP where all the other nodes reside (not the internal docker network IP, but the host local network IP). In case of an IP change, it is needed to update the Redis Cluster nodes IP. This is automatically done by the supplied containers, but if enough time passes since the IP change, Kiuwan will refuse to connect to the Redis Cluster after exhausting the defined maximum retries.
In the previous situation you will see in any wildflykiuwan-f* container logs these traces:
| Code Block |
|---|
ERROR [io.undertow.request] (default task-14) UT005023: Exception handling request to /saas/zkau: redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more cluster attempts left. |
Problem fix for Kiuwan On-Premises version >= 2.8.2004.5
To recover the system, simply restart all containers by running these commands:
| Code Block | ||
|---|---|---|
| ||
cd [INSTALLER_DIR]
sudo ./stop-all.sh
sudo ./start-all.sh |
Problem fix for Kiuwan On-Premises version < 2.8.2004.5
If your Kiuwan On-Premises version is older than 2.8.2004.5, you should restart Redis Cluster manually before upgrading to the latest version:
| Code Block | ||
|---|---|---|
| ||
cd [INSTALLER_DIR]
sudo ./stop-all.sh
cd [INSTALLER_DIR]/docker
sudo ./start-infrastructure.sh |
Once the infrastructure containers are up, you can proceed with the upgrade (see Kiuwan On-Premises Distributed Upgrade Guide). Once the upgrade is finished the problem will be gone.