KUMA provides the following types of logs:
Installer logs
KUMA automatically creates files containing logs of installation, reconfiguration, or removal.
The logs are stored in the ./log/ subdirectory in the installer directory. The name of the log file reflects the date and time when the corresponding script was started.
Names are generated in the following formats:
KUMA creates a new log file each time the installation, reconfiguration, or removal script is started. Log rotation or automatic deletion is not performed.
The log incorporates the lines of the inventory file used when the corresponding command was invoked, and the ansible log. For each task, the following information is listed in this order: task start time (Tuesday, October 31, 2023 10:29:14 +0300), run time of the previous task (0:00:02.611), and the total time passed since the installation, reconfiguration, or removal was initiated (0:04:56.906).
Example:
TASK [Add columns to the replicated table] ***************************************
Tuesday, October 31, 2023 10:29:14 +0300 (0:00:02.611) 0:04:56.906 *******
Component logs
By default, only errors are logged for all KUMA components. To receive detailed data in logs, configure Debug mode in the component settings.
The Core logs /opt/kaspersky/kuma/core/log/stdout.log and /opt/kaspersky/kuma/core/log/stderr.log are archived when they reach 5 GB or 7 days, whichever comes first. These conditions are checked once daily. Archives are kept in the log folder for 7 days, after 7 days the archive is deleted. A maximum of four archived logs are stored on the server at the same time. Whenever a new log archive is created, if the total number of archives becomes greater than four, the oldest log archive is deleted. If the logs fill up quickly, you must have enough disk space to create a copy of the log file and archive it as part of log rotation.
The component logs are appended until the file reaches 5 GB. When the log reaches 5 GB, it is archived and new events are written to a new log. Archives are kept in the log folder for 7 days, after 7 days the archive is deleted. A maximum of four archived logs are stored on the server at the same time. Whenever a new log archive is created, if the total number of archives becomes greater than four, the oldest log archive is deleted.
Debug mode is available for the following components:
Core |
To enable it: in the KUMA web interface, select Settings → General → Core settings → Debug. Storage location:
If KUMA is installed in a high availability configuration, refer to the Viewing Core logs in Kubernetes section below. |
Services:
|
To enable it, use the Debug toggle switch in the settings of the service. Storage location: the service installation directory. For example, /opt/kaspersky/kuma/<service name>/log/<service name>. You can download the service logs from the KUMA web interface, in the Resources → Active services section by selecting the desired service and clicking Log. Logs residing on Linux machines can be viewed by running the journalctl and tail command. For example:
|
Resources:
|
To enable it, use the Debug toggle switch in the settings of the service to which the resource is linked. The logs are stored on the machine hosting the installed service that uses the relevant resource. Detailed data for resources can be viewed in the log of the service linked to a resource. |
Viewing Core logs in Kubernetes
When Core log files reach 100 MB, they are archived and a new log is written. No more than five files are stored at a time. If there are more than five files when a new log appears, the oldest file is deleted.
On worker nodes, you can view the logs of containers and pods residing on these nodes in the file system of the node.
For example:
/var/log/pods/kuma_core-deployment-<UID>/core/*.log
/var/log/pods/kuma_core-deployment-<UID>/mongodb/*.log
To view the logs of all containers in the Core pod:
k0s kubectl logs -l app=core --all-containers -n kuma
To view the log of a specific container:
k0s kubectl logs -l app = core -c <container_name> -n kuma
To enable real-time log viewing, add the -f switch:
k0s kubectl logs -f -l app=core --all-containers -n kuma
To view the logs of the previous pod that was overwritten by a new one (for example, when recovering from a critical error or after redeployment), add the --previous switch:
k0s kubectl logs -l app=core -c core -n kuma --previous
To access the logs from other hosts that are not included in the cluster, you need the k0s-kubeconfig.yml file containing the access credentials created during KUMA installation, and the locally installed kubectl cluster management utility.
The cluster controller or traffic balancer specified in the server parameter of the k0s-kubeconfig.yml file must be accessible over the network.
The file path must be exported to a variable: export KUBECONFIG=/<file path>/k0s-kubeconfig.yml
You can use kubeclt to view the logs. For example:
kubectl logs -l app=core -c mongodb -n kuma