新聞中心
從監(jiān)控到可觀(guān)測(cè)性,設(shè)計(jì)思想、技術(shù)選型、職責(zé)分工都有哪些變化
作者:dbaplus社群 2022-04-26 10:36:34
運(yùn)維
云原生
新聞 本文圍繞“從監(jiān)控到可觀(guān)測(cè)性應(yīng)如何轉(zhuǎn)變與升級(jí)”這一話(huà)題,希望可以幫助廣大技術(shù)從業(yè)者準(zhǔn)確認(rèn)識(shí)可觀(guān)測(cè)性、給企業(yè)搭建適配自身發(fā)展的可觀(guān)測(cè)體系提供建議和啟發(fā)。

隨著大量云原生技術(shù)的應(yīng)用,IT系統(tǒng)日益復(fù)雜,主動(dòng)感知、預(yù)測(cè)故障并迅速定位、排障的難度變得越來(lái)越大,傳統(tǒng)監(jiān)控方式已無(wú)法跟上需求,由此應(yīng)運(yùn)而生的可觀(guān)測(cè)性,被視為未來(lái)云環(huán)境生產(chǎn)部署不可或缺的技術(shù)支撐。
目前大多數(shù)傳統(tǒng)企業(yè)對(duì)可觀(guān)測(cè)性仍處于初步了解階段,不少互聯(lián)網(wǎng)公司在可觀(guān)測(cè)性建設(shè)上也是起步不久。因此,圍繞“從監(jiān)控到可觀(guān)測(cè)性應(yīng)如何轉(zhuǎn)變與升級(jí)”這一話(huà)題,本期dbaplus話(huà)題接力專(zhuān)欄,特別采訪(fǎng)到知乎全鏈路可觀(guān)測(cè)系統(tǒng)和接入層網(wǎng)絡(luò)負(fù)責(zé)人-熊豹、虎牙直播SRE平臺(tái)研發(fā)團(tuán)隊(duì)負(fù)責(zé)人-匡凌軒、好大夫基礎(chǔ)架構(gòu)部高級(jí)工程師-方勇三位老師,希望能通過(guò)他們?cè)诳捎^(guān)測(cè)性領(lǐng)域的研究心得和實(shí)踐經(jīng)驗(yàn),幫助廣大技術(shù)從業(yè)者準(zhǔn)確認(rèn)識(shí)可觀(guān)測(cè)性、給企業(yè)搭建適配自身發(fā)展的可觀(guān)測(cè)體系提供建議和啟發(fā)。
Q1監(jiān)控與可觀(guān)測(cè)性是什么關(guān)系?有什么區(qū)別?可否從兩者的關(guān)注點(diǎn)、應(yīng)用場(chǎng)景、作用、局限性等方面進(jìn)行解析?
熊豹
“正在發(fā)生什么 與 為什么會(huì)這樣”
監(jiān)控是常見(jiàn)的運(yùn)維手段,一般是指以觀(guān)測(cè)系統(tǒng)的外部資源使用情況和接口表現(xiàn)來(lái)推測(cè)系統(tǒng)運(yùn)行狀態(tài),即感知到“正在發(fā)生什么”。
可觀(guān)測(cè)性是一種屬性,是指在可以感知系統(tǒng)當(dāng)前運(yùn)行狀態(tài)的性質(zhì),提升系統(tǒng)的可被觀(guān)測(cè)的性質(zhì)有助于我們了解“正在發(fā)生什么”以及“為什么會(huì)這樣”。
云原生架構(gòu)在業(yè)內(nèi)逐步落地,給穩(wěn)定性建設(shè)帶來(lái)了更多新的挑戰(zhàn):迭代發(fā)布更迅速、業(yè)務(wù)系統(tǒng)更龐大、網(wǎng)絡(luò)鏈路更復(fù)雜、運(yùn)行環(huán)境更動(dòng)態(tài)。在這樣的混沌系統(tǒng)中僅僅只是知道問(wèn)題發(fā)生是不夠的,在這樣紛繁復(fù)雜的環(huán)境下赤手空拳的我們很難去進(jìn)行問(wèn)題的追蹤和溯源。我們要依托分層、多維度的觀(guān)測(cè)數(shù)據(jù)來(lái)構(gòu)建更立體和智能的診斷系統(tǒng),以更多樣的視角來(lái)觀(guān)察和解讀系統(tǒng)。
匡凌軒
“可觀(guān)測(cè)性更多是對(duì)業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求”
我認(rèn)為監(jiān)控是可觀(guān)測(cè)性能力的一部分,初期監(jiān)控主要是外部對(duì)業(yè)務(wù)應(yīng)用系統(tǒng)的主動(dòng)行為,運(yùn)維是傳統(tǒng)監(jiān)控的使用主體,如:通過(guò)業(yè)務(wù)進(jìn)程狀態(tài)、系統(tǒng)資源等監(jiān)控?cái)?shù)據(jù)的分析和告警來(lái)發(fā)現(xiàn)問(wèn)題。而現(xiàn)在可觀(guān)測(cè)性更多是對(duì)業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求,如何設(shè)計(jì)去暴露出更多可被觀(guān)測(cè)的應(yīng)用運(yùn)行時(shí)的數(shù)據(jù),并為這些數(shù)據(jù)之間建立關(guān)聯(lián),如:微服務(wù)框架在請(qǐng)求處理和RPC調(diào)用時(shí)提供一些AOP擴(kuò)展的設(shè)計(jì),可以更方便地對(duì)請(qǐng)求進(jìn)行Metric度量和Trace追蹤,以及異常情況的上下文關(guān)聯(lián)。
方勇
“從局部到全局可用性視角的延伸”
兩者的關(guān)系:監(jiān)控和可觀(guān)測(cè)性都旨在輔助建設(shè)高可用的服務(wù),縮短故障處理時(shí)長(zhǎng),兩者往往是密切協(xié)作的,界限相對(duì)模糊。
兩者的區(qū)別:監(jiān)控往往關(guān)注告警觸發(fā)的瞬時(shí)狀態(tài),一般圍繞告警事件展開(kāi),涉及從告警事件的產(chǎn)生到應(yīng)急響應(yīng)等一系列動(dòng)作。關(guān)注的視角一般是局部可用性,關(guān)注每個(gè)具體的監(jiān)控項(xiàng),如CPU負(fù)載、剩余內(nèi)存等。監(jiān)控是個(gè)老生常談的話(huà)題,最常見(jiàn)的場(chǎng)景是系統(tǒng)資源監(jiān)控、進(jìn)程或服務(wù)狀態(tài)的粗粒度監(jiān)控。對(duì)定制化的業(yè)務(wù)指標(biāo)監(jiān)控不太友好,另外傳統(tǒng)的監(jiān)控體系對(duì)云原生的支持、對(duì)微服務(wù)體系監(jiān)控的支持也不太友好。
可觀(guān)測(cè)性可以看作是監(jiān)控的一種延續(xù),涉及面較廣,包括全鏈路分析(APM)、業(yè)務(wù)服務(wù)質(zhì)量(SLA)、業(yè)務(wù)容量等,聚焦服務(wù)的整體可用性。關(guān)注的視角一般是全局可用性,會(huì)忽略不影響服務(wù)質(zhì)量的一些指標(biāo),如CPU負(fù)載高,服務(wù)整體時(shí)延波動(dòng)不大就會(huì)忽略這個(gè)CPU負(fù)載指標(biāo)。
可觀(guān)測(cè)性的應(yīng)用場(chǎng)景一般與業(yè)務(wù)能力相綁定,通過(guò)可視化聚合展示影響SLA的相關(guān)指標(biāo)(SLI),再配合監(jiān)控告警,通過(guò)可觀(guān)測(cè)性看板下鉆分析異常根因。另外可觀(guān)測(cè)性打通Metrics/Traces/Logs后可主動(dòng)識(shí)別出服務(wù)的潛在風(fēng)險(xiǎn),能先于用戶(hù)發(fā)現(xiàn)問(wèn)題。
可觀(guān)測(cè)性也有所局限,由于需要收集業(yè)務(wù)數(shù)據(jù),對(duì)業(yè)務(wù)具有一定的侵入性,加上打造可視化平臺(tái)投入成本較高。另外可觀(guān)測(cè)性整體處于初期階段,很多工具鏈還不太完善,價(jià)值預(yù)期其實(shí)是被高估了。
Q2從監(jiān)控到可觀(guān)測(cè)性都有哪些變化?對(duì)運(yùn)維、開(kāi)發(fā)、架構(gòu)師等崗位人員分別提出了怎樣的新要求?
熊豹
“要把可觀(guān)測(cè)性理念貫穿到架構(gòu)和程序設(shè)計(jì)中”
目標(biāo)不一樣了,除了要知道“正在發(fā)生什么”,還要嘗試解釋“為什么會(huì)這樣”。我們需要把可觀(guān)測(cè)性的理念貫穿到架構(gòu)和程序設(shè)計(jì)中,而不是到事發(fā)或事后再來(lái)補(bǔ)救。我們需要有意識(shí)地設(shè)計(jì)一些機(jī)制來(lái)觀(guān)察業(yè)務(wù)指標(biāo)的關(guān)聯(lián)變化、系統(tǒng)架構(gòu)的數(shù)據(jù)漏斗模型、程序內(nèi)邏輯分支的運(yùn)行開(kāi)銷(xiāo)、外部資源依賴(lài)的健康狀態(tài),還要暴露程序內(nèi)的一些資源并發(fā)度、池的填充率和命中率、運(yùn)行時(shí)的狀態(tài)等情況,當(dāng)運(yùn)行錯(cuò)誤時(shí)也要在錯(cuò)誤信息中攜帶足量的上下文信息。
運(yùn)維同學(xué)要為可觀(guān)測(cè)場(chǎng)景提供更堅(jiān)實(shí)的工具基礎(chǔ),在上述龐大的數(shù)據(jù)壓力下,保障和解決數(shù)據(jù)存儲(chǔ)和查詢(xún)的性能、資源開(kāi)銷(xiāo)、集群的拓展性和穩(wěn)定性等問(wèn)題。
匡凌軒
“從被動(dòng)監(jiān)控向主動(dòng)發(fā)現(xiàn)與定位問(wèn)題的轉(zhuǎn)變”
我認(rèn)為最大的變化是應(yīng)用系統(tǒng)自身角色的轉(zhuǎn)變,從被動(dòng)監(jiān)控轉(zhuǎn)向主動(dòng)發(fā)現(xiàn)與定位問(wèn)題,在設(shè)計(jì)應(yīng)用系統(tǒng)架構(gòu)之初就需要考慮到系統(tǒng)自身的可觀(guān)測(cè)性建設(shè)。運(yùn)維、開(kāi)發(fā)、架構(gòu)師都是各環(huán)節(jié)設(shè)計(jì)的參與者,在協(xié)作方式也有一定的改變:
- 運(yùn)維:深入熟悉產(chǎn)品業(yè)務(wù)和應(yīng)用服務(wù),定義并關(guān)聯(lián)業(yè)務(wù)指標(biāo)、應(yīng)用服務(wù)指標(biāo)、系統(tǒng)資源指標(biāo)等。
- 開(kāi)發(fā):在框架層設(shè)計(jì)和實(shí)現(xiàn)對(duì)分布式應(yīng)用服務(wù)運(yùn)行時(shí)的Metric、Trace、Log數(shù)據(jù)采集。
- 架構(gòu)師:業(yè)務(wù)應(yīng)用系統(tǒng)和可觀(guān)測(cè)性系統(tǒng)的整體架構(gòu)設(shè)計(jì),需要關(guān)注無(wú)侵入式采集上報(bào)、多維度量聚合、錯(cuò)誤尋根分析、整體海量數(shù)據(jù)處理和存儲(chǔ)等。
總體來(lái)說(shuō),需要各角色有更多跨技術(shù)領(lǐng)域的知識(shí)儲(chǔ)備、業(yè)務(wù)思維和模型抽象能力。
方勇
“職責(zé)分工、認(rèn)知意識(shí)、排障效率的轉(zhuǎn)變和升級(jí)”
個(gè)人認(rèn)為主要變化有以下幾個(gè)方面:
- 職責(zé)分工的轉(zhuǎn)變,研發(fā)關(guān)注服務(wù)質(zhì)量后,部分職責(zé)從運(yùn)維側(cè)開(kāi)始遷移到研發(fā)側(cè)。研發(fā)上線(xiàn)后不再當(dāng)甩手掌柜,開(kāi)始對(duì)自己的服務(wù)負(fù)責(zé)。
- 認(rèn)知意識(shí)的提高,從被動(dòng)響應(yīng)告警到主動(dòng)提升服務(wù)質(zhì)量。
- 排障效率的提升,從原先的黑盒排障模式逐漸朝可視化發(fā)展。
對(duì)不同崗位人員也有新的要求:
- 運(yùn)維,需要擺脫傳統(tǒng)監(jiān)控的意識(shí)枷鎖,擁抱云原生監(jiān)控體系,同時(shí)和其他崗位人員達(dá)成共識(shí),共建高可用服務(wù)。
- 開(kāi)發(fā),接棒部分運(yùn)維職責(zé),聚焦服務(wù)可用性,需要有MDD(Metrics-Driven Developmen)的思想,建設(shè)具有高韌性的服務(wù)。
- 架構(gòu)師,在架構(gòu)設(shè)計(jì)的過(guò)程中需要暴露可觀(guān)測(cè)性的指標(biāo),同時(shí)需要提升數(shù)據(jù)分析的能力,建模分析Metrics/Traces/Logs數(shù)據(jù),識(shí)別服務(wù)中潛在的風(fēng)險(xiǎn)。圍繞可觀(guān)測(cè)性打造相應(yīng)的工具鏈及服務(wù)治理平臺(tái)。
Q3可觀(guān)測(cè)性的核心方法論/關(guān)鍵技術(shù)有哪些?
熊豹
“數(shù)據(jù)的采集、存儲(chǔ)、分析是核心關(guān)注點(diǎn)”
可觀(guān)測(cè)性建設(shè)的核心關(guān)注點(diǎn)還是在數(shù)據(jù)的采集、存儲(chǔ)、分析環(huán)節(jié)。
數(shù)據(jù)采集的覆蓋可以以多種角度來(lái)看:可嘗試梳理完整的數(shù)據(jù)鏈路,來(lái)覆蓋從終端發(fā)起、網(wǎng)關(guān)、業(yè)務(wù)、基礎(chǔ)設(shè)施中間的每一層組件;可以不同的觀(guān)測(cè)視角進(jìn)行覆蓋,比如Metrics、Traces、Logs、Exception Collection、Profiler、Debuger、Changelog等類(lèi)別的數(shù)據(jù)或能力都已建設(shè)齊備;可以多種維度來(lái)觀(guān)察系統(tǒng),比如業(yè)務(wù)維度、資源瓶頸、關(guān)聯(lián)組件等維度進(jìn)行覆蓋的建設(shè)。
數(shù)據(jù)存儲(chǔ)環(huán)節(jié)要關(guān)注多種類(lèi)型數(shù)據(jù)的存儲(chǔ)和查詢(xún)系統(tǒng)選型。最為常見(jiàn)的是Metrics、Traces、Logs相關(guān)的存儲(chǔ)系統(tǒng),這三者都有非常廣泛的基礎(chǔ)軟件選型。其中相對(duì)棘手的是指標(biāo)維度爆炸、日志和Trace存儲(chǔ)成本及性能相關(guān)的問(wèn)題,一般需要搭配預(yù)聚合、前采樣和后采樣、存儲(chǔ)分級(jí)等策略來(lái)解決。
數(shù)據(jù)分析環(huán)節(jié)要關(guān)聯(lián)不同數(shù)據(jù)源的元信息,糅合以多維視角來(lái)構(gòu)建查詢(xún)界面。同時(shí),我們也要關(guān)注如何在海量的原始數(shù)據(jù)中找到一些突出和異常的數(shù)據(jù),一般需要建設(shè)一些流式檢測(cè)和聚類(lèi)分析的能力。
匡凌軒
“采集數(shù)據(jù),建立關(guān)聯(lián),設(shè)計(jì)模型”
可觀(guān)測(cè)性的核心思考:需要采集什么數(shù)據(jù)、如何建立關(guān)聯(lián)、如何設(shè)計(jì)模型,我們以應(yīng)用服務(wù)場(chǎng)景為例:
- 采集:請(qǐng)求量、耗時(shí)、錯(cuò)誤和容量等,以及線(xiàn)程池、隊(duì)列、連接池等資源指標(biāo)。
- 關(guān)聯(lián):縱向關(guān)聯(lián)請(qǐng)求上下游鏈路和調(diào)用棧,橫向關(guān)聯(lián)請(qǐng)求和處理請(qǐng)求所消耗的應(yīng)用資源。
- 模型:數(shù)據(jù)采集和關(guān)聯(lián)、異常定義和分析、全鏈路錯(cuò)誤尋根三方面統(tǒng)一的模型化設(shè)計(jì)。
以上可指導(dǎo)我們針對(duì)不同的業(yè)務(wù)應(yīng)用系統(tǒng)進(jìn)行合理抽象,建設(shè)更標(biāo)準(zhǔn)的可觀(guān)測(cè)性能力。
方勇
“MDD思想主張指標(biāo)驅(qū)動(dòng)開(kāi)發(fā)”
常用方法論:
1、SLI選擇:
- 參考Google VALET(Volume、Available、Latency、Error、Ticket)模型。
- Netflix的USE方法,USE是Utilization(使用率)、Saturation(飽和度)、Error(錯(cuò)誤)。
- Weave Cloud的RED方法,Request-Rate(每秒接收的請(qǐng)求數(shù))/Request-Errors(每秒失敗的請(qǐng)求數(shù))/Request-Duration(每個(gè)請(qǐng)求所花費(fèi)的時(shí)間,用時(shí)間間隔表示)。
2、MDD(Metrics-Driven Development)思想:MDD主張整個(gè)應(yīng)用開(kāi)發(fā)過(guò)程由指標(biāo)驅(qū)動(dòng),通過(guò)實(shí)時(shí)指標(biāo)來(lái)驅(qū)動(dòng)快速、精確和細(xì)粒度的軟件迭代。指標(biāo)驅(qū)動(dòng)開(kāi)發(fā)的理念,不但可以讓程序員實(shí)時(shí)感知生產(chǎn)狀態(tài),及時(shí)定位并終結(jié)問(wèn)題,還可以幫助產(chǎn)品經(jīng)理和運(yùn)維人員一起關(guān)注相關(guān)的業(yè)務(wù)指標(biāo)。
關(guān)鍵技術(shù):
1、數(shù)據(jù)收集:如果是基于Prometheus生態(tài),有豐富的Exporte可用,還可以自研相應(yīng)的Exporter。如果基于文件日志收集,可考慮Flume、Fluentd等等。
2、數(shù)據(jù)分析:可基于Clickhouse SQL分析提煉日志指標(biāo),如果是Prometheus體系,也有豐富的PromQL可用來(lái)分析相關(guān)指標(biāo)。針對(duì)Traces、Logs分析一般采用自研分析引擎,并與Metrics打通。
3、數(shù)據(jù)存儲(chǔ):Prometheus本身就是一款很好的時(shí)序數(shù)據(jù)庫(kù),但不支持分布式存儲(chǔ)。一般采用遠(yuǎn)程存儲(chǔ)引擎搭配使用,常用Clickhouse、InfluxDB等。Traces和Logs一般可采用Elasticsearch存儲(chǔ)。
4、數(shù)據(jù)展示:數(shù)據(jù)最終呈現(xiàn)形式,需要契合可視化設(shè)計(jì)規(guī)劃,支持上卷/下鉆。大部分需求可采用Grafana呈現(xiàn),Grafana提供了豐富的插件,支持豐富的數(shù)據(jù)庫(kù)類(lèi)型,也可基于Echarts自研。如果托管公有云,可充分利用公有云自有的體系,不過(guò)有些需要單獨(dú)付費(fèi)。
Q4如何將Metrics、Traces、Logs三者打通并發(fā)揮最大價(jià)值?
熊豹
“基于時(shí)間范圍內(nèi)的統(tǒng)計(jì)關(guān)系或Label和TraceID關(guān)聯(lián)”
我們已知的有兩類(lèi)方式:
1、基于時(shí)間范圍內(nèi)的統(tǒng)計(jì)關(guān)系:一般的使用習(xí)慣是在Metric異常的時(shí)間區(qū)間里去找到對(duì)應(yīng)時(shí)間區(qū)間出現(xiàn)異常行為的Traces和Logs,這種方式會(huì)依賴(lài)對(duì)Traces和Logs的聚類(lèi)分析能力。
2、基于Label和TraceID關(guān)聯(lián):基于OpenTelemetry Collector可觀(guān)測(cè)數(shù)據(jù)采集的框架,我們可以以插件的形式、以Trace Span元數(shù)據(jù)Label來(lái)生成訪(fǎng)問(wèn)指標(biāo),也同時(shí)將TraceID攜帶記錄到日志的元信息中,這樣就能以同樣的TraceID或Label維度進(jìn)行關(guān)聯(lián)查看了。另外當(dāng)前Prometheus實(shí)現(xiàn)了一個(gè)exemplar特性可以將Metric與TraceID關(guān)聯(lián)存儲(chǔ),這個(gè)設(shè)計(jì)也挺有意思的。
匡凌軒
“全鏈路錯(cuò)誤尋根是三者打通的最大價(jià)值”
三者打通最大的價(jià)值是能做到全鏈路錯(cuò)誤尋根,即從發(fā)現(xiàn)請(qǐng)求Metric指標(biāo)異常,通過(guò)指標(biāo)關(guān)聯(lián)分析,并逐層下鉆到明細(xì)Trace追蹤和具體Error Log,全流程自動(dòng)化從宏觀(guān)到明細(xì)的錯(cuò)誤發(fā)現(xiàn)和根因定位。
虎牙為三者統(tǒng)一設(shè)計(jì)了應(yīng)用監(jiān)控模型,包括應(yīng)用服務(wù)的透明零成本SDK接入,三者數(shù)據(jù)自動(dòng)采集和關(guān)聯(lián),以及在虎牙大型分布式系統(tǒng)充分實(shí)踐的全鏈路錯(cuò)誤尋根算法。就整體實(shí)踐經(jīng)驗(yàn)來(lái)說(shuō),最終業(yè)務(wù)價(jià)值在于幫助研發(fā)和運(yùn)維提高了應(yīng)用服務(wù)的排障和治理效率。
方勇
“打通后可立體、全息分析整個(gè)服務(wù)的可用性”
從投入成本(CapEx)、運(yùn)維成本(OpEx)、響應(yīng)能力(Reaction)、查問(wèn)題的有效程度(Investigation)幾個(gè)方面分析。Metrics、Logs、Traces具有以下特征:
Logs和Traces一般采用trace_id打通,trace_id一般在端入口生成,貫穿整個(gè)請(qǐng)求的生命周期,業(yè)務(wù)記錄Logs的時(shí)候可記錄當(dāng)前的trace_id,這樣Logs和Traces就能打通了。
與Metrics打通一般是采用標(biāo)簽Tags模式,如某個(gè)服務(wù)servername產(chǎn)生的metrics可與Traces中的servername關(guān)聯(lián)。
打通后可以服務(wù)名的維度,立體、全息分析整個(gè)服務(wù)的可用性。
Q5可觀(guān)測(cè)性工具如何選型?有通用的標(biāo)準(zhǔn)嗎?
熊豹
“高可用、可伸縮、降成本、易運(yùn)維”
我們關(guān)注可觀(guān)測(cè)工具系統(tǒng)的這些特性:
- 高可用:可觀(guān)測(cè)系統(tǒng)作為穩(wěn)定性的守衛(wèi)者,本身要求更高的可靠性。
- 可伸縮:我們關(guān)注存儲(chǔ)寫(xiě)入和查詢(xún)能力的可拓展性,以支持更大的數(shù)據(jù)量級(jí)。
- 降成本:觀(guān)測(cè)類(lèi)數(shù)據(jù)會(huì)隨著時(shí)間的推移逐漸失去價(jià)值,歷史數(shù)據(jù)最好能低成本地失效或能對(duì)存儲(chǔ)介質(zhì)進(jìn)行降級(jí)。
- 易運(yùn)維:擁有一定的自動(dòng)化能力或者本身架構(gòu)足夠簡(jiǎn)單。
匡凌軒
“是否基于業(yè)界標(biāo)準(zhǔn)且方便擴(kuò)展”
虎牙主要是基于OpenTracing標(biāo)準(zhǔn)進(jìn)行的深度自研和擴(kuò)展,通過(guò)業(yè)界標(biāo)準(zhǔn)來(lái)做會(huì)有充分的開(kāi)源代碼和社區(qū)支持,可以節(jié)省很多基礎(chǔ)代碼的工作,讓我們更關(guān)注自身的業(yè)務(wù)系統(tǒng)特性和模型設(shè)計(jì)?,F(xiàn)在OpenTelemetry對(duì)Metrics、Traces、Logs三者提供了統(tǒng)一標(biāo)準(zhǔn),開(kāi)源社區(qū)熱度也比較大,是個(gè)值得去研究和實(shí)踐的方向。
可觀(guān)測(cè)性工具選型建議可考慮兩個(gè)方面:
- 是否基于業(yè)界標(biāo)準(zhǔn),有更多社區(qū)和廠(chǎng)商支持。
- 是否方便擴(kuò)展,更容易把共性和個(gè)性結(jié)合,最終在此基礎(chǔ)上建設(shè)符合自身業(yè)務(wù)特性的可觀(guān)測(cè)性系統(tǒng)。
方勇
“根據(jù)已有技術(shù)棧按需選擇,不必盲從主流”
可觀(guān)測(cè)性分析整個(gè)技術(shù)??蓞⒖既缦聢D:
工具選型:
- Metrics:常用Zabbix、Nagios、Prometheus,及相關(guān)高可用部署方案如Prometheus-operator、Thanos。
- Logging:ELK Stack、Fluentd、Loki等。
- Traceing:常用Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth等。
- 可視化:Grafana。
其實(shí)技術(shù)選型沒(méi)什么特定的標(biāo)準(zhǔn),每個(gè)企業(yè)不同階段可能有不同的選擇,適合自己的才是最好的,這里總結(jié)幾點(diǎn)心得:
- 控制成本預(yù)算,企業(yè)一般需要從自身的發(fā)展階段實(shí)際情況考慮,不必一上來(lái)就整全鏈路可觀(guān)測(cè)性,也許初期只用傳統(tǒng)的Zabbix就滿(mǎn)足需求了。理性按需選擇,大可不必盲從主流。
- 擁抱開(kāi)源,初期一般采用開(kāi)源產(chǎn)品,開(kāi)箱即用,搭順風(fēng)車(chē)。另外,選型時(shí)還需要考慮周邊生態(tài)的豐富度。
- 根據(jù)團(tuán)隊(duì)技術(shù)棧選擇,中間件、業(yè)務(wù)服務(wù)、云原生、物理機(jī)監(jiān)控等選型都要貼合團(tuán)隊(duì)已有的技術(shù)棧。
本文標(biāo)題:從監(jiān)控到可觀(guān)測(cè)性,設(shè)計(jì)思想、技術(shù)選型、職責(zé)分工都有哪些變化
分享路徑:http://www.5511xx.com/article/dhohhpg.html


咨詢(xún)
建站咨詢(xún)
