Managing the Log Level of a Component

Components Other Than BSS

Each CloudBlue Commerce component has its own log level settings specified in a ConfigMap named COMPONENT_NAME-logging-config. When you install a component, its log level is set to a reasonable default value, depending on the features of that component.

You can change the current log level for a CloudBlue Commerce component by completing these steps on a server that has access to your Kubernetes cluster:

Open the COMPONENT_NAME-logging-config ConfigMap of that component for editing:
```
kubectl -n CBC_NAMESPACE edit cm COMPONENT_NAME-logging-config
```
Note: If this ConfigMap is absent on your installation, this means that the current version of that component does not support log level management through ConfigMaps. This functionality will be supported in a future version of that component.
In data.log.properties, in the ROOT setting, specify the log level you need:
```
...
data:
  log.properties: |
    ROOT=DEBUG
...
kind: ConfigMap
...
```
You can use the OFF, FATAL, ERROR, WARN, INFO, DEBUG, and TRACE log levels, from the least informative to the most informative.
Save the ConfigMap and wait for a while. The log level of the component will be automatically changed.

The BSS Component

The BSS component has its own mechanism of log level management, which is different from the mechanism used by other components.

To manage the log level of the BSS component, complete these steps on a server that has access to your Kubernetes cluster:

Enter the bss-atm pod:

kubectl -n CBC_NAMESPACE exec -ti deploy/bss-atm bash

In that pod, use the log_ctl utility to manage the log level of various BSS pods that the BSS component consists of:

Execute log_ctl --command=list to view BSS pods and their log levels. For example:

[root@bss-atm-796446bd9b-8ncpn /]# log_ctl --command=list
Current log levels:
        XMLRPC_Container:0: 4 (TRC)
        billing._amt_: 4 (TRC)
        billing.scheduler: 4 (TRC)
        billing.www: 4 (TRC)
        generic_worker:10.165.0.37_43: 4 (TRC)
        generic_worker:10.165.2.114_43: 4 (TRC)
        generic_worker:10.165.2.94_43: 4 (TRC)
        generic_worker:10.165.3.146_43: 4 (TRC)
        generic_worker:10.165.4.36_43: 4 (TRC)
        generic_worker:10.165.5.40_43: 4 (TRC)

Execute log_ctl --command=set --match=PATTERN --level=LOG_LEVEL to set the required log level for the pods with names that match the specified pattern. You can use the 0 (FATAL), 1 (ERR), 2 (WARN), 3 (NOTE), 4 (TRACE), 5 (INFO), 6 (DEBUG), and 7 (ALL) log levels, from the least informative to the most informative.

For example:

[root@bss-atm-796446bd9b-8ncpn /]# log_ctl --command=set --match=worker --level=6
Changing log level to 6 (DBG) for containers matched 'worker'
Current log levels:
        XMLRPC_Container:0: 4 (TRC)
        billing._amt_: 4 (TRC)
        billing.scheduler: 4 (TRC)
        billing.www: 4 (TRC)
        generic_worker:10.165.0.37_43: 6 (DBG)
        generic_worker:10.165.2.114_43: 6 (DBG)
        generic_worker:10.165.2.94_43: 6 (DBG)
        generic_worker:10.165.3.146_43: 6 (DBG)
        generic_worker:10.165.4.36_43: 6 (DBG)
        generic_worker:10.165.5.40_43: 6 (DBG)

Execute log_ctl --help to get the description of the utility and its parameters.

Note: BSS pod log levels you specify with the log_ctl utility are not kept permanently. If a BSS pod is restarted, its log level is reset to a default value.