資訊專欄INFORMATION COLUMN
摘要：目的錯(cuò)誤碼告警和超時(shí)告警超時(shí)告警數(shù)據(jù)分析關(guān)于錯(cuò)誤和超時(shí)監(jiān)控有一點(diǎn)要考慮的是收到告警時(shí)，要能夠快速知道是哪個(gè)后端服務(wù)節(jié)點(diǎn)出現(xiàn)了問題。關(guān)于消息隊(duì)列的選擇，前面已經(jīng)提到我們已有集群就直接拿來用了。
背景
在我們的系統(tǒng)架構(gòu)中，Nginx作為所有HTTP請求的入口，是非常重要的一層。每天產(chǎn)生大量的Nginx Access Log，閑置在硬盤上實(shí)在是太浪費(fèi)資源了。所以，能不能把Nginx日志利用起來，實(shí)時(shí)監(jiān)控每個(gè)業(yè)務(wù)的訪問趨勢、用戶行為、請求質(zhì)量和后端異常呢，這就是本文要探討的主題。
目的錯(cuò)誤碼告警（499、500、502和504）；
upstream_response_time超時(shí)告警；
request_time超時(shí)告警；
數(shù)據(jù)分析；
關(guān)于錯(cuò)誤和超時(shí)監(jiān)控有一點(diǎn)要考慮的是收到告警時(shí)，要能夠快速知道是哪個(gè)后端服務(wù)節(jié)點(diǎn)出現(xiàn)了問題。
在這之前，我們都是通過隨機(jī)進(jìn)入一個(gè)Nginx節(jié)點(diǎn)tail log才能定位到，效率有些低。
廢話不多說，先上架構(gòu)圖。整體架構(gòu)沒太復(fù)雜的地方，隨便畫了一張，莫笑話我~
日志采集這部分結(jié)合lua-resty-kafka使用Lua擴(kuò)展將數(shù)據(jù)按照一定格式拼接后寫入Kafka集群。Nginx+Lua的性能就不用多說了，這樣一來完全可以關(guān)掉Nginx本身的日志開關(guān)，減少磁盤消耗；
消息隊(duì)列我們數(shù)據(jù)分析組的同事在這之前就已經(jīng)建立Kafka集群，無需再搞一套消息隊(duì)列服務(wù)。另外一個(gè)很重要的點(diǎn)是，我們不希望日志數(shù)據(jù)取完就刪掉了，運(yùn)維組除了要做監(jiān)控告警之外，數(shù)據(jù)組也要讀取數(shù)據(jù)做分析。因此，如Redis此類的消息隊(duì)列就直接被我們pass掉了；
異常監(jiān)控計(jì)算這部分使用Heka來做，Heka使用Go語言編寫，內(nèi)置豐富的插件可以滿足大部分的需求。若不滿足需求，可以使用Go或者Lua自行開發(fā)擴(kuò)展。之前使用過Logstash做業(yè)務(wù)日志收集，但它有時(shí)的CPU占用實(shí)在太嚇人，不敢再在業(yè)務(wù)機(jī)上使用，并且感覺擴(kuò)展不方便。就我們目前的應(yīng)用來看，Heka的性能和資源占用還是很不錯(cuò)的。
可以使用Filter做計(jì)算，有錯(cuò)誤時(shí)向Heka消息流中寫入告警消息，SMTPOuter匹配到告警消息后通過自定義的Encoder定制好郵件內(nèi)容后再發(fā)送。
可視化Heka層一方面做異常監(jiān)控，另一方面使用Message Matcher Syntax匹配異常數(shù)據(jù)寫入到Elasticsearch, 再架設(shè)一個(gè)Kibana。我們在收到告警郵件后，就可以進(jìn)入Kibana后臺查看異常的Log。
不足郵件告警機(jī)制需要優(yōu)化, 我們目前的設(shè)置是每分鐘檢查一次，發(fā)現(xiàn)錯(cuò)誤就會(huì)一直告警。之后可以優(yōu)化為發(fā)現(xiàn)異常時(shí)告警一次，異常結(jié)束時(shí)再發(fā)一次匯總郵件；
Heka服務(wù)管理和進(jìn)程監(jiān)控需要優(yōu)化，支持自動(dòng)重啟，不然進(jìn)程掛了都不知道；
Heka配置接入配置中心并支持自動(dòng)重啟（目前的配置主要是各業(yè)務(wù)的告警閥值，需要進(jìn)入機(jī)器修改）；
總結(jié)整個(gè)開發(fā)過程還是比較順利的，唯一比較耗時(shí)的是熟悉Heka的整個(gè)消息處理的流程和機(jī)制，以及如何開發(fā)擴(kuò)展。另一個(gè)比較坑的是Heka的錯(cuò)誤提示不全和調(diào)試不方便，有時(shí)完全靠猜，不過好在它本身并沒有多復(fù)雜，有些問題看一看源代碼就明白了。
關(guān)于消息隊(duì)列的選擇，前面已經(jīng)提到我們已有Kafka集群就直接拿來用了。如果僅僅做異常監(jiān)控，不需要消息留存, 倒可以考慮使用Redis之類輕量些的消息隊(duì)列, Kafka未免有些重了。
原文地址: http://mlongbo.com/2015/NginxLog%E5%AE%9...
掃描二維碼，關(guān)注我。
內(nèi)容大多會(huì)是后端技術(shù)、前端工程、DevOps，偶爾會(huì)有一些大數(shù)據(jù)相關(guān)，會(huì)推薦一些好玩的東西。希望你會(huì)喜歡~
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/39165.html
摘要：我會(huì)寫一些是后端技術(shù)前端工程相關(guān)的文章，偶爾會(huì)有一些大數(shù)據(jù)相關(guān)，也會(huì)推薦一些好玩的東西。 showImg(https://segmentfault.com/img/remote/1460000006767498); Nginx作為所有HTTP請求的入口，是非常重要的一層。本文主要介紹如何利用 Nginx日志實(shí)時(shí)監(jiān)控每個(gè)業(yè)務(wù)的請求異常。? 這篇文章基于我之前的的一篇 《基于Lua+Kaf...
摘要：現(xiàn)在用方式調(diào)用接口，中使用方式輸入內(nèi)容日志平臺網(wǎng)關(guān)層基于。日志平臺網(wǎng)關(guān)層基于到此為止，提取經(jīng)過網(wǎng)關(guān)的接口信息，并將其寫入日志文件就完成了，所有的接口日志都寫入了文件中。 背景介紹 1、問題現(xiàn)狀與嘗試 沒有做日志記錄的線上系統(tǒng)，絕對是給系統(tǒng)運(yùn)維人員留下的坑。尤其是前后端分離的項(xiàng)目，后端的接口日志可以解決對接、測試和運(yùn)維時(shí)的很多問題。之前項(xiàng)目上發(fā)布的接口都是通過Oracle Service...
摘要：容器內(nèi)文件日志平臺支持的文件存儲是，避免了許多復(fù)雜環(huán)境的處理。以上是數(shù)人云在實(shí)踐容器日志系統(tǒng)過程中遇到的問題，更高層次的應(yīng)用包括容器日志分析等，還有待繼續(xù)挖掘和填坑，歡迎大家提出建議，一起交流。 業(yè)務(wù)平臺每天產(chǎn)生大量日志數(shù)據(jù)，為了實(shí)現(xiàn)數(shù)據(jù)分析，需要將生產(chǎn)服務(wù)器上的所有日志收集后進(jìn)行大數(shù)據(jù)分析處理，Docker提供了日志驅(qū)動(dòng)，然而并不能滿足不同場景需求，本次將結(jié)合實(shí)例分享日志采集、存儲以...
閱讀 1968·2021-11-19 09:40
閱讀 2155·2021-10-09 09:43
閱讀 3306·2021-09-06 15:00
閱讀 2823·2019-08-29 13:04
閱讀 2779·2019-08-26 11:53
閱讀 3543·2019-08-26 11:46
閱讀 2333·2019-08-26 11:38
閱讀 402·2019-08-26 11:27
