edit-icon download-icon

マルチチャネルデータの収集

最終更新日: Dec 12, 2017

ログサービス LogHub 機能は、リアルタイムのデータ収集と使用をサポートします。リアルタイム収集機能は 30 以上の収集方法をサポートします。

データは、通常、下記のように 2 つの異なる方法で収集されます。このドキュメントでは、主に LogHub ストリーミングインポート(リアルタイム)によるデータ収集について説明します。

メソッド 長所 短所
バッチインポート 過去のデータに焦点を当てた大量のスループット リアルタイムのパフォーマンスが低い FTP、OSS アップロード、メーリングハードドライブ、SQL データエクスポート
ストリーミングインポート リアルタイム、WYSIWYG(what you see is what you get)、リアルタイムデータに焦点 収集端末に関するより高い要求 Loghub、HTTP アップロード、IOT およびキュー

背景

“I Want Take-away”は、ユーザー、レストラン、宅配業者を含む独自のプラットフォームを備えた電子商取引のウェブサイトです。ユーザーは、Web ページ、App、WeChat、Alipay を使用して商品の注文を行うことができます。注文を受けると、店側がその商品の準備を開始し、近くの宅配業者に自動的に通知されます。次に、宅配業者のうちの 1 人が商品を受け取り商品をユーザーに届けます。

1

動作要件

操作中に、以下の問題が分かりました。

  • ユーザーを獲得することが難しい。さまざまなマーケティングチャネル(ウェブページ広告やプッシュメッセージ)に多額の広告投資があったにもかかわらず、新しいユーザーの追加を除いて、これらのチャネルの効果を評価することができない
  • ユーザーはしばしば配信が遅いと苦情を言うが、なぜ遅くなるのでしょうか。発注、流通、または食品の準備?どのように改善する
  • ユーザ運営チームは、クーポンを付与するなどいくつかの宣伝を企画したが、役に立たなかった
  • スケジューリングの観点から、商店街でピーク時に食料を手に入れる方法を考える。特定の地域にもっと宅配便を送るには
  • 顧客サービスの観点から、注文をしなかったことをユーザーが報告したとき、どの操作を実行したか、システムエラーがあったか

データ収集の課題

デジタル操作では、最初に分散ログデータを一元的に収集し、解析しますが、いくつかの課題があります。

  • 複数のチャンネル:広告主、ストリートプロモーション(チラシ)など
  • 複数の端末:ウェブページ、公式のソーシャルメディアアカウント、携帯電話、ウェブブラウザ(デスクトップおよびモバイルウェブサイト)
  • 異種端末ネットワーク:VPC、ユーザー作成の IDC、Alibaba Cloud ECS など
  • 様々な開発言語:コアシステム用の Java、フロントエンド用の Nginx サーバ、バックエンド決済システム用の C++ など
  • デバイス:販売者の端末はさまざまなプラットフォーム(X86、ARMなど)で動作するなど

一元的に管理するには社内外に配布されたログを収集する必要があります。過去においては、これは大規模で複雑な作業でしたが今では統一アクセスのためにLogHub の収集機能を使用することができます。

multi-logs

統一されたログ管理と設定

  1. MyOrder などのログ管理プロジェクトを作成します。
  2. 異なるデータソースから生成されたログのログライブラリ LogStore を作成します。たとえば:
    • Wechat-server(WeChatサーバーアクセスログを格納するため)
    • Wechat-app(WeChatサーバーアプリケーションログを格納するため)
    • WeChat-error(エラーログ)
    • alipay-server
    • alipay-app
    • 配信アプリ(宅配アプリのステータス)
    • 配信エラー(エラーログ)
    • ウェブクリック(H5ウェブページのクリック)
    • サーバーアクセス(サービス側アクセスログ)
    • Server-app(アプリケーション)
    • クーポン(アプリケーションクーポンログ)
    • 支払い(支払いログ)
    • 注文(注文ログ)
  3. たとえば、生データに対して ETL ジョブをクリーンアップして実行する必要がある場合は、いくつかの中間ログストアを作成できます。

その他の操作については、クイックスタート/管理コンソール を参照してください。

ユーザープロモーションログの収集

新規ユーザーを獲得するには、2 つの一般的な方法があります。

  • ウェブサイトのサインアップ時にクーポンを直接渡す
  • QR コードを他のチャンネルでスキャンするためのクーポンを提供する
    • リーフレットの QR コード
    • ログインするWebページ上の QR コードをスキャンする

実装

次のサインアップサーバーのリンクを定義し、ユーザーがスキャンしてサインアップするためのチラシと Web ページ用のQRコードを生成します。ユーザーがウェブページ上の QR コードをスキャンしてサインアップすると、ユーザーを特定のソースから特定し、それに従ってログを作成することができます。

  1. http://examplewebsite/login?source=10012&ref=kd4b

要求を受信すると、サーバーは次のログを提供します。

  1. 2016-06-20 19:00:00 e41234ab342ef034,102345,5k4d467890

上記のコマンドでは:

  • 時間:登録の時間。
  • セッション:行動追跡のために使用される現在のブラウザセッション。
  • ソース:ソースチャンネル。たとえば、キャンペーンAには「10001」、チラシ「10002」、エレベータ広告「10003」というラベルが付けられています。
  • 参照:紹介アカウント。他の誰かがユーザーに登録を推奨するかどうかを示します。存在しない場合は空白にします。
  • Params:その他のパラメータ。

収集メソッド:

  • アプリケーションはログをハードドライブにエクスポートします。これらはLogtail Collectionで収集されます。
  • アプリケーションはSDKを介してログを書き込みます。 SDKを参照してください。

サービス側のデータ収集

Alipay / WeChat 公式アカウントプログラミングは一般的に 3 つのタイプのログを利用する典型的な Web サイドモデルです:

  • Nginx / Apache アクセスログ:監視およびリアルタイム統計に使用されます

    1. 10.1.168.193 - - Mozilla/5.0X11; x86_64Linux i686; rv 10.0.2Gecko/20100101 Firefox/ 10.0.2 "
  • Nginx/Apache のエラーログ:

    1. 2016/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: "ali-tianchi-log.cn-hangzhou-devcommon-intranet. sls.aliyuncs.com"
  • アプリケーション層のログ:アプリケーション層のログは、発生したイベント(時間、場所、結果、遅延、メソッド、パラメータなど)の詳細を取得し、通常は拡張フィールドで終了します

    1. {
    2. "time":"2016-08-31 14:00:04",
    3. "localAddress":"10.178.93.88:0",
    4. "methodName":"load",
    5. "param":["31851502"],
    6. "result":....
    7. "serviceName":"com.example",
    8. "startTime":1472623203994,
    9. "success":true,
    10. "traceInfo":"88_1472621445126_1092"
    11. }
  • アプリケーション層のエラーログ:エラーコードの時刻、エラーコード、理由など

    1. 2016/04/18 18:59:01 :/var/www/html/SCMC/routes/example.php:329 [thread:1] errorcode:20045 message:extractFuncDetail failed: account_hsf_service_log

実装

  • ログは Logtail を介してローカルファイルに書き込まれ、設定の正規表現は指定されたLogStoreに書き込まれます。
  • Docker で生成されたログはコンテナサービス統合ログサービスを使用して収集されます 。
  • Java プログラムの場合は、Log4J アペンダ(ハードドライブ上にログを保存せずに)、LogHub プロデューサライブラリ(並行性の高いクライアント側書き込み用)、または Log4J アペンダを使用します。
  • C#、Python、Java、PHP、および C では、SDK Write を使用します。
  • Windows Server の場合、LogStash収集 を使用してください。

エンドユーザログへのアクセス

  • モバイル端末:ログアクセスにはモバイル端末SDK IOSAndroidまたはMAN(モバイルアナリティクス)を使用します。
  • ARMデバイス:ARMプラットフォームでは、クロスコンパイルにネイティブCを使用できます。
  • 商人プラットフォームデバイス:X86プラットフォームで動作するデバイスはSDKを使用でき、ARMプラットフォームで動作するデバイスはクロスコンパイルにNative Cを使用できます。

デスクトップウェブサイト/モバイルウェブサイトユーザーのページアクション

収集するユーザーのページアクションは、次の2つのタイプに分類されます。

  • バックエンドサーバーとの対話を伴うページアクション:たとえば、発注、ログイン、ログアウトなど。
  • バックエンドサーバーとのやりとりのないページアクション:フロントエンドで直接処理されるリクエスト(ページのスクロール、ページの終了など)。

実装

  • 最初のタイプについては、サービス側の収集方法を参照してください。
  • 2番目のタイプの場合は、トラッキングピクセル/ JSライブラリを使用してページアクションを収集します。 Tracking Web Interfaceを参照してください。

サーバログのメンテナンス

例えば:

  • Syslogログ

    1. 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
  • アプリケーションのデバッグログ

    1. __FILE__:build/release64/sls/shennong_worker/ShardDataIndexManager.cpp
    2. __LEVEL__:WARNING
    3. __LINE__:238
    4. __THREAD__:31502
    5. offset:816103453552
    6. saved_cursor:1469780553885742676
    7. seek count:62900
    8. seek data redo
    9. log:pangu://localcluster/redo_data/41/example/2016_08_30/250_1472555483
    10. user_cursor:1469780553885689973
  • トレースログ

    1. [2013-07-13 10:28:12.772518] [DEBUG] [26064] __TRACE_ID__:661353951201 __item__:[Class:Function]_end__ request_id:1734117 user_id:124 context:.....

実装

サービス側の収集方法を参照してください。

異なるネットワーク環境でのデータ収集

LogHubは、それぞれのアクセスポイントを提供していリージョン 3つのアクセス方法を提供します:

  • イントラネット(クラシックネットワーク):現在のリージョン内のサービスアクセスのために、最高の帯域幅リンク品質(推奨)を提供します。
  • インターネット(クラシックネットワーク):誰にでもアクセスできるため、アクセスの速度はリンクの品質によって異なる場合があり、セキュリティと保護のためにHTTPSが推奨されます。
  • プライベートネットワーク(VPC):現在のリージョン内のVPCネットワークにアクセスできます。

詳細については、ネットワークアクセスを参照してください。いつでも適切な解決策を見つけることができます。

その他