我們都有過上機(jī)器查日志的經(jīng)歷,當(dāng)集群數(shù)量增多的時候,這種原始的操作帶來的低效率不僅給我們定位現(xiàn)網(wǎng)問題帶來極大的挑戰(zhàn),同時,我們也無法對我們服務(wù)框架的各項指標(biāo)進(jìn)行有效的量化診斷,更無從談有針對性的優(yōu)化和改進(jìn)。這個時候,構(gòu)建具備信息查找,服務(wù)診斷,數(shù)據(jù)分析等功能的實時日志監(jiān)控系統(tǒng)尤為重要。
“只有客戶發(fā)展了,才有我們的生存與發(fā)展!”這是創(chuàng)新互聯(lián)建站的服務(wù)宗旨!把網(wǎng)站當(dāng)作互聯(lián)網(wǎng)產(chǎn)品,產(chǎn)品思維更注重全局思維、需求分析和迭代思維,在網(wǎng)站建設(shè)中就是為了建設(shè)一個不僅審美在線,而且實用性極高的網(wǎng)站。創(chuàng)新互聯(lián)對網(wǎng)站設(shè)計、做網(wǎng)站、網(wǎng)站制作、網(wǎng)站開發(fā)、網(wǎng)頁設(shè)計、網(wǎng)站優(yōu)化、網(wǎng)絡(luò)推廣、探索永無止境。
ELK (ELK Stack: ElasticSearch, LogStash, Kibana, Beats) 是一套成熟的日志解決方案,其開源及高性能在各大公司廣泛使用。而我們業(yè)務(wù)所使用的服務(wù)框架,如何接入 ELK 系統(tǒng)呢?
業(yè)務(wù)背景
我們的業(yè)務(wù)框架背景:
我們將整個框架接入 ELK 簡單歸納為下面幾個步驟:
一、日志結(jié)構(gòu)設(shè)計
傳統(tǒng)的,我們在做日志輸出的時候,是直接輸出日志的等級(level)和日志的內(nèi)容字符串(message)。然而我們不僅關(guān)注什么時間,發(fā)生了什么,可能還需要關(guān)注類似的日志發(fā)生了多少次,日志的細(xì)節(jié)與上下文,以及關(guān)聯(lián)的日志。 因此我們不只是簡單地將我們的日志結(jié)構(gòu)化一下為對象,還要提取出日志關(guān)鍵的字段。
1. 將日志抽象為事件
我們將每一條日志的發(fā)生都抽像為一個事件。事件包含:
事件元字段
請求元字段
數(shù)據(jù)字段
不同類型的事件,需要輸出的細(xì)節(jié)不盡相同,我們將這些細(xì)節(jié)(非元字段)統(tǒng)一放到d -- data,之中。使我們的事件結(jié)構(gòu)更加清晰,同時,也能避免數(shù)據(jù)字段對元字段造成污染。
e.g. 如 client-init
事件,該事件會在每次服務(wù)器接收到用戶請求時打印,我們將用戶的 ip
, url
等事件獨有的統(tǒng)一歸為數(shù)據(jù)字段放到 d
對象中
舉個完整的例子
{ "datetime":"2018-11-07 21:38:09.271", "timestamp":1541597889271, "level":"INFO", "event":"client-init", "reqId":"rJtT5we6Q", "reqLife":5874, "reqUid": "999793fc03eda86", "d":{ "url":"/", "ip":"9.9.9.9", "httpVersion":"1.1", "method":"GET", "userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36", "headers":"*" }, "browser":"{"name":"Chrome","version":"70.0.3538.77","major":"70"}", "engine":"{"version":"537.36","name":"WebKit"}", "os":"{"name":"Mac OS","version":"10.14.0"}", "content":"(Empty)", "line":"middlewares/foo.js:14", "server":"127.0.0.1" }
一些字段,如:browser, os, engine為什么在外層 有時候我們希望日志盡量扁平(最大深度為2),以避免 ES 不必要的索引帶來的性能損耗。在實際輸出的時候,我們會將深度大于1的值輸出為字符串。而有時候一些對象字段是我們關(guān)注的,所以我們將這些特殊字段放在外層,以保證輸出深度不大于2的原則。
一般的,我們在打印輸出日志的時候,只須關(guān)注事件名稱
及數(shù)據(jù)字段
即可。其他,我們可以在打印日志的方法中,通過訪問上下文統(tǒng)一獲取,計算,輸出。
2. 日志改造輸出
前面我們提到了如何定義一個日志事件, 那么,我們?nèi)绾位谝延腥罩痉桨缸錾?,同時,兼容舊代碼的日志調(diào)用方式。
升級關(guān)鍵節(jié)點的日志
// 改造前 logger.info('client-init => ' + JSON.stringfiy({ url, ip, browser, //... })); // 改造后 logger.info({ event: 'client-init', url, ip, browser, //... });
兼容舊的日志調(diào)用方式
logger.debug('checkLogin');
因為 winston 的 日志方法本身就支持 string
或者 object
的傳入方式, 所以對于舊的字符串傳入寫法,formatter 接收到的實際上是{ level: 'debug', message: 'checkLogin' }
。formatter 是 winston 的日志輸出前調(diào)整日志格式的一道工序, 這一點使我們在日志輸出前有機(jī)會將這類調(diào)用方式輸出的日志,轉(zhuǎn)為一個純輸出事件 -- 我們稱它們?yōu)?code>raw-log事件,而不需要修改調(diào)用方式。
改造日志輸出格式
前面提到 winston 輸出日志前,會經(jīng)過我們預(yù)定義的formatter,因此除了兼容邏輯的處理外,我們可以將一些公共邏輯統(tǒng)一放在這里處理。而調(diào)用上,我們只關(guān)注字段本身即可。
如何提取元字段,這里涉及上下文的創(chuàng)建與使用,這里簡單介紹一下 domain 的創(chuàng)建與使用。
//--- middlewares/http-context.js const domain = require('domain'); const shortid = require('shortid'); module.exports = (req, res, next) => { const d = domain.create(); d.id = shortid.generate(); // reqId; d.req = req; //... res.on('finish', () => process.nextTick(() => { d.id = null; d.req = null; d.exit(); }); d.run(() => next()); } //--- app.js app.use(require('./middlewares/http-context.js')); //--- formatter.js if (process.domain) { reqId = process.domain.id; }
這樣,我們就可以將 reqId
輸出到一次請求中所有的事件, 從而達(dá)到關(guān)聯(lián)事件的目的。
二、日志采集
現(xiàn)在,我們知道怎么輸出一個事件了,那么下一步,我們該考慮兩個問題:
換句話說,整個請求鏈路中,哪些節(jié)點是我們關(guān)注的,出現(xiàn)問題,可以通過哪個節(jié)點的信息快速定位到問題?除此之外,我們還可以通過哪些節(jié)點的數(shù)據(jù)做統(tǒng)計分析?
結(jié)合一般常見的請求鏈路(用戶請求,服務(wù)側(cè)接收請求,服務(wù)請求下游服務(wù)器/數(shù)據(jù)庫(*多次),數(shù)據(jù)聚合渲染,服務(wù)響應(yīng)),如下方的流程圖
流程圖
那么,我們可以這樣定義我們的事件:
用戶請求
下游依賴
字段這么多,該怎么選擇? 一言以蔽之,事件輸出的字段原則就是:輸出你關(guān)注的,方便檢索的,方便后期聚合的字段。
一些建議
請求下游的請求體和返回體有固定格式, e.g. 輸入:{ action: 'getUserInfo', payload: {} }
輸出: { code: 0, msg: '', data: {}}
我們可以在事件輸出 action,code 等,以便后期通過 action 檢索某模塊具體某個接口的各項指標(biāo)和聚合。
一些原則
保證輸出字段類型一致 由于所有事件都存儲在同一個 ES 索引, 因此,相同字段不管是相同事件還是不同事件,都應(yīng)該保持一致,例如:code不應(yīng)該既是數(shù)字,又是字符串,這樣可能會產(chǎn)生字段沖突,導(dǎo)致某些記錄(document)無法被沖突字段檢索到。ES 存儲類型為 keyword, 不應(yīng)該超過ES mapping 設(shè)定的 ignore_above
中指定的字節(jié)數(shù)(默認(rèn)4096個字節(jié))。否則同樣可能會產(chǎn)生無法被檢索的情況三、ES 索引模版定義
這里引入 ES 的兩個概念,映射(Mapping)與模版(Template)。
首先,ES 基本的存儲類型大概枚舉下,有以下幾種
一般的,我們不需要顯示指定每個事件字段的在ES對應(yīng)的存儲類型,ES 會自動根據(jù)字段第一次出現(xiàn)的document中的值來決定這個字段在這個索引中的存儲類型。但有時候,我們需要顯示指定某些字段的存儲類型,這個時候我們需要定義這個索引的 Mapping, 來告訴 ES 這此字段如何存儲以及如何索引。
e.g.
還記得事件元字段中有一個字段為 timestamp ?實際上,我們輸出的時候,timestamp 的值是一個數(shù)字,它表示跟距離 1970/01/01 00:00:00 的毫秒數(shù),而我們期望它在ES的存儲類型為 date 類型方便后期的檢索和可視化, 那么我們創(chuàng)建索引的時候,指定我們的Mapping。
PUT my_logs { "mappings": { "_doc": { "properties": { "title": { "type": "date", "format": "epoch_millis" }, } } } }
但一般的,我們可能會按日期自動生成我們的日志索引,假定我們的索引名稱格式為 my_logs_yyyyMMdd (e.g. my_logs_20181030)。那么我們需要定義一個模板(Template),這個模板會在(匹配的)索引創(chuàng)建時自動應(yīng)用預(yù)設(shè)好的 Mapping。
PUT _template/my_logs_template { "index_patterns": "my_logs*", "mappings": { "_doc": { "properties": { "title": { "type": "date", "format": "epoch_millis" }, } } } }
提示:將所有日期產(chǎn)生的日志都存在一張索引中,不僅帶來不必要的性能開銷,也不利于定期刪除比較久遠(yuǎn)的日志。
小結(jié)
至此,日志改造及接入的準(zhǔn)備工作都已經(jīng)完成了,我們只須在機(jī)器上安裝 FileBeat -- 一個輕量級的文件日志Agent, 它負(fù)責(zé)將日志文件中的日志傳輸?shù)?ELK。接下來,我們便可使用 Kibana 快速的檢索我們的日志。
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持創(chuàng)新互聯(lián)。