2 Logs

Log files are used to register system events, together with their date and time of occurrence. They can be valuable tools for troubleshooting. Not only do logs indicate that specific events occurred, they also provide important clues about a chain of events that led to an error or problem.

Collecting Logs

This section describes the steps to collect logs from PODs and containers. Perform the following steps:
  1. Run the following command to get the PODs details:
    $ kubectl -n <namespace_name> get pods
  2. Collect the logs from the specific pods or containers:
    $ kubectl logs <podname> -n <namespace> -c <containername>
  3. Store the log in a file using the following command:
    $ kubectl logs <podname> -n <namespace>  > <filename>
  4. (Optional) You can also use the following commands for the log stream with file redirection starting with last 100 lines of log:
    $ kubectl logs <podname> -n <namespace> -f --tail <number of lines> > <filename>

For more information on kubectl commands, see Kubernetes website.

2.1 Log Levels

This section provides information on log levels supported by Oracle Communications Cloud Native Core, Binding Support Function (BSF).

A log level helps in defining the severity level of a log message. Using this information, the logs can be filtered based on the system requirements. For instance, if you want to filter the critical information about your system from the informational log messages, set a filter to view messages with only WARN log level in Kibana.

As shown in the following image, only log messages with level defined as WARN are shown, after adding filter:Filtering logs in Kibana according to log level

Supported Log Levels

For BSF, the log level for a micro-service can be set to any of the following valid values:
  • TRACE: A log level describing events showing step by step execution of your code that can be ignored during the standard operation, but may be useful during extended debugging sessions.
  • DEBUG: A log level used for events considered to be useful during software debugging when more granular information is needed.
  • INFO: The standard log level indicating that something happened, the application entered a certain state, etc.
  • WARN: Indicates that something unexpected happened in the application, a problem, or a situation that might disturb one of the processes. But that doesn’t mean that the application failed. The WARN level should be used in situations that are unexpected, but the code can continue the work.
  • ERROR: The log level that should be used when the application hits an issue preventing one or more functionalities from properly functioning.

Configuring Log Levels

To view logging configurations and update logging levels, use the Logging Level page under Logging Configurations on the CNC Console. For more information, see the section "Log Level" in Oracle Communications Cloud Native Core, Binding Support Function User Guide.

2.2 Understanding Logs

This section provides information on how to read logs for various services of BSF in Kibana.

Understanding Logs

The following is a sample log for BSF services:
{
  "instant": {
    "epochSecond": 1627016656,
    "nanoOfSecond": 137175036
  },
  "thread": "Thread-2",
  "level": "INFO",
  "loggerName": "ocbsf.framework.domain.orchestration.AbstractProcess",
  "marker": {
    "name": "ALWAYS"
  },
  "message": "Received RECONFIGURE request",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 34,
  "threadPriority": 5,
  "messageTimestamp": "2021-07-23T05:04:16.137+0000"
}

The log message format is same for all the BSF services.

The following table describes key attributes of a log message:

Table 2-1 Log Attributes

Attribute Description
level Log level of the log printed
loggerName Class/Module which printed the log
message Message related to the log providing brief details
loggerFqcn Log4j2 Internal, Fully Qualified class name of logger module
thread Thread name
threadId Thread ID generated internally by Log4j2
threadPriority Thread priority generated internally by Log4j2
messageTimeStamp Timestamp of log from application container
kubernetes.labels.application NF Application Name
kubernetes.labels.engVersion Engineering version of software
kubernetes.labels.mktgVersion Marketing version of software
kubernetes.labels.microservice Name of the microservice
kubernetes.namespace_name Namespace of BSF deployment
kubernetes.host worker node name on which container is running
kubernetes.pod_name Pod Name
kubernetes.container_name Container Name
Docker.container_id Process ID internally assigned
kubernetes.labels.vendor Vendor of product