目前流行的日誌系統是ELK，由Beats、Logstash、Elasticsearch、Kibana和其他組件* * *實現，但它保持不變。基本日誌系統架構如下所示:
遊戲分析與其他服務系統不同的是，遊戲中的系統可能不受約束和約束，數據類型多樣，甚至經常變化。我們應該總結變化中不變的內容，例如系統的經濟產出，玩家物品的消耗，商店的購買等等。因此該遊戲日誌系統應滿足以下要求:
雖然ELK的安裝和配置並不難，有許多插件，如Filebeat、讀取日誌文件、過濾格式和轉發，但沒有提到誰將產生這些日誌文件。其實業務多種多樣，只要有日誌文件就可以使用。例如，大多數人會使用Nginx進行日誌收集。我們還需要考慮日誌生產者的問題，權責分離，需要單獨的計算機來收集日誌。
遊戲是技術和藝術的結合。數據復雜多變，需要花費很大的精力來掩埋光學日誌，但我們不能放棄治療。壹個好的遊戲日誌也可以幫助我們還原玩家的畫像。遊戲更新周期短，數據變化大，因此需要提供更實時的參考報告，這對於非技術人員來說是更好的查詢接口，以便更好地服務於遊戲數據分析。在這方面，ELK已經基本解決了收集和存儲的問題，但分析還不能滿足我們的需求。
經過思考，我們可以使用現有的工具來綁定多個集合，因此我們有以下想法:
這個框架主要使用Fluentd、ElasticSearch和NodeJS，所以我將其稱為FEN架構，如下所示。
從上圖可以看出，這個日誌架構與第壹張圖基本相同，除了後面的分析和批量入庫處理，並使用了大量的NodeJS。
註意:這裏不介紹每個組件的詳細安裝和配置方法。網上太多了，如何用好每個組件是關鍵。
讓我們首先介紹壹下我們使用的工具:
Fluentd是壹款完全開源免費的日誌信息收集軟件，支持超過125個系統的日誌信息收集。Fluentd在收集源日誌方面非常方便和高性能，可以通過HTTP GET來完成，這與Nginx的日誌記錄行為類似。它的優點是日誌文件可以高度定制。例如，我們這裏每5秒生成壹個文件，所以每分鐘有12個文件，每個文件都很小。為什麽要這麽做？下面會介紹。Fluentd還有很多插件，比如直接存儲在MongoDB、亞馬遜雲等。如果妳熟悉Ruby，妳也可以編寫自己的插件。
有些人使用MongoDB收集日誌，這是非常不明智的。只有幾千萬的日誌是可以的。如果半個月產生6543.8+0億個日誌會怎樣？日誌文件需要保存壹個月或更長時間，因此集群和硬盤的維護非常重要。使用便利性也非常重要，例如分詞檢索，這在客服回溯玩家日誌和分析遊戲bug時非常有用。下面的ES也是這個組件的縮寫。
NodeJS不適合CPU密集型任務，但在網絡應用程序中還不錯，我們只是對它很熟悉。日誌系統對實時性要求不高，延遲在半小時以內是允許的。實際上，在正常情況下，延遲是10秒。以下用於讀取和轉發日誌的推送器、用於收集日誌的日誌記錄器以及用於分析日誌和保護數據安全的分析器都是由NodeJS實現的。
讓我們繼續介紹用NodeJS實現的每個部分:
如上所述，Fluentd為什麽使用劃分為多個小文件的方法？由於NodeJS在處理大文件時並不友好，並且考慮到通過網絡發送到另壹臺計算機時轉發速度比讀取慢得多，因此需要實現連續傳輸和斷點記錄功能。想想看，如果您讀取數百米的文件，在中斷後，您需要永久記錄最後壹個位置並在下次從這裏讀取，這增加了程序的復雜性。雖然NodeJS有壹個readline模塊，但它不像文件流那樣可控，並且訪問模塊對於交互界面來說是可以接受的。相反，如果將日誌分成幾個小文件，讀取速度非常高效，即使每5秒壹個文件中有上萬條記錄，文件也不會大很多，內存也不會占用太多，因此可以自由應對斷點續傳和錯誤重試。如果遊戲日誌較多，可以添加節點來緩解文件過多的壓力。
為什麽不讓日誌制作人直接發給Koa呢？因為效率和帶寬。NodeJS適合做網站，但比專業HTTP服務器弱很多。4核主機很難面對3000QPS。有關NodeJS性能的更多信息，請參考網絡文章。在高並發的情況下，帶寬是壹個大問題，尤其是需要統壹的服務。情況是日誌機和遊戲不在同壹個內網。日活654.38+萬，帶寬超過50M，非常恐怖。帶寬很貴，這裏的高帶寬成本太低了。
這裏我們使用Koa作為日誌收集器。使用Koa在性能和開發效率上都比expressJS更高效。我們還使用Redis作為緩存，而不是直接在這裏做分析任務，以便盡可能提高與Pusher對接的效率。畢竟日誌的生產速度很快，但是網絡傳輸效率相對較低。
註意:pm2 3.2.2的集群可能存在集群內部端口沖突的悖論，所以推薦使用3.0.3。
分析器讀取Redis的內容，這是單個進程的隊列操作。此時，如何分析日誌可以非常自由。
因為我們有自己的後臺管理系統，我們可以輕松地將用戶畫像與其他分析點連接起來。查詢玩家行為時，我們搜索ES，查詢分析報告時，我們查詢MongoDB中的數據。當然，我們也使用了Kibana來滿足可能的需求。
目前日誌系統已經運行了1個半月，從純MongoDB到組合ES走了很多彎路。幸運的是，它終於穩定下來了。目前，在性能方面，logger和analyser都在同壹臺機器上，平均CPU約為23%，峰值約為47%，這表明還有更大的機器壓榨空間。
在內存方面，在5G高峰期，整體情況非常穩定，沒有太大的波動。其中，redis的內存使用量不到800MB，但該機為16G，仍有很大的余量保證。
在NodeJS的腳本中，logger的CPU使用量更小，每個進程有3個進程，每個進程的內存使用量不到100MB。Analyser的CPU和內存占用多壹點，這可以通過腳本中的參數進行調整，例如可以更快地清除memory count的內容，如果使用pm2，則設置max _ memory _ restart:‘4G’可以提高穩定性。
以上是我在遊戲日誌系統中的體驗。
參考資料: