Ingesting CCE Application Logs to LTS
CCE provides highly scalable, high-performance, enterprise-class Kubernetes clusters. With CCE, you can easily deploy, manage, and scale containerized applications.
After ingesting CCE logs to LTS, you can centrally manage and analyze them and visualize log reports on the LTS console. This helps you better monitor and manage containerized application running, promptly detect container issues, and improve container performance and reliability.
Perform the following steps to complete the ingestion configuration:
- Step 1: Select a Log Stream
- Step 2: Check Dependencies
- Step 3: (Optional) Select a Host Group
- Step 4: Configure the Collection
- Step 5: Configure Indexing
- Step 6: Complete the Ingestion Configuration
To collect logs from multiple scenarios, set multiple ingestion configurations in a batch.
Prerequisites
- ICAgent has been installed in the CCE cluster and a host group with custom identifiers has been created for related nodes. The system will automatically check these configurations and make necessary corrections when CCE logs are ingested to LTS.
- If you use AOM 2.0 for the first time, authorize it by referring to Subscribing to AOM 2.0. Then, log in to the AOM 2.0 console, grant AOM 2.0 the permission to access data of cloud services, such as LTS and CCE, by referring to Cloud Service Authorization.
- On the Hosts page, select CCE Clusters, select the target cluster in the search box, and click Upgrade ICAgent. For details, see Upgrading ICAgent.
- You have disabled Output to AOM.
- You have enabled ICAgent Diagnosis to view exceptions, overall status, and collection status of ICAgent. For details, see Setting ICAgent Collection.
Restrictions
- CCE cluster nodes whose container engine is Docker are supported. For details, see Cloud Container Engine (CCE).
- CCE cluster nodes whose container engine is Containerd are supported. You must be using ICAgent 5.12.130 or later.
- CCE Turbo clusters are supported. You must be using ICAgent 5.12.130 or later.
- To collect container log directories mounted to host directories to LTS, you must configure the node file path.
- Restrictions on the Docker storage driver: Currently, container file log collection supports only the overlay2 storage driver. devicemapper cannot be used as the storage driver. Run the following command to check the storage driver type:
docker info | grep "Storage Driver"
- If you select Fixed log stream for log ingestion, ensure that you have created a CCE cluster.
Step 1: Select a Log Stream
- Log in to the LTS console.
- Choose Log Ingestion > Ingestion Center in the navigation pane. Then, click CCE (Cloud Container Engine).
Alternatively, choose Log Ingestion > Ingestion Management in the navigation pane, and click Ingest Log > CCE (Cloud Container Engine).
Alternatively, choose Log Management in the navigation pane and click the target log stream to access its details page. Click in the upper right corner. On the displayed page, click the Log Ingestion tab and click Ingest Log. In the displayed dialog box, click CCE (Cloud Container Engine).
- Choose a collection mode between Fixed log stream (recommended) and Custom log stream.
- If you set Collect to Fixed log stream, perform the following steps:
Logs will be collected to a fixed log stream. The default log streams for a CCE cluster are stdout-{ClusterID} for standard output/errors, hostfile-{ClusterID} for node files, event-{ClusterID} for Kubernetes events, and containerfile-{ClusterID} for container files. Log streams are automatically named with a cluster ID. For example, if the cluster ID is Cluster01, the standard output/error log stream is stdout-Cluster01.
Log streams that can be created for a CCE cluster are stdout-{ClusterID} for standard output/errors, hostfile-{ClusterID} for node files, event-{ClusterID} for Kubernetes events, and containerfile-{ClusterID} for container files. If one of them has been created in a log group, the log stream will no longer be created in the same log group or other log groups.
- Select a cluster from the CCE Cluster drop-down list.
- The default log group is k8s-log-ClusterID. For example, if the cluster ID is c7f3f4a5-bcb8-11ed-a4ec-0255ac100b07, the default log group will be k8s-log-c7f3f4a5-bcb8-11ed-a4ec-0255ac100b07.
If there is no such group, the system displays the following message: This log group does not exist and will be automatically created to start collecting logs.
- Click Next: Check Dependencies.
- If you set Collect to Custom log stream, perform the following steps:
- Select a cluster from the CCE Cluster drop-down list.
- Select a log group from the Log Group drop-down list. If there are no desired log groups, click Create Log Group to create one.
- Select a log stream from the Log Stream drop-down list. If there are no desired log streams, click Create Log Stream to create one.
- Click Next: Check Dependencies.
- If you set Collect to Fixed log stream, perform the following steps:
Step 2: Check Dependencies
The system automatically checks the following items:
- ICAgent has been installed (version 5.12.130 or later).
- There is a host group with the same name and custom identifier k8s-log-ClusterID.
- There is a log group named k8s-log-ClusterID.
- The recommended log stream exists. If Fixed log stream is selected, this item is checked.
- Auto Correct: Check the previous settings with one click.
- Check Again: Recheck dependencies.
- If Custom log stream is selected, the check item There is a log group named k8s-log-ClusterID is optional. Toggle the switch to enable or disable the check.
Step 3: (Optional) Select a Host Group
- In the host group list, select one or more host groups from which you want to collect logs.
- The host group to which the cluster belongs is selected by default. You can also select host groups as required.
- For a host group of CCE clusters, its custom identifier must be in the format of k8s-log-Cluster ID.
- You can also skip this step, but the collection configuration will not take effect. You are advised to select a host group during the first ingestion configuration. If you skip this step, follow either of the following ways to configure host groups after the ingestion configuration is complete:
- Choose Host Management > Host Groups in the navigation pane and associate host groups with ingestion configurations.
- On the Ingestion Rule tab page, click Edit in the Operation column. On the displayed page, select required host groups.
- Click Next: Configurations.
Step 4: Configure the Collection
When CCE is used to ingest logs, the configuration details are as follows:
- Collection Configuration Name: Enter 1 to 64 characters. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. Do not start with a period or underscore, or end with a period.
- Data Source: Select a data source type and configure it. For details, see Table 2.
If multiple hosts are configured to collect logs from the mounted network disk or shared storage at the same time, duplicate logs will be generated.
Table 2 Data source parameters Parameter
Description
Container standard output
Collects stderr and stdout logs of a specified container in the cluster.
NOTE:- The standard output of the matched container is collected to the specified log stream. Standard output to AOM stops.
- The container standard output can be collected to only one log stream.
- Output to AOM: ICAgent has been installed on hosts in the cluster and collects container standard output to AOM only. This function is enabled by default. To collect container standard output to LTS, disable this function.
- At least one of Container Standard Output (stdout) and Container Standard Error (stderr) must be enabled.
- If you enable Container Standard Error (stderr), select your collection destination path: Collect standard output and standard error to different files (stdout.log and stderr.log) or Collect standard output and standard error to the same file (stdout.log).
Container file
Collects file logs of a specified container in the cluster.
- Add Collection Path: Add one or more host paths. LTS will collect logs from these paths. For more examples, see Collection Paths.
NOTE:
- If a container mount path has been configured for the CCE cluster workload, the paths added for this field are invalid. The collection paths take effect only after the mount path is deleted.
- You cannot add the same host path to more than one log stream.
- Add Custom Wrapping Rule: ICAgent determines whether a file is wrapped based on the file name rule. If your wrapping rule does not comply with the built-in rules, you can add a custom wrap rule to prevent log loss during repeated collection and wrapping.
The built-in rules are {basename}{connector}{wrapping identifier}.{suffix} and {basename}.{suffix}{connector}{wrapping identifier}. The connector is -._, the wrapping identifier is a non-letter symbol, and the suffix consists of letters.
A custom wrapping rule consists of {basename} and the feature regular expression of the wrapped file. Example: If your log file name is /opt/test.out.log, and the wrapped file names are test.2024-01-01.0.out.log and test.2024-01-01.1.out.log, the collection path is /opt/*.log and the wrapping rule is {basename}\.[-0-9\.].out.log.
- Files can be collected for multiple times (not available to Windows).
After you enable Allow Repeated File Collection, one host log file can be collected to multiple log streams. This function is available only to certain ICAgent versions. For details, see Checking the ICAgent Version Description.
After you disable this function, each collection path must be unique. That is, the same log file in the same host cannot be collected to different log streams.
- Set Collection Filters: Blacklisted directories or files will not be collected. If you specify a directory, all files in the directory are filtered out.
Node file
Collects files of a specified node in a cluster.
- Add Collection Path: Add one or more host paths. LTS will collect logs from these paths. For more examples, see Collection Paths.
- Add Custom Wrapping Rule: ICAgent determines whether a file is wrapped based on the file name rule. If your wrapping rule does not comply with the built-in rules, you can add a custom wrap rule to prevent log loss during repeated collection and wrapping.
The built-in rules are {basename}{connector}{wrapping identifier}.{suffix} and {basename}.{suffix}{connector}{wrapping identifier}. The connector is -._, the wrapping identifier is a non-letter symbol, and the suffix consists of letters.
A custom wrapping rule consists of {basename} and the feature regular expression of the wrapped file. Example: If your log file name is /opt/test.out.log, and the wrapped file names are test.2024-01-01.0.out.log and test.2024-01-01.1.out.log, the collection path is /opt/*.log and the wrapping rule is {basename}\.[-0-9\.].out.log.
- Files can be collected for multiple times (not available to Windows).
After you enable Allow Repeated File Collection, one host log file can be collected to multiple log streams. This function is available only to certain ICAgent versions. For details, see Checking the ICAgent Version Description.
After you disable this function, each collection path must be unique. That is, the same log file in the same host cannot be collected to different log streams.
- Set Collection Filters: Blacklisted directories or files will not be collected. If you specify a directory, all files in the directory are filtered out.
Kubernetes event
Collects event logs of the Kubernetes cluster. This function is available only to ICAgent 5.12.150 or later.
Kubernetes events of a Kubernetes cluster can be collected to only one log stream.
- (Optional) Kubernetes Matching Rules: Set these parameters only when the data source type is set to Container standard output or Container file.
After entering a regular expression, click Verify to verify it.
Table 3 Kubernetes matching rules Parameter
Description
Namespace Name Regular Expression
Specifies the container whose logs are to be collected based on the namespace name. Regular expression matching is supported.NOTE:LTS will collect logs of the namespaces with names matching this expression. To collect logs of all namespaces, leave this field empty.
Pod Name Regular Expression
Specifies the container whose logs are to be collected based on the pod name. Regular expression matching is supported.
NOTE:LTS will collect logs of the pods with names matching this expression. To collect logs of all pods, leave this field empty.
Container Name Regular Expression
Specifies the container whose logs are to be collected based on the container name (the Kubernetes container name is defined in spec.containers). Regular expression matching is supported.NOTE:LTS will collect logs of the containers with names matching this expression. To collect logs of all containers, leave this field empty.
Label Whitelist
Specifies the containers whose logs are to be collected. If you want to set a Kubernetes label whitelist, Label Key is mandatory and Label Value is optional.
When adding multiple whitelists, you can select the And or Or relationship. This means a container will be matched when it satisfies all or any of the whitelists.
NOTE:If Label Value is empty, LTS will match all containers whose Kubernetes label contains a specified Label Key. If Label Value is not empty, only containers whose Kubernetes label contains a specified Label Key that is equal to its Label Value are matched. Label Key requires full matching while Label Value supports regular matching.
Label Blacklist
Specifies the containers whose logs are not to be collected. If you want to set a Kubernetes label blacklist, Label Key is mandatory and Label Value is optional.
When adding multiple blacklists, you can select the And or Or relationship. This means a container will be excluded when it satisfies all or any of the blacklists.
NOTE:If Label Value is empty, LTS will exclude all containers whose Kubernetes label contains a specified Label Key. If Label Value is not empty, only containers whose Kubernetes label contains a specified Label Key that is equal to its Label Value will be excluded. Label Key requires full matching while Label Value supports regular matching.
Kubernetes Label
After the Kubernetes Label is set, LTS adds related fields to logs.
NOTE:LTS adds the specified fields to the log when each Label Key has a corresponding Label Value. For example, if you enter "app" as the key and "app_alias" as the value, when the container label contains "app=lts", "{app_alias: lts}" will be added to the log.
Container Label Whitelist
Specifies the containers whose logs are to be collected. If you want to set a container label whitelist, Label Key is mandatory and Label Value is optional.
When adding multiple whitelists, you can select the And or Or relationship. This means a container will be matched when it satisfies all or any of the whitelists.
NOTE:If Label Value is empty, LTS will match all containers whose container label contains a specified Label Key. If Label Value is not empty, only containers whose container label contains a specified Label Key that is equal to its Label Value are matched. Label Key requires full matching while Label Value supports regular matching.
Container Label Blacklist
Specifies the containers whose logs are not to be collected. If you want to set a container label blacklist, Label Key is mandatory and Label Value is optional.
When adding multiple blacklists, you can select the And or Or relationship. This means a container will be excluded when it satisfies all or any of the blacklists.
NOTE:If Label Value is empty, LTS will exclude all containers whose container label contains a specified Label Key. If Label Value is not empty, only containers whose container label contains a specified Label Key that is equal to its Label Value will be excluded. Label Key requires full matching while Label Value supports regular matching.
Container Label
After the Container Label is set, LTS adds related fields to logs.
NOTE:LTS adds the specified fields to the log when each Label Key has a corresponding Label Value. For example, if you enter "app" as the key and "app_alias" as the value, when the container label contains "app=lts", "{app_alias: lts}" will be added to the log.
Environment Variable Whitelist
Specifies the containers whose logs are to be collected. If you want to set an environment variable whitelist, Label Key is mandatory and Label Value is optional.
When adding multiple whitelists, you can select the And or Or relationship. This means a container will be matched when it satisfies all or any of the whitelists.
NOTE:If Environment Variable Value is empty, LTS will match all containers whose environment variable contains a specified Environment Variable Key. If Environment Variable Value is not empty, only containers whose environment variable contains a specified Environment Variable Key that is equal to its Environment Variable Value are matched. Label Key requires full matching while Label Value supports regular matching.
Environment Variable Blacklist
Specifies the containers whose logs are not to be collected. If you want to set an environment variable blacklist, Label Key is mandatory and Label Value is optional.
When adding multiple blacklists, you can select the And or Or relationship. This means a container will be excluded when it satisfies all or any of the blacklists.
NOTE:If Environment Variable Value is empty, LTS will exclude all containers whose environment variable contains a specified Environment Variable Key. If Environment Variable Value is not empty, only containers whose environment variable contains a specified Environment Variable Key that is equal to its Environment Variable Value will be excluded. Label Key requires full matching while Label Value supports regular matching.
Environment Variable Label
After the environment variable label is set, the log service adds related fields to the log.NOTE:LTS adds the specified fields to the log when each Environment Variable Key has a corresponding Environment Variable Value. For example, if you enter "app" as the key and "app_alias" as the value, when the Kubernetes environment variable contains "app=lts", "{app_alias: lts}" will be added to the log.
- Enable structuring parsing. For details, see Setting ICAgent Structuring Parsing Rules.
LTS enables combined parsing, allowing you to create different structuring parsing rules for each collection configuration of a log stream.
If you have configured cloud structuring parsing, delete its configurations before configuring ICAgent structuring parsing.
Figure 1 ICAgent structuring parsing configuration
- Set other configurations.
- Configure the log format and time by referring to Table 5.
The following functions are no longer recommended. Use structuring parsing instead.
Table 5 Log collection settings Parameter
Description
Log Format
- Single-line: Each log line is displayed as a single log event.
- Multi-line: Multiple lines of exception log events can be displayed as a single log event. This is helpful when you check logs to locate problems.
Log Time
System time: log collection time by default. It is displayed at the beginning of each log event.
NOTE:- Log collection time is the time when logs are collected and sent by ICAgent to LTS.
- Log printing time is the time when logs are printed. ICAgent collects and sends logs to LTS with an interval of 1 second.
- Restriction on log collection time: Logs are collected within 24 hours before and after the system time.
Time wildcard: You can set a time wildcard so that ICAgent will look for the log printing time as the beginning of a log event.
- If the time format in a log event is 2019-01-01 23:59:59.011, the time wildcard should be set to YYYY-MM-DD hh:mm:ss.SSS.
- If the time format in a log event is 19-1-1 23:59:59.011, the time wildcard should be set to YY-M-D hh:mm:ss.SSS.
NOTE:If a log event does not contain year information, ICAgent regards it as printed in the current year.
Example:
YY - year (19) YYYY - year (2019) M - month (1) MM - month (01) D - day (1) DD - day (01) hh - hours (23) mm - minutes (59) ss - seconds (59) SSS - millisecond (999) hpm - hours (03PM) h:mmpm - hours:minutes (03:04PM) h:mm:sspm - hours:minutes:seconds (03:04:05PM) hh:mm:ss ZZZZ (16:05:06 +0100) hh:mm:ss ZZZ (16:05:06 CET) hh:mm:ss ZZ (16:05:06 +01:00)
Log Segmentation
This parameter needs to be specified if the Log Format is set to Multi-line. By generation time indicates that a time wildcard is used to detect log boundaries, whereas By regular expression indicates that a regular expression is used.
Regular Expression
You can set a regular expression to look for a specific pattern to indicate the beginning of a log event. This parameter needs to be specified when you select Multi-line for Log Format and By regular expression for Log Segmentation.
The time wildcard and regular expression will look for the specified pattern right from the beginning of each log line. If no match is found, the system time, which may be different from the time in the log event, is used. In general cases, you are advised to select Single-line for Log Format and System time for Log Time.
Step 5: Configure Indexing
- (Optional) Configure indexing. For details, see Setting Indexes.
- Click Submit.
Step 6: Complete the Ingestion Configuration
- Click its name to view its details.
- Click Edit in the Operation column to modify the ingestion configuration.
- Click Configure Tag in the Operation column to add a tag.
- Click Copy in the Operation column to copy the ingestion configuration.
- Click Delete in the Operation column to delete the ingestion configuration.
- Click ICAgent Collect Diagnosis in the Operation column of the ingestion configuration to monitor the exceptions, overall status, and collection status of ICAgent.
Setting Multiple Ingestion Configurations in a Batch
You can set multiple ingestion configurations for multiple scenarios in a batch, avoiding repetitive setups.
- On the Ingestion Management page, click Batch Ingestion to go to the details page. For details, see Table 6.
Table 6 Adding configurations in batches Type
Parameter
Description
Basic Settings
Ingestion Type
Select CCE (Cloud Container Engine).
Configurations to Add
Enter the number of ingestion configurations in the text box and click Add.
A maximum of 100 ingestion configurations can be added, including the one already exists under Ingestion Settings by default. Therefore, you can add up to 99 more.
Ingestion Settings
Configuration List
- The ingestion configurations are displayed on the left. You can add up to 99 more configurations.
- The ingestion configuration details are displayed on the right. Set them by referring to Step 4: Configure the Collection.
- After an ingestion configuration is complete, you can click Apply to Other Configurations to copy its settings to other configurations.
- Click Check Parameters. After the check is successful, click Submit.
The added ingestion configurations will be displayed on the Ingestion Rule tab page after the batch creation is successful.
- (Optional) Perform the following operations on ingestion configurations:
- Select multiple existing ingestion configurations and click Edit. On the displayed page, select an ingestion type to modify the corresponding ingestion configurations.
- Select multiple existing ingestion configurations and click Enable or Disable. If you toggle off the switch in the Status column of an ingestion configuration, logs will not be collected for this configuration.
- Select multiple existing ingestion configurations and click Delete.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot