遊戲日誌分析2：全方位資料採集

系列文章：

• 遊戲日誌分析（1）：概覽
• 遊戲日誌分析（2）：全方位資料採集
• 遊戲日誌分析（3）：程式日誌規範與埋點
• 遊戲日誌分析（4）：線上問題定位與排查
• 遊戲日誌分析（5）：資料庫與日誌關聯分析
• 遊戲日誌分析（6）：CDN/物件儲存日誌分析
• 遊戲日誌分析（7）：網路日誌查詢與分析
• 遊戲日誌分析（8）：資料庫日誌分析
• 遊戲日誌分析（9）：安全日誌分析
• 遊戲日誌分析（10）：資料視覺化與報表
• 遊戲日誌分析（11）：數倉建設
• 遊戲日誌分析（12）：實時資料處理與流計算

前言

在上一篇文章中，我們介紹了日誌資料對遊戲的重要性，這一篇我們來討論下如何高效地實施全方位無死角的日誌採集。

遊戲日誌資料

日誌來源

遊戲日誌資料有很多的來源，例如：

• 在推廣期，我們需要採集廣告流量和點選的資料，以確定新使用者轉化率
• 在使用者端，如果是手遊，我們需要採集移動端Android、IOS上游戲執行及操作日誌
• 如果是頁遊，除了服務端日誌之外，靜態頁面JS對我們也很重要
• 如果是客戶端遊戲，需要跨平臺採集客戶端執行資料
• 服務端各模組打點記錄，包括請求、使用者操作

日誌分類

以上這些也只是部分而已，在阿里集團和支撐業務中，涉及到採集的日誌如下：

• 程式日誌
• 中介軟體日誌
• 前端伺服器日誌
• Tomcat等日誌

• 主機日誌

  • syslog
  • var/log/message
• H5頁面日誌
• 雲產品日誌：雲服務商提供的日誌資料

• 移動端埋點日誌

  • IOS 日誌
  • Android 日誌
  • WAP 頁面

• 資料庫日誌

  • Binlog
  • Slow Log
  • SQL Log

• 硬體裝置

  • X86
  • ARMS
  • RTOS

日誌採集的作用就是把這些分佈在全球各地域，多個渠道和終端，異構網路的資料統一，以適應後期各種角色（研發、運維、客服、運營、產品、總監等）對資料處理的各種需求。

資料採集方法

1. 硬體裝置日誌採集

隨著VR遊戲的流行，一部分業務會使用嵌入式裝置，例如感測器、攝像頭、互動大屏等。這類裝置一般會有如下特點：

• 硬體架構、系統型別多樣，例如ARM、X86、PPC等硬體架構，Linux、RTOS、嵌入式Windows等系統
• 裝置端資源緊張，可分配給日誌採集的資源較少
• 全球化部署，裝置部署具有全球化、邊緣化特點
  日誌服務提供C Producer系列日誌庫，用於採集各種硬體裝置的日誌。優勢如下：
• 客戶端高併發寫入：可配置的傳送執行緒池，支援每秒數十萬條日誌寫入，詳情參見效能測試。
• 低資源消耗：每秒20W日誌寫入只消耗70% CPU；同時在低效能硬體（例如樹莓派）上，每秒產生100條日誌對資源基本無影響。詳情參見效能測試。
• 客戶端日誌不落盤：既資料產生後直接通過網路發往服務端。
• 客戶端計算與 I/O 邏輯分離：日誌非同步輸出，不阻塞工作執行緒。
• 支援多優先順序：不通客戶端可配置不同的優先順序，保證高優先順序日誌最先傳送。
• 本地除錯：支援設定本地除錯，便於您在網路不通的情況下本地測試應用程式。
• 全球化動態加速：利用阿里雲全球化部署能力和靜態頻寬資源，為全球部署的裝置進行採集加速。
• 

根據不同裝置型別以及資源限制，我們推薦使用以下方式進行日誌採集：

• C Producer : 適用於C++遊戲伺服器、路由器/交換機、平板類裝置採集，佔用資源1MB左右。
• C Producer Lite : 適用於智慧裝置（例如智慧音響、攝像頭等）日誌採集，佔用資源80KB左右。
• C Producer Bricks : 適用於IOT裝置（例如感測器、RTOS裝置等）日誌採集，佔用資源8KB左右。

2. 移動端日誌採集

在移動網際網路時代，手遊已經成為遊戲中最熱點的類目，對於手遊APP的日誌採集場景，我們希望將APP的日誌直接上傳到日誌服務中，而不需要通過APP服務端中轉，這樣使用者就能專注在自己的業務邏輯開發。

普通模式下，日誌寫入日誌服務需要開啟主賬號的訪問祕鑰，用於鑑權以及防篡改。移動APP如果通過此模式接入日誌服務，需要將您的AK資訊儲存在移動端，存在AK洩漏的資料安全風險。一旦發生AK洩漏，需要升級移動APP，並替換AK，代價太大。另一種移動端日誌接入日誌服務的方式為通過使用者伺服器中轉，但是該種模式下，如果移動APP數量較大，使用者的應用伺服器需要承載所有的移動端資料，對伺服器的規模有較高的要求。

為了避免以上問題，日誌服務為您提供能更安全、更便捷的移動APP日誌資料採集方案，即通過RAM搭建一個基於移動服務的移動應用資料直傳服務。相較於直接使用AK訪問日誌服務，使用者不需要在APP端儲存AK，不存在AK洩露的風險。使用臨時Token訪問，更加安全，Token有生命週期，並且可以針對Token定製更加複雜的許可權控制，比如限制IP段的訪問許可權等。成本低，使用者不需要準備很多伺服器，移動應用直聯雲平臺，只有控制流走使用者自己的應用伺服器。

手遊日志直傳服務搭建可參考：搭建移動端日誌直傳服務。該方案可搭配以下SDK進行接入：

• 移動端：可以使用移動端 SDK IOS, Android 接入。
• ARM 裝置：ARM 平臺可以使用 Native C 交叉編譯。
• 商家平臺裝置：X86 平臺裝置可以用 SDK、ARM 平臺可以使用 Native C 交叉編譯。

3. H5靜態頁面採集

頁面使用者行為收集可以分為兩類：

• 頁面與後臺伺服器互動：例如下單，登陸、退出等。
• 頁面無後臺伺服器互動：請求直接在前端處理，例如滾屏，關閉頁面等。

實施方法：

• 第一種可以參考服務端採集方法。
• 第二種可以使用 Tracking Pixel/JS Library 收集頁面行為，參考 Tracking Web 介面。

Web Tracking只需一個http get請求即可將資料傳輸至日誌服務Logstore端，適應各種無需任何驗證的靜態網頁、廣告投放、宣傳資料和移動端資料採集。相比其他日誌採集方案，特點如下：

• 便捷：支援瀏覽器、JS、Image等標籤埋點，無需簽名即可傳送
• 高併發：服務端百萬級QPS，全國+全球20個以上接入點
• 無運維成本：無伺服器開銷，無運維負擔
• 按量付費：成本低廉，按照使用量付費

4. 服務端-伺服器採集

伺服器日誌一般通過Agent進行採集，相對應用直髮，Agent採集具備以下優勢：只要應用可以將日誌輸出（以檔案形式儲存到磁碟、syslog等）或者支援通用的介面拉取，Agent即可將日誌採集到。大部分場景下鬆耦合、可擴充套件性、可維護性相比Agent額外開銷更具優勢。

日誌採集Agent選型一般需要關注功能、效能、穩定性、運維代價4個方面：

• 功能：作為選擇Agent最基本需求，主要分為輸入源、資料處理（除日誌解析外，還包括過濾、壓縮等）、資料輸出。
• 效能：不同型別Agent之間會有數十倍的效能差距。當日志產生速率較低且資源充足時，此項可以忽略；但大部分情況下采集Agent是作為整個叢集的基礎軟體，在叢集規模龐大的情況下，即使每臺機器節省1%的CPU、10MB的記憶體也是很大一筆資金節省。
• 穩定性：穩定的重要性無需多言，除保證自身執行的穩定外，Agent還需保證不能超出限定的資源使用Quota，以免對應用產生影響。
• 運維代價：日誌採集的運維主要包括：Agent部署、動態伸縮、配置管理、Agent升級、Agent異常監控。當只有數臺主機時，Agent可以使用人肉的方式進行管理，但當叢集規模擴大到數百及以上時，運維必須依賴有效的機制。

目前阿里雲日誌服務logtail採集Agent已承載阿里雲全站、所有云產品服務、全球各Region部署、阿里巴巴集團（淘寶、天貓、菜鳥等）上重要服務的資料採集。每天採集接近百萬伺服器上數PB的實時資料，對接數千個應用與消費者。之所以使用Logtail作為採集Agent也是經過上述四個方面的綜合考慮。由於採集Agent數量眾多，這裡我們選擇目前最主流的3款Agent進行對比：

		Logtail	Logstash	Fluentd	Beats系列
功能	文字檔案採集	支援	支援	支援	支援
	syslog	支援	支援	支援	不支援
	處理方式	正則、anchor、分隔符、json任意組合	外掛擴充套件	外掛擴充套件	只支援multiline
	過濾	正則	外掛擴充套件	外掛擴充套件	不支援
	壓縮	lz4	外掛擴充套件	外掛擴充套件	支援
	功能擴充套件	支援外掛	支援外掛	支援外掛	支援（修改原始碼）
效能	採集效能	極簡單核160M/s、正則20M/s	單核2M/s左右	單核3-5M/s	極簡單核15M/s
	資源消耗	平均CPU 2%、記憶體 40M	10倍以上效能消耗	10倍以上效能消耗	記憶體消耗較低
穩定性	多租戶隔離	自實現的隔離	執行緒級隔離	執行緒級隔離	goroutine隔離
	硬性資源限制	支援	支援	支援	不支援
	資源動態調整	支援	不支援	不支援	不支援
	資料儲存	支援	外掛支援	外掛支援	不支援
	程式守護	支援	輔助軟體支援	輔助軟體支援	輔助軟體支援
	採集點位儲存	所有均支援	只支援檔案	外掛支援	只支援檔案
運維代價	本地監控	支援	支援	支援
	服務端監控	支援	Beta版本支援簡單功能	輔助監控軟體擴充套件	不支援
	叢集自動縮擴容	自定義標識機器組	不支援	不支援	不支援
	執行時配置變更	支援	支援	支援	支援
	服務端配置管理	支援	Beta版本支援簡單功能	輔助軟體擴充套件	不支援
	自動升級	支援	輔助軟體擴充套件	輔助軟體擴充套件	不支援

相對主流的採集Agent，Logtail在採集功能上有一定的不足，對於輸入源、處理方式等支援沒有開源軟體的多，但從目前的功能來看，可以滿足95%以上的日誌採集需求。但日誌採集並不是能夠採集到就可以。相對開源軟體，Logtail的優勢是有集團百萬伺服器、上萬應用的練兵環境，很多問題純粹從Agent和開源社群的角度並不會考慮到。因此經歷了數年的迭代優化，在效能、穩定性、運維代價上，Logtail相對更加成熟，在價效比上具有絕對的優勢。

因此建議使用Logtail進行資料採集，針對不同格式的日誌配置方法如下：

• 正則日誌
• 分隔符日誌
• JSON日誌

5. 服務端-K8S採集

在K8S中，日誌採集並沒有很好的解決方案，主要原因如下：

1. __採集目標多__：需要採集宿主機日誌、容器內日誌、容器stdout。針對每種資料來源都有對應的採集軟體，但缺乏一站式解決方案。
2. __彈性伸縮難__：K8S是一個分散式的叢集，服務、環境的彈性伸縮對於日誌採集帶來了很大的困難，採集的動態性以及資料完整性是非常大的挑戰。
3. __運維成本大__：現有的方案只能使用多種軟體組合採集，各個軟體組裝起來的系統穩定性難以保障，且缺乏中心化的管理、配置、監控手段，運維負擔巨大。
4. __侵入性高__：Docker Driver擴充套件需要修改底層引擎；一個Container對應一個採集Agent又會產生資源競爭和浪費。
5. __採集效能低__：正常情況下一個Docker Engine會執行數十個甚至數百個Container，此時開源Agent日誌採集效能以及資源消耗十分堪憂。

基於阿里巴巴多年來容器服務日誌採集的經驗積累，並結合阿里雲Kubernetes廣大使用者的反饋與訴求，日誌服務推出了Kubernetes日誌採集方案，支援容器檔案 、容器stdout 、宿主機檔案 的全方位採集。相比其他容器日誌採集方案優勢如下：

• 全方位資料採集：支援metric、event、容器stdout、容器日誌檔案、宿主機日誌檔案
• Kubernetes無縫整合：支援原生Kubernetes配置方式，與應用釋出、管理無縫整合
• 高效能：c&c++&go實現的高效能客戶端，相比開源方案數倍、數十倍效能優勢
• 穩定可靠：百萬級規模，經歷多次雙11雙12考驗
• 中心化配置管理：所有配置管理均在控制檯配置，支援配置動態載入
• 詳細採集監控：詳細的採集監控資訊，支援資料採集狀態查詢與自定義報警

6. 程式日誌採集

日誌服務提供多種語言的SDK，支援各種語言程式直髮日誌服務：

• Java: Producer Library 、Log4j Appender
• C: C Producer Library
• Python
• PHP
• .NET
• Golang

針對高效能應用場景，我們推薦使用Producer Library（Java Producer Library 、 C Producer Library）。Producer Library 會簡化您程式開發的步驟，幫助您批量聚合寫請求，通過非同步的方式發往LogHub服務端。在整個過程中，您可以配置批量聚合的引數、服務端異常處理的邏輯等。該方式具備以下特點：

• 客戶端日誌不落盤：既資料產生後直接通過網路發往服務端。
• 客戶端高併發寫入：例如一秒鐘會有百次以上寫操作。
• 客戶端計算與 I/O 邏輯分離：列印日誌不影響計算耗時。

若您的Java程式使用Log4J庫進行日誌輸出，可直接使用日誌服務Log4j Appender 進行日誌採集。該方式具備以下特點：

• 日誌不落盤：產生資料實時通過網路發給服務端。
• 無需改造：對已使用Log4J應用，只需簡單配置即可採集。
• 非同步高吞吐：高併發設計，後臺非同步傳送，適合高併發寫入。
• 上下文查詢：服務端除了通過關鍵詞檢索外，給定日誌能夠精確還原原始日誌檔案上下文日誌資訊。

此外若您的程式日誌已經打到本地，可直接通過Logtail 進行採集。

7. 資料庫日誌採集

ChangeLog-Binlog

Logtail binlog 支援以MySQL slave的形式基於Binlog進行同步，支援Insert、Update、Delete以及DDL採集。相比傳統資料庫採集方式，Logtail binlog方式具備以下優勢：

• 採集效能高：Logtail binlog實現了Mysql master slave同步協議，以slave的形式同步資料，對資料庫壓力極小。
• 增量採集：只採集變化的資料，且對於Update型別資料可以看到更改前後資料對比。
• 豐富過濾規則：支援正規表示式設定採集的table黑白名單，配置極其靈活。
• 採整合本低：Logtail完全免費，部署一個Logtail可以採集多個資料庫日誌，成本極低。

資料庫中的增量資料

Logtail JDBC 支援以SQL形式定期採集資料庫中的資料，根據SQL可實現各種自定義採集方式。可根據自增ID或時間等標誌進行增量資料同步，也可根據業務需求進行自定義篩選同步。Logtail JDBC功能如下：

• 支援提供MySQL介面的資料庫，包括RDS
• 支援分頁設定
• 支援時區設定
• 支援超時設定
• 支援checkpoint狀態儲存
• 支援SSL
• 支援每次最大采集數量限制

8. 自定義資料採集

Logtail HTTP輸入 可根據您的配置定期請求指定URL，將請求返回body值作為輸入源上傳到日誌服務。通過該方式可採集各類以OpenApi方式提供介面的應用，例如Nginx status、kafka status、flink等。Logtail HTTP功能如下：

• 支援配置多個URL。
• 支援請求間隔配置。
• 支援HTTP方法配置。
• 支援自定義header。
• 支援設定method。
• 支援HTTPS。
• 支援檢測body是否匹配固定pattern。

日誌記錄注意事項

在程式日誌輸出時，為了保證後續處理，有一些通用的原則：

1. 通用日誌原則

• 可追溯：記錄必要的資訊，例如發起人、請求id、處理IP、處理結果、錯誤ID等
• 可分析：欄位表達清晰，不需要過多的清洗即可分析結果
• 可建模：每個欄位有明確含義，避免歧義性
• 可診斷：包含明確錯誤資訊與上下文

2. 分檔案

對於簡單的系統，可以將所有的日誌輸出到同一個日誌檔案中，並通過不同的關鍵字進行區分。而對於複雜的系統，將不同需求的日誌輸出到不同的日誌檔案中是必要的，通過對不同型別的檔案採用不同的日誌格式（例如對於計費日誌可以直接輸出為Json格式），可以方便接入其他的子系統。

對於應用而言，可以分3個日誌檔案

/worker/app.log <-- 程式邏輯相關
/worker/access.log <-- 使用者請求和訪問相關
/worker/error.log <-- 錯誤日誌

3. 動態日誌控制

DEBUG日誌和INFO日誌的一個重要的區別是：INFO日誌用於記錄常規的系統執行狀態，請求的基本的輸入和輸出等，對定位一般的問題已經足夠了。而DEBUG日誌則詳細的記錄了一個請求的處理過程，甚至是每一個函式的輸入和輸出結果，遇到一些隱藏比較深的問題時，必須要依賴DEBUG日誌。

然而，由於DEBUG級別的日誌數量比INFO級別的數量多很多（通常差一個數量級），如果長期線上上伺服器開啟DEBUG級別的日誌輸出，日誌量太大。再比如，有時候僅僅是由於某一個使用者的訪問模式比較特殊導致了問題，如果將整個服務（特別是一個服務部署了很多臺節點時）都臨時調整為DEBUG級別日誌輸出，也非常不方便。

下面介紹集中動態日誌控制技術：

1. 根據請求控制

   在業務處理層的Proxy中，實現如下邏輯：當接收到的HTTP請求的QueryString中包含"Level=Debug"引數時，就將所有的DEBUG級別的日誌也輸出：
   在負載均衡層的Openresty中，實現如下介面：管理員可以配置將哪個使用者的哪個桶的哪個物件的哪種操作（注：這是物件儲存中的幾個概念）輸出為DEBUG日誌，Openresty會對每個請求進行過濾，當發現請求和配置的DEBUG日誌輸出條件相匹配時，則在請求的QueryString中新增"Level=Debug"引數。
   通過這種方式，管理員可以隨時配置哪些請求需要輸出為DEBUG級別的日誌，可以大大提高線上定位問題的效率。

2. 主動監控配置檔案

   程式通過Inotify等技術監控日誌配置檔案，例如Log4J.property，當配置檔案有更新時（例如LogLevel發生變動），即可感知。
   該方案可以在程式不重啟的情況下完成配置更改與生效。
   > 如果使用者使用 spring，可以使用 org.springframework.web.util.Log4jConfigListener[http://www.cnblogs.com/Irving/archive/2013/02/28/2936810.html](http://www.cnblogs.com/Irving/archive/2013/02/28/2936810.html)
   > 否則，使用 Log4j DOMConfigurator類的configureAndWatch方法[http://489291468.iteye.com/blog/1895471](http://489291468.iteye.com/blog/1895471)

3. 動態配置伺服器

   例如所有伺服器都實時與配置管理伺服器（ConfigServer）互通，當配置有改動時會實時生效。