Cloud Log Service (CLS) provides a one-stop log data solution. You can quickly and conveniently connect to it in five minutes to enjoy a full range of stable and reliable services from log collection, storage, and processing to search, analysis, consumption, shipping, dashboard generation, and alarming, with no need to care about resource issues such as scaling. It helps you improve the problem locating and metric monitoring efficiency in an all-around manner, making log Ops much easier.
CLS has the following features.
Logs are record data generated during the running of an application system, such as user operation logs, API access logs, and system error logs. Logs are usually stored in text format on the host where the application system resides. A log corresponding to a system running record may contain one line of text (single-line log) or multiple lines of text (multi-line log).
For more information and examples, see Log and Log Group.
CLS provides the log lifecycle management feature. You can set the log validity period to 1–3,600 days or permanent when creating a log topic. Once expired, the data will be cleared and no longer incur storage fees.
A log topic is a basic unit for log data collection, storage, search and analysis on the CLS platform. The massive amounts of logs collected are managed by log topic. For example, you can configure log collection rules and storage time, search for and analyze logs, and download, consume, and ship logs by log topic.
A logset is a class of log topics and can contain multiple log topics. A logset itself does not store any log data, but just makes it easier for users to manage log topics.
For more information and examples, see Log Topic and Logset.
To collect high numbers of logs, a single topic contains multiple partitions, each of which has up to 500 write QPS and 5 MB/s write traffic. If there are many logs to be collected, we recommend you enable the automatic partition splitting feature (which is enabled by default). A single log topic can contain up to 50 partitions and thus has up to 50 * 500 = 25000 write QPS and 50 * 5 = 250 MB/s write traffic.
Here, the write request quantity and write traffic are not simply equal to the number of logs and log volume respectively. As multiple logs will be packaged and compressed into a log group during log upload, the actually supported number of logs and log volume are far greater than the above values. Logs will be automatically packaged and compressed if you use LogListener, so you don't need to care about the specific packaging policy.
Index configuration is necessary for log search and analysis in CLS. Only after index is enabled can CLS search for and analyze logs. Index creation is to split a raw log into multiple segments with the specified symbol and add an inverted index to such segments.
For more information and examples, see Segment and Index.
errormeans to search for logs that contain the keyword
level:errormeans to search for logs with a
levelfield whose value contains
For more information and examples, see Configuring Indexes.
status:404to search for application request logs whose response status code is 404.
status:404 | select count(*) as logCountsto get the number of application request logs whose response status code is 404.
For more information and examples, see Overview and Syntax Rules.
The delay is within one minute if LogListener is used for log collection. If an API or SDK is used to collect logs, it takes no more than one minute for logs to become searchable after API call.
Yes. CLS has no restrictions on the log source. You can collect logs to CLS as long as the log source can be connected to CLS over the network. For specific regions supported by CLS and corresponding domain names, see Available Regions.
/etc/loglistener.conf file under the LogListener installation directory. Here, the
/user/local installation directory is used as an example:
Press i to enter the edit mode.
Enter the changed IP address in
group_ip in the configuration file.
Press Esc, enter :wq, and press Enter to save the configuration and exit the editor.
Run the following command to restart LogListener.
Log in to the CLS console and select Machine Group Management on the left sidebar. Locate the machine group to which the server is bound and click Edit. In the pop-up window, replace the old IP address with the new one and click OK.
Case 1: The page displays "Message sending failed".
Hover over the "Message sending failed" message to view the error code and detailed failure cause. Common error codes are as listed below:
|Error Code||Description||Troubleshooting Method|
|-1004||Message sending via this notification channel failed.||This is generally because no mobile numbers or email addresses have been configured or verified for all recipients or recipient groups. You can view and configure them in the user list.|
|-1005||Some messages failed to be sent via notification channels; for example, messages failed to be sent to some users or via some notification channels.||This is generally because no mobile numbers or email addresses have been configured or verified for some recipients or recipient groups. You can view and configure them in the user list.|
|-1006||The custom API callback reported an error.||Troubleshoot based on the specific failure cause. Common errors include:
Case 2: The page displays "Sent", but the testing message is not received.
Common reasons of different receipt channels are as listed below:
|Email, SMS, and phone||To avoid disturbing users with repeated notifications, only one testing message can be sent to the same user via each channel per day.|
|Custom API callback (DingTalk and Lark bot addresses)||The testing message didn't meet DingTalk or Lark's API requirements and was ignored. In this case, the feature of the testing notification channel is meaningless. You can directly configure the appropriate request headers and content in the alarm policy according to DingTalk and Lark's API requirements to send alarm messages.|
|Custom API callback (other addresses)||CLS determines whether a message was sent successfully based on the HTTP response status code. Check whether the custom API has other business logic limits while the HTTP response status code is normal.|