摘要：我會(huì)寫(xiě)一些是后端技術(shù)前端工程相關(guān)的文章，偶爾會(huì)有一些大數(shù)據(jù)相關(guān)，也會(huì)推薦一些好玩的東西。

Nginx作為所有HTTP請(qǐng)求的入口，是非常重要的一層。本文主要介紹如何利用 Nginx日志實(shí)時(shí)監(jiān)控每個(gè)業(yè)務(wù)的請(qǐng)求異常。?

這篇文章基于我之前的的一篇 《基于Lua+Kafka+Heka的Nginx Log實(shí)時(shí)監(jiān)控系統(tǒng)》 整理而來(lái)。

你可以掃描文章末尾的二維碼關(guān)注我的關(guān)注我的公眾號(hào)，內(nèi)容大多會(huì)是后端技術(shù)、前端工程、DevOps，偶爾會(huì)有一些大數(shù)據(jù)相關(guān)，會(huì)推薦一些好玩的東西。希望你會(huì)喜歡~

Nginx 由于其出色的性能，在互聯(lián)網(wǎng)中被廣泛應(yīng)用，它通常會(huì)作為 HTTP 接入層負(fù)責(zé)分流及靜態(tài)文件處理。因此，每天會(huì)產(chǎn)生大量的日志，而這些日志是可以產(chǎn)生很多價(jià)值的，比如用來(lái)做用戶行為分析、服務(wù)性能質(zhì)量分析，以及本文要介紹的異常監(jiān)控。
一條訪問(wèn)日志通常會(huì)記錄用戶請(qǐng)求來(lái)源、目標(biāo)資源、設(shè)備信息、響應(yīng)狀態(tài)等，這里主要關(guān)注異常的響應(yīng)狀態(tài)碼如500，另外一個(gè)是upstream_response_time，它反映了后端服務(wù)的響應(yīng)速度。所以，這里主要是做兩件事情：1. 監(jiān)控錯(cuò)誤；2. 監(jiān)控慢的響應(yīng)。最終的目標(biāo)是要監(jiān)測(cè)到哪個(gè)模塊出了什么異常，問(wèn)題出現(xiàn)在哪臺(tái)機(jī)器上。

我先假設(shè)目前只有一個(gè) Nginx 節(jié)點(diǎn)且QPS 不高，不用太考慮性能問(wèn)題，那么最簡(jiǎn)單的做法是寫(xiě)個(gè)腳本每分鐘計(jì)算一下500狀態(tài)碼的數(shù)量，超過(guò)預(yù)設(shè)閥值則發(fā)送告警郵件，郵件內(nèi)容要盡量詳細(xì)，比如模塊名、錯(cuò)誤數(shù)量、告警級(jí)別等，并且把異常的日志輸出到另外一份文件方便排查。慢響應(yīng)的監(jiān)控同理，根據(jù) upstream_response_time 計(jì)算出慢的數(shù)量，以及平均值。

以上的做法基本夠一些小流量場(chǎng)景使用，但是當(dāng)單節(jié)點(diǎn)無(wú)法滿足需求及遇到大流量時(shí)，這種方案就會(huì)有些吃力了，比如性能上，比如指標(biāo)的聚合計(jì)算。針對(duì)新的應(yīng)對(duì)方案，我簡(jiǎn)單畫(huà)了一張圖：

這個(gè)方案中自下而上依次是 Nginx集群 -> 日志采集 -> 消息隊(duì)列 -> 指標(biāo)計(jì)算與輸出 -> 可視化 。下面我分別介紹一下各階段的做法。

可選擇的工具比較多，比如 logstash、flume 等，我推薦使用 lua-resty-kafka 模塊編寫(xiě)Lua擴(kuò)展將數(shù)據(jù)按照一定格式拼接后寫(xiě)入消息隊(duì)列。而且也完全可以關(guān)掉 Nginx 本身的日志開(kāi)關(guān)，減少磁盤(pán)消耗。

可以選擇 Redis 或者 Kafka，主要取決于你們是否需要對(duì)日志做其它的利用。Redis 輕量級(jí)一些，Kafka的優(yōu)勢(shì)是高吞吐量、分布式架構(gòu), 并且除了做異常監(jiān)控，還可以將數(shù)據(jù)放到 Hadoop/離線數(shù)據(jù)倉(cāng)庫(kù)中做用戶行為分析。

這一步其實(shí)和最開(kāi)始的簡(jiǎn)單方案的類似，需要實(shí)現(xiàn)指標(biāo)計(jì)算、告警發(fā)送和異常數(shù)據(jù)輸出保存。如果日志采集時(shí)使用了logstash，那么這一步也推薦使用logstash保持一致，具體做法我就不多說(shuō)了，看官方文檔吧。但如果是使用Lua擴(kuò)展采集的自定義格式數(shù)據(jù)，我推薦使用Heka來(lái)做。Heka使用Go語(yǔ)言編寫(xiě)，性能不錯(cuò)，內(nèi)置豐富的插件可以滿足大部分的需求。若不滿足需求，可以使用Go或者Lua自行開(kāi)發(fā)擴(kuò)展。在Filter階段做指標(biāo)計(jì)算，有錯(cuò)誤時(shí)向Heka消息流中寫(xiě)入告警消息，SMTPOuter匹配到告警消息后通過(guò)自定義的Encoder定制好郵件內(nèi)容后發(fā)送，使用ElasticSearchOutput匹配異常數(shù)據(jù)寫(xiě)入ES節(jié)點(diǎn)。

前面使用Message Matcher Syntax匹配異常數(shù)據(jù)寫(xiě)入到Elasticsearch后, 搭建一個(gè)Kibana。這樣在收到告警郵件后，就可以進(jìn)入Kibana后臺(tái)查看異常的Log。還可以定制一些圖表以查看系統(tǒng)的錯(cuò)誤趨勢(shì)情況。

我建議不要直接使用 Heka 發(fā)送郵件，不然可能會(huì)遇到郵件轟炸?？梢酝ㄟ^(guò) HTTP 接口將告警消息寫(xiě)到另外一個(gè)服務(wù)，在那里做一些告警策略和頻率控制，以及恢復(fù)檢查。

需要對(duì) Heka 進(jìn)程監(jiān)控，支持自動(dòng)重啟，不然進(jìn)程掛了都不知道；

這個(gè)方案的主要開(kāi)發(fā)點(diǎn)在Nginx Lua擴(kuò)展和 Heka 的擴(kuò)展。Nginx Lua 相對(duì)簡(jiǎn)單些，然后就是熟悉Heka的整個(gè)消息處理的流程和機(jī)制，以及如何開(kāi)發(fā)插件。另一個(gè)比較坑的是Heka的錯(cuò)誤提示不全，而且調(diào)試不方便，有時(shí)完全靠猜，不過(guò)好在它本身并沒(méi)有多復(fù)雜，有些問(wèn)題看一看源代碼就明白了。

微信掃描二維碼，關(guān)注我。

我會(huì)寫(xiě)一些是后端技術(shù)、前端工程、DevOps相關(guān)的文章，偶爾會(huì)有一些大數(shù)據(jù)相關(guān)，也會(huì)推薦一些好玩的東西。希望你會(huì)喜歡~

一切，源于喜歡。