腳本之家服務器常用軟件

快捷導航

淺談Node框架接入ELK實踐總結

更新時間：2019年02月22日 10:53:33 作者：騰訊云加社區(qū)

這篇文章主要介紹了淺談Node框架接入ELK實踐總結，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

我們都有過上機器查日志的經(jīng)歷，當集群數(shù)量增多的時候，這種原始的操作帶來的低效率不僅給我們定位現(xiàn)網(wǎng)問題帶來極大的挑戰(zhàn)，同時，我們也無法對我們服務框架的各項指標進行有效的量化診斷，更無從談有針對性的優(yōu)化和改進。這個時候，構建具備信息查找，服務診斷，數(shù)據(jù)分析等功能的實時日志監(jiān)控系統(tǒng)尤為重要。

ELK （ELK Stack: ElasticSearch, LogStash, Kibana, Beats）是一套成熟的日志解決方案，其開源及高性能在各大公司廣泛使用。而我們業(yè)務所使用的服務框架，如何接入 ELK 系統(tǒng)呢？

業(yè)務背景

我們的業(yè)務框架背景：

業(yè)務框架是基于 NodeJs 的 WebServer
服務使用 winston 日志模塊將日志本地化
服務產(chǎn)生的日志存儲在各自機器的磁盤上
服務部署在不同地域多臺機器

我們將整個框架接入 ELK 簡單歸納為下面幾個步驟：

日志結構設計：由傳統(tǒng)的純文本日志改成結構化對象并輸出為 JSON.
日志采集：在框架請求生命周期的一些關鍵節(jié)點輸出日志
ES 索引模版定義：建立 JSON 到 ES 實際存儲的映射

一、日志結構設計

傳統(tǒng)的，我們在做日志輸出的時候，是直接輸出日志的等級（level）和日志的內容字符串（message）。然而我們不僅關注什么時間，發(fā)生了什么，可能還需要關注類似的日志發(fā)生了多少次，日志的細節(jié)與上下文，以及關聯(lián)的日志。因此我們不只是簡單地將我們的日志結構化一下為對象，還要提取出日志關鍵的字段。

1. 將日志抽象為事件

我們將每一條日志的發(fā)生都抽像為一個事件。事件包含：

事件元字段

事件發(fā)生時間：datetime, timestamp
事件等級：level，例如: ERROR, INFO, WARNING, DEBUG
事件名稱: event, 例如：client-request
事件發(fā)生的相對時間（單位：納秒）：reqLife, 此字段為事件相對請求開始發(fā)生的時間（間隔）
事件發(fā)生的位置: line，代碼位置; server, 服務器的位置

請求元字段

請求唯一ID: reqId, 此字段貫穿整個請求鏈路上發(fā)生的所有事件
請求用戶ID: reqUid, 此字段為用戶標識，可以跟蹤用戶的訪問或請求鏈路

數(shù)據(jù)字段

不同類型的事件，需要輸出的細節(jié)不盡相同，我們將這些細節(jié)（非元字段）統(tǒng)一放到d -- data，之中。使我們的事件結構更加清晰，同時，也能避免數(shù)據(jù)字段對元字段造成污染。

e.g. 如 client-init事件，該事件會在每次服務器接收到用戶請求時打印，我們將用戶的 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的值輸出為字符串。而有時候一些對象字段是我們關注的，所以我們將這些特殊字段放在外層，以保證輸出深度不大于2的原則。

一般的，我們在打印輸出日志的時候，只須關注事件名稱及數(shù)據(jù)字段即可。其他，我們可以在打印日志的方法中，通過訪問上下文統(tǒng)一獲取，計算，輸出。

2. 日志改造輸出

前面我們提到了如何定義一個日志事件，那么，我們如何基于已有日志方案做升級，同時，兼容舊代碼的日志調用方式。

升級關鍵節(jié)點的日志

// 改造前
logger.info('client-init => ' + JSON.stringfiy({
  url,
  ip,
  browser,
  //...
}));

// 改造后
logger.info({
  event: 'client-init',
  url,
  ip,
  browser,
  //...
});

兼容舊的日志調用方式

logger.debug('checkLogin');

因為 winston 的日志方法本身就支持 string 或者 object 的傳入方式, 所以對于舊的字符串傳入寫法，formatter 接收到的實際上是{ level: 'debug', message: 'checkLogin' }。formatter 是 winston 的日志輸出前調整日志格式的一道工序，這一點使我們在日志輸出前有機會將這類調用方式輸出的日志，轉為一個純輸出事件 -- 我們稱它們?yōu)?code>raw-log事件，而不需要修改調用方式。

改造日志輸出格式

前面提到 winston 輸出日志前，會經(jīng)過我們預定義的formatter，因此除了兼容邏輯的處理外，我們可以將一些公共邏輯統(tǒng)一放在這里處理。而調用上，我們只關注字段本身即可。

元字段提取及處理
字段長度控制
兼容邏輯處理

如何提取元字段，這里涉及上下文的創(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 輸出到一次請求中所有的事件, 從而達到關聯(lián)事件的目的。

二、日志采集

現(xiàn)在，我們知道怎么輸出一個事件了，那么下一步，我們該考慮兩個問題：

我們要在哪里輸出事件？
事件要輸出什么細節(jié)？

換句話說，整個請求鏈路中，哪些節(jié)點是我們關注的，出現(xiàn)問題，可以通過哪個節(jié)點的信息快速定位到問題？除此之外，我們還可以通過哪些節(jié)點的數(shù)據(jù)做統(tǒng)計分析？

結合一般常見的請求鏈路（用戶請求，服務側接收請求，服務請求下游服務器/數(shù)據(jù)庫（*多次），數(shù)據(jù)聚合渲染，服務響應），如下方的流程圖

流程圖

那么，我們可以這樣定義我們的事件：

用戶請求

client-init: 打印于框架接收到請求（未解析），包括：請求地址，請求頭，Http 版本和方法，用戶 IP 和瀏覽器
client-request: 打印于框架接收到請求（已解析），包括：請求地址，請求頭，Cookie, 請求包體
client-response: 打印于框架返回請求，包括：請求地址，響應碼，響應頭，響應包體

下游依賴

http-start: 打印于請求下游起始：請求地址，請求包體，模塊別名（方便基于名字聚合而且域名）
http-success: 打印于請求返回 200：請求地址，請求包體，響應包體(code & msg & data)，耗時
http-error: 打印于請求返回非 200，亦即連接服務器失?。赫埱蟮刂?，請求包體，響應包體(code & message & stack)，耗時。
http-timeout: 打印于請求連接超時：請求地址，請求包體，響應包體(code & msg & stack)，耗時。

字段這么多，該怎么選擇？一言以蔽之，事件輸出的字段原則就是：輸出你關注的，方便檢索的，方便后期聚合的字段。

一些建議

請求下游的請求體和返回體有固定格式， e.g. 輸入：{ action: 'getUserInfo', payload: {} } 輸出: { code: 0, msg: '', data: {}} 我們可以在事件輸出 action，code 等，以便后期通過 action 檢索某模塊具體某個接口的各項指標和聚合。

一些原則

保證輸出字段類型一致由于所有事件都存儲在同一個 ES 索引，因此，相同字段不管是相同事件還是不同事件，都應該保持一致，例如：code不應該既是數(shù)字，又是字符串，這樣可能會產(chǎn)生字段沖突，導致某些記錄（document）無法被沖突字段檢索到。ES 存儲類型為 keyword, 不應該超過ES mapping 設定的 ignore_above 中指定的字節(jié)數(shù)（默認4096個字節(jié)）。否則同樣可能會產(chǎn)生無法被檢索的情況三、ES 索引模版定義

這里引入 ES 的兩個概念，映射(Mapping)與模版(Template)。

首先，ES 基本的存儲類型大概枚舉下，有以下幾種

String: keyword & text
Numeric: long, integer, double
Date: date
Boolean: boolean

一般的，我們不需要顯示指定每個事件字段的在ES對應的存儲類型，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)建時自動應用預設好的 Mapping。

PUT _template/my_logs_template
{
 "index_patterns": "my_logs*",
 "mappings": {
  "_doc": { 
   "properties": { 
    "title":  {
      "type": "date",
      "format": "epoch_millis"
     }, 
   }
  }
 }
}