雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
日志收集是每一家公司都需要的基礎元件，尤其是已經步入正軌的公司。但是，日志收集要收集哪些内容呢？我們要對這些資訊一視同仁麼？
日志種類劃分
一般說到日志，想到的都是後端日志。但是後端日志根據不同的需要和日志級别，最終的流向和處理方式也是不一樣的。
普通業務日志。 你要知道，在這個世界中，線上開着DEBUG日志級别跑的程式員，到處都是。那些像撒尿一樣的流水賬，是沒必要收集的。也就是說，業務日志中，大多數都是沒用的東西。對待這種資料，我們隻要有個地方進行統一存儲就可以了。
檢索型業務日志。 檢索的業務日志，是有業務屬性的。比如你的系統和第三方支付進行對接所産生的封包互動資料。它們比普通業務日志有用，但又沒有存放到資料庫的必要，我們一般的處理方式就是收集到ES這種大容量的存儲中。
并不是說你收集到ES，挂個kibana就完事了。這些資訊我們還需要檢索，也就是字段要有具體的意義。這時候，普通字元串就沒什麼用了，需要轉化成json一類的規格資料，這樣就可以根據某個條件進行搜尋統計。
ES和mongo對此支援也都不錯。
檢索型業務日志是建設的重點，需要對日志輸出元件進行二次開發和定制，配合完成。
以下是一個可能的外觀接口。
//輸出攜帶參數的日志，參數為偶數，将會對其進行key，value配對。
LogMe.out("title","remark aa", "vendorid", 5, "storecode", "1011", "poscode", "POS1111", "version", "7.0.0.16");
//參數為奇數，放入_all字段，無法根據内容查找（要盡量避免此情況）
LogMe.out("test _all title","remark aa", "vendorid", 5, "storecode", "1011", "poscode", "POS1111", "version");
//error堆棧+參數，以上兩個方法都可以追加異常棧
LogMe.out("error","remark error", new Exception("error"), "vendorid", "5", "storecode", "1011");
異常日志。 異常日志又是一種流向。對待這一類資訊，我們希望得到兩個效果。第一、異常日志能夠及時的被業務人員發現；第二、異常日志能夠被統計和事後分析。是以，一個觸發式的日志處理鍊，以及檢索型的上下文查詢，都是必要的。
APM 這個和前端，終端綜合起來，可以進行調用鍊追蹤，行為分析等，一般是垮端的整體性分析。市面上有很多這樣的産品，包括收費的和開源的。
再向上，就是一些終端的日志。終端包括Android、IOS，以及其他手持裝置。它和WEB端是類似的，隻是工具鍊不同。
行為日志。 你在使用一些App的時候，都會預設勾選上一個叫做匿名發送使用資料-幫助我們提高的選項。最詳細的行為資料記錄，使用者的每一次點選事件，都會産生一條日志，這些日志會傳送到服務端進行分析。這種日志的資料一般是非常龐大的，需要專門處理，使用TSDB等超大容量的存儲進行存放。
終端異常日志 終端的異常日志一般是個技術活。除了收集應用正常運作中産生的異常，還需要獲得應用異常退出時候的異常資訊。
可以看到，每一種日志都有它自己的使用場景，後端使用的技術棧也不盡相同。
幹什麼用？
後端日志收集之後，大多數是為了輔助開發或者運維進行問題定位，減少分析問題的時間。
我們着重說一下用戶端日志收集。
除了偷偷使用你的硬體進行挖礦的無良App，還有類似支付寶這種偷偷拍你的照，錄你的音的大廠軟體（自行搜尋，我姑且認為這是真的）。目的都是為了采集使用者資料，搞一些類似大資料殺熟的勾當。像iphone本身等也有類似的功能，比較缺德的是預設是打勾的。
大多使用者對自己的行為資料無感覺，但當大量的資料聚合起來，廠商會覺得很香，很帶感。做技術當然是去實作就好，不用去譴責自己的良心，天塌下來還有公關部那群炮灰頂着呢。
和APM這種用來用來改善調用關系、性能的工具不同，用戶端收集的資料更加零散，業務模型也更加多樣化。
使用者的資料即然這麼寶貴，那麼都收集些什麼呢？又是怎麼收集呢？當然不是通過收集調查問卷。使用者的每個點選，甚至頁面的停留時間，都可能會成為被分析的對象。
由于使用者安裝了你的軟體，其硬體環境的資訊也能夠擷取，包括調用硬體的裝置采取的包括使用者隐私、截圖、音頻、視訊等資料等。是以收集的資料是多種多樣的。
1、硬體資訊
這個在Android裝置上展現的比較明顯。收集這些資料用來分析app與裝置、裝置版本、語言等之間的關系。可以将工作重點轉向市場占用率高的裝置和版本上。你可能還會收集裝置的CPU、記憶體、顯示卡等資訊，以便對你的産品進行專項優化。
2、軟體環境
收集自有軟體的資訊
軟體版本。通過分析使用者安裝的每個軟體版本的數量，你可以決定那些版本可以不在維護，哪些版本發生的bug多等，是你很多決策的依據。
收集其他軟體的資訊
3、功能監控
對一些灰階的，或者重要的功能進行監控。比如你新上線了一個idea，到底行不行，還得需要線上資料來驗證。通過分析日志，就能判斷出哪些産品經理的主意是非常差勁的。
4、LBS
使用者位置資料是非常敏感的。LBS曾經成就了陌陌，對于大部分應用來說，位置資料可以分析産品在某個區域、省份、國家的受歡迎程度和差異化。
當你釋出了一個新的産品需求，就應該考慮到後期的資料追蹤，以便評估你的需求效果。包括在釋出期間使用者的裝機、解除安裝量。這都是有資料支撐的，而不是拍腦袋決定的。
5、行為資料
前幾年還是比較火的推薦功能，現在加上深度學習的加持，分析更為準确。機器會在背景默默的記錄你的喜好，并産生相應的輸出，投你所好。
End
綜上所述，設計一個比較全面的日志系統，還是有一番挑戰的。不同類型的業務日志，有着不同的分析處理方式，資料的最終流向也不盡相同。xjjdog後續會嘗試從日志規範方面，将這個體系進行整體的歸納。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-13
本文作者：小姐姐味道
本文來自：“
掘金”，了解相關資訊可以關注“掘金”