數字IT基礎-數據採集總線

摘要： 日誌服務是阿里自產自用的產品，在雙11、雙十二和新春紅包期間承載阿里雲/螞蟻全站、阿里電商板塊、雲上幾千商家數據鏈路，每日處理來自百萬節點幾十PB數據，峯值流量達到每秒百GB， 具有穩定、可靠、低成本，生態豐富等特性。

數字化運營基礎

在現在「雙十一」再也不是線上活動的代名詞，而逐步變爲一場線上線下同時進行的消費者盛宴。銷售、運營、物流、生產商等都在開足馬力在各大渠道備戰，據統計：

• 消費者在期間被平均推送200+活動消息
• 消費者會花幾個小時比較、提早篩選本身中意產品
• 除了線上外，90%線下店鋪都掛出針對雙十一運營活動

雙十一觸客渠道也呈現多樣化，例如：網絡店鋪、短信、郵件、微信公衆帳號、派單與Kitty板、自提櫃、智能設備（例如天貓精靈點單）、多媒體設備（例如電視或機頂盒購物）等。

面對如此多的渠道和銷售方式，運營和銷售如何有效掌控，並經過數字化方式進行運營是一項硬能力。讓咱們來看幾個例子：

例子1：新用戶引流

互聯網經典書籍《上癮：構建習慣養成的產品》把用戶獲取過程分爲4個階段：觸發、行動、獎勵、投入。做爲最開始的觸發環節，給用戶羣發消息是最有效的手段之一。但如何衡量轉化效果呢？

咱們能夠在推廣信息中作一個埋點，把用戶點擊短信帶上關聯信息，例如設計一個以下的URL，其中放入2個關鍵參數：

• t: 表明發送的批次編號，也能夠做爲渠道的標識
• m：表明發送的短信號碼

html://mywebsite.com/new?t=1002&m=13860394XX複製代碼

當用戶點點擊消息訪問站點時，咱們在服務端訪問日誌中會自動記錄對應信息:

202.168.1.209 - - [02/Feb/2016:17:44:13+0800] "GEThtml://mywebsite.com/new?t=1002&m=13860394XX HTTP/1.1" 200 209 - "Mozilla/5.0(Macintosh; Intel Mac OS X10_11_3) AppleWebKit/537.36(KHTML, like Gecko)Chrome/48.0.2564.97 Safari/537.36"複製代碼

這樣咱們就能得到推廣效果和轉化率：

例子2：線上購買意圖捕捉

在獲取客戶後，下一步是讓用戶付諸於行動。用戶在瀏覽商品時，會有頁面的停留，閱讀，比較和加入購物車等操做。能夠藉助Web Tracking和Serve端埋點來進行靜態與動態數據採集。

在靜態網頁和瀏覽器埋點：

<img src=‘http://${project}.${sls-host}/logstores/${logstore}/track_ua.gif?APIVersion=0.6.0&key1=val1&key2=val2’/> 複製代碼

經過JS埋點：

varlogger = new window.Tracker('cn-hangzhou.log.aliyuncs.com','ali-test-tracking','web-tracking');
logger.push('customer','zhangsan');
logger.push('product','iphone6s');
logger.push('price',5500);
logger.logger();複製代碼

在完成數據埋點後，咱們能夠在日誌服務分析功能中，得到每一個環節的點擊數和轉化數字，以衡量購買階段的效果。

Web Tracking連接：help.aliyun.com/document_de…
服務端埋點連接：help.aliyun.com/document_de…

數據採集挑戰

從上面例子來看，數據採集是數字化IT的基礎。讓咱們來看一個典型的數據採集架構：

1. 購買一批機器搭建網絡服務器
2. 爲服務器搭建負載均衡設備
3. 在網絡服務器（例如Nginx）模塊中使用Kafka等中間件寫入數據

該方案經過無狀態設計解決了高可用，按需擴容等問題，也是衆多廠商採用的方案，在理想狀態下運行得很是好。但在現實過程當中，每每會遇到以下挑戰：

步驟	模塊	挑戰	成本
端	協議封裝與客戶端開發	須要開發衆多SDK，例如Android、IOS、嵌入式等	研發成本、運維
	客戶端傳輸	面向網絡不可用	斷點續傳功功能
	客戶端傳輸	傳輸過程當中安全問題	HTTPS協議支持與證書
	客戶端升級	客戶端若是有Bug如何升級	運維成本
傳輸	網絡質量差	網絡質量差	購買昂貴專線
	地域與合規	用戶數據不能出國，例如歐盟等協議	在全球建各數據中心
	網絡選擇	運營商速度、質量不一，質量差	購買第三方加速服務
服務端	擴容	流量上漲時，如何自動擴容	購買服務器、手動運維
	防攻擊	採集服務器可能被DDOS	運維服務器
	認證	進行用戶認證與管理	開發負責的認證與管理模塊
	數據加工	數據到服務端後，增長來源IP、服務端時間等字段	服務端開發成本
	上下游對接	對接各類流計算、離線處理系統	硬件採購、程序開發與維護

做爲用戶最終的目標是爲了分析數據。但這些問題的存在，須要在業務、規模與增加上消耗大量人力、精力和物力，幹了不必定幹得好。

日誌服務LogHub功能

阿里雲日誌服務（Log Service，/原SLS）是針對實時數據一站式服務，其中的LogHub模塊就是專爲數據採集定製的功能，該功能有以下特色：

1. 30+實時採集手段

LogHub提供30+種開箱即用的數據採集手段，包括直接和雲產品打通的日誌、移動端、服務端、程序、SDK、網頁、嵌入端等，如下咱們分別介紹下最經常使用的四種與試用場景：

方式	應用場景	當前規模	優點
Logtail	X86服務器採集	百萬-千萬	功能強
Android/IOS SDK	移動端數據採集、手機、POS機等	千萬DAU	斷點續傳
C Producer Library	硬件資源受限的系統（如 IoT、嵌入式、RTOS等）	千萬-億級	資源消耗低
Web Tracking	網頁靜態數據採集	千萬-億級	輕量級，無驗證

1.1 Logtail（部署量最大Agent）

Logtail安裝在X86設備上，經過中央服務器進行管控，只需點點鼠標或API就可以在幾秒鐘內對百萬機器下達數據採集指令。Logtail目前天天有幾百萬的運行實例，適配全部Linux版本、Window、Docker、K8S等環境；支持幾十種數據源對接，關於Logtail功能能夠參見介紹文檔。

得益於阿里巴巴集團場景的不斷錘鍊，Logtail和開源Agent（例如Fluentd、Logstash、Beats）相比，性能、資源消耗、可靠性和多組合隔離等硬指標上較爲領先。能夠知足國內最大的直播網站、最大的教育類網站、最大的金融類網站的苛刻要求。和開源Agent主要差距在於日誌格式的豐富性（當前Logtail版本已支持Logstash、Beats協議，既能夠將這些開源插件無縫跑在Logtail之上）。

2018年Logtail針對Docker/K8S等場景作了很是多的適配工做，包括：

• 一條命令一個參數便可實現部署，資源自動初始化
• 支持CRD方式配置，支持K8S控制檯、kubectl、kube api等，與K8S發佈、部署無縫集成
• K8S RBAC鑑權，日誌服務STS鑑權管理

能夠自豪地說，Logtail方案是K8S下全部Agent中最全，最完整的之一，感興趣能夠參見LC3視角：Kubernetes下日誌採集、存儲與處理技術實踐 ：

1.2 C Producer Library系列（面向嵌入式設備新秀）

​ 除X86機器外，咱們可能會面對各類更底層IoT/嵌入式設備。針對這種場景，LogHub推出C Producer Library系列SDK，該SDK能夠定位是一個「輕量級Logtail」，雖沒有Logtail實時配置管理機制，但具有除此以外70%功能，包括：

• 多租戶概念：能夠對多種日誌（例如Metric，DebugLog，ErrorLog）進行優先級分級處理，同時配置多個客戶端，每一個客戶端可獨立配置採集優先級、目的project/logstore等
• 支持上下文查詢：同一個客戶端產生的日誌在同一上下文中，支持查看某條日誌先後相關日誌
• 併發發送，斷點續傳：支持緩存上線可設置，超過上限後日志寫入失敗
  專門爲IoT準備功能：
• 本地調試：支持將日誌內容輸出到本地，並支持輪轉、日誌數、輪轉大小設置
• 細粒度資源控制：支持針對不一樣類型數據/日誌設置不一樣的緩存上線、聚合方式
• 日誌壓縮緩存：支持將未發送成功的數據壓縮緩存，減小設備內存佔用

關於C Producer Library的更多內容參見目錄：yq.aliyun.com/articles/30…

目前針對不一樣的環境（例如網絡服務器、ARM設備、以及RTOS等設備）從大到小咱們提供了3種方案：

​ 在X86以及ARM設備測試場景中，C-Producer系列SDK能在穩定服務狀況下，極大優化性能和內存空間佔用，勝任只有4KB運行內存的火火兔場景（Brick版本）。

使用C Producer系列的客戶有： 百萬日活的天貓精靈、小朋友們最愛的故事機火火兔、 遍及全球的碼牛、釘釘路由器、 兼容多平臺的視頻播放器、 實時傳輸幀圖像的攝像頭等。

這些智能SDK天天DAU超百萬，遍及在全球各地的設備上，一天傳輸百TB數據。關於C Producer Library 的細節能夠參考這篇文章: 智能設備日誌利器：嵌入式日誌客戶端（C Producer）發佈。

2. 服務端多地域支持

​ 客戶端問題解決了後，咱們來看看服務端。LogHub 是阿里雲化基礎設施，在全球阿里雲全部Region都有部署。確保不管業務在哪一個Region開展，均可以選擇就近的Region。

例如歐盟、新加坡等國家有相關的法律約束數據不能出境，對於這類場景咱們能夠選擇合適的數據中心來提供服務。對於同Region下ECS、Docker等服務，咱們能夠直接使用同Region服務進行處理，節省跨洋傳輸的成本。

3. 全球加速網絡

​ 對全球化業務而言，用戶可能分佈在全球各地（例如遊戲，App、物聯網等場景），但在構建數倉業務的過程當中，咱們每每須要對數據進行集中化處理。例如一款移動App用戶散佈在全國各省市

• 將日誌採集中心定在杭州，那對於西南（例如成都）用戶而言，遠程進行日誌傳輸的延時和質量難以保障
• 將日誌採集中心定在成都，那對位於東部和東北用戶又難以權衡，更不用說中國的三大運營商鏈路質量的影響

​ 2018年6月初LogHub 聯合 CDN 推出了一款全球自動上傳加速方案：「基於阿里雲CDN硬件資源，全球數據就近接入邊緣節點，經過內部高速通道路由至LogHub，大大下降網絡延遲和抖動 」。只需簡單配置便可構建起快速、穩定的全球數據採集網絡，任意LogHub SDK均可以經過Global域名得到自動加速的支持。

​
在咱們測試case中，通過全球7個區域對比總體延時降低50%，在中東，歐洲、澳洲和新加坡等效果明顯。除了平均延時降低外，總體穩定性也有較大提高（參見最下圖，幾乎沒有任何抖動）。確保如何在世界各地，只要訪問一個統一域名，就可以高效、便捷將數據採集到指望Region內。

4. 服務端彈性伸縮

​ 在解決網絡接入問題後，咱們把問題聚焦在服務端流量這個問題上。熟悉Kafka都知道，經過Partition策略能夠將服務端處理資源標準化：例如定義一個標準的單元Partition或Shard（例如每一個Shard固定5MB/S寫，10MB/S讀）。當業務高峯期時，能夠後臺Split Shard以獲取2倍的吞吐量。

這種方法看起來很工程化，但在使用過程當中有兩個難以繞開的現實問題：

• 業務沒法預測：事先沒法準確預估數據量，預設多少個shard才合適呢
• 人的反應滯後：數據量隨時會突增，人不必定可以及時處理，長時間超出服務端負載能力會有數據丟失風險

​ 針對以上狀況，LogHub提供了全球獨創Shard自動分裂功能：在用戶開啓該功能後，後臺系統實時監控每一個shard的流量，若是發現一個shard的寫入在一段時間內，有連續出現超過shard處理能力的狀況，會觸發shard的自動分裂，時刻保障業務流量。

更多細節能夠參考這篇文章: 支持Shard自動分裂

5. 豐富上下游生態與場景支持

LogHub也提供豐富上下游與生態對接，包括各類主流流計算、數據倉庫等引擎支持：

• 採集端：Logstash、Beats、Log4J等
• 實時消費端（流計算）：Flink/Blink、Storm、Samza等
• 存儲端（數倉）：Hadoop、Spark、Presto、Hive等

經過LogHub與日誌服務其餘功能+產品組合，能夠輕鬆支撐安全、運營、運維和研發對於數據處理的各類場景需求，更多能夠參考學習路徑 和 用戶手冊。

寫在最後

日誌服務是阿里自產自用的產品，在雙11、雙十二和新春紅包期間承載阿里雲/螞蟻全站、阿里電商板塊、雲上幾千商家數據鏈路，每日處理來自百萬節點幾十PB數據，峯值流量達到每秒百GB， 具有穩定、可靠、低成本，生態豐富等特性。
阿里雲官網上提供同款產品，只要5分鐘即可開通並開啓數字化IT之旅，歡迎試用。