Help Center/ Log Tank Service/ Best Practices/ Log Ingestion/ Collecting Logs from Multiple Channels to LTS
Updated on 2025-09-26 GMT+08:00

Collecting Logs from Multiple Channels to LTS

Log ingestion is the process of collecting log data generated during the running of applications or services and storing the data to specified locations for subsequent analysis and use. Log data includes system running status, error information, and user operation records. Log data is important for system O&M, troubleshooting, and service analysis.

LTS enables real-time log ingestion via various methods. Logs can be collected using ICAgent, ingested from cloud services, or reported to LTS via custom software, APIs, or SDKs, meeting requirements in different scenarios.

  • More than 40 Huawei Cloud services
  • Web, iOS, Android, and applets
  • Open-source software, such as Logstash, Flume, and Beats
  • Standard protocols, such as HTTP, HTTPS, syslog, and Kafka

Applications Scenarios

This practice uses a food take-out and delivery platform as an example. Customers can place orders through its website, mobile app, WeChat, and Alipay. Once restaurants confirm and prepare the orders, the platform dispatches notifications to nearby delivery personnel, who then deliver the foods to customers.

During data-based operations, data collection is challenging for the following reasons:

  • Multiple channels: Data is scattered across channels, including advertisers and promoters.
  • Various devices: Data comes from websites, official accounts, mobile phones, browsers (web and mobile pages), etc.
  • Heterogeneity: Data sources include VPCs, customer-built IDCs, and Huawei Cloud ECSs.
  • Multiple development languages: Different languages are used, with Java for the core system, Nginx for the frontend server, and C++ for the backend payment system.
  • Diverse architectures: Restaurant devices run on both x86 and Arm.

In this case, you can use LTS to collect internal and external logs for central management.

Centrally Managing Logs

  1. On the LTS console, create a log group. For details, see Managing Log Groups.
  2. Create log streams for logs generated by different data sources. For details, see Managing Log Streams. The following log streams are for reference only.
    • wechat-server for storing WeChat server access logs
    • wechat-app for storing WeChat server application logs
    • wechat-error for storing error logs
    • alipay-server
    • alipay-app
    • deliver-app for storing the app statuses of delivery personnel
    • deliver-error for storing error logs
    • web-click for storing logs of HTML5 page clicks
    • server-access for storing server-side access logs
    • server-app for storing server application logs
    • coupon for storing application coupon logs
    • pay for storing payment logs
    • order for storing order logs

Collecting Promotion Logs

Restaurants usually use the following promotion ways:

  • Issue coupons when customers sign up.
  • Distribute coupons via QR codes on flyers, web pages or other channels.

Before promotion, set the following registration server address to generate a QR code for flyers or web pages. When a customer scans the QR code for registration, the platform recognizes that the customer is accessing it from the specific source and records a log.

http://example.com/login?source=10012&ref=kd4b

When the server side receives a request, the server generates a log like the following one:

2024-06-20 19:00:00 e41234ab342ef034,102345,5k4d,467890

Promotion logs can be collected in the following ways:

Collecting Server-Side Data

Alipay and WeChat public account programming is of typical web mode. Generally, it involves four types of logs. You can use LTS SDKs to report these logs. For details, see LTS Alipay Applet SDK and LTS WeChat Applet SDK. The following example logs are for reference only.

  • Nginx and Apache access logs

    Nginx and Apache access logs are used for monitoring and real-time statistics.

    10.1.168.193 - - [01/Mar/2024:16:12:07 +0800] "GET /Send?AccessKeyId=8225105404 HTTP/1.1" 200 5 "-" "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2"
  • Nginx and Apache error logs
    2024/04/18 18:59:01 [error] 26671#0: *20949999 connect() to unix:/tmp/fastcgi.socket failed (111: Connection refused) while connecting to upstream, client: 10.101.1.1, server: , request: "POST /logstores/test_log HTTP/1.1", upstream: "fastcgi://unix:/tmp/fastcgi.socket:", host: "example.com" 
  • Application-layer logs

    An application-layer log records the time, location, result, and parameters of an event, with extended fields placed at the end.

    {"labels":{"cccdasd":51,"platform":"wx"},"logs":[{"contents":[{"aaa":"13123","__client_time__":1728565099070}]}]}
  • Application layer error logs
    {"errorCode":"LTS.403","errorMessage":" request header auth is empty"}

You can use the following methods to collect server-side data:

  • Create a log collection task to write logs to a specified log stream.
  • Ingest CCE logs to LTS to collect logs generated in Docker. For details, see Ingesting CCE Application Logs to LTS.
  • Use SDKs to write C#, Python, Java, PHP, and C logs into LTS. For details, see SDK Overview.

Collecting Device User Logs

LTS collects logs from various devices, including web browsers, iOS, Android, Baidu applets, WeChat applets, DingTalk applets, and quick apps. You can quickly integrate LTS's mobile SDKs to your devices to enable functions such as cache sending, retry upon exceptions, and batch sending.

Collection solution:

  • Mobile devices: Use iOS and Android SDKs to ingest logs.
  • Arm devices: Use Native C for cross compilation.
  • Restaurant devices: Use SDKs for x86 devices, and Native C for cross compilation for Arm devices.

You can use the following methods to collect device user logs:

  • Create a log collection task to write logs to a specified log stream.
  • Ingest CCE logs to LTS to collect logs generated in Docker. For details, see Ingesting CCE Application Logs to LTS.
  • Use SDKs to write C#, Python, Java, PHP, and C logs into LTS. For details, see SDK Overview.

Collecting User Behavior Logs from Web and Mobile Pages

User behavior logs from web and mobile pages are classified into the following types:

  • Logs that record interactions between the pages and back-end servers, such as, order placement, login, and logout
  • Logs that record page interactions (not involving back-end servers), including requests processed on the front end, such as screen scrolling and page closing

Use anonymous write to collect user behavior logs from web and mobile pages. For details, see Using Anonymous Write to Collect Logs. The anonymous write function is available only to whitelisted users in regions CN North-Beijing4, CN East-Shanghai1, and CN South-Guangzhou. To use it, submit a service ticket.

Collecting Server Logs

The following server logs are for reference only.

  • Syslog logs
    Aug 31 11:07:24 zhouqi-mac WeChat[9676]: setupHotkeyListenning event NSEvent: type=KeyDown loc=(0,703) time=115959.8 flags=0 win=0x0 winNum=7041 ctxt=0x0 chars="u" unmodchars="u" repeat=0 keyCode=32
  • Application debug logs
    __FILE__:build/release64/sls/shennong_worker/ShardDataIndexManager.cpp
    __LEVEL__:WARNING
    __LINE__:238
    __THREAD__:31502
    offset:816103453552
    saved_cursor:1469780553885742676
    seek count:62900
    seek data redo
    log:pangu://localcluster/redo_data/41/example/2016_08_30/250_1472555483
    user_cursor:1469780553885689973
  • Trace logs
    [2013-07-13 10:28:12.772518]    [DEBUG] [26064]  __TRACE_ID__:661353951201    __item__:[Class:Function]_end__  request_id:1734117   user_id:124 context:.....

You can use the following methods to collect server logs:

  • Create a log collection task to write logs to a specified log stream.
  • Ingest CCE logs to LTS to collect logs generated in Docker. For details, see Ingesting CCE Application Logs to LTS.
  • Use SDKs to write C#, Python, Java, PHP, and C logs into LTS. For details, see SDK Overview.

Collecting Logs from Various Network Environments

LTS provides access points in each region, enabling three access methods:

  • Intranet (classic network): Cloud services in the same region as LTS can access LTS via the intranet, which features high-bandwidth links and is the recommended method.
  • Public network (classic network): Any access is allowed. The access speed depends on the link quality. In this case, HTTPS is recommended for transmission security.
  • Private network (VPC): Cloud services in the same region as LTS can access LTS through VPCs.