資訊專欄INFORMATION COLUMN
摘要：我會寫一些是后端技術(shù)前端工程相關(guān)的文章，偶爾會有一些大數(shù)據(jù)相關(guān)，也會推薦一些好玩的東西。
Nginx作為所有HTTP請求的入口，是非常重要的一層。本文主要介紹如何利用 Nginx日志實時監(jiān)控每個業(yè)務(wù)的請求異常。?
這篇文章基于我之前的的一篇 《基于Lua+Kafka+Heka的Nginx Log實時監(jiān)控系統(tǒng)》 整理而來。
你可以掃描文章末尾的二維碼關(guān)注我的關(guān)注我的公眾號，內(nèi)容大多會是后端技術(shù)、前端工程、DevOps，偶爾會有一些大數(shù)據(jù)相關(guān)，會推薦一些好玩的東西。希望你會喜歡~
Nginx 由于其出色的性能，在互聯(lián)網(wǎng)中被廣泛應(yīng)用，它通常會作為 HTTP 接入層負(fù)責(zé)分流及靜態(tài)文件處理。因此，每天會產(chǎn)生大量的日志，而這些日志是可以產(chǎn)生很多價值的，比如用來做用戶行為分析、服務(wù)性能質(zhì)量分析，以及本文要介紹的異常監(jiān)控。
一條訪問日志通常會記錄用戶請求來源、目標(biāo)資源、設(shè)備信息、響應(yīng)狀態(tài)等，這里主要關(guān)注異常的響應(yīng)狀態(tài)碼如500，另外一個是upstream_response_time，它反映了后端服務(wù)的響應(yīng)速度。所以，這里主要是做兩件事情：1. 監(jiān)控錯誤；2. 監(jiān)控慢的響應(yīng)。最終的目標(biāo)是要監(jiān)測到哪個模塊出了什么異常，問題出現(xiàn)在哪臺機(jī)器上。
我先假設(shè)目前只有一個 Nginx 節(jié)點且QPS 不高，不用太考慮性能問題，那么最簡單的做法是寫個腳本每分鐘計算一下500狀態(tài)碼的數(shù)量，超過預(yù)設(shè)閥值則發(fā)送告警郵件，郵件內(nèi)容要盡量詳細(xì)，比如模塊名、錯誤數(shù)量、告警級別等，并且把異常的日志輸出到另外一份文件方便排查。慢響應(yīng)的監(jiān)控同理，根據(jù) upstream_response_time 計算出慢的數(shù)量，以及平均值。
大流量場景的應(yīng)對方案以上的做法基本夠一些小流量場景使用，但是當(dāng)單節(jié)點無法滿足需求及遇到大流量時，這種方案就會有些吃力了，比如性能上，比如指標(biāo)的聚合計算。針對新的應(yīng)對方案，我簡單畫了一張圖：
這個方案中自下而上依次是 Nginx集群 -> 日志采集 -> 消息隊列 -> 指標(biāo)計算與輸出 -> 可視化 。下面我分別介紹一下各階段的做法。
日志采集可選擇的工具比較多，比如 logstash、flume 等，我推薦使用 lua-resty-kafka 模塊編寫Lua擴(kuò)展將數(shù)據(jù)按照一定格式拼接后寫入消息隊列。而且也完全可以關(guān)掉 Nginx 本身的日志開關(guān)，減少磁盤消耗。
消息隊列可以選擇 Redis 或者 Kafka，主要取決于你們是否需要對日志做其它的利用。Redis 輕量級一些，Kafka的優(yōu)勢是高吞吐量、分布式架構(gòu), 并且除了做異常監(jiān)控，還可以將數(shù)據(jù)放到 Hadoop/離線數(shù)據(jù)倉庫中做用戶行為分析。
異常監(jiān)控計算這一步其實和最開始的簡單方案的類似，需要實現(xiàn)指標(biāo)計算、告警發(fā)送和異常數(shù)據(jù)輸出保存。如果日志采集時使用了logstash，那么這一步也推薦使用logstash保持一致，具體做法我就不多說了，看官方文檔吧。但如果是使用Lua擴(kuò)展采集的自定義格式數(shù)據(jù)，我推薦使用Heka來做。Heka使用Go語言編寫，性能不錯，內(nèi)置豐富的插件可以滿足大部分的需求。若不滿足需求，可以使用Go或者Lua自行開發(fā)擴(kuò)展。在Filter階段做指標(biāo)計算，有錯誤時向Heka消息流中寫入告警消息，SMTPOuter匹配到告警消息后通過自定義的Encoder定制好郵件內(nèi)容后發(fā)送，使用ElasticSearchOutput匹配異常數(shù)據(jù)寫入ES節(jié)點。
可視化前面使用Message Matcher Syntax匹配異常數(shù)據(jù)寫入到Elasticsearch后, 搭建一個Kibana。這樣在收到告警郵件后，就可以進(jìn)入Kibana后臺查看異常的Log。還可以定制一些圖表以查看系統(tǒng)的錯誤趨勢情況。
其它改進(jìn)我建議不要直接使用 Heka 發(fā)送郵件，不然可能會遇到郵件轟炸。可以通過 HTTP 接口將告警消息寫到另外一個服務(wù)，在那里做一些告警策略和頻率控制，以及恢復(fù)檢查。
需要對 Heka 進(jìn)程監(jiān)控，支持自動重啟，不然進(jìn)程掛了都不知道；
總結(jié)這個方案的主要開發(fā)點在Nginx Lua擴(kuò)展和 Heka 的擴(kuò)展。Nginx Lua 相對簡單些，然后就是熟悉Heka的整個消息處理的流程和機(jī)制，以及如何開發(fā)插件。另一個比較坑的是Heka的錯誤提示不全，而且調(diào)試不方便，有時完全靠猜，不過好在它本身并沒有多復(fù)雜，有些問題看一看源代碼就明白了。
微信掃描二維碼，關(guān)注我。
我會寫一些是后端技術(shù)、前端工程、DevOps相關(guān)的文章，偶爾會有一些大數(shù)據(jù)相關(guān)，也會推薦一些好玩的東西。希望你會喜歡~
一切，源于喜歡。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/39252.html
摘要：目的錯誤碼告警和超時告警超時告警數(shù)據(jù)分析關(guān)于錯誤和超時監(jiān)控有一點要考慮的是收到告警時，要能夠快速知道是哪個后端服務(wù)節(jié)點出現(xiàn)了問題。關(guān)于消息隊列的選擇，前面已經(jīng)提到我們已有集群就直接拿來用了。 背景 在我們的系統(tǒng)架構(gòu)中，Nginx作為所有HTTP請求的入口，是非常重要的一層。每天產(chǎn)生大量的Nginx Access Log，閑置在硬盤上實在是太浪費資源了。所以，能不能把Nginx日志利用起...
摘要：是由淘寶網(wǎng)發(fā)起的服務(wù)器項目?；卦幢O(jiān)控是內(nèi)容分發(fā)網(wǎng)絡(luò)的簡稱，其分發(fā)的內(nèi)容來自用戶源站，負(fù)責(zé)回源的模塊是最重要組成部分之一，使跨越單機(jī)的限制，完成網(wǎng)絡(luò)數(shù)據(jù)的接收處理和轉(zhuǎn)發(fā)。這部分主要介紹的一些調(diào)試技巧和回源資源監(jiān)控的內(nèi)容，以及相應(yīng)的實例分享。 摘要： Tengine是由淘寶網(wǎng)發(fā)起的Web服務(wù)器項目。它在Nginx的基礎(chǔ)上，針對大訪問量網(wǎng)站的需求，提供更強(qiáng)大的流量負(fù)載均衡能力、全站HTTPS...
閱讀 1779·2021-11-12 10:35
閱讀 1702·2021-08-03 14:02
閱讀 2769·2019-08-30 15:55
閱讀 2099·2019-08-30 15:54
閱讀 838·2019-08-30 14:01
閱讀 2490·2019-08-29 17:07
閱讀 2311·2019-08-26 18:37
閱讀 3105·2019-08-26 16:51
