從監(jiān)控到可觀測(cè)性，設(shè)計(jì)思想、技術(shù)選型、職責(zé)分工都有哪些變化

作者：dbaplus社群 2022-04-26 10:36:34

運(yùn)維

云原生

新聞 本文圍繞“從監(jiān)控到可觀測(cè)性應(yīng)如何轉(zhuǎn)變與升級(jí)”這一話題，希望可以幫助廣大技術(shù)從業(yè)者準(zhǔn)確認(rèn)識(shí)可觀測(cè)性、給企業(yè)搭建適配自身發(fā)展的可觀測(cè)體系提供建議和啟發(fā)。

隨著大量云原生技術(shù)的應(yīng)用，IT系統(tǒng)日益復(fù)雜，主動(dòng)感知、預(yù)測(cè)故障并迅速定位、排障的難度變得越來越大，傳統(tǒng)監(jiān)控方式已無法跟上需求，由此應(yīng)運(yùn)而生的可觀測(cè)性，被視為未來云環(huán)境生產(chǎn)部署不可或缺的技術(shù)支撐。

目前大多數(shù)傳統(tǒng)企業(yè)對(duì)可觀測(cè)性仍處于初步了解階段，不少互聯(lián)網(wǎng)公司在可觀測(cè)性建設(shè)上也是起步不久。因此，圍繞“從監(jiān)控到可觀測(cè)性應(yīng)如何轉(zhuǎn)變與升級(jí)”這一話題，本期dbaplus話題接力專欄，特別采訪到知乎全鏈路可觀測(cè)系統(tǒng)和接入層網(wǎng)絡(luò)負(fù)責(zé)人-熊豹、虎牙直播SRE平臺(tái)研發(fā)團(tuán)隊(duì)負(fù)責(zé)人-匡凌軒、好大夫基礎(chǔ)架構(gòu)部高級(jí)工程師-方勇三位老師，希望能通過他們?cè)诳捎^測(cè)性領(lǐng)域的研究心得和實(shí)踐經(jīng)驗(yàn)，幫助廣大技術(shù)從業(yè)者準(zhǔn)確認(rèn)識(shí)可觀測(cè)性、給企業(yè)搭建適配自身發(fā)展的可觀測(cè)體系提供建議和啟發(fā)。

Q1監(jiān)控與可觀測(cè)性是什么關(guān)系？有什么區(qū)別？可否從兩者的關(guān)注點(diǎn)、應(yīng)用場(chǎng)景、作用、局限性等方面進(jìn)行解析？

熊豹

“正在發(fā)生什么 與 為什么會(huì)這樣”

監(jiān)控是常見的運(yùn)維手段，一般是指以觀測(cè)系統(tǒng)的外部資源使用情況和接口表現(xiàn)來推測(cè)系統(tǒng)運(yùn)行狀態(tài)，即感知到“正在發(fā)生什么”。

可觀測(cè)性是一種屬性，是指在可以感知系統(tǒng)當(dāng)前運(yùn)行狀態(tài)的性質(zhì)，提升系統(tǒng)的可被觀測(cè)的性質(zhì)有助于我們了解“正在發(fā)生什么”以及“為什么會(huì)這樣”。

云原生架構(gòu)在業(yè)內(nèi)逐步落地，給穩(wěn)定性建設(shè)帶來了更多新的挑戰(zhàn)：迭代發(fā)布更迅速、業(yè)務(wù)系統(tǒng)更龐大、網(wǎng)絡(luò)鏈路更復(fù)雜、運(yùn)行環(huán)境更動(dòng)態(tài)。在這樣的混沌系統(tǒng)中僅僅只是知道問題發(fā)生是不夠的，在這樣紛繁復(fù)雜的環(huán)境下赤手空拳的我們很難去進(jìn)行問題的追蹤和溯源。我們要依托分層、多維度的觀測(cè)數(shù)據(jù)來構(gòu)建更立體和智能的診斷系統(tǒng)，以更多樣的視角來觀察和解讀系統(tǒng)。

匡凌軒

“可觀測(cè)性更多是對(duì)業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求”

我認(rèn)為監(jiān)控是可觀測(cè)性能力的一部分，初期監(jiān)控主要是外部對(duì)業(yè)務(wù)應(yīng)用系統(tǒng)的主動(dòng)行為，運(yùn)維是傳統(tǒng)監(jiān)控的使用主體，如：通過業(yè)務(wù)進(jìn)程狀態(tài)、系統(tǒng)資源等監(jiān)控?cái)?shù)據(jù)的分析和告警來發(fā)現(xiàn)問題。而現(xiàn)在可觀測(cè)性更多是對(duì)業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求，如何設(shè)計(jì)去暴露出更多可被觀測(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)控和可觀測(cè)性都旨在輔助建設(shè)高可用的服務(wù)，縮短故障處理時(shí)長(zhǎng)，兩者往往是密切協(xié)作的，界限相對(duì)模糊。

兩者的區(qū)別：監(jiān)控往往關(guān)注告警觸發(fā)的瞬時(shí)狀態(tà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è)老生常談的話題，最常見的場(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)控的支持也不太友好。

可觀測(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)。

可觀測(cè)性的應(yīng)用場(chǎng)景一般與業(yè)務(wù)能力相綁定，通過可視化聚合展示影響SLA的相關(guān)指標(biāo)（SLI），再配合監(jiān)控告警，通過可觀測(cè)性看板下鉆分析異常根因。另外可觀測(cè)性打通Metrics/Traces/Logs后可主動(dòng)識(shí)別出服務(wù)的潛在風(fēng)險(xiǎn)，能先于用戶發(fā)現(xiàn)問題。

可觀測(cè)性也有所局限，由于需要收集業(yè)務(wù)數(shù)據(jù)，對(duì)業(yè)務(wù)具有一定的侵入性，加上打造可視化平臺(tái)投入成本較高。另外可觀測(cè)性整體處于初期階段，很多工具鏈還不太完善，價(jià)值預(yù)期其實(shí)是被高估了。

Q2從監(jiān)控到可觀測(cè)性都有哪些變化？對(duì)運(yùn)維、開發(fā)、架構(gòu)師等崗位人員分別提出了怎樣的新要求？

熊豹

“要把可觀測(cè)性理念貫穿到架構(gòu)和程序設(shè)計(jì)中”

目標(biāo)不一樣了，除了要知道“正在發(fā)生什么”，還要嘗試解釋“為什么會(huì)這樣”。我們需要把可觀測(cè)性的理念貫穿到架構(gòu)和程序設(shè)計(jì)中，而不是到事發(fā)或事后再來補(bǔ)救。我們需要有意識(shí)地設(shè)計(jì)一些機(jī)制來觀察業(yè)務(wù)指標(biāo)的關(guān)聯(lián)變化、系統(tǒng)架構(gòu)的數(shù)據(jù)漏斗模型、程序內(nèi)邏輯分支的運(yùn)行開銷、外部資源依賴的健康狀態(tài)，還要暴露程序內(nèi)的一些資源并發(fā)度、池的填充率和命中率、運(yùn)行時(shí)的狀態(tài)等情況，當(dāng)運(yùn)行錯(cuò)誤時(shí)也要在錯(cuò)誤信息中攜帶足量的上下文信息。

運(yùn)維同學(xué)要為可觀測(cè)場(chǎng)景提供更堅(jiān)實(shí)的工具基礎(chǔ)，在上述龐大的數(shù)據(jù)壓力下，保障和解決數(shù)據(jù)存儲(chǔ)和查詢的性能、資源開銷、集群的拓展性和穩(wěn)定性等問題。

匡凌軒

“從被動(dòng)監(jiān)控向主動(dòng)發(fā)現(xiàn)與定位問題的轉(zhuǎn)變”

我認(rèn)為最大的變化是應(yīng)用系統(tǒng)自身角色的轉(zhuǎn)變，從被動(dòng)監(jiān)控轉(zhuǎn)向主動(dòng)發(fā)現(xiàn)與定位問題，在設(shè)計(jì)應(yīng)用系統(tǒng)架構(gòu)之初就需要考慮到系統(tǒng)自身的可觀測(cè)性建設(shè)。運(yùn)維、開發(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)等。
• 開發(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)和可觀測(cè)性系統(tǒng)的整體架構(gòu)設(shè)計(jì)，需要關(guān)注無侵入式采集上報(bào)、多維度量聚合、錯(cuò)誤尋根分析、整體海量數(shù)據(jù)處理和存儲(chǔ)等。

總體來說，需要各角色有更多跨技術(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è)開始遷移到研發(fā)側(cè)。研發(fā)上線后不再當(dāng)甩手掌柜，開始對(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ù)。
• 開發(fā)，接棒部分運(yùn)維職責(zé)，聚焦服務(wù)可用性，需要有MDD（Metrics-Driven Developmen）的思想，建設(shè)具有高韌性的服務(wù)。
• 架構(gòu)師，在架構(gòu)設(shè)計(jì)的過程中需要暴露可觀測(cè)性的指標(biāo)，同時(shí)需要提升數(shù)據(jù)分析的能力，建模分析Metrics/Traces/Logs數(shù)據(jù)，識(shí)別服務(wù)中潛在的風(fēng)險(xiǎn)。圍繞可觀測(cè)性打造相應(yīng)的工具鏈及服務(wù)治理平臺(tái)。

Q3可觀測(cè)性的核心方法論/關(guān)鍵技術(shù)有哪些？

熊豹

“數(shù)據(jù)的采集、存儲(chǔ)、分析是核心關(guān)注點(diǎn)”

可觀測(cè)性建設(shè)的核心關(guān)注點(diǎn)還是在數(shù)據(jù)的采集、存儲(chǔ)、分析環(huán)節(jié)。

數(shù)據(jù)采集的覆蓋可以以多種角度來看：可嘗試梳理完整的數(shù)據(jù)鏈路，來覆蓋從終端發(fā)起、網(wǎng)關(guān)、業(yè)務(wù)、基礎(chǔ)設(shè)施中間的每一層組件；可以不同的觀測(cè)視角進(jìn)行覆蓋，比如Metrics、Traces、Logs、Exception Collection、Profiler、Debuger、Changelog等類別的數(shù)據(jù)或能力都已建設(shè)齊備；可以多種維度來觀察系統(tǒng)，比如業(yè)務(wù)維度、資源瓶頸、關(guān)聯(lián)組件等維度進(jìn)行覆蓋的建設(shè)。

數(shù)據(jù)存儲(chǔ)環(huán)節(jié)要關(guān)注多種類型數(shù)據(jù)的存儲(chǔ)和查詢系統(tǒng)選型。最為常見的是Metrics、Traces、Logs相關(guān)的存儲(chǔ)系統(tǒng)，這三者都有非常廣泛的基礎(chǔ)軟件選型。其中相對(duì)棘手的是指標(biāo)維度爆炸、日志和Trace存儲(chǔ)成本及性能相關(guān)的問題，一般需要搭配預(yù)聚合、前采樣和后采樣、存儲(chǔ)分級(jí)等策略來解決。

數(shù)據(jù)分析環(huán)節(jié)要關(guān)聯(lián)不同數(shù)據(jù)源的元信息，糅合以多維視角來構(gòu)建查詢界面。同時(shí)，我們也要關(guān)注如何在海量的原始數(shù)據(jù)中找到一些突出和異常的數(shù)據(jù)，一般需要建設(shè)一些流式檢測(cè)和聚類分析的能力。

匡凌軒

“采集數(shù)據(jù)，建立關(guān)聯(lián)，設(shè)計(jì)模型”

可觀測(cè)性的核心思考：需要采集什么數(shù)據(jù)、如何建立關(guān)聯(lián)、如何設(shè)計(jì)模型，我們以應(yīng)用服務(wù)場(chǎng)景為例：

• 采集：請(qǐng)求量、耗時(shí)、錯(cuò)誤和容量等，以及線程池、隊(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)的可觀測(cè)性能力。

方勇

“MDD思想主張指標(biāo)驅(qū)動(dòng)開發(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)用開發(fā)過程由指標(biāo)驅(qū)動(dòng)，通過實(shí)時(shí)指標(biāo)來驅(qū)動(dòng)快速、精確和細(xì)粒度的軟件迭代。指標(biāo)驅(qū)動(dòng)開發(fā)的理念，不但可以讓程序員實(shí)時(shí)感知生產(chǎn)狀態(tài)，及時(shí)定位并終結(jié)問題，還可以幫助產(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可用來分析相關(guān)指標(biāo)。針對(duì)Traces、Logs分析一般采用自研分析引擎，并與Metrics打通。

3、數(shù)據(jù)存儲(chǔ)：Prometheus本身就是一款很好的時(shí)序數(shù)據(jù)庫，但不支持分布式存儲(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ù)庫類型，也可基于Echarts自研。如果托管公有云，可充分利用公有云自有的體系，不過有些需要單獨(dú)付費(fèi)。

Q4如何將Metrics、Traces、Logs三者打通并發(fā)揮最大價(jià)值？

熊豹

“基于時(shí)間范圍內(nèi)的統(tǒng)計(jì)關(guān)系或Label和TraceID關(guān)聯(lián)”

我們已知的有兩類方式：

1、基于時(shí)間范圍內(nèi)的統(tǒng)計(jì)關(guān)系：一般的使用習(xí)慣是在Metric異常的時(shí)間區(qū)間里去找到對(duì)應(yīng)時(shí)間區(qū)間出現(xiàn)異常行為的Traces和Logs，這種方式會(huì)依賴對(duì)Traces和Logs的聚類分析能力。

2、基于Label和TraceID關(guān)聯(lián)：基于OpenTelemetry Collector可觀測(cè)數(shù)據(jù)采集的框架，我們可以以插件的形式、以Trace Span元數(shù)據(jù)Label來生成訪問指標(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)異常，通過指標(biāo)關(guān)聯(lián)分析，并逐層下鉆到明細(xì)Trace追蹤和具體Error Log，全流程自動(dòng)化從宏觀到明細(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)來說，最終業(yè)務(wù)價(jià)值在于幫助研發(fā)和運(yùn)維提高了應(yīng)用服務(wù)的排障和治理效率。

方勇

“打通后可立體、全息分析整個(gè)服務(wù)的可用性”

從投入成本（CapEx）、運(yùn)維成本（OpEx）、響應(yīng)能力（Reaction）、查問題的有效程度（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可觀測(cè)性工具如何選型？有通用的標(biāo)準(zhǔn)嗎？

熊豹

“高可用、可伸縮、降成本、易運(yùn)維”

我們關(guān)注可觀測(cè)工具系統(tǒng)的這些特性：

• 高可用：可觀測(cè)系統(tǒng)作為穩(wěn)定性的守衛(wèi)者，本身要求更高的可靠性。
• 可伸縮：我們關(guān)注存儲(chǔ)寫入和查詢能力的可拓展性，以支持更大的數(shù)據(jù)量級(jí)。
• 降成本：觀測(cè)類數(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ò)展，通過業(yè)界標(biāo)準(zhǔn)來做會(huì)有充分的開源代碼和社區(qū)支持，可以節(jié)省很多基礎(chǔ)代碼的工作，讓我們更關(guān)注自身的業(yè)務(wù)系統(tǒng)特性和模型設(shè)計(jì)。現(xiàn)在OpenTelemetry對(duì)Metrics、Traces、Logs三者提供了統(tǒng)一標(biāo)準(zhǔn)，開源社區(qū)熱度也比較大，是個(gè)值得去研究和實(shí)踐的方向。

可觀測(cè)性工具選型建議可考慮兩個(gè)方面：

1. 是否基于業(yè)界標(biāo)準(zhǔn)，有更多社區(qū)和廠商支持。
2. 是否方便擴(kuò)展，更容易把共性和個(gè)性結(jié)合，最終在此基礎(chǔ)上建設(shè)符合自身業(yè)務(wù)特性的可觀測(cè)性系統(tǒng)。

方勇

“根據(jù)已有技術(shù)棧按需選擇，不必盲從主流”

可觀測(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ù)選型沒什么特定的標(biāo)準(zhǔn)，每個(gè)企業(yè)不同階段可能有不同的選擇，適合自己的才是最好的，這里總結(jié)幾點(diǎn)心得：

• 控制成本預(yù)算，企業(yè)一般需要從自身的發(fā)展階段實(shí)際情況考慮，不必一上來就整全鏈路可觀測(cè)性，也許初期只用傳統(tǒng)的Zabbix就滿足需求了。理性按需選擇，大可不必盲從主流。
• 擁抱開源，初期一般采用開源產(chǎn)品，開箱即用，搭順風(fēng)車。另外，選型時(shí)還需要考慮周邊生態(tài)的豐富度。
• 根據(jù)團(tuán)隊(duì)技術(shù)棧選擇，中間件、業(yè)務(wù)服務(wù)、云原生、物理機(jī)監(jiān)控等選型都要貼合團(tuán)隊(duì)已有的技術(shù)棧。

分享名稱：從監(jiān)控到可觀測(cè)性，設(shè)計(jì)思想、技術(shù)選型、職責(zé)分工都有哪些變化
文章位置：http://uogjgqi.cn/article/dhohhpg.html