每日優(yōu)鮮監(jiān)控系統(tǒng)早期情況
系統(tǒng)覆蓋不全
每日優(yōu)鮮早期只有交易平臺(tái)存在一套內(nèi)部的業(yè)務(wù)監(jiān)控系統(tǒng)，沒(méi)有推廣到全公司級(jí)別。大數(shù)據(jù)團(tuán)隊(duì)與自己的業(yè)務(wù)監(jiān)控，運(yùn)維團(tuán)隊(duì)有自己的基礎(chǔ)監(jiān)控。除了交易系統(tǒng)其他業(yè)務(wù)線的業(yè)務(wù)監(jiān)控幾乎為零，很多時(shí)候都是用戶告知我們出問(wèn)題了，而不是我們主動(dòng)發(fā)現(xiàn)出問(wèn)題了，導(dǎo)致問(wèn)題發(fā)現(xiàn)的時(shí)候已經(jīng)過(guò)去很久了。
監(jiān)控類型不完善
監(jiān)控內(nèi)容主要是涉及日志中出現(xiàn)的數(shù)據(jù)統(tǒng)計(jì)，所以對(duì)PV、UV、JVM相關(guān)監(jiān)控都沒(méi)有，尤其對(duì)自身業(yè)務(wù)的監(jiān)控幾乎為零，我們無(wú)法實(shí)時(shí)的知道當(dāng)前接口的訪問(wèn)量，錯(cuò)誤率等信息；除此之外我們依賴的zookeeper、mq、redis、數(shù)據(jù)庫(kù)等中間件的監(jiān)控也基本沒(méi)有，所以很難做到深入的排查。不過(guò)好在有一套pinpoint可以幫助故障和性能定位。但是這并不能代替業(yè)務(wù)監(jiān)控。
監(jiān)控系統(tǒng)選型和實(shí)現(xiàn)
選型
要實(shí)現(xiàn)一套監(jiān)控系統(tǒng)，必須要保證數(shù)據(jù)的收集、存儲(chǔ)和可視化，然后在基于此實(shí)現(xiàn)一套告警系統(tǒng)，最終實(shí)現(xiàn)數(shù)據(jù)的可視化與問(wèn)題的觸達(dá)。
可視化選型
在做監(jiān)控系統(tǒng)選型的時(shí)候，最優(yōu)先定下來(lái)的是可視化，即Grafana這套開(kāi)源產(chǎn)品，因?yàn)槠渲С侄鄶?shù)據(jù)源，同時(shí)也支持告警規(guī)則，除此之外其提供了一套完備的API，我們通過(guò)程序調(diào)用其API實(shí)現(xiàn)了監(jiān)控?cái)?shù)據(jù)可視化的自動(dòng)化流程。
存儲(chǔ)選型
第二個(gè)定下來(lái)的是存儲(chǔ)系統(tǒng)，監(jiān)控的數(shù)據(jù)基本都帶有時(shí)序性，所以我們自然而然的朝著時(shí)序數(shù)據(jù)庫(kù)(TSDB)方向進(jìn)行選型。最終定下來(lái)的存儲(chǔ)有兩種：存儲(chǔ)業(yè)務(wù)監(jiān)控?cái)?shù)據(jù)的OpenTSDB和存儲(chǔ)中間件監(jiān)控?cái)?shù)據(jù)的Prometheus。
選擇OpenTSDB的原因在于我們的業(yè)務(wù)數(shù)據(jù)需要長(zhǎng)期保留，比如我們現(xiàn)在業(yè)務(wù)的監(jiān)控?cái)?shù)據(jù)已經(jīng)存儲(chǔ)了一年，大家可以輕易的查到?5.17?，?6.18?的歷史大盤(pán)數(shù)據(jù)。
中間件等監(jiān)控?cái)?shù)據(jù)不需要保留太長(zhǎng)時(shí)間，所以單獨(dú)的采用了另一套存儲(chǔ)Prometheus的TSDB，為什么選擇它的，原因是Prometheus擴(kuò)展性非常高，通過(guò)相關(guān)的exporter可以快速的開(kāi)發(fā)一套針對(duì)性的中間件監(jiān)控，同時(shí)社區(qū)也已經(jīng)支持了很大一部分的中間件的exporter(收集服務(wù)暴露監(jiān)控?cái)?shù)據(jù)接口)。
數(shù)據(jù)收集
監(jiān)控?cái)?shù)據(jù)的收集從兩方面做的，一方面是提供內(nèi)存埋點(diǎn)的方式，即我們提供的monitor包，另一方面為了接入了老監(jiān)控系統(tǒng)能夠平滑遷移到新的監(jiān)控系統(tǒng)上來(lái)，我們支持了基于日志的統(tǒng)計(jì)，可以統(tǒng)計(jì)pv、異常等信息。
日志收集也兼容原來(lái)的方案，即采用flume進(jìn)行日志采集，kafka進(jìn)行日志傳輸，日志統(tǒng)計(jì)系統(tǒng)進(jìn)行日志數(shù)據(jù)消費(fèi)、統(tǒng)計(jì)。
告警系統(tǒng)
為了方便與自研的監(jiān)控系統(tǒng)實(shí)現(xiàn)自動(dòng)化接入以及與現(xiàn)有的組織人員接入，對(duì)告警系統(tǒng)做了自研。
告警系統(tǒng)自動(dòng)化接入： 業(yè)務(wù)接入監(jiān)控，如果該業(yè)務(wù)在應(yīng)用中心已經(jīng)注冊(cè)存在，那么監(jiān)控系統(tǒng)在第一次收到業(yè)務(wù)發(fā)送的監(jiān)控?cái)?shù)據(jù)時(shí)，會(huì)調(diào)用告警平臺(tái)接口創(chuàng)建告警應(yīng)用，同時(shí)告警平臺(tái)會(huì)根據(jù)App_code從應(yīng)用中心拉取該app_code下所有相關(guān)研發(fā)人員，全程自動(dòng)化。
靈活性: 告警平臺(tái)除了自動(dòng)化接入，也可以手動(dòng)接入告警，手動(dòng)維護(hù)告警人員，對(duì)外提供了告警接口，業(yè)務(wù)方可以根據(jù)自己的需求接入告警發(fā)送、消息通知等功能。
告警方式： 在告警系統(tǒng)上線之初支持短信、郵件、電話三種告警方式，去年年前緊急接入了lark，實(shí)現(xiàn)了第一版lark告警功能的接入，到現(xiàn)在告警平臺(tái)已經(jīng)對(duì)接了多個(gè)lark機(jī)器人，同時(shí)實(shí)現(xiàn)了群機(jī)器人的告警消息推送。
監(jiān)控系統(tǒng)的架構(gòu)
監(jiān)控系統(tǒng)的實(shí)現(xiàn)
業(yè)務(wù)監(jiān)控
業(yè)務(wù)監(jiān)控采用sdk和日志收集兩種方式進(jìn)行統(tǒng)計(jì)上報(bào)，其中monitor中內(nèi)置了對(duì)數(shù)據(jù)庫(kù)連接池的監(jiān)控、JVM監(jiān)控、dubbo提供者調(diào)用監(jiān)控、dubbo消費(fèi)監(jiān)控等。
對(duì)于JVM監(jiān)控采用內(nèi)置的ManagementFactory獲取
Dubbo和Http接口的pv和異常監(jiān)控均采用攔截器的方式，直接集成在monitor中。
機(jī)器監(jiān)控
機(jī)器監(jiān)控的基礎(chǔ)數(shù)據(jù)來(lái)源于運(yùn)維團(tuán)隊(duì)的Prometheus，通過(guò)業(yè)務(wù)監(jiān)控上報(bào)上來(lái)的機(jī)器IP拼接PromQL，并將機(jī)器的監(jiān)控與業(yè)務(wù)監(jiān)控的大盤(pán)集成，業(yè)務(wù)可以在業(yè)務(wù)監(jiān)控大盤(pán)中看到自己的應(yīng)用的資源使用情況。
中間件監(jiān)控
中間件監(jiān)控分為兩種方式，早期的redis管理平臺(tái)和rocketmq各自基于monitor sdk實(shí)現(xiàn)了自己的監(jiān)控埋點(diǎn)，走的路線跟業(yè)務(wù)監(jiān)控相同。
監(jiān)控系統(tǒng)自身依賴的組件，如hdfs、kafka、opentsdb等直接采用prometheus exporter進(jìn)行收集,組件內(nèi)部維護(hù)了一組exporter。
監(jiān)控圖像自動(dòng)生成
為了監(jiān)控接入的便捷性，我們實(shí)現(xiàn)了監(jiān)控大盤(pán)的自動(dòng)生成，根據(jù)monitor內(nèi)置的相關(guān)埋點(diǎn)進(jìn)行默認(rèn)的監(jiān)控?cái)?shù)據(jù)上報(bào)，如JVM、Dubbo、Http等。通過(guò)這些上報(bào)數(shù)據(jù)拼接JSON，同時(shí)調(diào)用Grafana的創(chuàng)建Dashboard的API接口，自動(dòng)創(chuàng)建Dashboard，大致流程如下：
機(jī)器的核心指標(biāo)（cpu、內(nèi)存、磁盤(pán)、帶寬），通過(guò)應(yīng)用上報(bào)的指標(biāo)信息中的host tag，生成promql，通過(guò)promql從運(yùn)維的prometheus數(shù)據(jù)源中獲取，自動(dòng)添加到大盤(pán)監(jiān)控中。
監(jiān)控接入全程自動(dòng)化
為了方便業(yè)務(wù)快速接入監(jiān)控，我們除了對(duì)監(jiān)控自動(dòng)生成大盤(pán)之外，還做了其他的處理，監(jiān)控系統(tǒng)接入全程自動(dòng)化，自動(dòng)化過(guò)程如下圖所示：
- 監(jiān)控?cái)?shù)據(jù)網(wǎng)關(guān)觸發(fā)安裝filebeat流程，調(diào)用ocean平臺(tái)的接口進(jìn)行filebeat推送安裝，實(shí)現(xiàn)wf日志的收集。
- 調(diào)用告警平臺(tái)實(shí)現(xiàn)大盤(pán)對(duì)應(yīng)的告警創(chuàng)建，告警平臺(tái)根據(jù)監(jiān)控?cái)?shù)據(jù)網(wǎng)關(guān)推送的應(yīng)用名從應(yīng)用中心拉取該應(yīng)用下的相關(guān)開(kāi)發(fā)人員，實(shí)現(xiàn)告警的自動(dòng)化設(shè)置。
- 監(jiān)控大盤(pán)生成，通過(guò)業(yè)務(wù)推送的監(jiān)控指標(biāo)數(shù)據(jù)和告警地址拼接大盤(pán)模板，然后調(diào)用Grafana的接口實(shí)現(xiàn)界面的自動(dòng)化創(chuàng)建和更新。
- 監(jiān)控?cái)?shù)據(jù)網(wǎng)關(guān)調(diào)用異常網(wǎng)關(guān)，實(shí)現(xiàn)異常網(wǎng)關(guān)對(duì)wf日志的top5日志統(tǒng)計(jì)
- 監(jiān)控?cái)?shù)據(jù)網(wǎng)關(guān)調(diào)用日志統(tǒng)計(jì)，實(shí)現(xiàn)wf的error和warning的pv統(tǒng)計(jì)以及異常統(tǒng)計(jì)
監(jiān)控系統(tǒng)的推廣歷程
對(duì)監(jiān)控埋點(diǎn)的認(rèn)知
最開(kāi)始推監(jiān)控的時(shí)候大家對(duì)埋點(diǎn)的認(rèn)知還比較淺，所以主要是通過(guò)日志方式進(jìn)行接入，對(duì)埋點(diǎn)存在抵觸心理。
監(jiān)控系統(tǒng)分享
監(jiān)控系統(tǒng)在一次分享大會(huì)上做過(guò)相關(guān)分享，主要分享通用的監(jiān)控系統(tǒng)的架構(gòu)是什么樣，我們的Monitor監(jiān)控實(shí)現(xiàn)是什么樣，支持了哪些功能。
在分享會(huì)上再一次重點(diǎn)的宣講了一下埋點(diǎn)的重要性，因?yàn)橹挥袠I(yè)務(wù)人員對(duì)自己所負(fù)責(zé)的業(yè)務(wù)最熟悉，所以為了方便第一時(shí)間發(fā)現(xiàn)問(wèn)題，以及對(duì)自己的業(yè)務(wù)有全局的監(jiān)控，那么就需要手動(dòng)去埋點(diǎn)。以登陸功能為例，我們需要在登陸操作的每一步做埋點(diǎn)，我們需要知道登陸成功的pv，失敗的pv，是什么原因失敗，失敗比例各占多少。
監(jiān)控系統(tǒng)方面做的改進(jìn)
Grafana改造
指標(biāo)分組
指標(biāo)分組主要是為了方便大家快速定位自己的埋點(diǎn)位置，比如我們有一組與用戶登陸相關(guān)的埋點(diǎn)數(shù)據(jù)，埋點(diǎn)指標(biāo)名稱統(tǒng)一為UserLogin_前綴，那么在上報(bào)之后我們會(huì)自動(dòng)進(jìn)行分組，將UserLogin_xxx分到同一組下。為了快速定位一組埋點(diǎn)，對(duì)Grafana前端進(jìn)行大盤(pán)進(jìn)行了拆解顯示，可以通過(guò)下拉的方式選擇自己的埋點(diǎn)指標(biāo)組，然后會(huì)過(guò)濾掉無(wú)用的展示，只展示該指標(biāo)組下的內(nèi)容。
指標(biāo)搜索
Grafana Git上很多人都對(duì)指標(biāo)查詢這個(gè)功能有需求，不過(guò)官方?jīng)]有打算做，隨著業(yè)務(wù)指標(biāo)數(shù)量的遞增，排查起來(lái)非常麻煩，為此，除了可以通過(guò)指標(biāo)分組功能來(lái)實(shí)現(xiàn)過(guò)濾之外，還對(duì)指標(biāo)搜索功能做了實(shí)現(xiàn)，可以通過(guò)搜索具體的指標(biāo)來(lái)查看具體的單個(gè)指標(biāo)。
分時(shí)段告警
不同時(shí)段的指標(biāo)的數(shù)據(jù)、趨勢(shì)是不同的，有些業(yè)務(wù)基本上晚上都沒(méi)有什么量，為了使得告警更準(zhǔn)確，實(shí)現(xiàn)了第一版的單時(shí)段告警，可以實(shí)現(xiàn)在指定時(shí)間段內(nèi)才會(huì)對(duì)指標(biāo)進(jìn)行監(jiān)控。
這種方式已經(jīng)滿足了大部分的場(chǎng)景，但是業(yè)務(wù)是多樣性的，指標(biāo)數(shù)據(jù)、趨勢(shì)也存在多樣性。因此實(shí)現(xiàn)了第二個(gè)版本，分時(shí)段、分策略告警。咋不同時(shí)間段可以配置不同的告警策略，從而使得告警更加準(zhǔn)確，更加的人性化。
同環(huán)比
Grafana的指標(biāo)圖根據(jù)不同的數(shù)據(jù)類型，配置、查詢方式等都不相同，Grafana的OpenTSDB數(shù)據(jù)源前端指標(biāo)圖默認(rèn)無(wú)法將不同時(shí)間段的數(shù)據(jù)放在同一個(gè)指標(biāo)圖上，為了增加同環(huán)比的功能，對(duì)OpenTSDB的查詢模塊在前端做了擴(kuò)展。做法如下：
- 對(duì)指標(biāo)查詢做標(biāo)記，標(biāo)記是否為同環(huán)比查詢
- 查詢時(shí)對(duì)時(shí)間進(jìn)行計(jì)算
- 渲染前對(duì)時(shí)間進(jìn)行計(jì)算
- 最終達(dá)到將不同時(shí)間段的數(shù)據(jù)展示在同一個(gè)指標(biāo)圖上。
告警分布式
Grafana官方的告警策略是不支持分布式的，因此擴(kuò)展了其分布式告警的功能。
第一版分布式告警
在告警配置數(shù)量還在上百個(gè)、上千個(gè)的時(shí)候。在這個(gè)階段，直接在數(shù)據(jù)庫(kù)中加了一張鎖表，用來(lái)處理分布式告警，發(fā)送告警前先獲取鎖，獲取成功則繼續(xù)發(fā)送，如果獲取失敗，取消告警的發(fā)送，即誰(shuí)拿鎖誰(shuí)發(fā)送。同時(shí)引入了鎖檢查的任務(wù)。
第二版分布式告警
隨著接入的應(yīng)用和指標(biāo)數(shù)達(dá)到了一定的量級(jí)，配置的告警策略也翻了好幾倍，數(shù)據(jù)庫(kù)實(shí)現(xiàn)的鎖表出現(xiàn)一定的瓶頸。因此換了第二版本的實(shí)現(xiàn)，即對(duì)查詢的告警策略數(shù)據(jù)進(jìn)行拆分，每個(gè)節(jié)點(diǎn)跑一部分，實(shí)現(xiàn)分布式告警。
告警平臺(tái)
告警回執(zhí)、告警統(tǒng)計(jì)
針對(duì)告警信息做了定制化，添加告警回執(zhí)、告警處理等功能，實(shí)現(xiàn)告警跟蹤、溯源。
告警回執(zhí)
異常日志報(bào)出來(lái)
直接將出錯(cuò)內(nèi)容通過(guò)告警發(fā)出來(lái)，業(yè)務(wù)方可以快速定位問(wèn)題。默認(rèn)取出現(xiàn)頻率較高的top5異常。
異常推送
監(jiān)控系統(tǒng)未來(lái)方向
當(dāng)前監(jiān)控系統(tǒng)數(shù)據(jù)收集方面還是分鐘級(jí)別，機(jī)器指標(biāo)是十秒級(jí)別，無(wú)法發(fā)現(xiàn)峰值的qps，因?yàn)榻酉聛?lái)的方向考慮加入秒級(jí)監(jiān)控，實(shí)現(xiàn)分鐘和秒級(jí)監(jiān)控的靈活切換，需要的時(shí)候開(kāi)通秒級(jí)監(jiān)控，平時(shí)使用分鐘級(jí)監(jiān)控即可，當(dāng)然，因?yàn)槊爰?jí)監(jiān)控很耗費(fèi)性能，所以也可能單獨(dú)的在諦聽(tīng)平臺(tái)去做。
引入AI算法，對(duì)歷史數(shù)據(jù)進(jìn)行分析、趨勢(shì)分析，實(shí)現(xiàn)告警的智能化，提前預(yù)知告警，防患于未然。
此外當(dāng)前可觀測(cè)技術(shù)已經(jīng)越發(fā)趨于成熟，Metric、Logging、Tracing逐漸走向統(tǒng)一，三者可以相互跳轉(zhuǎn)、幫助研發(fā)快速定位問(wèn)題，也是我們值得思考的方向，當(dāng)然我們現(xiàn)在也在逐步的將三者通過(guò)一些手段串聯(lián)起來(lái)，加快問(wèn)題的定位能力。
