摘要：是，經(jīng)過我的調(diào)研就發(fā)現(xiàn)這個(gè)玩意其實(shí)不太好用，性能差是主要原因。運(yùn)營(yíng)數(shù)據(jù)日志的日志內(nèi)容其實(shí)和消息系統(tǒng)很像，我就直接引用這里的概念，。

本文章首發(fā)于我的博客 基于 Eleasticsearch 和 Kibana 的運(yùn)營(yíng)數(shù)據(jù)可視化后臺(tái)，轉(zhuǎn)載請(qǐng)注明來(lái)源。

前一段時(shí)間在研究 ELK 這個(gè)東西，之前也用過一點(diǎn)，但都沒有深入研究，其實(shí)這回也沒有深入研究，但我找到了在現(xiàn)在情況下我該怎么用這個(gè)東西的方法。

ELK 是一個(gè)日志系統(tǒng)的全家桶工具，Elasticsearch 用的人比較多，很多人把這個(gè)當(dāng)作搜索后臺(tái)，如果你選擇了 Django 這樣的框架的話也很容易繼承搜索功能進(jìn)去，比如用這個(gè)庫(kù) django-haystack，當(dāng)然很多人是用來(lái)做日志存儲(chǔ)。

L 是 Logstash，經(jīng)過我的調(diào)研就發(fā)現(xiàn)這個(gè)玩意其實(shí)不太好用，性能差是主要原因。這個(gè)東西的用途就是一個(gè)中間件，把多個(gè)平臺(tái)的不同格式的日志全部進(jìn)行預(yù)處理，然后再存入 ES 中，但是作為一個(gè)還很小，沒那么復(fù)雜的后臺(tái)服務(wù)來(lái)說(shuō)，用不著，只有一個(gè)日志來(lái)源，日志格式也是固定的，一條日志里面有四個(gè) JSON object，每個(gè) object 的 key 不是固定的，只要處理一下時(shí)間戳就行了，其他都不用動(dòng)，直接 mapping 到 ES 中，剛開始我甚至還用到了 filebeat，先用 filebeat 監(jiān)控文件，然后 filebeat output 給 logstash，然后 logstash 再 output 給 ES，簡(jiǎn)直了，測(cè)試的時(shí)候沒什么問題，但一上線過了兩三天日志數(shù)量多了起來(lái)我就發(fā)現(xiàn)問題了，數(shù)量不對(duì)，每天都在累加前一天的日志條數(shù)，等于說(shuō)是 tail 文件沒成功，每次都從頭開始讀文件了，外加用了 rsync 這個(gè)東西從生產(chǎn)服務(wù)器上同步日志到 ES 機(jī)器上，我也沒整明白到底是哪里出了問題，索性直接棄用 logstash 和 filebeat，只用 ES 和 kibana，我自己寫腳本監(jiān)控文件、把日志寫入 ES 中，也把日志按天切分成文件，簡(jiǎn)單又靠譜。

運(yùn)營(yíng)數(shù)據(jù)日志的日志內(nèi)容其實(shí)和消息系統(tǒng)很像，我就直接引用這里的概念 AVOT，Actor/Verb/Object/Target。舉例說(shuō)明: xxx 關(guān)注了 yyy，xxx 是 Actor，關(guān)注 是 Verb，yyy 是 Target，這里沒有 Object，再舉一個(gè)例子，xxx 將 uuu 添加到了 yyy 中，這里的 Verb 是 添加，Object 是 uuu，Actor/Object/Target 就是模型，當(dāng)然我們不用把模型的全部字段都放進(jìn)去，放個(gè) type/id/name 就夠了。按照這樣的規(guī)則規(guī)定好日志內(nèi)容之后就簡(jiǎn)單了，在每個(gè)需要記錄日志的地方進(jìn)行埋點(diǎn)，這個(gè)就是比較麻煩的地方，如果業(yè)務(wù)比較復(fù)雜的化，埋點(diǎn)很多，寫的時(shí)候一定要一次性寫對(duì) Object 和 Target，不要寫了一次之后復(fù)制粘貼，很容易搞錯(cuò)，一個(gè)個(gè)寫。還有一點(diǎn)就是 Actor/Object/Target 的 id 都轉(zhuǎn)成字符串存儲(chǔ)，因?yàn)橛脩舻?id 是 uuid，日志 object 直接 to_json()，django logger 直接用，用戶 id 會(huì)變成字符串，其他 model 的 id 還是 int，類型如果不一致再存到 ES 里面數(shù)據(jù)會(huì)有沖突。

最終的日志格式示例：

{"target": {"type": "Paper", "title": "Deep Depth Super-Resolution : Learning Depth Super-Resolution using Deep  Convolutional Neural Network", "id": "791", "owner": "MKFMIKU"}, "object": {}, "actor": {"agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36", "accept_language": "en-US,en;q=0.8", "username": "qhl722", "host": "zijin.paperweekly.site", "referer": "http://www.paperweekly.site/getting-started"}, "verb": "點(diǎn)贊", "time": 1507000406.305043}
{"target": {"type": "User", "id": "fcc3837f-1a61-4d2c-bdbf-0961085547a3", "owner": "gg5d"}, "object": {}, "actor": {"agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36", "accept_language": "zh-CN,zh;q=0.8", "username": "", "host": "zijin.paperweekly.site", "referer": "http://www.paperweekly.site/"}, "verb": "注冊(cè)", "time": 1507000688.429523}

我用了 Elasticsearch 的官方 Python API elasticsearch-py，腳本放在了 Gist 里面。

日志存到 ES 中是這個(gè)樣子：

Kibana 是一個(gè)可是化工具，能看到 ES 中的數(shù)據(jù)，做一些報(bào)表，只要把數(shù)據(jù)導(dǎo)入到 ES 中，做報(bào)表就很簡(jiǎn)單了，簡(jiǎn)單的也是有前提的，前提是你要定義好日志的內(nèi)容。

比如點(diǎn)贊數(shù)量，在 Visualize 里面新建一個(gè)柱狀圖，搜索 item.verb="點(diǎn)贊"，然后第一個(gè) Y 軸聚合搜索出來(lái)的日志條數(shù)，就是點(diǎn)贊的數(shù)量，再添加一個(gè) Y 軸 Unique Count item.actor.username.keyword 就能得出多少個(gè)用戶產(chǎn)生了這么多贊，X 軸就是按照時(shí)間，我都是按天來(lái)，選擇 Date Histogram，Interval選 Daily，如果你的日志系統(tǒng)要求的實(shí)時(shí)性比較高，還能選擇 Hourly，然后把實(shí)時(shí)刷新打開，就能看到比較實(shí)時(shí)的數(shù)據(jù)了。

Kibana 最終是這個(gè)樣子：

過幾天我把這個(gè)東西拆分出來(lái)變成一個(gè)倉(cāng)庫(kù)再詳細(xì)寫一下教程。