2 Logs

This chapter explains the process to retrieve the logs and status that can be used for effective troubleshooting. Logs register system events along with their date and time of occurrence. They also provide important details about a chain of events that could have led to an error or problem.

2.1 Log Levels

This section provides information on log levels supported by Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF).

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 example, 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.

Supported Log Levels

For NSSF, you can set the log level for a microservice to any of the following valid values:
  • TRACE: This log level describes events showing step-by-step execution of your code. You may ignore this log during the standard operation. However, it may be useful during extended debugging sessions.
  • DEBUG: This log level is useful while debugging an event and when more granular information is required.
  • INFO: This is the standard log level indicating an event has occurred. For example, when the application enters a certain state.
  • WARN: This log level indicates that some unexpected behavior has occurred in the application, but the application has not failed. Even with this unexpected behavior, the code can continue running.
  • ERROR: This log level indicates an issue has occurred in the application that prevents one or more functionalities from working correctly.

Configuring Log Levels

Use the logLevel parameter to view and update the logging level configurations in the ocnssf-custom-values.yaml file. For example, see the following snippet from the ocnssf-custom-values.yaml file for Helm test hook related configuration. 
test:
    config:
      logLevel: WARN
      timeout: 120

Examples with various Log Level Values

The following section provides examples for log messages containing different log level values:

For level ERROR: 

{
  "instant": {
    "epochSecond": 1635408023,
    "nanoOfSecond": 739237045
  },
  "thread": "XNIO-1 task-1",
  "level": "ERROR",
  "loggerName": "com.oracle.cgbu.cne.nssf.nsavailability.service.NsAvailabilityService",
  "message": "Unsupported PLMN/S received , supported plmn list: [Plmn [mcc=100, mnc=101], Plmn [mcc=100, mnc=02], Plmn [mcc=101, mnc=101], Plmn [mcc=102, mnc=102], Plmn [mcc=100, mnc=100], Plmn [mcc=200, mnc=200], Plmn [mcc=100, mnc=102], Plmn [mcc=100, mnc=001], Plmn [mcc=103, mnc=103]]",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger",
  "contextMap": {
    "ocLogId": "1635408023716_15768_ocnssf-ingress-gateway-6d554c596-q86hp"
  },
  "threadId": 1446,
  "threadPriority": 5,
  "ts": "2021-10-28 08:00:23.739+0000",
  "ocLogId": "1635408023716_15768_ocnssf-ingress-gateway-6d554c596-q86hp",
  "pod": "ocnssf-nsavailability-5f858b7745-mk2pv",
  "processId": "1",
  "vendor": "Oracle",
  "application": "ocnssf",
  "engVersion": "1.0.0",
  "mktgVersion": "1.0.0.0.0",
  "microservice": "nsavailability",
  "namespace": "ocnssf",
  "node_name": "remote-setup-kamal"
}

For level INFO: 

{
  "instant": {
    "epochSecond": 1635408080,
    "nanoOfSecond": 653030110
  },
  "thread": "scheduling-1",
  "level": "INFO",
  "loggerName": "com.oracle.common.scheduler.ReloadConfig",
  "message": "All configurations intact, no updation in the configuration",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger",
  "contextMap": {},
  "threadId": 28,
  "threadPriority": 5,
  "ts": "2021-10-28 08:01:20.653+0000",
  "ocLogId": "${ctx:ocLogId}",
  "pod": "ocnssf-nsavailability-5f858b7745-mk2pv",
  "processId": "1",
  "vendor": "Oracle",
  "application": "ocnssf",
  "engVersion": "1.0.0",
  "mktgVersion": "1.0.0.0.0",
  "microservice": "nsavailability",
  "namespace": "ocnssf",
  "node_name": "remote-setup-kamal"
}

2.2 Collecting Logs

This section describes how to collect logs from pods and containers. The steps are as follows:

Collect the NSSF Logs to check the error scenarios

Problem: The error scenarios are checked by collecting the NSSF logs.

Solution:

Perform the following steps to get the logs from nssf:

  1. Run the following command to get the pod details: 
    kubectl -n <ocnssf_namespace> get pods
  2. Collect the logs from the specific pods or containers:
    kubectl logs <podname> -n <ocnssf_namespace> -c <containername>
  3. Store the log in a file using the following command:
    kubectl logs <podname> -n <ocnssf_namespace> > <filename>

    Example:

    kubectl logs ocnssf-nsselection-57cff5665c-skk4l -n ocnssf > ocnssf_logs1.log
  4. (Optional) Run the following command for the log stream with file redirection starting with last 100 lines of log:
    kubectl logs <podname> -n <ocnssf_namespace> -f --tail <number of lines> > <filename>

For more information on kubectl commands, see Kubernetes website.

2.3 Understanding Logs

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

The log message format is same for all the NSSF 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 or 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 Time stamp 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 NSSF 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

Sample Logs

Sample log statement of nsconfig:
{"instant":{"epochSecond":1645187968,"nanoOfSecond":864222104},"thread":"main","level":"INFO","loggerName":"com.oracle.cgbu.cne.nssf.nsconfig.Application","message":"Started Application in 21.489 seconds (JVM running for 23.688)","endOfBatch":false,"loggerFqcn":"org.apache.commons.logging.LogAdapter$Log4jLog","contextMap":{},"threadId":1,"threadPriority":5,"ts":"2022-02-18 12:39:28.864+0000","ocLogId":"${ctx:ocLogId}","pod":"ocnssf-nsconfig-85bd697b74-kxrfv","processId":"1","vendor":"Oracle","application":"ocnssf","engVersion":"22.1.1","mktgVersion":"22.1.1.0.0","microservice":"nsconfig","namespace":"nssf","node_name":"bumblebee-k8s-node-15"}