Using Environment Variables to Configure Log Collection

Prev Next

search by keyword

Recent Pages

Documentation

Download PDF

Using Environment Variables to Configure Log Collection

Last updated: 2022-09-23 14:45:09

Download PDF

Overview

In TKE Serverless clusters, you can use environment variables to configure log collection, and collect logs by line without parsing, or use custom resource definitions (CRD) to configure log collection.

This document describes how to use the environment variables to configure the log collection feature for a TKE Serverless cluster, and to send the logs of services within the cluster to Cloud Log Service (CLS) or external Kafka. This feature is suitable for users who need to store and analyze service logs in TKE Serverless clusters.

To use the log collection feature in a TKE Serverless cluster, you need to manually enable it for the cluster when creating a workload. You can enable this feature by performing the following operations:

Configuring log collection in the console
Configuring log collection via yaml
Updating log collection

Notes

After the log collection feature is enabled for the TKE Serverless cluster, the log collection agent will send the collected logs in JSON format to the specified consumer end based on your configuration. The details of the collection path and consumer end are as follows:

Consumer end: The log collection service allows you to set Kafka or CLS as the log consumer end.
Collection path: The path of the logs to collect. The collection path supports collection standard output (stdout) and absolute path. It also supports wildcard (*). If multiple paths are specified, separate them with “,”.

Prerequisite

Confirm that the Kubernetes cluster can access the log consumer end.
The length of a log is limited to 2 M. The log is truncated if this limit is exceeded.

Note

If the log output rate is high, you need to adjust this parameter configuration to avoid OOM. For more information, see How to adjust the log collection configuration to adapt to different log output rates.

Directions

Configuring log collection in the console

When the log collection is enabled for the TKE Serverless cluster, the log information is collected and output to the specified consumer end in JSON format with Kubernetes metadata attached, including the label of the Pod to which the container belongs, annotation, etc. The specific directions are as follows:

Log in to the TKE console and click Cluster in the left sidebar.
On the cluster management page, click the ID of the target Serverless cluster to enter the cluster details page.
Select a workload type in Workload on the left to go to the corresponding page, and then click Create.
In Containers in the Pod section, select Advanced settings, and check Activate to enable log collection.
Refer to the following information to configure the log consumer end. You can choose CLS or Kafka as the log consume end.
- Configuring CLS as the log consumer end
- Configuring Kafka as the log consumer end
1. Select CLS as the Consumer end, and select the Logset and Log topic.
  
  If there is no suitable logset, you can create a logset and a log topic.
  
  Note
  
  CLS currently only supports log collection and reporting for intra-region container clusters.
2. Enable the log index for the selected log topic. Index configuration is required for CLS log search and analysis. If it is not enabled, you cannot view the logs. For how to configure the index, see Configuring Index.
  You can go to the CLS console > Log topic page, select a log topic name, and enable the index in the Index configuration page.
If you select Kafka as the consumer end, it is recommended that you use CKafka. The experience of its consumption and production modes are the same as the native version, and it supports alarm configurations.
Specify the Broker address and Topic of Kafka in the container configuration, and ensure that all resources in the cluster can access the Kafka Topic specified by the user.

Note

You need to select “delete” for cleanup.policy in Kafka Topic configuration. If you select “compact”, CLS will fail to report to Kafka, resulting in data loss.
Select Role or Key to authorize.
Note
- You can only select the same authorization method for the containers in the same Pod. The last modification shall prevail. For example, if you select key authorization for the first container and role authorization for the second container, finally both containers will adopt role authorization.
- You can only select the same role to authorize for the containers in the same Pod.
- Role authorization
- Key authorization
- Select a role that can access CLS, as shown in the figure below:
- If there is no suitable role, you can create one as follows:
Creating a policy
You need to create a policy before creating a role. This policy determines the permissions your role can have.
1. Log in to the CAM console and select Policies in the left sidebar.
2. On the “Polices” page, click Create custom policy.
3. Select Create by policy generator in “Select policy creation method” pop-up window.
4. In the “Visual Policy Generator”, select Cloud Log Service (cls) for Service, and select Write: pushLog for Action.
5. Click Next to go to the “Associate users/user groups” page.
6. Confirm the policy name and click Done.
Creating a role
After creating a policy, you need to bind this policy to a role, so that the role has permissions corresponding to the policy.
1. Log in to the CAM console, and select Roles in the left sidebar.
2. On the “Roles” page, click Create role.
3. In the “Select role entity” window that appears, select Tencent Cloud Product Service to go to the “Create custom role” page.
4. In the “Enter role entity info” step, select Cloud Virtual Machine (cvm) and click Next.
  
  Note
  
  You must select Cloud Virtual Machine (cvm) as the role entity, otherwise, you cannot complete the authorization process.
5. In the “Configure role policy” step, select Created policy, and click Next.
6. In the “Review” step, enter the role name to review the role information, and then click Done. For more information, see Creating a Role.
- Select the “SecretId” and “SecretKey” of your account API key as the variable values to create the cluster Secret.
- If there is no suitable Secret, you need to create one. For more information, see Secret Management. You can view the SecretId and SecretKey in API Keys.
  
  Note
  
  The user corresponding to the API key must have the permission to access the CLS. If there is no API key, you need to create one. For more information, see Access Key.
Configure the collection path.

At this point, you have configured the log collection feature. You can set other configurations of the workload as needed.

Configuring log collection via yaml

This document provides three collection methods for your choice: Collecting logs to Kafka, collecting logs to CLS via a secret and collecting logs to CLS via a role.

Note

If both key and role authorization are configured in yaml, the Pod actually uses role authorization.

Collecting logs to Kafka
Collecting logs to CLS via a secret
Collecting logs to CLS via a role

Enable log collection by adding environment variables.

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
labels:
    k8s-app: kafka
    qcloud-app: kafka
  name: kafka
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: kafka
      qcloud-app: kafka
 template:
metadata:
      annotations:
        eks.tke.cloud.tencent.com/cpu: "0.25"
        eks.tke.cloud.tencent.com/mem: "0.5Gi"
labels:
        k8s-app: kafka
        qcloud-app: kafka
    spec:
      containers:
      - env:
        - name: EKS_LOGS_OUTPUT_TYPE
          value: kafka
        - name: EKS_LOGS_KAFKA_BROKERS
          value: 10.0.16.42:9092
        - name: EKS_LOGS_KAFKA_TOPIC
          value: eks
        - name: EKS_LOGS_KAFKA_MESSAGE_KEY # Optional
          valueFrom:
             fieldRef:
               fieldPath: metadata.name
        - name: EKS_LOGS_METADATA_ON
          value: "true"
        - name: EKS_LOGS_LOG_PATHS
          value: stdout,/tmp/busy*.log
        image: busybox:latest
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello world; date; echo hello >> /tmp/busy.log; sleep 1; done"]
        imagePullPolicy: Always
        name: while
        resources:
          requests:
            cpu: 250m
            memory: 512Mi

Field description:

Field Name	Description
EKS_LOGS_OUTPUT_TYPE	The consumer end can be kafka or CLS. The key indicates whether log collection is enabled.
EKS_LOGS_LOG_PATHS	Log path. It supports stdout (collection standard output) and absolute path. It also supports wildcard (*). If multiple paths are specified, separate them with “,”.
EKS_LOGS_METADATA_ON	Valid values: `true` or `false`. Default value: `true`.
EKS_LOGS_KAFKA_TOPIC	Log topic
EKS_LOGS_KAFKA_BROKERS	kafka brokers: ip1:port1, ip1:port2, and ip2:port2 formats, separated by “,”. Use this environmental variable for external application. EKS_LOGS_KAFKA_HOST will no longer be visible to external users.
EKS_LOGS_KAFKA_MESSAGE_KEY	Optional. A key can be specified to deliver the log to the specified partition. If the delivery by key is not enabled, logs will be randomly delivered to different partitions. If the delivery by key is enabled, logs with the same key will be delivered to the same partition. Note: Here the key gets the variable value from the field of the Pod. The above examples all take the Pod name as an example, and it also supports namespace, PodIP, etc. For more information, see Kubernetes Documentation.

Verify whether the delivery by key is enabled, as shown below:

If it is not enabled, the key is not displayed in the message details, as shown below:
If it is enabled, the key is displayed in the message details, as shown below:

Creating a secret

Note

The following sample is to manually create a secret through yaml. If you create a secret through the console, you do not need to perform 64 encoding. For more information, see Secret Management.

Run the following command via kubectl to obtain the secretid and secretkey for base64 encoding. Replace secretid and secretkey with the actual secretid and secretkey that you use. For more information, see API Keys.

$ echo -n 'secretid' | base64
c2VjcmV0aWQ=
$ echo -n 'secretkey' | base64
c2VjcmV0a2V5

Manually create a secret via yaml. Specify secretid and secretkey based on the values obtained in the step of Creating a secret.

apiVersion: v1
kind: Secret
metadata:
  name: secretidkey
data:
  secretid: 
  secretkey:

Creating a deployment

Enable log collection by adding environment variables.

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    k8s-app: cls
    qcloud-app: cls
  name: cls
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: cls
      qcloud-app: cls
  template:
    metadata:
      annotations:
        eks.tke.cloud.tencent.com/cpu: "0.25"
        eks.tke.cloud.tencent.com/mem: "0.5Gi"
      labels:
        k8s-app: cls
        qcloud-app: cls
    spec:
      containers:
      - env:
        - name: EKS_LOGS_OUTPUT_TYPE
          value: cls
        - name: EKS_LOGS_LOGSET_NAME
          value: eks
        - name: EKS_LOGS_TOPIC_ID
          value: 617c8270-e8c8-46e2-a90b-d94c4bebe519
        - name: EKS_LOGS_SECRET_ID
          valueFrom:
            secretKeyRef:
              name: secretidkey
              key: secretid
        - name: EKS_LOGS_SECRET_KEY
          valueFrom:
            secretKeyRef:
              name: secretidkey
              key: secretkey
        - name: EKS_LOGS_LOG_PATHS
          value: stdout,/tmp/busy*.log
        - name: EKS_LOGS_METADATA_ON
          value: "true"
        image: busybox:latest
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello world; date; echo hello >> /tmp/busy.log; sleep 1; done"]
        imagePullPolicy: Always
        name: hello
      - env:
        - name: EKS_LOGS_OUTPUT_TYPE
          value: cls
        - name: EKS_LOGS_LOGSET_NAME
          value: eks
        - name: EKS_LOGS_TOPIC_ID
          value: 617c8270-e8c8-46e2-a90b-d94c4bebe519
        - name: EKS_LOGS_SECRET_ID
          valueFrom:
            secretKeyRef:
              name: secretidkey
              key: secretid
        - name: EKS_LOGS_SECRET_KEY
          valueFrom:
            secretKeyRef:
              name: secretidkey
              key: secretkey
        - name: EKS_LOGS_LOG_PATHS
          value: stdout,/tmp/busy*.log
        - name: EKS_LOGS_METADATA_ON
          value: "true"
        image: busybox:latest
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello world; date; echo hello >> /tmp/busy.log; sleep 1; done"]
        imagePullPolicy: Always
        name:world

Field description:

Field Name	Description
EKS_LOGS_OUTPUT_TYPE	The consumer end can be kafka or CLS. The key indicates whether log collection is enabled.
EKS_LOGS_LOG_PATHS	Log path. It supports stdout (collection standard output) and absolute path. It also supports wildcard (*). If multiple paths are specified, separate them with “,”.
EKS_LOGS_METADATA_ON	Valid values: `true` or `false`. Default value: `true`.
EKS_LOGS_LOGSET_NAME	CLS logset name
EKS_LOGS_TOPIC_ID	CLS logset topic ID
EKS_LOGS_SECRET_ID	SecretId
EKS_LOGS_SECRET_KEY	SecretKey

Step 1: Creating a role

Creating a policy
You need to create a policy before creating a role. This policy determines the permissions your role can have.

Log in to the CAM console and select Policies in the left sidebar.
On the “Polices” page, click Create custom policy.
Select Create by policy generator in “Select policy creation method” pop-up window.
In the “Visual Policy Generator”, select Cloud Log Service (cls) for Service, and select Write: pushLog for Action.
Click Next to go to the “Associate users/user groups” page.
Confirm the policy name and click Done.

Creating a role
After creating a policy, you need to bind this policy to a role, so that the role has permissions corresponding to the policy.

Log in to the CAM console, and select Roles in the left sidebar.
On the “Roles” page, click Create role.
In the “Select role entity” window that appears, select Tencent Cloud Product Service to go to the “Create custom role” page.
In the “Enter role entity info” step, select Cloud Virtual Machine (cvm) and click Next.

Note

You must select Cloud Virtual Machine (cvm) as the role entity, otherwise, you cannot complete the authorization process.
In the “Configure role policy” step, select Created policy, and click Next.
In the “Review” step, enter the role name to review the role information, and then click Done. For more information, see Creating a Role.

After creating a role, you need to add annotation, specify the role name, and obtain the permission policy contained in the role in the Pod template.

template:
  metadata:
    annotations:
      eks.tke.cloud.tencent.com/role-name: "eks-pushlog"

Step 2: Creating a Deployment

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    k8s-app: cls
    qcloud-app: cls
  name: cls
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: cls
      qcloud-app: cls
  template:
    metadata:
      annotations:
        eks.tke.cloud.tencent.com/cpu: "0.25"
        eks.tke.cloud.tencent.com/mem: "0.5Gi"
        eks.tke.cloud.tencent.com/role-name: "eks-pushlog"
      labels:
        k8s-app: cls
        qcloud-app: cls
    spec:
      containers:
      - env:
        - name: EKS_LOGS_OUTPUT_TYPE
          value: cls
        - name: EKS_LOGS_LOGSET_NAME
          value: eks
        - name: EKS_LOGS_TOPIC_ID
          value: 617c8270-e8c8-46e2-a90b-d94c4bebe519
        - name: EKS_LOGS_LOG_PATHS
          value: stdout,/tmp/busy*.log
        - name: EKS_LOGS_METADATA_ON
          value: "true"
        image: busybox:latest
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello world; date; echo hello >> /tmp/busy.log; sleep 1; done"]
        imagePullPolicy: Always
        name: hello
      - env:
        - name: EKS_LOGS_OUTPUT_TYPE
          value: cls
        - name: EKS_LOGS_LOGSET_NAME
          value: eks
        - name: EKS_LOGS_TOPIC_ID
          value: 617c8270-e8c8-46e2-a90b-d94c4bebe519
        - name: EKS_LOGS_LOG_PATHS
          value: stdout,/tmp/busy*.log
        - name: EKS_LOGS_METADATA_ON
          value: "true"
        image: busybox:latest
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello world; date; echo hello >> /tmp/busy.log; sleep 1; done"]
        imagePullPolicy: Always
        name: world

Field description:

Field Name	Description
EKS_LOGS_OUTPUT_TYPE	The consumer end can be kafka or CLS. The key indicates whether log collection is enabled.
EKS_LOGS_LOG_PATHS	Log path. It supports stdout (collection standard output) and absolute path. It also supports wildcard (*). If multiple paths are specified, separate them with “,”.
EKS_LOGS_METADATA_ON	Valid values: `true` or `false`. Default value: `true`.
EKS_LOGS_LOGSET_NAME	CLS logset name
EKS_LOGS_TOPIC_ID	CLS logset topic ID

Updating the log collection

You can update log collection in the console or via yaml. Please refer to the following directions:

Updating log collection in the console
Updating log collection via yaml

Log in to the TKE console and click Cluster in the left sidebar.
On the cluster management page, click the ID of the target Serverless cluster to enter the cluster details page.
Choose Workload on the left, find the row of the desired workload for which you want to update log collection, and click Update Pod configuration > Advanced settings on the right to modify configurations.
Click Done to complete the process.

FAQs

If you have any questions, please refer to Log Collection FAQs. If your question remains unresolved, please Contact Us.

Contact Us

Contact our sales team or business advisors to help your business.

Technical Support

Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

7x24 Phone Support

tencent cloud

Recent Pages

Using Environment Variables to Configure Log Collection

Overview

Notes

Prerequisite

Directions

Configuring log collection in the console

Configuring log collection via yaml

Creating a secret

Creating a deployment

Step 1: Creating a role

Step 2: Creating a Deployment

Updating the log collection

FAQs

Was this page helpful?

Was this page helpful?

tencent cloud

Sign Up

Log in

Recent Pages

Using Environment Variables to Configure Log Collection

Overview

Notes

Prerequisite

Directions

Configuring log collection in the console

Configuring log collection via yaml

Creating a secret

Creating a deployment

Step 1: Creating a role

Step 2: Creating a Deployment

Updating the log collection

FAQs

Was this page helpful?

Was this page helpful?