1. 兩者適用于多大規(guī)模的監(jiān)控場景？超過5000以上監(jiān)控節(jié)點(diǎn)時(shí)怎么辦？高可用怎么解決？

2. 兩者怎么解決存儲問題？對于監(jiān)控信息是否有歷史存儲和分析，能從歷史信息中挖掘到哪些有價(jià)值的信息？

3. 兩者怎么應(yīng)對告警風(fēng)暴和誤報(bào)？

4. 在智能監(jiān)控和自動治愈方面是否有可借鑒的實(shí)踐？基于什么算法或策略？怎么進(jìn)行故障預(yù)判和預(yù)處理？

5. 監(jiān)控大屏是怎么設(shè)計(jì)的？

6. 自動化運(yùn)維管理是兩者同時(shí)使用還是二選一更合適？

7. 兩者在配合使用時(shí)，應(yīng)該怎么分工？怎么落地？

8. 如果已經(jīng)部署了Zabbix，怎么平穩(wěn)過渡到Prometheus？

9. 分布式鏈路的可觀測性和端到端診斷怎么做？

10. 大規(guī)模場景下，兩者的性能和成本哪個(gè)比較低？

監(jiān)控，為什么總讓我們頭痛

監(jiān)控一直都是運(yùn)維工作中不可或缺的部分，一個(gè)高效、契合的監(jiān)控系統(tǒng)是服務(wù)賴以健康穩(wěn)定的基石。隨著業(yè)務(wù)規(guī)模的增長、技術(shù)的發(fā)展、行業(yè)的變革，企業(yè)對用戶體驗(yàn)越來越重視，監(jiān)控的需求發(fā)生著日新月異的變化，相應(yīng)的監(jiān)控工具和解決方案也層出不窮。其中，Zabbix和Prometheus就是兩款非常典型的監(jiān)控工具，應(yīng)用頗為廣泛。

說起來，監(jiān)控在不同的團(tuán)隊(duì)和公司之間，可能會存在各種差異化的需求。如何基于開源產(chǎn)品打造一個(gè)符合自己業(yè)務(wù)場景的監(jiān)控體系，并且持續(xù)迭代？這成為了大家無法繞開的課題。

比如說，如何選擇監(jiān)控方案和開源工具？如何為自己的業(yè)務(wù)場景做定制化適配？如何實(shí)現(xiàn)端到端的全鏈路監(jiān)控？如何讓業(yè)務(wù)方以更低成本接入到這個(gè)系統(tǒng)中？如何做監(jiān)控的自動化？如何做異常告警的路由、分發(fā)、收斂和抑制？如何做統(tǒng)一化的監(jiān)控大屏、Dashboard等等……這些都是我們在構(gòu)建監(jiān)控系統(tǒng)中可能會面臨的問題。

圍繞這些問題，dbaplus社群特別邀請到美圖SRE負(fù)責(zé)人-石鵬(東方德勝)作為主持人、招商銀行技術(shù)經(jīng)理-蔡翔華作為Zabbix使用方、甜橙金融基礎(chǔ)技術(shù)架構(gòu)師-劉宇作為Prometheus使用方，針對Zabbix和Prometheus展開實(shí)用選型探討。

十問十答，監(jiān)控工具怎么選

蔡翔華：我們和Zabbix官方其實(shí)有溝通過，業(yè)內(nèi)他們有一些監(jiān)控到了40萬以上的節(jié)點(diǎn)數(shù)，當(dāng)然這個(gè)節(jié)點(diǎn)數(shù)也要根據(jù)你每個(gè)節(jié)點(diǎn)上監(jiān)控多少東西。Zabbix其實(shí)有一個(gè)指標(biāo)叫做NVPS（New Value Per Second），也就是每秒新增的值的指標(biāo)，來判斷你的監(jiān)控規(guī)模是不是合適的。

那么對于5000個(gè)節(jié)點(diǎn)以上的場景來說，其實(shí)Zabbix還是OK的，你可以通過多布署一些Proxy，去對后臺數(shù)據(jù)庫做一些性能調(diào)優(yōu)等等，以這些方式去提高整個(gè)監(jiān)控平臺的可承受、負(fù)載的性能。

另外關(guān)于高可用，我們的數(shù)據(jù)庫端是會有Mycat或者HAProxy高可用，但服務(wù)器端本身它其實(shí)沒有高可用，那么我們可以依賴于虛擬化平臺，或者是比如像我們有Vmotion等熱遷移這些技術(shù)。另外，在未來的5.x版本或者6版本以上的話，官方已經(jīng)將原生的高可用納入到Zabbix的Roadmap里面了，大家可以期待一下。

石鵬：好的，蔡老師的核心觀點(diǎn)其實(shí)就是我們需要關(guān)注核心的指標(biāo)，也就是NVPS，這個(gè)值是比較關(guān)鍵的。然后蔡老師之前您在實(shí)際的應(yīng)用中，見過這個(gè)系統(tǒng)的峰值可以達(dá)到多少嗎？是否可以給大家做個(gè)參考？

蔡翔華：在我們自己的環(huán)境里面，NVPS峰值達(dá)到過6000以上，但我們后面其實(shí)也做了一些優(yōu)化，把它調(diào)整到3000左右。主要目的是，因?yàn)橐婚_始我們做的時(shí)候是希望做到大而全，什么都監(jiān)控，但最后發(fā)現(xiàn)其實(shí)大而全不一定有用，因?yàn)楹芏啾O(jiān)控即使它是問題，你也不會care它。

劉宇：是的，蔡老師已經(jīng)講得比較詳細(xì)了，其實(shí)以多大的規(guī)模是取決于你的監(jiān)控目標(biāo)，還有就是采集的間隔，比如說5秒采集一次和1分鐘采集一次，這個(gè)規(guī)模都是支持著不一樣的目標(biāo)，所以還是要根據(jù)你的需求。

一般來說，我們會配置成30秒或者是一分鐘；如果是對于高頻的，會15秒。因?yàn)閱蝹€(gè)Prometheus性能已經(jīng)比較強(qiáng)了，一般來說，它每秒百萬個(gè)指標(biāo)都是沒什么問題的。Prometheus會根據(jù)你的指標(biāo)來計(jì)算，就是看你一個(gè)監(jiān)控點(diǎn)上有多少個(gè)指標(biāo)，這樣來換算。

如果你單個(gè)Prometheus的性能達(dá)不到它的要求時(shí)，也可以去做一些拆分，比如說我們把Prometheus根據(jù)它的功能來做區(qū)分，這個(gè)去監(jiān)控node exporter，那個(gè)去監(jiān)控Redis，這樣來做區(qū)分。

當(dāng)然，如果你單個(gè)的性能還是不夠的話，可以用分區(qū)，即用hash mod去多分幾個(gè)Prometheus來做監(jiān)控。

然后關(guān)于高可用這塊，其實(shí)社區(qū)Prometheus這部分做得也不是特別好，會用兩個(gè)Prometheus來同時(shí)監(jiān)控同樣的一個(gè)目標(biāo)，這樣來做到一個(gè)高可用。當(dāng)然，在容器環(huán)境，你也可以去通過K8S的deployment這種方式，來把高可用維護(hù)起來。

蔡翔華：的確，存儲這個(gè)問題因?yàn)楸O(jiān)控寫的東西最多就是寫到存儲里面去，Zabbix以前被吐槽最多的就是它不支持時(shí)序數(shù)據(jù)庫TSDB。其實(shí)在4.2以后，它就已經(jīng)開始支持TSDB了，當(dāng)然可能還沒有Prometheus那么成熟，它主要的數(shù)據(jù)庫還是MySQL為主。

如果就存儲問題的話，一方面你可以去嘗試TSDB的這種方式；另外一方面的話，你可以去通過增加SSD，或者說數(shù)據(jù)庫層面的一些性能提升，去解決它的問題。包括數(shù)據(jù)庫本身可以去分庫分表，去拆分一下，然后對歷史數(shù)據(jù)做一個(gè)歸檔……就是通過數(shù)據(jù)庫層面的優(yōu)化，來解決這個(gè)問題。

那么對于歷史存儲和分析這些信息，Zabbix提供了兩個(gè)維度，一個(gè)叫history，一個(gè)叫trend，也就是一個(gè)歷史數(shù)據(jù)和趨勢數(shù)據(jù)。它具體數(shù)值是可以自己設(shè)定的，它的邏輯是說，如果超過history的保留期限，比如說30天，它自動會把數(shù)據(jù)歸檔成trend的數(shù)據(jù)，trend的數(shù)據(jù)就會只會保留最大值、最小值和平均值這三個(gè)指標(biāo)，而并不能像history數(shù)據(jù)可以看到每一秒鐘，甚至說每一個(gè)輪巡周期的指標(biāo)。

我們實(shí)際場景應(yīng)用的話，主要是用于我們的性能分析，因?yàn)槲覀冇泻芏嗷ヂ?lián)網(wǎng)應(yīng)用，會看一下這個(gè)業(yè)務(wù)增長對我平臺的要求，會不會CPU比較緊張、內(nèi)存比較緊張等等。另外，我們會根據(jù)這些數(shù)據(jù)做一個(gè)分析，為我們后期的擴(kuò)容、決策提供一些參考性的依據(jù)。比方說我現(xiàn)在看到今年整體的使用率在多少，我們每年的增長量是在20%還是30%，這樣我們后續(xù)做一些決策的時(shí)候，是需要多少的資源、多少的預(yù)算，就比較能有參考價(jià)值。

劉宇：Prometheus本身存儲如果存在本地的話，大概只能存15天，最多你也只能放到30天這樣子。官方其實(shí)也不建議你把所有的監(jiān)控?cái)?shù)據(jù)都存在Prometheus的一個(gè)本地的數(shù)據(jù)庫里。所以我在案例分享中也提到了一個(gè)遠(yuǎn)端存儲的技術(shù)（案例分享內(nèi)容請關(guān)注dbaplus社群后續(xù)文章發(fā)布）。

我們是存在InfluxDB的，也有一些是可以存在比如說ES，通過remote_write的功能去存到ES或者是其它時(shí)序數(shù)據(jù)庫中，或者是比如說HBase這種大數(shù)據(jù)的也可以存。

石鵬：好的了解，其實(shí)關(guān)于存儲這個(gè)問題，我們還是更多應(yīng)該從需求出發(fā)。整體來看有一些比較通用的思路，最典型的就是這兩種：

第一種是數(shù)據(jù)的轉(zhuǎn)儲。比如像Prometheus，我們在本地只存2周或者4周的數(shù)據(jù)，然后更多的話，就把它寫到遠(yuǎn)端。

第二種思路是做數(shù)據(jù)采樣。其實(shí)在很多監(jiān)控系統(tǒng)里面，是一個(gè)比較常規(guī)的思路，就像在Zabbix里的history、trend，開始可能是每30秒一個(gè)點(diǎn)，然后數(shù)據(jù)采樣之后，可能是每5分鐘一個(gè)點(diǎn)。就用這樣的方式，把這個(gè)數(shù)據(jù)量級減小，然后以此來做存儲問題的優(yōu)化。

蔡翔華：首先誤報(bào)這個(gè)事情，其實(shí)在我理解里是不存在的。也就是說，之所以我們會覺得很多有誤報(bào)的東西存在，是因?yàn)槲覀儗τ谝?guī)則，比方說我監(jiān)控東西或者是我配置觸發(fā)器，本身是有問題的。

我碰到很多人說，打算監(jiān)控它的CPU使用率，很多人會直接記錄usage，它的使用率，也有很多人會監(jiān)控它的free的這個(gè)space。但有時(shí)候會由于配置錯(cuò)誤，導(dǎo)致原本監(jiān)控cpu usage的使用了cpu free的指標(biāo)。所以說，其實(shí)很多時(shí)候報(bào)警之所以會產(chǎn)生誤報(bào)，是因?yàn)榕渲帽旧聿皇呛苷_。

Zabbix的工作機(jī)制很簡單：我去收集數(shù)據(jù)，去根據(jù)這個(gè)處罰規(guī)則去做比較，然后去發(fā)報(bào)警。當(dāng)中所有的邏輯其實(shí)本身是不會出任何問題，除非說收集數(shù)據(jù)配錯(cuò)了、觸發(fā)規(guī)則配錯(cuò)了、報(bào)警機(jī)制配錯(cuò)了……這些其實(shí)更多是人為的因素在里面。

所以說，更多的是要通過這種檢查來判斷一下你是否有配錯(cuò)。

另外一個(gè)減少誤報(bào)的方式是通過模板化。因?yàn)槲覀冎灰渲靡淮文０?，那我把所有的Linux機(jī)型的監(jiān)控模板都統(tǒng)一起來，對于所有監(jiān)控Linux都套用同一個(gè)模板，那么就可以在一定程度上降低誤報(bào)。關(guān)鍵還是在于人的問題。

關(guān)于告警風(fēng)暴，其實(shí)Zabbix里有一個(gè)特性叫做依賴項(xiàng)目。就比方說我現(xiàn)在有一臺機(jī)器宕機(jī)，那么它可能里面的端口都會不通，然后ping也ping不通，CPU可能也拿不到，可能會有一堆的報(bào)警。那么我們可以把所有的這種依賴項(xiàng)關(guān)聯(lián)到ping上，一旦ping的機(jī)器都死了，上面肯定東西都是宕掉了，這樣子的話，它只會報(bào)ping的這一個(gè)問題，而不會把這堆機(jī)器上所有的東西都給報(bào)出來。就好比一個(gè)人如果死了，你跟他說這里有問題那里有問題，其實(shí)沒有任何意義。它就只會把你最終的Root Cause（根因）給報(bào)出來，去防范這種告警風(fēng)暴。

劉宇：是的，誤報(bào)我其實(shí)跟蔡老師的觀點(diǎn)是很像的，就是告警中其實(shí)是存在一個(gè)誤報(bào)率的，如果你的誤報(bào)率很高的話，運(yùn)維人員就很疲勞了，可能大家都會覺得狼來了，沒有辦法信任你的那種告警，反而你真正發(fā)生故障的告警就會被忽略掉。所以制定告警的規(guī)則就非常重要，需要想辦法把誤報(bào)率給它降低。

那這種規(guī)則的制定其實(shí)就比較不是那么具體，會比較抽象，可能比如說把必須要人工介入處理的這種，才把它定為告警；然后如果系統(tǒng)可以自己處理掉，就不要把它告出來，或者只是在后面做一個(gè)每天發(fā)一次的報(bào)告也就行了。這是我對誤報(bào)的一個(gè)看法。

關(guān)于告警風(fēng)暴，在Prometheus中，對告警風(fēng)暴的處理方式是這樣：可以通過靜默告警解決，或者是可以加入維護(hù)組，或者是也可以做一個(gè)聚合，也就是把告警給聚集，然后同類的告警合并，這樣來減少告警的條數(shù)，主要是這樣來做的。

當(dāng)然如果你有些機(jī)器需要維護(hù)，它也是可以支持的，就是可以把一些告警直接靜默掉。當(dāng)然還有就是測試環(huán)境，比如說這種告警，你就可以完全忽略掉，我覺得可以這樣來解決。

石鵬：好的，我總結(jié)一下，關(guān)于誤報(bào)這個(gè)問題，兩位老師的意見是比較一致的，我也是比較贊同的。誤報(bào)其實(shí)最根本的原因就是可能你的使用不合理，不管是你的配置還是說你的各種姿勢可能不合理，才會導(dǎo)致誤報(bào)。

然后針對告警風(fēng)暴，其實(shí)Zabbix和Prometheus也就是alert manager，它們都有提供一些相應(yīng)的功能、特性。在Zabbix這邊的話，可以像蔡老師說的用依賴項(xiàng)，然后也是可以加維護(hù)，也可以規(guī)避一些告警；然后Prometheus這邊是alert manager它里面有silent這個(gè)靜默規(guī)則，也是可以去做一些規(guī)避告警這種東西。

可能在很多公司，他們除了監(jiān)控平臺本身去做告警風(fēng)暴的抑制，還會有另外一層。比如說我們公司這邊是這樣：

我們有一個(gè)告警平臺，所有的告警都會匯集到這個(gè)告警平臺里，然后這個(gè)告警平臺會去做一層合并、收斂和抑制。這樣的話，就可以不用特別依賴監(jiān)控平臺本身來提供這些特性，而是由一個(gè)統(tǒng)一的平臺，在做最后發(fā)送動作的時(shí)候，再來做一層cover?？赡茉诹考壌蟮膱鼍跋?，這種是比較推薦的一種思路。

蔡翔華：是的，因?yàn)檎嬲谋O(jiān)控當(dāng)中，其實(shí)還會納入很多比方說ES等其它監(jiān)控平臺，甚至是一些業(yè)務(wù)告警。當(dāng)平臺很多的時(shí)候，其實(shí)你需要有一層聚合的方式，去把告警做一個(gè)聚合收斂，然后通過在聚合平臺里配置一定規(guī)則之后，再去做后續(xù)的一些報(bào)警。

石鵬：沒錯(cuò)，并且你有這個(gè)平臺之后，就可以把一些告警的規(guī)則和策略做得更統(tǒng)一，這樣的話，給用戶的界面和體驗(yàn)也會更好。

蔡翔華：對，所以說其實(shí)看公司規(guī)模，因?yàn)檫@一塊會涉及到一些二次開發(fā)，如果公司沒有這個(gè)能力，那就可以把Zabbix全套或Prometheus全套都用上；如果后續(xù)有能力去做這種聚合的話，其實(shí)Zabbix也好，Prometheus也好，更多的角色定位會變成一個(gè)收集器的角色。然后后面的邏輯其實(shí)都交給事件管理平臺或聚合平臺去做。

劉宇：沒錯(cuò)，這里Zabbix其實(shí)也可以把它的報(bào)警發(fā)送到alert manager里，也可以做一些靜默處理，因?yàn)?/span>Zabbix本身它的靜默功能確實(shí)不是特別多，還是alert manager會做的更好一點(diǎn)。所以兩個(gè)工具其實(shí)可以結(jié)合起來使用。

蔡翔華：首先我們是有嘗試過智能監(jiān)控，但是包括我看到的很多書籍里面，包括Prometheus的一些書籍里面，也說設(shè)這種固定的預(yù)知是一個(gè)很蠢的方法。

根據(jù)我這邊實(shí)際的應(yīng)用，其實(shí)你要做到智能監(jiān)控，肯定要有一些大數(shù)據(jù)的東西，比方說我有這種規(guī)律：

例如，按照我們的實(shí)際操作里有很多互聯(lián)網(wǎng)的應(yīng)用，有些東西它就是會有高并發(fā)高搶購，可能每個(gè)月固定的時(shí)候，比如每個(gè)月10號放一個(gè)活動，活動時(shí)它的量是平時(shí)的10倍甚至100倍；但也可能有時(shí)候，業(yè)務(wù)會不停地在不同的時(shí)間放，你很難去判斷這個(gè)點(diǎn)到底是不是一個(gè)故障點(diǎn)。

也就是說，你用戶數(shù)從10變成了1萬，這1萬到底是因?yàn)楣收狭?，還是說是因?yàn)闃I(yè)務(wù)的一些邏輯導(dǎo)致的，很難判斷。所以目前來說，我們嘗試以后，還是用了一些比較固定的報(bào)警預(yù)知去做。

那么回到這個(gè)話題，Zabbix本身它提供了一些預(yù)測的功能，它會預(yù)測現(xiàn)在我的磁盤消耗大約什么時(shí)候會消耗到20%以下，或某個(gè)閾值以下，它本身是提供了這個(gè)功能的。還有一些內(nèi)置函數(shù)可以去做這個(gè)計(jì)算。但是目前來說，我個(gè)人還是建議使用一個(gè)比較固定的閾值，可以方便我們有一個(gè)明確判斷，否則你早期會有很多的誤報(bào)，甚至可能你都會覺得這東西很正常。

預(yù)測的數(shù)據(jù)也是基于現(xiàn)狀的，如果可以對預(yù)測數(shù)據(jù)進(jìn)行判斷報(bào)警，理論上，也可以針對現(xiàn)有的數(shù)據(jù)進(jìn)行判斷報(bào)警。

劉宇：這塊我們實(shí)踐的案例倒不是特別多，我主要還是對數(shù)據(jù)庫的監(jiān)控比較熟，所以就說一下我們在數(shù)據(jù)庫的自動治愈上是怎么實(shí)現(xiàn)的吧。

比如說告警，它發(fā)送出來的同時(shí)，也會發(fā)送給數(shù)據(jù)庫的一個(gè)自動化平臺，這個(gè)平臺會有一個(gè)程序根據(jù)告警內(nèi)容來調(diào)一些自動治愈的程序來處理這種簡單的故障。但這個(gè)其實(shí)做的也比較有限，就是說我的這種能夠自愈的程序，都是根據(jù)具體場景的，并不是所有的東西都可以做。比如說清理日志、殺讀庫大查詢，以及需要加一些表空間這些場景，類似這種比較固定的會采用自愈來做，其他的嘗試倒不是太多。

石鵬：嗯嗯，這個(gè)問題其實(shí)比較前沿，并且涉獵的范圍是比較廣的。像自動治愈，其實(shí)Zabbix也有一些相關(guān)的功能，它可以去配置action，當(dāng)發(fā)現(xiàn)告警，有問題，我就可以綁定腳本去做一下處理。

但這個(gè)東西要做到什么程度，或者說要用什么技術(shù)來打造這個(gè)底座，可能都會有些差別。

蔡翔華：是的，因?yàn)槲矣X得Prometheus和Zabbix或者說其他平臺，都支持調(diào)action、調(diào)腳本去做一些重啟，但是我覺得關(guān)鍵問題的點(diǎn)是在于你敢不敢做這個(gè)事情。

因?yàn)槲覀冎牢覀兊沫h(huán)境其實(shí)是很復(fù)雜的。比方說，我發(fā)覺數(shù)據(jù)庫宕了，服務(wù)停了，我敢不敢通過這個(gè)服務(wù)自己切過去。因?yàn)楹芏鄷r(shí)候并不是數(shù)據(jù)庫本身的問題，是網(wǎng)絡(luò)的問題，網(wǎng)絡(luò)抖動了，監(jiān)控?cái)?shù)據(jù)拿不到了。這個(gè)是非常依賴于整個(gè)整體環(huán)境的，你可能要想到方方面面，這個(gè)規(guī)則會非常復(fù)雜。你可能在做服務(wù)自愈的時(shí)候，還要去對其他的東西做一個(gè)完全的檢查，確保其他東西是沒有問題的。

所以不說服務(wù)自愈，哪怕在我們?nèi)粘５墓收咸幚懋?dāng)中，也很依賴于經(jīng)驗(yàn)。就是說這個(gè)東西是能做的，但是我們不太敢，因?yàn)橐紤]的要素很多，就不太敢去直接做自愈這一塊。

石鵬：沒錯(cuò)，本身其實(shí)它是一個(gè)體系化的工程，不僅僅是跟監(jiān)控相關(guān)。我這邊的一個(gè)想法是這樣，關(guān)于自動治愈這塊，我們可能還是要更多去依靠業(yè)務(wù)側(cè)的能力。就是說，業(yè)務(wù)側(cè)要具備一些這種架構(gòu)設(shè)計(jì)上的考量，比如說架構(gòu)的柔性，可以自己去做限流、降級、做熔斷，這要求業(yè)務(wù)側(cè)有這樣的能力才可以，而不是說僅僅依靠監(jiān)控系統(tǒng)去做某些動作觸發(fā)。

至于說一些算法和策略的話，之前美圖這邊也是有過一些簡單的嘗試，應(yīng)用不算非常廣泛。但業(yè)界的話，DataOps、AIOps的概念也是比較火熱，這些東西在像BAT這些公司其實(shí)也有一些實(shí)際的應(yīng)用已經(jīng)在落地了。

之前我們做的話，有做這么幾個(gè)小東西，關(guān)于故障預(yù)測是有這么幾個(gè)算法：有同期的數(shù)據(jù)比較、同期的振幅比較、有一個(gè)移動平均算法、然后再有一個(gè)變點(diǎn)監(jiān)測。然后這幾個(gè)的話，可以簡單說一下思路，其實(shí)也比較好理解。

• 同期數(shù)據(jù)，是我按照周期，比如說今天某個(gè)時(shí)間點(diǎn)這個(gè)數(shù)據(jù)，我去比較昨天這個(gè)點(diǎn)是什么樣子的，去比較數(shù)據(jù)；

• 振幅，其實(shí)它就相對更柔性一點(diǎn)，里面會給你加上一個(gè)權(quán)重，加上一個(gè)比例，比如正態(tài)分布里邊的3-sigma，作為振幅系數(shù)去比較同期的數(shù)據(jù)，看在算上振幅之后，你是不是已經(jīng)超出了，去做一個(gè)預(yù)測；

• 變點(diǎn)監(jiān)測，就是說我整體的數(shù)據(jù)曲線是什么樣子的，突然出現(xiàn)了一個(gè)離我正常預(yù)測曲線偏離非常遠(yuǎn)的一個(gè)點(diǎn)，這種的話會有一個(gè)這樣的算法來做這個(gè)事情。

然后這塊相對比較成熟的工具的話，像騰訊之前有開源的運(yùn)維學(xué)件METIS，它里面集成了非常多的算法模型，這個(gè)有興趣的同學(xué)可以去做一些了解。

蔡翔華：首先從技術(shù)本身來說，5.0版本可以看到Zabbix的UI都很不錯(cuò)，可以很多的組、主機(jī)都往大屏里面去拖。大屏的話，我們大概會分幾塊：

第一塊是整個(gè)系統(tǒng)運(yùn)行狀態(tài)。我可能整個(gè)系統(tǒng)有從用戶登錄到用戶支付，包括到購物車等等，有一個(gè)鏈路。我對于每個(gè)鏈路其實(shí)都會有一個(gè)監(jiān)控，它每一個(gè)S組 Service的組，那么Service的組里面包括它的應(yīng)用、數(shù)據(jù)庫緩存、應(yīng)用系統(tǒng)甚至硬件服務(wù)器，一旦這里有任何東西出問題之后，直接會在大屏上顯示一個(gè)警告，那么我就會知道現(xiàn)在整個(gè)生產(chǎn)環(huán)節(jié)哪個(gè)系統(tǒng)是有問題的。

那么另外就是一個(gè)summary，一個(gè)overview的全局的導(dǎo)覽，因?yàn)橐坏┪抑肋@個(gè)有問題，我就希望更加細(xì)化知道這個(gè)東西哪里有問題。那么在下面就會有一個(gè)trigger list的問題列表，就是說有哪些觸發(fā)器被觸發(fā)了，我會看到比方說，數(shù)據(jù)庫端口不通了，還是說磁盤空間已經(jīng)滿了。下面會有trigger list，然后這個(gè)trigger list會按照故障等級是disaster還是warning，同時(shí)對應(yīng)的管理員或者運(yùn)維人員也會收到這個(gè)短信，就知道要立即去處理了。

所以我們盡可能就在大屏里從兩方面來把控，一方面從大的來講，有一個(gè)over view看到全局，從小的來講，我要知道我的故障發(fā)生在哪里?；旧媳ＷC這兩個(gè)要素在大屏里面就OK了。

劉宇：我們這邊大屏其實(shí)主要還是應(yīng)用的維度以及網(wǎng)絡(luò)流量的維度為主。比如說從公網(wǎng)的一個(gè)出口和入口的流量來看會不會有大面積的一個(gè)問題。如果發(fā)現(xiàn)已經(jīng)達(dá)到外面防火墻或者它流量的一個(gè)閾值了，就可以迅速定位問題。

如果是細(xì)節(jié)的話，我們會在大型活動前夕，梳理活動鏈路上的所有應(yīng)用，根據(jù)應(yīng)用的維度來設(shè)計(jì)這樣一個(gè)大屏。大屏可以看到鏈路上所有應(yīng)用、數(shù)據(jù)庫或者是中間件的情況，一旦哪個(gè)應(yīng)用的QPS高了，或者是其他壓力的情況，就可以第一時(shí)間定位到問題出現(xiàn)在哪里，是這樣一個(gè)思路來做。

石鵬：監(jiān)控大屏做得好，確實(shí)可以輔助我們技術(shù)同學(xué)去更快地定位和排查問題，還有一個(gè)比較重要的點(diǎn)，我是這么想的，就是老板會關(guān)注。有些公司會把大屏設(shè)計(jì)得非常有科技感，讓老板看的話，可能老板也覺得我的技術(shù)團(tuán)隊(duì)還挺牛的。當(dāng)然這是一個(gè)題外話。

前面蔡老師和劉老師都給了一些建設(shè)上的思路，就是你應(yīng)該去包含哪些數(shù)據(jù)，應(yīng)該怎么去做。這方面的話，我的一個(gè)思考是你可能要去做服務(wù)的梳理，然后可以以分塊、分業(yè)務(wù)或者說按照分層的方式來做。

分塊的話，就是你按照業(yè)務(wù)線來分。你公司可能有很多塊業(yè)務(wù)，然后按照不同的業(yè)務(wù)去提供一個(gè)視角。在每個(gè)業(yè)務(wù)里，你可以去做分層，分層的意思就是說可以把整個(gè)鏈路，從客戶端一直到CDN、 DNS鏈路，然后到LB入口層，以及應(yīng)用這一層是什么樣的，再關(guān)聯(lián)到后面的一些后端資源，像數(shù)據(jù)庫、緩存這些東西，還有一些其他的周邊依賴，按照這樣分層的方式來做。

具體實(shí)踐的話，可以跟大家做個(gè)預(yù)告，最近我們美圖有一些實(shí)踐經(jīng)驗(yàn)可以分享，近期會把一些完整的設(shè)計(jì)思路和細(xì)節(jié)放出來，大家可以期待一下，持續(xù)關(guān)注dbaplus社群的發(fā)文。

關(guān)于技術(shù)實(shí)現(xiàn)方面，我簡單贅述兩句。我們公司的監(jiān)控大屏是用了Grafana來做的，Grafana可能已經(jīng)成為了事實(shí)上的監(jiān)控UI、數(shù)據(jù)可視化的標(biāo)準(zhǔn)了，它可以后面去接各種各樣的數(shù)據(jù)源，然后你各個(gè)監(jiān)控系統(tǒng)、各種數(shù)據(jù)原理的數(shù)據(jù)可以統(tǒng)一來展示。

這里需要感謝一個(gè)社區(qū)的插件，叫Flow Charting，這個(gè)插件可以非常好地去做監(jiān)控鏈路的事情，就是你可以用這個(gè)插件去把整個(gè)鏈路關(guān)鍵環(huán)節(jié)，以這種圖的方式繪制出來，然后給每一個(gè)點(diǎn)、每一條線綁定上監(jiān)控?cái)?shù)據(jù)，最后生成的圖就動起來了，就可以看到一個(gè)全局性的鏈路狀態(tài)：從入口一直到后端資源，包括各種依賴，當(dāng)前它的狀態(tài)是什么樣子的。

當(dāng)然這個(gè)前提是，你整個(gè)鏈路的監(jiān)控?cái)?shù)據(jù)是要完備的，然后你才可以借助這個(gè)插件去把它呈現(xiàn)出來，大概是這個(gè)樣子的，在這個(gè)圖上就一目了然了。

蔡翔華：如果是個(gè)純?nèi)萜骰模驼f你環(huán)境里面全是Docker，那么說實(shí)話我也不推薦你去使用Zabbix。

因?yàn)閆abbix對容器的監(jiān)控，雖然官方已經(jīng)開始重視了，甚至說現(xiàn)在也支持了Prometheus的很多metrics和exporter這種方式去做監(jiān)控，就是它也可以原生的去支持Prometheus這些東西，但相對來說，Prometheus在容器化監(jiān)控這邊還是會更好一些。

如果你的監(jiān)控需求是又要監(jiān)控硬件服務(wù)器，又要監(jiān)控中間件，又要監(jiān)控業(yè)務(wù)指標(biāo)，那么我推薦使用Zabbix，因?yàn)閆abbix覆蓋的面會更廣一些。

的確我覺得任何需求Zabbix和Prometheus都可以去做，但是從實(shí)現(xiàn)成本來說，相對于Prometheus，你的服務(wù)環(huán)境越復(fù)雜，Zabbix可能就越適合這種比較復(fù)雜的異構(gòu)的環(huán)境。

劉宇：我們目前公司情況是兩個(gè)都在用，的確是偏容器的會往Prometheus優(yōu)先考慮，如果是舊的，比如說是有偏服務(wù)化的這種監(jiān)控，也會慢慢地往Prometheus做一些遷移。

如果你的環(huán)境是一種就可以滿足的話，建議還是一種，因?yàn)楫吘怪恍枰S護(hù)一種技術(shù)棧就可以了?；蛘呤悄憧梢宰鲆恍┢?，比如說把一些不變的放在一種上面，經(jīng)常會變的放在另外一種上面。盡量去減少你維護(hù)的技術(shù)棧。如果你的環(huán)境比較簡單的話，只用一種，當(dāng)然是最好了。

石鵬：其實(shí)還是看場景，美圖跟劉老師這邊比較類似，我們也是多種監(jiān)控工具在用，不過我們現(xiàn)在沒有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，還有很多基于大數(shù)據(jù)的一些流式處理的組件，我們都是混合在用。

主要還是看你具體的需求和場景，沒有銀彈，沒有說一個(gè)工具可以非常合適去搞定所有事情。當(dāng)然它有可能有能力，但是它并不一定特別合適。至于具體的選擇上，還是要看具體場景。比較明確的一個(gè)思路可能就是要看你的監(jiān)控對象到底是容器還是非容器，它是這種易變的還是比較穩(wěn)定態(tài)的。這兩個(gè)思路的話，也是跟蔡老師和劉老師比較一致的。

蔡翔華：其實(shí)從場景來說，Prometheus更適合容器。你可以看一下整個(gè)環(huán)境里，容器和Zabbix的占比，像剛才劉老師說的，這兩者數(shù)據(jù)其實(shí)是可以互相使用、互相監(jiān)控甚至是互相觸發(fā)報(bào)警，那么在Zabbix現(xiàn)在其實(shí)已經(jīng)原生支持了Prometheus的這些exporter的功能，即使你沒有Prometheus后端，Zabbix也可以直接去exporter上拿一些數(shù)據(jù)，通過Zabbix的一些邏輯和機(jī)制去報(bào)警。那么相同的，Zabbix也可以通過action把這些數(shù)據(jù)扔給Prometheus。

也就是說，你可以把它們兩者當(dāng)中的一個(gè)作為數(shù)據(jù)的采集器，另外一個(gè)作為整個(gè)數(shù)據(jù)的邏輯處理的功能，類似于alert manager或者是在zabbix server一樣，這樣做的好處就是說，收集數(shù)據(jù)會非常方便，比方說Prometheus不能收集硬件數(shù)據(jù)，但Zabbix可以收集，我們就用Zabbix收集，同時(shí)把它的數(shù)據(jù)扔給Prometheus，做一個(gè)統(tǒng)一的報(bào)警。這樣的確還是要維護(hù)兩個(gè)平臺，但是相對來說，維護(hù)成本會有所降低，不需要對Zabbix那邊做太多的模板，它其實(shí)只是一個(gè)數(shù)據(jù)采集器。

那么穩(wěn)定性、可用性、性能及監(jiān)控這些東西，其實(shí)也基本上可以基于Prometheus現(xiàn)成的這些規(guī)則、Zabbix現(xiàn)成的這些模板來做。其實(shí)Zabbix社區(qū)里面也有很多模板可以提供到。

關(guān)鍵我覺得有一點(diǎn)就是，我們要思考它模板里面提供的東西，是否是我真的需要的，因?yàn)楹芏鄷r(shí)候大家覺得我啥都要監(jiān)控，但事實(shí)上不是這樣子，只有真正需要關(guān)注的點(diǎn)，才是需要監(jiān)控的東西。所以說大家在部署監(jiān)控之前，要先思考一下監(jiān)控的目的是什么。

劉宇：我的看法其實(shí)還是這樣，比如說偏基礎(chǔ)的，像主機(jī)、網(wǎng)絡(luò)這種可以用Zabbix來監(jiān)控，偏服務(wù)類的和容器的，就用Prometheus來做監(jiān)控。

我們監(jiān)控Redis的一個(gè)集群，在以前沒有Grafana或者Prometheus的情況下，用Zabbix去看集群的整體情況就會比較麻煩，因?yàn)閆abbix依賴的監(jiān)控的一個(gè)點(diǎn)還是以host為基礎(chǔ)的，所以你去看整個(gè)服務(wù)的話會比較麻煩。而Prometheus因?yàn)樗菚r(shí)序的數(shù)據(jù)，可以方便地去打一些你想要的標(biāo)簽，這樣就可以比較方便地監(jiān)控單個(gè)服務(wù)上一個(gè)整體的情況，所以服務(wù)這塊來說，還是Prometheus比較方便。而前面其他蔡老師也說了，比如說硬件這種還是Zabbix比較好用。

石鵬：OK，這個(gè)點(diǎn)上我們理解還是非常一致的。像現(xiàn)在美圖這邊，就單講Prometheus和Open-Falcon，我們基礎(chǔ)的這些監(jiān)控都是在Open-Falcon里，然后容器會在Prometheus里。

這里需要補(bǔ)充一下我們的環(huán)境，現(xiàn)在我們所有業(yè)務(wù)都是基于云上來做的，業(yè)務(wù)容器化程度的話，應(yīng)該是只有個(gè)別服務(wù)沒有容器化，整個(gè)比例應(yīng)該95%以上都是容器化的。但即使是這樣，我們也沒有完全摒棄掉Open-Falcon。

我們在這個(gè)容器里，容器層的這些服務(wù)，像servive、pod這些監(jiān)控，比如說業(yè)務(wù)上暴露出來的metrics，這些東西我們都是用Prometheus來做的。但是像k8s node節(jié)點(diǎn)、ECS，它本身的一些監(jiān)控，包括一些網(wǎng)絡(luò)質(zhì)量的監(jiān)控，還是要有一個(gè)更適合做這種基礎(chǔ)監(jiān)控的平臺來做。我們就是在Open-Falcon里做的。

所以主要還是看場景，怎么去側(cè)重就是看你具體的需求了。

蔡翔華：如果已經(jīng)部署了Zabbix，我估計(jì)你直接通過數(shù)據(jù)庫去導(dǎo)入這種方式會很難做，因?yàn)樗谋斫Y(jié)構(gòu)，包括一個(gè)是時(shí)序數(shù)據(jù)庫，一個(gè)是TSDB，就沒辦法直接做。

我建議如果真的要過渡到Prometheus的話，可以仍然使用Zabbix agent，在數(shù)據(jù)采樣完之后，把它扔到Prometheus，觸發(fā)一些action去提供給Prometheus。這是一種中轉(zhuǎn)方式。

另外一種方式，我會通過一些ansible去部署一些Prometheus expoter到那些機(jī)器上去，把這些數(shù)據(jù)扔給Prometheus。其實(shí)也就回到剛才那個(gè)問題，我這邊所有的數(shù)據(jù)都可以扔給Prometheus使用，去觸發(fā)報(bào)警，這都OK的。

劉宇：如果真的要把Zabbix遷移到Prometheus，就是涉及到一個(gè)監(jiān)控遷移的過程。我這邊的建議還是按照Zabbix先模塊劃分，比如說其中一個(gè)模塊準(zhǔn)備遷到Prometheus，然后首先會把這個(gè)模塊Prometheus的監(jiān)控也加上，會把兩邊的監(jiān)控進(jìn)行一個(gè)比較，至少Prometheus能把原來Zabbix的監(jiān)控都能覆蓋掉，不僅是監(jiān)控的覆蓋，還有告警覆蓋，這樣一個(gè)并行的過程。

最終完全能夠達(dá)到一樣的效果，我就可以把原來Zabbix相關(guān)模塊的監(jiān)控給下掉，是這樣一個(gè)建議的路徑。

蔡翔華：對，而且其實(shí)Prometheus和Zabbix同時(shí)存在并不沖突，并不是說兩者只能選其一。其實(shí)可以說，我先把Prometheus的exporter規(guī)則都配上去，兩邊同時(shí)監(jiān)控，然后再根據(jù)需求，把Zabbix給下了，也OK，這是不存在沖突的。

石鵬：沒錯(cuò)，既然你要平滑，那兩邊同時(shí)有，這應(yīng)該是最平滑的。我們之前是有從Zabbix遷到了Open-Falcon，遷移經(jīng)過了一個(gè)比較長的耗時(shí)，大概用了一年多的時(shí)間。其實(shí)就是你把另一邊的監(jiān)控也布起來，同時(shí)監(jiān)控，然后逐步去下舊監(jiān)控。在這個(gè)過程里，你還可以去比較兩者之間是不是有差異，是不是都能滿足需求，這樣的話應(yīng)該是比較平滑的。

蔡翔華：分布式鏈路其實(shí)我們沒有用Zabbix，因?yàn)榉植际芥溌芬紤]上下游的關(guān)系，所以我們會基于APM去做?，F(xiàn)在像業(yè)內(nèi)比較流行的CAT，可以參考這些去做。

端到端的偵測的話，其實(shí)Zabbix也支持，它支持兩種方式：

一個(gè)是它可以在本地跑一些腳本去做，就是說我這個(gè)檢測是從Zabbix某個(gè)Agen端出發(fā)，到另外一臺目標(biāo)機(jī)器，而不是通過Zabbix server去做檢測。所以說這是Zabbix 提供的另外一種方式，Zabbix active的一種方式，它可以去實(shí)現(xiàn)這種端到端的偵測。Zabbix active的監(jiān)控方式也是比較好的一種方式，可以減輕Zabbix server端的壓力，或proxy端的壓力，能提供更豐富的一些監(jiān)控。

劉宇：這塊因?yàn)?/span>Prometheus是一個(gè)基于數(shù)值的監(jiān)控，對于這種全鏈路的話，一般不太會用Prometheus來做，基本上會用APM的一些分布式鏈路追蹤的工具，比如skywalking等來做。

還會通過一些日志系統(tǒng)來做分布式的監(jiān)控，在鏈路上，提前寫入一些標(biāo)簽，這樣從始至終都可以拿到整個(gè)鏈路上的一個(gè)關(guān)系，就可以做一些分布式鏈路上的監(jiān)控的東西。

石鵬：是的，這也就回到我們前面討論的，沒有銀彈，沒有一種技術(shù)?？梢越鉀Q所有需求的。包括Zabbix和Prometheus，其實(shí)更關(guān)注的還是在偏服務(wù)端，如果是應(yīng)用端的話，其實(shí)還是要依賴一些APM的工具。就像劉老師說的Apache的skywalking，還有像鷹眼、基于open tracing的其他工具。這些東西其實(shí)都是一種思路。

還有一些有技術(shù)能力的公司，會選擇自研一些APM工具，需要自己去開發(fā)各種SDK，然后需要遷到客戶端，去上報(bào)數(shù)據(jù)，是這個(gè)樣子的。

其實(shí)端到端整體的建設(shè)思路應(yīng)該是分段的，客戶端的是一段，中間鏈路是一段，服務(wù)端又是另外一側(cè)。所以想做端到端，很難說用一個(gè)工具就可以完全覆蓋起來。

現(xiàn)在基于云原生、微服務(wù)這些發(fā)展的比較火熱，可能會有一些各個(gè)服務(wù)之間調(diào)用鏈路的服務(wù)治理相關(guān)的監(jiān)控需求，可能也不是說通過Prometheus或Zabbix就可以很好地去完成。還是要看需求場景，選擇更合適的工具，并且組合起來使用。

蔡翔華：首先我覺得還是看應(yīng)用場景，因?yàn)榇笠?guī)模場景下，要看這個(gè)場景是容器多還是非容器環(huán)境多，這是一個(gè)主要依據(jù)。

Zabbix性能的話，其實(shí)瓶頸主要是在數(shù)據(jù)庫，只要把數(shù)據(jù)庫的優(yōu)化做得足夠好，其實(shí)開頭也說了，業(yè)內(nèi)也有做到40萬NVPS的這種案例，已經(jīng)是比較變態(tài)了。那無非就是說，去做數(shù)據(jù)庫分區(qū)分庫拆表、加SSD存儲，通過這種方式。

成本的話，我個(gè)人覺得在底層資源滿足的前提下，成本應(yīng)該都OK。因?yàn)镻rometheus是基于exporter，Zabbix是基于Agent，通過Zabbix agent，配合自動發(fā)現(xiàn)和低級別發(fā)現(xiàn)的這種方式去實(shí)現(xiàn)自動化。

配置成本可能Zabbix會低很多，因?yàn)槎际腔赨I去做，而Prometheus是基于配置文件去做，這個(gè)可能Zabbix會更好些。所以我綜合成本，覺得Zabbix稍微會好一些，但還是取決于你的場景里有多少虛擬化。

劉宇：我覺得如果是性能的話，通過一些分區(qū)的手段都能解決。但如果是非常大的規(guī)模，通過Zabbix，其實(shí)它的數(shù)據(jù)庫瓶頸還是比較嚴(yán)重的，這塊還是需要一些比較好優(yōu)化手段才能解決。

監(jiān)控采集的agent的方式而言，我覺得Prometheus的exporter做得非常全面，像我們以前用Zabbix，基本上有很多東西監(jiān)控都是自己去開發(fā)的；而現(xiàn)在用Prometheus，基本上對于這種采集器的開發(fā)都沒有了，用社區(qū)的就可以全部解決了。所以在采集的層面上，去實(shí)現(xiàn)它最底層和服務(wù)的一個(gè)數(shù)據(jù)采集，我感覺Prometheus的成本會更低一點(diǎn)。

當(dāng)然因?yàn)?span style="color: rgb(62, 62, 62);font-family: Helvetica, Arial, sans-serif;font-size: 15px;letter-spacing: 0.5px;">Prometheus相對來說還是一個(gè)微服務(wù)的架構(gòu)，它的所有組件都是分開的，在搭建成本、學(xué)習(xí)成本會稍微高一點(diǎn)。

石鵬：其實(shí)還是要針對個(gè)性化的場景去做一些選擇。成本的話，如果說你的環(huán)境是一個(gè)比較純粹的，要么是全容器，要么是虛擬化或者物理環(huán)境，你就選一種就好了。如果說你是異構(gòu)的話，可能就不可避免的要選兩種同時(shí)維護(hù)。這兩種里如果有所側(cè)重的話，成本其實(shí)就會有所側(cè)重，所以還是看你的具體需求。

選型，在于抓住監(jiān)控的核心

對于大家比較關(guān)注的監(jiān)控工具選型，用一句話來概括就是：沒有最好的，只有最適合的，要具體場景具體分析。

總的來講，如果是比較純粹的環(huán)境，比如是純物理機(jī)、純虛擬機(jī)，更關(guān)注一些偏基礎(chǔ)設(shè)施層面的需求的話，Zabbix會是一個(gè)非常不錯(cuò)的選項(xiàng)；如果是容器化場景，Prometheus的適應(yīng)性會更好；如果是異構(gòu)的話，建議兩者或更多其它工具結(jié)合起來使用。

縱觀整個(gè)監(jiān)控發(fā)展史，其實(shí)監(jiān)控方案一直是跟隨著行業(yè)技術(shù)、業(yè)務(wù)發(fā)展不斷變化的。到現(xiàn)在，比較火熱的技術(shù)像5G互聯(lián)、物聯(lián)網(wǎng)、人工智能……各種技術(shù)層出不窮，我們需要去監(jiān)控的目標(biāo)對象也一直發(fā)生著變化。隨著多云、混合云架構(gòu)在更多行業(yè)里持續(xù)落地開花，容器、云原生等各種技術(shù)的蓬勃發(fā)展，對監(jiān)控系統(tǒng)其實(shí)也提出了新的需求。

技術(shù)更新迭代速度越來越快，很多同學(xué)難免會有一些焦慮的情緒。這種焦慮是不可避免的，我們應(yīng)該做的還是要去抓住事物的本質(zhì)。

針對監(jiān)控這個(gè)需求，也就是說監(jiān)控的核心是什么？

監(jiān)控在高度抽象之后，無非可以這么來分：監(jiān)控?cái)?shù)據(jù)的暴露、數(shù)據(jù)的采集和傳輸、監(jiān)控?cái)?shù)據(jù)的存儲和處理……這個(gè)過程里，包括各種優(yōu)化、各種格式化處理等；最后是我們怎么去用好監(jiān)控?cái)?shù)據(jù)，把監(jiān)控?cái)?shù)據(jù)的價(jià)值最大化，比如說我們?nèi)プ鰣?bào)表展示、做數(shù)據(jù)分析，像前面講到的用一些DataOps、AIOps的算法、能力介入，把監(jiān)控?cái)?shù)據(jù)的價(jià)值挖掘出來。

這其實(shí)就是監(jiān)控系統(tǒng)所要承載的功能，我們要做的就是抓住這些核心路徑里的原理，然后掌握它，其實(shí)也就OK了。

另外，我們需要保持對這些新鮮事物的熱忱，保持對技術(shù)的敏銳，要有行業(yè)發(fā)展趨勢的感知能力。比如企業(yè)上云，其實(shí)從行業(yè)報(bào)告來看，從去年就已經(jīng)過了上云的拐點(diǎn)，會有越來越多公司選擇把服務(wù)遷移到云上；再看容器和云原生，會有越來越多的周邊生態(tài)完善起來。我們要有這樣的感知能力，要能夠感受到這個(gè)行業(yè)發(fā)展的脈搏，然后做好相應(yīng)的技術(shù)儲備，只有這樣，我們才可能在技術(shù)的浪潮里做到從容不迫，才能夠乘風(fēng)破浪。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝