IoT日誌利器:嵌入式日誌採集客戶端(C Producer)釋出

阿里云云棲社群發表於2017-12-26

2017年12月19日至20日,2017雲棲大會·北京峰會在國家會議中心召開,飛天智慧是貫穿雲棲大會不變的主題,雲端計算、大資料、人工智慧、物聯網等熱門話題備受各方關注。其中阿里雲日誌服務釋出的嵌入式日誌採集客戶端(C Producer Library) 就是其中解決物聯網日誌採集、分析難的利器。

背景

IoT(Internet of Things)正在高速增長,越來越多裝置開始逐步走進日常生活(例如智慧路由器、各種電視棒、天貓精靈、掃地機器人),讓我們體驗到智慧領域的便利。距Gartner預測,到2020年末預計會有200億智慧裝置,可見該領域的巨大市場。

image

作為IoT/嵌入式工程師,除了需要深厚的開發功底外,面對海量的裝置,如何有能力管理、監控、診斷這些“黑盒”裝置至關重要。我們總結了嵌入式開發需求,主要有以下幾點:

  • 資料採集:如何實時採集分散在全球各地的百萬/千萬級裝置上的資料?
  • 除錯:如何使用一套方案既滿足線上資料採集以及開發時的實時除錯?
  • 線上診斷:某個線上裝置出現錯誤,如何快速定位裝置,檢視引起該裝置出錯的上下文是什麼?
  • 監控:當前有多少個裝置線上?工作狀態分佈如何?地理位置分佈如何?出錯裝置如何實時告警?
  • 資料實時分析:裝置產生資料如何與實時計算、大資料倉儲對接,構建使用者畫像?
image

思考以上問題的解決方案,我們發現在傳統軟體領域那一套手段面臨IoT領域基本全部失效,主要挑戰來自於IoT裝置這些特點:

  • 數目多:在傳統運維領域管理1W臺伺服器屬於一家大公司了,但10W線上對於IoT裝置而言只是一個小門檻
  • 分佈廣:硬體一旦部署後,往往會部署在全國、甚至全球各地
  • 黑盒:難以登陸並除錯,大部分情況屬於不可知狀態
  • 資源受限:出於成本考慮,IoT裝置硬體較為受限(例如總共只有32MB記憶體),傳統PC領域手段往往失效

針對不同端的資料採集

日誌服務(原SLS) 客戶端Logtail在X86伺服器上有百萬級部署,可以參見文章:Logtail技術分享 : 多租戶隔離技術+雙十一實戰效果Polling + Inotify 組合下的日誌保序採集方案。除此之外我們還有以下幾種方式:

  • 移動端SDK:Android/IOS平臺資料採集,一天已有千萬級DAU
  • Web Tracking(JS):類似百度統計,Google Analytics 輕量級採集方式,無需簽名

在IoT領域,我們從多年Logtail的開發經驗中,汲取其中精華的部分,並結合IoT裝置針對CPU、記憶體、磁碟、網路、應用方式等特點,開發出一套專為IoT定製的日誌資料採集方案:C Producer

image.png

C Producer特點

C Producer Library 繼承Logtail穩定、邊界特點,可以定位是一個“輕量級Logtail”,雖沒有Logtail實時配置管理機制,但具備除此之外70%功能,包括:

  • 提供多租戶概念:可以對多種日誌(例如Metric,DebugLog,ErrorLog)進行優先順序分級處理,同時配置多個客戶端,每個客戶端可獨立配置採集優先順序、目的project/logstore等
  • 支援上下文查詢:同一個客戶端產生的日誌在同一上下文中,支援檢視某條日誌前後相關日誌
  • 併發傳送,斷點續傳:支援快取上線可設定,超過上限後日志寫入失敗

還有一些專門為IoT準備功能,例如:

  • 本地除錯:支援將日誌內容輸出到本地,並支援輪轉、日誌數、輪轉大小設定
  • 細粒度資源控制:支援針對不同型別資料/日誌設定不同的快取上線、聚合方式
  • 日誌壓縮快取:支援將未傳送成功的資料壓縮快取,減少裝置記憶體佔用

image.png

功能優勢

C-Producer是量身為IoT定製的方案,因此會有一些特定考慮:

image.png

  • 客戶端高併發寫入:可配置的傳送執行緒池,支援每秒數十萬條日誌寫入,詳情參見效能測試
  • 低資源消耗:每秒20W日誌寫入只消耗70% CPU;同時在低效能硬體(例如樹莓派)上,每秒產生100條日誌對資源基本無影響
  • 客戶端日誌不落盤:既資料產生後直接通過網路發往服務端
  • 客戶端計算與 I/O 邏輯分離:日誌非同步輸出,不阻塞工作執行緒
  • 支援多優先順序:不通客戶端可配置不同的優先順序,保證高優先順序日誌最先傳送。
  • 本地除錯:支援設定本地除錯,便於您在網路不通的情況下本地測試應用程式。

在以上場景中,C Producer Library 會簡化您程式開發的步驟,您無需關心日誌採集細節實現、也不用擔心日誌採集會影響您的業務正常執行,大大降低資料採集門檻。

為了有一個感性認識,我們對C-Producer 方案與其他嵌入式採集方案做了一個對比,如下:

image.png

整體解決方案

C-Producer + 日誌服務可以給IoT帶來什麼?答案是:IoT日誌解決方案:

  • 規模大

    • 支援億級別客戶端實時寫入
    • 支援 PB/Day 資料量
  • 速度快

    • 採集快:0延遲:寫入0延遲,寫入即可消費

      • 查詢快:一秒內,複雜查詢(5個條件)可處理10億級資料
      • 分析快:一秒內,複雜分析(5個維度聚合+GroupBy)可聚合億級別資料
  • 對接廣

    • 與阿里雲各類產品無縫打通
    • 各種開源格式儲存、計算、視覺化系統完美相容

image.png

如何使用

一個應用可建立多個producer,每個producer可包含多個client,每個client可單獨配置目的地址、日誌level、是否本地除錯、快取大小、自定義標識、topic等資訊。

image.png

效能測試

環境配置:傳統X86伺服器,樹莓派(低功耗環境),配置分別如下:

image.png

C-Producer配置

  • ARM(樹莓派)

    • 快取:10MB
    • 聚合時間:3秒 (聚合時間、聚合資料包大小、聚合日誌數任一滿足即打包傳送)
    • 聚合資料包大小:1MB
    • 聚合日誌數:1000
    • 傳送執行緒:1
    • 自定義tag : 5
  • X86

    • 快取:10MB
    • 聚合時間:3秒 (聚合時間、聚合資料包大小、聚合日誌數任一滿足即打包傳送)
    • 聚合資料包大小:3MB
    • 聚合日誌數:4096
    • 傳送執行緒:4
    • 自定義tag : 5

日誌樣例

  1. 10個鍵值對,總資料量約為600位元組
  2. 9個鍵值對,資料量約為350位元組IoT日誌利器:嵌入式日誌採集客戶端(C Producer)釋出

測試結果

X86平臺結果

  • C Producer可以輕鬆到達90M/s的傳送速度,每秒上傳日誌20W,佔用CPU只有70%,記憶體140M
  • 伺服器在200條/s,傳送資料對於cpu基本無影響(降低到0.01%以內)
  • 客戶執行緒傳送一條資料(輸出一條log)的平均耗時為:1.2us

image.png

樹莓派平臺結果

  • 在樹莓派的測試中,由於CPU的頻率只有600MHz,效能差不多是伺服器的1/10左右,最高每秒可傳送2W條日誌
  • 樹莓派在20條/s的時候,傳送資料對於cpu基本無影響(降低到0.01%以內)
  • 客戶執行緒傳送一條資料(輸出一條log)的平均耗時為:12us左右(樹莓派通過USB連線到PC共享網路)

image.png

一些典型場景可以參見雲棲論壇最佳實踐



相關文章