Collecting Logs from Multiple Channels to LTS

Applications Scenarios

This practice uses a food take-out and delivery platform as an example. This platform allows order foods via websites, apps, WeChat, and Alipay. Once restaurants confirm and prepare the orders, the platform notifies nearby delivery drivers, 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.

• Collecting Promotion Logs
• Collecting Device User Logs
• Collecting Server Logs
• Collecting Logs from Various Network Environments

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 drivers
   • 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:

• Applications output logs to hard disks, and ICAgent collects logs. For details, see Ingesting ECS Text Logs to LTS.
• Application logs are written to LTS via SDKs. 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 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.