Collecting Container Logs Using the Cloud Native Log Collection Add-on

Notes and Constraints

• Up to 100 log rules can be created for each cluster.
• The Cloud Native Log Collection add-on cannot collect .gz, .tar, and .zip logs and cannot access symbolic links of logs.
• If the node storage driver is Device Mapper, container file logs must be collected from the path where the data disk is attached to the node.
• If the container runtime is containerd, each stdout log cannot be in multiple lines. (This does not apply to the Cloud Native Log Collection add-on of version 1.3.0 or later.)
• If a volume is mounted to the directory of a service container, this add-on cannot collect data from the parent directory. In this case, you need to configure a complete data directory.
• If the lifetime of a container is less than 1 minute, logs cannot be collected in a timely manner. As a result, logs may be lost.

Billing

LTS does not charge you for creating log groups and offers a free quota for you to collect logs every month. You pay only for the log volume exceeding the quota. For details, see Price Calculator.

Enabling Logging on the Console

1. Enable logging.

   Enabling logging during cluster creation

   1. Log in to the CCE console.
   2. Click Buy Cluster.
   3. Configure the parameters by referring to Buying a CCE Standard/Turbo Cluster. Then, click Next: Select Add-on in the lower right corner.
   4. On the Select Add-on page, select Cloud Native Log Collection.
   5. Click Next: Configure Add-on in the lower right corner and select the required logs.
      • Container logs: A log collection policy named default-stdout will be created, and stdout logs in all namespaces will be reported to LTS.
      • Kubernetes events: A log collection policy named default-event will be created, and Kubernetes events in all namespaces will be reported to LTS.
   6. Click Next: Confirm Settings in the lower right corner. On the displayed page, click Submit.

   Enabling logging for an existing cluster

   1. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Logging.
   2. (Optional) If you are not authorized, obtain required permissions first.

      In the displayed dialog box, click Authorize.

      Figure 1 Authorize
      

   3. Click Enable and wait for about 30 seconds until the log page is automatically displayed.
      Figure 2 Enable
      
      • Stdout logs: A log collection policy named default-stdout will be created, and stdout logs in all namespaces will be reported to LTS.
      • Kubernetes events: A log collection policy named default-event will be created, and Kubernetes events in all namespaces will be reported to LTS.
      • To collect add-on logs (stdout logs of NGINX Ingress Controller), you need to install NGINX Ingress Controller and enable logging for this add-on.

        After logging is enabled, a log policy named default-nginx-ingress will be created to collect the stdout logs of NGINX Ingress Controller and report the logs to LTS.

2. View and configure log collection policies.
   1. On the CCE console, click the cluster name to access the cluster console. In the navigation pane, choose Logging.

   2. Click View Log Collection Policies in the upper right corner.

      All log collection policies reported to LTS are displayed.

      Figure 3 Viewing log collection policies
      
   3. Click Create Log Collection Policy.

      Policy Template: If the default log collection policy provided by CCE is not enabled when log collection is enabled or the default log collection policy is deleted, you can use this option to create a default log collection policy.

      Custom Policy: You can use this option to create a custom log collection policy.

      Figure 4 Custom policy
      
      

      • To keep the logs organized, you are advised to select different log streams for different types of logs when configuring the log collection policies.
      • The following are requirements for configuring the container and node file log paths:
        • Log directory: Enter an absolute path, for example, /log. The path must start with a slash (/) and contain a maximum of 512 characters. Only uppercase letters, lowercase letters, digits, hyphens (-), underscores (_), slashes (/), asterisks (*), and question marks (?) are allowed.
        • Log file name: It can contain only uppercase letters, lowercase letters, digits, hyphens (-), underscores (_), asterisks (*), question marks (?), and periods (.). Logs in the format of .gz, .tar, and .zip are not supported.

        The directory and file names must be complete and support asterisks (*) and question marks (?) as wildcards. A maximum of three levels of directories can be matched using wildcards. The level-1 directory does not support wildcards. An asterisk (*) can match multiple characters. A question mark (?) can match only one character. For example:

        • If the directory is /var/logs/* and the file name is *.log, the match expression is /var/logs/*/*.log, indicating that any files with the extension .log in all level-1 directories in the /var/logs directory are matched. Note that this expression cannot match any files with the extension .log in the /var/logs directory and multi-level directories in the /var/logs directory.
        • If the directory is /var/logs/app_* and the file name is *.log, any log files with the extension .log in all directories that match app_* in the /var/logs directory will be reported.

      Table 1 Custom policy parameters

      Log Type	Container Stdout Log	Container File Log	Node File Log
      Description	Used to collect container stdout logs. You can create a log collection policy by namespace, workload name, or instance label.	Used to collect text logs. You can specify a workload or instance label to create a log collection policy.	Used to collect logs from a node. Only one file path can be configured in a log collection policy.
      Log Source	All containers: You can specify all containers in a namespace. If this parameter is not specified, logs of containers in all namespaces will be collected. Blocklist: The Cloud Native Log Collection add-on of 1.7.4 or later supports this function. You can exclude pods from log collection based on pod label groups. Labels in the same label group are in the AND relationship, and labels in different label groups are in the OR relationship. If a pod matches all labels in any label group, the pod is excluded. You can create up to 10 label groups, and each label group can contain up to five labels. For example, if you want to exclude all pods of a workload in a namespace, enter the workload label, for example, app:test. Workload: You can specify a workload and its containers. If this parameter is not specified, logs of all containers running the workload will be collected. Workload with target label: You can specify a workload by label and its containers. If this parameter is not specified, logs of all containers running the workload will be collected.	Workload: You can specify a workload and its containers. If this parameter is not specified, logs of all containers running the workload will be collected. Workload with target label: You can specify a workload by label and its containers. If this parameter is not specified, logs of all containers running the workload will be collected. You also need to specify the log collection path. For details, see the log path configuration requirements.	Collection Path: used to configure the log collection path. For details, see the log path configuration requirements.
      Log Format	Single-line Each log contains only one line of text. The newline character \n denotes the start of a new log. Multi-line Some programs (for example, Java program) print a log that occupies multiple lines. By default, logs are collected by line. If you want to display logs as a single message, you can enable multi-line logging and use the regular pattern. When you select Multi-line, configure Log Matching Format. For example, if logs need to be collected by line and each log starts with a date and occupies three lines, you can set Log Matching Format to the regular expression of the date, for example, \d{4}-\d{2}-\d{2} \d{2}\:\d{2}\:\d{2}.*. The three lines starting with the date are regarded as a log. 2022-01-01 00:00:00 Exception in thread "main" java.lang.RuntimeException: Something has gone wrong, aborting! at com.myproject.module.MyProject.badMethod(MyProject.java:22) at com.myproject.module.MyProject.oneMoreMethod(MyProject.java:18)
      Report to LTS	This parameter is used to configure the log group and log stream for log reporting. Default log groups/log streams: The default log group (k8s-log-{Cluster ID}) and default log stream (stdout-{Cluster ID}) are automatically selected. Custom log groups/log streams: You can select any log group and log stream. Log Group: A log group is the basic unit for LTS to manage logs. If you do not have a log group, CCE prompts you to create one. The default name is k8s-log-{Cluster ID}, for example, k8s-log-bb7eaa87-07dd-11ed-ab6c-0255ac1001b3. Log Stream: A log stream is the basic unit for reading and writing logs. You can put different types of logs into different streams to ease management. When you install the add-on or create a log collection policy based on the policy template, the following log streams are automatically created: - stdout-{Cluster ID} for container logs, for example, stdout-bb7eaa87-07dd-11ed-ab6c-0255ac1001b3 - event-{Cluster ID} for Kubernetes events, for example, event-bb7eaa87-07dd-11ed-ab6c-0255ac1001b3 - cceaddon-nginx-ingress-{Cluster ID} for NGINX Ingress Controller logs, for example, cceaddon-nginx-ingress-bb7eaa87-07dd-11ed-ab6c-0255ac1001b3.

3. View the logs.
   1. On the CCE console, click the cluster name to access the cluster console. In the navigation pane, choose Logging.
   2. View different types of logs:
      • Container Logs: displays all logs in the default log stream stdout-{Cluster ID} of the default log group k8s-log-{Cluster ID}. You can search for logs by workload.
        Figure 5 Querying container logs
        
      • Kubernetes Events: displays all Kubernetes events in the default log stream event-{Cluster ID} of the default log group k8s-log-{Cluster ID}.
      • Control Plane Logs: displays all logs of components on the control plane in the default log stream {Component name}-{Cluster ID} of the default log group k8s-log-{Cluster ID}.
      • Control Plane Audit Logs: displays all control plane audit logs in the default log stream audit-{Cluster ID} of the default log group k8s-log-{Cluster ID}.
      • Global Log Query: You can view logs in the log streams of all log groups. You can specify a log stream to view the logs. By default, the default log group k8s-log-{Cluster ID} is selected. You can click the edit icon on the right of Switching Log Groups to switch to another log group.
        Figure 6 Global log query
        
      • Add-on Logs: displays the add-on logs in the default log group k8s-log-{Cluster ID}. You can view the cluster add-on logs.
   3. Click View Log Collection Policies in the upper right corner. Locate the log collection policy and click View Log to go to the log list.
      Figure 7 Viewing logs
      

Configuring Log Collection Using YAML

The Cloud Native Log Collection add-on must be 1.6.1 or later.

1. Use kubectl to connect to the cluster. For details, see Accessing a Cluster Using kubectl.
2. Create a YAML file named log-config.yaml. You can create a custom file name.

   vi log-config.yaml

   The following examples are for your reference. For details about the parameters, see Table 2.

   • Scenario 1: Collecting stdout logs of all workloads

     apiVersion: logging.openvessel.io/v1
     kind: LogConfig
     metadata:
       name: test-log-01  # Change the rule name as needed.
       namespace: kube-system  #Namespace of the collection rule. The value is fixed at kube-system.
     spec:
       inputDetail  : # Input configuration
         type: container_stdout   # Input type. container_stdout indicates stdout logs.
         containerStdout:  # Stdout log configuration. This parameter is valid only when type is set to container_stdout.
           allContainers: true  # Whether to collect the logs of all containers.
           namespaces: []  # Namespace list, which is of array type. This parameter is valid only when allContainers is set to true. The stdout logs of containers in specified namespaces will be collected. An empty array indicates that the stdout logs of containers in all namespaces will be collected.
           excludePodLabels:  # This parameter can be configured for the Cloud Native Log Collection add-on of 1.7.4 or later. You can exclude pods from log collection based on pod label groups. Labels in the same label group are in the AND relationship, and labels in different label groups are in the OR relationship. If a pod instance meets all labels in any label group, the pod is excluded.
            - key1: value1    # Label group 1
              key2: value2
           - key3: value3    # Label group 2
       outputDetail:  # Output configuration
         type: LTS    # Output type. The value is fixed at LTS.
         LTS:
           ltsGroupID: abf5f0ad-627e-41cc-8d3f-61c9e1f57f5a      # LTS log group ID. The specified ID must exist.
           ltsStreamID: f7ed71e9-6b9d-4ba3-86e4-b1b9d22ef4fb     # LTS log stream ID. The specified ID must exist.

   • Scenario 2: Collecting container file logs of a specified workload

     apiVersion: logging.openvessel.io/v1
     kind: LogConfig
     metadata:
       name: test-log-02  # Change the rule name as needed.
       namespace: kube-system  #Namespace of the collection rule. The value is fixed at kube-system.
     spec:
       inputDetail  : # Input configuration
         type: container_file   # Input type. container_file indicates container file logs.
         containerFile:    # Container file log configuration. This parameter is valid only when type is set to container_file.
           workloads:        # Modify the workload information as needed.
           - namespace: monitoring  # Namespace that the workload belongs to
             kind: Deployment  # Workload type. The value can be Deployment, DaemonSet, StatefulSet, Job, or CronJob.
             name: prometheus-lightweight  # Workload name
             container: prometheus  # Container name
             files:
             - logPath: "/var/log"  # Log directory, which is an absolute path.
               filePattern: "*.log"  # Log file name, which supports wildcard characters.
         processors:    # Multi-line log definition. If multiple lines are not required, delete processors.
           type: multiline # Log type, which is optional. The value can be singleline or multiline. The default value is singleline.
           multilineRegulation: '\d+:\d+:\d+.*?'  # Multi-line regular expression, which is optional. This field is valid only when type is set to multiline.
       outputDetail:  # Output configuration
         type: LTS    # Output type. The value is fixed at LTS.
         LTS:
           ltsGroupID: abf5f0ad-627e-41cc-8d3f-61c9e1f57f5a      # LTS log group ID. The specified ID must exist.
           ltsStreamID: f7ed71e9-6b9d-4ba3-86e4-b1b9d22ef4fb     # LTS log stream ID. The specified ID must exist.

   • Scenario 3: Collecting container file logs of pods with specified labels

     apiVersion: logging.openvessel.io/v1
     kind: LogConfig
     metadata:
       name: test-log-03  # Change the rule name as needed.
       namespace: kube-system  #Namespace of the collection rule. The value is fixed at kube-system.
     spec:
       inputDetail  : # Input configuration
         type: container_file   # Input type. container_file indicates container file logs.
         containerFile:    # Container file log configuration. This parameter is valid only when type is set to container_file.
           podLabels:      # Modify the value based on the CRD description.
           - includeLabels: # Label set. The logs of pods with the following labels will be collected. At least one label must be specified. Note that the pod label is not the label of the workload.
               foo: bar
             namespaces:  # Namespace list, which is of array type. An empty array indicates all namespaces.
             - monitoring
             - kube-system
             containers: []  # Container name list, which is of array type. An empty array indicates all containers.
             files:
             - logPath: "/var/log"  # Log directory, which is an absolute path.
               filePattern: "*.log"  # Log file name, which supports wildcard characters.
       outputDetail:  # Output configuration
         type: LTS    # Output type. The value is fixed at LTS.
         LTS:
           ltsGroupID: abf5f0ad-627e-41cc-8d3f-61c9e1f57f5a      # LTS log group ID. The specified ID must exist.
           ltsStreamID: f7ed71e9-6b9d-4ba3-86e4-b1b9d22ef4fb     # LTS log stream ID. The specified ID must exist.

   • Scenario 4: Collecting node logs

     apiVersion: logging.openvessel.io/v1
     kind: LogConfig
     metadata:
       name: test-log-04  # Change the rule name as needed.
       namespace: kube-system  #Namespace of the collection rule. The value is fixed at kube-system.
     spec:
       inputDetail  : # Input configuration
         type: host_file   # Input type. host_file indicates node logs.
         hostFile:    # Node log configuration. This parameter is valid only when type is set to host_file.
           file:
             logPath: "/var/log"    # Log directory, which is an absolute path. Change it as needed.
             filePattern: "messages" # Log file name, which supports wildcard characters and can be modified as needed.
       outputDetail:  # Output configuration
         type: LTS    # Output type. The value is fixed at LTS.
         LTS:
           ltsGroupID: abf5f0ad-627e-41cc-8d3f-61c9e1f57f5a      # LTS log group ID. The specified ID must exist.
           ltsStreamID: f7ed71e9-6b9d-4ba3-86e4-b1b9d22ef4fb     # LTS log stream ID. The specified ID must exist.

   Table 2 Parameters

   Parameter	Type	Description	Example
   spec.inputDetail.type	String	Input type. The options are as follows: container_stdout: indicates stdout logs. This field must be used together with the containerStdout field. container_file: indicates container file logs. This field must be used together with the containerFile field. host_file: indicates node logs. This field must be used together with the hostFile field.	-
   spec.inputDetail.containerStdout	Object	Stdout log configuration. This parameter is valid only when type is set to container_stdout. It contains the following fields: allContainers: Whether to collect the logs of all containers. If the value is true, the logs of all containers will be collected. In this case, you need to specify the namespaces field. If the value is false, the logs of specified workloads will be collected. In this case, you need to specify the workloads field. namespaces: namespace list, which is of array type and is valid only when allContainers is set to true. The stdout logs of containers in specified namespaces will be collected. An empty array indicates that the stdout logs of containers in all namespaces will be collected. excludePodLabels: (supported by the Cloud Native Log Collection add-on of 1.7.4 or later) used to exclude pods from log collection based on pod label groups. This field is available only when allContainers is set to true. Labels in the same label group are in the AND relationship, and labels in different label groups are in the OR relationship. If a pod matches all labels in any label group, the pod is excluded. You can create up to 10 label groups, and each label group can contain up to five labels. workloads: workload list, which is of array type and is valid only when allContainers is set to false. namespace: namespace that a workload belongs to. kind: workload type. The value can be Deployment, DaemonSet, StatefulSet, Job, or CronJob. name: workload name. containers: container name list, which is of array type. An empty array indicates all containers. podLabels: pod labels, which is of array type and is valid only when allContainers is set to false and workloads is left empty. includeLabels: label set. The logs of pods with the following labels will be collected. At least one label must be specified. Note that the pod label is not the label of the workload. namespaces: namespace list, which is of array type. An empty array indicates all namespaces. containers: container name list, which is of array type. An empty array indicates all containers.	Example 1: Collecting the stdout logs of all containers in a namespace ... spec: inputDetail: type: container_stdout containerStdout: allContainers: true namespaces: - monitoring ... Example 2: Collecting the stdout logs of a workload ... spec: inputDetail: type: container_stdout containerStdout: allContainers: false workloads: - namespace: monitoring kind: Deployment name: prometheus-lightweight container: prometheus ... Example 3: Collecting the stdout logs of a pod ... spec: inputDetail: type: container_stdout containerStdout: allContainers: false workloads: [] podLabels: - includeLabels: foo: bar namespaces: - monitoring containers: [] ... Example 4: Collecting the stdout logs of all containers in a namespace, excluding the pods of multiple workloads from log collection (based on multiple groups of labels) ... spec: inputDetail: type: container_stdout containerStdout: allContainers: true namespaces: - monitoring excludePodLabels: - key1: value1 # Label group 1 key2: value2 - key3: value3 # Label group 2 ...
   spec.inputDetail.containerFile	Object	Container file log configuration. This parameter is valid only when type is set to container_file. It contains the following fields: workloads: workload list, which is of array type. namespace: namespace that a workload belongs to. kind: workload type. The value can be Deployment, DaemonSet, StatefulSet, Job, or CronJob. name: workload name. container: container name. files: file list, which is of array type and contains the logPath and filePattern fields. - logPath: log directory, which is an absolute path, for example, /var/log. - filePattern: log file name, which supports wildcard characters, for example, *.log. podLabels: pod labels, which is of array type and is valid only when workloads is left empty. includeLabels: label set. The logs of pods with the following labels will be collected. At least one label must be specified. Note that the pod label is not the label of the workload. namespaces: namespace list, which is of array type. An empty array indicates all namespaces. containers: container name list, which is of array type. An empty array indicates all containers. files: file list, which is of array type and contains the logPath and filePattern fields. - logPath: log directory, which is an absolute path, for example, /var/log. - filePattern: log file name, which supports wildcard characters, for example, *.log.	Example 1: Collecting container file logs of a workload ... spec: inputDetail: type: container_file containerFile: workloads: - namespace: monitoring kind: Deployment name: prometheus-lightweight container: prometheus files: - logPath: "/var/log" filePattern: "*.log" ... Example 2: Collecting container file logs of a pod ... spec: inputDetail: type: container_file containerFile: workloads: [] podLabels: - includeLabels: foo: bar namespaces: - monitoring containers: [] files: - logPath: "/var/log" filePattern: "*.log" ...
   spec.inputDetail.hostFile	Object	Node log configuration. This parameter is valid only when type is set to host_file. file: - logPath: log directory, which is an absolute path, for example, /var/log. - filePattern: log file name, which supports wildcard characters, for example, *.log.	... spec: inputDetail: type: host_file hostFile: files: logPath: "/var/log" filePattern: "*.log" ...
   spec.inputDetail.processors	Object	type: log type, which is optional. The value can be singleline or multiline. The default value is singleline. multilineRegulation: multi-line regular expression. This parameter is optional and is valid only when type is set to multiline.	... processors: type: multiline multilineRegulation: '\d+:\d+:\d+.*?' ...
   spec.outputDetail.type	String	Output type. The value is fixed at LTS.	-
   spec.outputDetail.LTS	Object	The following fields are supported: ltsGroupID: LTS log group ID. The specified ID must exist. ltsStreamID: LTS log stream ID. The specified ID must exist. Either ltsStreamID or ltsStreamName must be configured. ltsStreamName: LTS log stream name. If the specified log stream name does not exist, it will be automatically created. Either ltsStreamID or ltsStreamName must be configured. ltsStreamCreateParam: log stream creation parameter. This parameter is optional and is valid only when ltsStreamName is specified and an LTS log stream is automatically created. enterpriseProjectID: enterprise project ID of the LTS log group. This parameter is optional and is only available for enterprise accounts with enterprise projects enabled. If this parameter is not specified, the enterprise project ID of the cluster is used.	Example 1: Specifying an existing log group ID and log stream ID ... LTS: ltsGroupID: ***** ltsStreamID: ***** Example 2: Specifying an existing log group ID and an existing log stream name ... LTS: ltsGroupID: ***** ltsStreamName: test-stream-name-1 Example 3: Specifying an existing log group ID and a new log stream name to automatically create a log stream ... LTS: ltsGroupID: ***** ltsStreamName: test-stream-name-2 ltsStreamCreateParam: enterpriseProjectID: ""

3. Create a LogConfig.

   kubectl create -f log-config.yaml

   If information similar to the following is displayed, the LogConfig has been created:

   logconfig.logging.openvessel.io/test-log-xx created

4. Check the created LogConfig.

   kubectl get LogConfig -n kube-system

   If information similar to the following is displayed, the log collection policy has been created.

   NAME                AGE
   test-log-xx         30s