很多研發(fā)人員在日常工作中經(jīng)?；赜龅揭韵聝蓚€(gè)問(wèn)題：竟然不可以運(yùn)行，為什么？竟然可以運(yùn)行，為什么？

因此，他們非常期望可觀測(cè)能夠提供解決問(wèn)題的思路。

引言

2017 年，推特工程師 Cindy 發(fā)表了一篇名為《Monitoring and Observability》的文章，首次將可觀測(cè)性這一詞匯帶入開(kāi)發(fā)者視野，通過(guò)半開(kāi)玩笑的方式調(diào)侃了關(guān)于可觀測(cè)性和監(jiān)控的區(qū)別。在軟件產(chǎn)品和服務(wù)領(lǐng)域，監(jiān)控能夠告知我們服務(wù)究竟是否能正常運(yùn)行，而可觀測(cè)性可以告訴我們?yōu)闉槭裁捶?wù)沒(méi)有正常運(yùn)行。

從谷歌趨勢(shì)圖中可以看到，可觀測(cè)性的普及率呈現(xiàn)逐年上升的態(tài)勢(shì)，它也被視為系統(tǒng)的屬性，將逐步成為系統(tǒng)在做開(kāi)發(fā)設(shè)計(jì)過(guò)程中就需要具備的特性。

可觀測(cè)發(fā)展趨勢(shì)

2020 年后，可觀測(cè)的搜索趨勢(shì)出現(xiàn)井噴，很大一部分原因是 SRE 站點(diǎn)可靠性工程逐步普及，國(guó)內(nèi)大廠紛紛設(shè)立相關(guān)崗位和對(duì)應(yīng)招聘指標(biāo)，使得可觀測(cè)性在國(guó)內(nèi)也得到了較多關(guān)注。這也意味著越來(lái)越多的基礎(chǔ)服務(wù)面臨了穩(wěn)定性挑戰(zhàn)，而迎接穩(wěn)定性挑戰(zhàn)的重要手段就在于提供可觀測(cè)性。

上圖左下角為可觀測(cè)性的全球搜索趨勢(shì)，其中中國(guó)的搜索熱度頗高。

可觀測(cè)性定義

可觀測(cè)性是由匈牙利工程師提出的一個(gè)數(shù)學(xué)概念，指系統(tǒng)可以由外部輸出推斷其內(nèi)部狀態(tài)的程度。換句話說(shuō)，可觀測(cè)性應(yīng)當(dāng)可以從數(shù)據(jù)產(chǎn)出中分析出其內(nèi)部的具體運(yùn)轉(zhuǎn)細(xì)節(jié)。

難點(diǎn)與挑戰(zhàn)

業(yè)務(wù)蓬勃發(fā)展 穩(wěn)定性訴求激增

F6 汽車科技是一家專注于汽車后市場(chǎng)信息化建設(shè)的互聯(lián)網(wǎng)平臺(tái)公司，目前處于行業(yè)內(nèi)頭部位置。隨著業(yè)務(wù)蓬勃發(fā)展，F(xiàn)6 支持的商戶數(shù)目短時(shí)間內(nèi)暴增數(shù)十倍，同時(shí)也逐步開(kāi)展了面向技師等 C 端場(chǎng)景的業(yè)務(wù)，比如 Vin 碼解析、數(shù)據(jù)查詢等，對(duì)于穩(wěn)定性的要求顯著提高。

康威定律的作用

康威定律是 IT 史上對(duì)整個(gè)組織架構(gòu)進(jìn)行微服務(wù)拆分的指導(dǎo)性定律。任何組織在設(shè)計(jì)系統(tǒng)過(guò)程中都是組織架構(gòu)的翻版，隨著業(yè)務(wù)膨脹，康威定律作用會(huì)導(dǎo)致設(shè)計(jì)微服務(wù)時(shí)拆分方式趨同于組織架構(gòu)，業(yè)務(wù)增長(zhǎng)會(huì)導(dǎo)致部門(mén)拆分，后續(xù)設(shè)計(jì)微服務(wù)時(shí)也會(huì)十分靠近組織架構(gòu)。哪怕前期組織架構(gòu)和微服務(wù)拆分不一致，后面微服務(wù)也會(huì)逐步妥協(xié)于組織架構(gòu)。

雖然微服務(wù)和組織架構(gòu)趨同使得系統(tǒng)溝通效率較高，但是這也帶來(lái)了很多分布式的系統(tǒng)問(wèn)題。比如微服務(wù)之間的交互，沒(méi)有人能夠?qū)Ψ?wù)有整體性、全局性的了解，研發(fā)人員最直接的期望就是在分布式系統(tǒng)中也能有單機(jī)系統(tǒng)的排查效率，這促使我們需要將系統(tǒng)以服務(wù)器為中心的思路轉(zhuǎn)變?yōu)橐哉{(diào)用鏈為中心的思路。

穩(wěn)定性訴求激增

F6 最早進(jìn)行業(yè)務(wù)開(kāi)發(fā)時(shí)采用煙囪式的建設(shè)。單體應(yīng)用比較簡(jiǎn)單，但是它在擴(kuò)展性和可維護(hù)性上存在很多問(wèn)題。比如所有研發(fā)都在系統(tǒng)上進(jìn)行，代碼沖突較多，什么時(shí)間點(diǎn)能發(fā)布，發(fā)布會(huì)造成多少業(yè)務(wù)量損失等皆難以明確。因此，越來(lái)越多情況導(dǎo)致我們需要進(jìn)行微服務(wù)拆分，而微服務(wù)拆分和調(diào)用又會(huì)導(dǎo)致調(diào)用鏈?zhǔn)謴?fù)雜繁瑣，如上圖右所示，幾乎無(wú)法人為分析出調(diào)用鏈路。

那么，怎么樣才能盡可能降低線上排查故障的難度？

可觀測(cè)演進(jìn)

傳統(tǒng)監(jiān)控+微應(yīng)用日志收集

• ELKStack 獲取日志和查詢 ElastAlert 完成日志告警

傳統(tǒng)的監(jiān)控和微服務(wù)日志收集一般采用 ELKStack 進(jìn)行日志收集。ELK 是三個(gè)開(kāi)源項(xiàng)目的首字母縮寫(xiě)，分別是 Elasticsearch、Logstash 和 Kibana。

我們重度依賴 ELK 進(jìn)行微服務(wù)日志的收集，與此同時(shí)，還使用了開(kāi)源的基于 ES 的報(bào)警系統(tǒng) ElastAlert 組件，主要功能是從 ES 中查詢出匹配規(guī)則，對(duì)相關(guān)類型數(shù)據(jù)進(jìn)行報(bào)警。

上圖描述了通過(guò)日志收集進(jìn)行日常查詢的思路。比如研發(fā)人員會(huì)通過(guò) pipeling 查詢線上日志，ElastAlert 通過(guò)匹配規(guī)則告警獲取到 ES 日志中發(fā)掘出來(lái)異常數(shù)據(jù)，kibana 可以進(jìn)行查詢，也可以優(yōu)先定位出系統(tǒng)中發(fā)生的異常。

架構(gòu)升級(jí)+可觀測(cè)性引入

• Grafana 看板+Zorka 支持 jvm 監(jiān)控

隨著業(yè)務(wù)發(fā)展，系統(tǒng)對(duì)日志的要求也逐步增加，比如團(tuán)隊(duì)非常多，需要配置各種各樣的告警規(guī)則，因此我們引入了 Grafana 逐步替代 kibana 和 Zabbix 的查詢功能?？梢酝ㄟ^(guò) Grafana 的 ES 插件查詢對(duì)日志進(jìn)行告警，然后通過(guò) alert 功能完成原先 ElastAlert 的排除，同時(shí)可以使用 Grafana 做出更直觀的可視化大屏進(jìn)行展示。

除了日志外，我們也期望收集到 Java 應(yīng)用指標(biāo)，因此又引入了 Zorka 開(kāi)源組件。Zorka 和 Zabbix 可以簡(jiǎn)單地進(jìn)行結(jié)合，可以通過(guò) Zorka 將收集到的信息上報(bào)給 Zabbix 進(jìn)行展示。而 Zabbix 又可以通過(guò) Grafana Zabbix 插件直接輸出數(shù)據(jù)，最終將整個(gè)應(yīng)用大屏和看板信息都收集到 Grafana 界面。

Zorka 的工作機(jī)制類似于通過(guò) Zabbix Java gateway 的方式，通過(guò) Java Agent 自動(dòng)掛載到 Java 進(jìn)程中，用于統(tǒng)計(jì)常見(jiàn)應(yīng)用容器和請(qǐng)求數(shù)指標(biāo)等，初步解決了我們對(duì)于 Java 進(jìn)程的觀測(cè)需求。

云原生改造

• K8s 的編排能力和微服務(wù)相輔相成迫切需要 trace 組件的支持

隨著微服務(wù)程度不斷提升，傳統(tǒng)方式的運(yùn)維成本越來(lái)越高，因此，我們啟動(dòng)了云原生化改造。

首先，云原生化的改造是 K8s 側(cè)就緒探針和存活探針的編寫(xiě)。存活探針的編寫(xiě)提升了服務(wù)的自愈能力，出現(xiàn)了 OOM 后服務(wù)能夠自動(dòng)恢復(fù)、啟動(dòng)新節(jié)點(diǎn)，保證數(shù)據(jù)服務(wù)正常提供。除了 K8s 外，我們還引入了 Prometheus 和 ARMS 應(yīng)用監(jiān)控。

Prometheus 作為 CNCF 僅次于 K8s 的 2 號(hào)項(xiàng)目，在整個(gè) metrics 領(lǐng)域形成了足夠的話語(yǔ)權(quán)；ARMS 應(yīng)用監(jiān)控作為阿里云商業(yè) APM 的拳頭產(chǎn)品，使我們能夠結(jié)合云原生的方式，實(shí)現(xiàn)研發(fā)無(wú)感，無(wú)需進(jìn)行任何代碼改動(dòng)即可擁有 trace 功能。更重要的是，阿里云團(tuán)隊(duì)能夠保持持續(xù)迭代，支持越來(lái)越多中間件，因此我們認(rèn)為它必定會(huì)成為診斷利器。

• JmxExporter 快速支持云原生 Java 組件的 jvm 信息展示

進(jìn)行云原生化改造后，監(jiān)控模型也發(fā)生了改變。最早的監(jiān)控模型是 push，Zorka 每次發(fā)布都在同一臺(tái)機(jī)器上，因此它有固定的 host；而上云后，容器化改造導(dǎo)致 Pod 不再固定，且可能會(huì)出現(xiàn)新的應(yīng)用擴(kuò)縮容等問(wèn)題。因此，我們將監(jiān)控模型逐步從 push 轉(zhuǎn)換成 pull 模式，也更加契合 Prometheus 的收集模型，并逐步將 Zorka 從可觀測(cè)體系中剝離。

沒(méi)有使用 ARMS 直接收集 JMX 指標(biāo)是因?yàn)?ARMS 不會(huì)覆蓋線上和線下所有 java 應(yīng)用，沒(méi)有被覆蓋的應(yīng)用也期望有 JVM 數(shù)據(jù)收集功能，而 ARMS 成本略高。因此，出于成本的考慮，我們沒(méi)有將 ARMS 作為完整接入，而是選擇了 JMX Exporter 組件。

JMX Export 也是 Prometheus 官方社區(qū)提供的 exporter 之一。它通過(guò) Java Agent 利用 Java JMX 機(jī)制讀取 JVM 信息，可以將數(shù)據(jù)直接轉(zhuǎn)化成為 Prometheus 可以辨識(shí)的 metrics 格式，使 Prometheus 能夠?qū)ζ溥M(jìn)行監(jiān)控和采集，并通過(guò) Prometheus Operator 注冊(cè)對(duì)應(yīng)的 Service Moninor 完成指標(biāo)收集。

• 利用配置中心完成應(yīng)用到 owner 的精準(zhǔn)告警

隨著公司業(yè)務(wù)蓬勃發(fā)展，人員激增，微服務(wù)暴增，研發(fā)人數(shù)和告警也劇烈增長(zhǎng)。為了提升告警觸達(dá)率和響應(yīng)率，我們重新使用了 Apollo 配置中心的多語(yǔ)言 SDK，通過(guò) Go 自研了一套基于 Apollo 業(yè)務(wù)的應(yīng)用提醒，整體流程如下：

通過(guò) Grafana 收集到 ES 告警或其他場(chǎng)景下的告警，再通過(guò) metrics 應(yīng)用關(guān)聯(lián)到 alert ，告警時(shí)會(huì)轉(zhuǎn)發(fā)到前文提到的 Go 語(yǔ)言編寫(xiě)的精準(zhǔn)告警服務(wù)上。精準(zhǔn)告警服務(wù)解析到對(duì)應(yīng)應(yīng)用，根據(jù)應(yīng)用從 Apollo 配置中心中獲取到 owner 姓名、手機(jī)號(hào)等信息，再基于此信息通過(guò)釘釘進(jìn)行告警，極大提升了消息閱讀率。

• ARMS：無(wú)侵入支持 Trace

此外，我們還引入了阿里云的應(yīng)用實(shí)時(shí)監(jiān)控服務(wù) ARMS ，能夠在沒(méi)有任何代碼改造的前提下，支持絕大部分中間件和框架，比如 Kafka、MySQL、Dubbo 等。云原生化后，僅需要在 deployment 里添加注解即可支持相關(guān)探針的加載，微服務(wù)的可維護(hù)性極為友好。同時(shí)，還提供了較為完整的 trace 視圖，可以查看線上應(yīng)用節(jié)點(diǎn)調(diào)用日志的整個(gè) trace 鏈路，也提供了甘特圖的查看方式和依賴拓?fù)鋱D、上下游耗時(shí)圖等數(shù)據(jù)。

可觀測(cè)升級(jí)

• Log Trace Metrics 理念升級(jí)

可觀測(cè)在國(guó)內(nèi)微服務(wù)領(lǐng)域已遍地開(kāi)花。因此，F(xiàn)6 公司也升級(jí)了可觀測(cè)思路。業(yè)界廣泛推行的可觀測(cè)性包含三大支柱，分別是日志事件、分布式鏈路追蹤以及指標(biāo)監(jiān)控。任何時(shí)代都需要監(jiān)控，但是它已經(jīng)不再是核心需求。上圖可以看出，監(jiān)控僅包含告警和應(yīng)用概覽，而事實(shí)上可觀測(cè)性還需包括排錯(cuò)剖析以及依賴分析。

最早的監(jiān)控功能使用主體是運(yùn)維人員，但運(yùn)維人員大多只能處理系統(tǒng)服務(wù)告警。而上升到整個(gè)微服務(wù)領(lǐng)域，更多問(wèn)題可能出現(xiàn)在應(yīng)用之間，需要進(jìn)行問(wèn)題排障。比如服務(wù)出現(xiàn)了慢請(qǐng)求，有可能是因?yàn)榇a問(wèn)題，也可能因?yàn)殒i或線程池不足，或連接數(shù)不夠等，以上種種問(wèn)題最終表現(xiàn)出來(lái)的特征是慢和服務(wù)無(wú)法響應(yīng)。而如此多的可能性，需要通過(guò)可觀測(cè)性才能定位到真正根因。然而，定位根因并非真實(shí)需求，真實(shí)需求更多的是利用可觀測(cè)性分析出問(wèn)題所處節(jié)點(diǎn)，然后通過(guò)替換對(duì)應(yīng)組件、進(jìn)行熔斷或限流等措施，盡可能提升整體 SLA 。

可觀測(cè)性還可以很好的剖析問(wèn)題，比如線上服務(wù)慢，可以觀測(cè)其每個(gè)節(jié)點(diǎn)的耗時(shí)、每個(gè)請(qǐng)求中的耗時(shí)等。依賴分析也可以得到解決，比如服務(wù)依賴是否合理、服務(wù)依賴調(diào)用鏈路是否正常等。

隨著應(yīng)用越來(lái)越多，對(duì)于可觀測(cè)性和穩(wěn)定性的訴求也越來(lái)越多。因此，我們自研了一套簡(jiǎn)單的根因分析系統(tǒng)，通過(guò)文本相似度算法將當(dāng)前服務(wù)日志進(jìn)行歸類聚類分析。

• 簡(jiǎn)版根因分析上線

上圖為典型 ONS 故障，依賴服務(wù)進(jìn)行服務(wù)升級(jí)。如果這是通過(guò)日志抓取智能分析出來(lái)的日志，做了很長(zhǎng)時(shí)間 SRE 后，變更也會(huì)對(duì)于線上穩(wěn)定性造成很大破壞。如果能將變更等也收集到可觀測(cè)體系中，將會(huì)帶來(lái)很大好處。同理，如果能將 ONS 要升級(jí)的信息收集到可觀測(cè)體系統(tǒng)中，通過(guò)種種事件關(guān)聯(lián)，能夠分析出根因，對(duì)于系統(tǒng)穩(wěn)定性和問(wèn)題排查將極為有益。

• ARMS 支持 traceId 透出 responseHeader

F6 公司和 ARMS 團(tuán)隊(duì)也進(jìn)行了深入合作，探索了可觀測(cè)的最佳實(shí)踐。ARMS 近期退出了一項(xiàng)新功能，將 traceID 直接透出到 HTTP 頭，可以在接入層日志中將它輸出到對(duì)應(yīng)日志，通過(guò) Kibana 進(jìn)行檢索。

客戶在發(fā)生故障時(shí)，將日志信息和 traceID 一起上報(bào)給技術(shù)支持人員，最后研發(fā)人員可通過(guò) traceID 快速定位到問(wèn)題原因、上下游鏈路，因?yàn)?traceID 在整個(gè)調(diào)用鏈路中是唯一的，非常適合作為檢索條件。

同時(shí)，ARMS 支持直接通過(guò) MDC 透?jìng)?traceID ，支持 Java 主流日志框架，包括 Logback、Log4j、Log4j2 等，也可以將 traceID 作為標(biāo)準(zhǔn) Python 輸出。

上圖展示了典型的日志輸出場(chǎng)景下 ARMS 的后臺(tái)配置，可以打開(kāi)關(guān)聯(lián)業(yè)務(wù)日志和 traceID ，支持各種各樣的組件，只需在日志系統(tǒng)中定義 eagleeye_traceid 即可輸出 traceID。

上述方案較為簡(jiǎn)單，研發(fā)的修改也很少，甚至可以做到免修改，且對(duì)于 Loggin 和 Trace 的關(guān)聯(lián)程度做到了較大提升，減少了數(shù)據(jù)孤島。

• ARMS 支持運(yùn)維告警平臺(tái)

ARMS 為進(jìn)一步降低 MTTR ，提供了很多數(shù)據(jù)，但是數(shù)據(jù)如何到達(dá) SRE 、DevOps 或研發(fā)運(yùn)維人員手里，依然需要花費(fèi)一些心思。

因此，ARMS 上線了運(yùn)維告警平臺(tái)，通過(guò)可視化方式完成了告警轉(zhuǎn)發(fā)、分流等事件處理，可以通過(guò)靜默功能、分組等，支持多種集成方式。目前 F6 在用的包括 Prometheus、buffalo、ARMS 以及云監(jiān)控，其中云監(jiān)控包含了包括 ONS、Redis 在內(nèi)的很多數(shù)據(jù)，研發(fā)人員或 SRE 人員在釘釘群里認(rèn)領(lǐng)對(duì)應(yīng)的響應(yīng)事件即可。同時(shí)還支持報(bào)表、定時(shí)提醒、事件升級(jí)等功能，便于事后復(fù)盤(pán)和改善。

上圖為線上處理問(wèn)題的界面截圖。比如釘釘群里的告警會(huì)提示上一次相似告警由誰(shuí)處理、告警列表以及對(duì)應(yīng)事件處理流程等。同時(shí)，還提供了過(guò)濾功能，可以分割內(nèi)容，通過(guò)字段豐富或匹配更新等方式替換內(nèi)容填充模板，用于精準(zhǔn)告警，比如識(shí)別到應(yīng)用名稱后，可以關(guān)聯(lián)到對(duì)應(yīng)應(yīng)用的 owner 或告警人員。此功能后續(xù)也將逐步替代前文用 Go 語(yǔ)言寫(xiě)的 Apollo SDK 應(yīng)用。

• Java 生態(tài)免修改注入 agent 方式-JAVA_TOOL_OPTIONS

同時(shí)，我們也借鑒了 ARMS 免修改注入 Agent 的方式。ARMS 通過(guò)one point initContainer 的方式注入了很多 ARMS 信息，也掛載了一個(gè)名為 home/admin/.opt 的 mount 用于存儲(chǔ)日志。正因?yàn)橛?initContainer ，它才能夠?qū)崿F(xiàn)自動(dòng)升級(jí)。

在 initContainer 中，可以通過(guò)調(diào)用 ARMS 接口獲取到當(dāng)前 ARMS Agent 最新版本，然后下載 Java Agent 最新版本，放到 mount 目錄下，與目錄下對(duì)應(yīng)的數(shù)組 Pod 進(jìn)行通信，通過(guò)共享 volume 的方式完成 Java Agent 共享。過(guò)程中最核心的點(diǎn)在于，通過(guò) JAVA_TOOL_OPTIONS 實(shí)現(xiàn)了 Java Agent 掛載。

通過(guò)上述方式，我們模擬了一套流程，通過(guò)openkruise 組件 workspread 使用 patch 方式修改 deployment。最簡(jiǎn)單的實(shí)踐是利用 openkruise workspread給對(duì)應(yīng)的 deployment 打注解，從而使得無(wú)需由研發(fā)或 SRE 團(tuán)隊(duì)進(jìn)行處理，只要編寫(xiě)對(duì)應(yīng) CRD 即可，CRD 過(guò)程直接注入 JAVA_TOOL_OPTIONS（見(jiàn)上圖右下角代碼）。其應(yīng)用場(chǎng)景也較為豐富，可以做應(yīng)用流量回放、自動(dòng)化測(cè)試等。

• Prometheus Exporter

除了 ARMS 等商業(yè)化產(chǎn)品外，我們也積極開(kāi)源，擁抱 Prometheus 社區(qū)，接入了較多 Exporter 組件，包括 SSLExport 和 BlackBoxExporter，極大提升了整個(gè)系統(tǒng)的可觀測(cè)性。Exporter 可以用于黑盒探針，比如探測(cè) HTTP 請(qǐng)求是否正常、HTTPS 請(qǐng)求是否正、DNS 是否正常、TCP 是否正常等，典型的使用場(chǎng)景是探測(cè)當(dāng)前服務(wù)入口地址是否正常。SSL 證書(shū)異常更為常見(jiàn)，通過(guò) SSLExporter 可以定期輪詢證書(shū)是否過(guò)期，進(jìn)一步提升可觀測(cè)性。

• 成本觀測(cè)

除了日常服務(wù)可觀測(cè)，我們還實(shí)踐了成本可觀測(cè)等優(yōu)化項(xiàng)目。對(duì)于云原生環(huán)境，可以利用 kubecost 開(kāi)源組件進(jìn)行成本優(yōu)化，直接輸出資源使用率以及報(bào)表等，反饋給研發(fā)人員進(jìn)行優(yōu)化，甚至可以用來(lái)發(fā)現(xiàn) CPU 和內(nèi)存是否呈正常比例，盡可能實(shí)現(xiàn)資源合理分配。

未來(lái)暢想

基于 eBPF 的 Kuberneters 一站式可觀測(cè)性

eBPF 云原生組件愈發(fā)進(jìn)入到深水區(qū)，很多問(wèn)題不再只停留于應(yīng)用層面，更多地會(huì)出現(xiàn)在系統(tǒng)層面和網(wǎng)絡(luò)層面，需要更加底層的數(shù)據(jù)進(jìn)行追蹤和排障。利用 eBPF 可以更好地回答 Google SRE 提出的比如延遲、流量、錯(cuò)誤率、飽和度等黃金指標(biāo)出現(xiàn)的問(wèn)題。

比如 Redis 進(jìn)行閃斷切換的過(guò)程中，可能會(huì)形成 TCP 半開(kāi)連接，從而對(duì)業(yè)務(wù)產(chǎn)生影響；再比如 TCP 連接剛建立時(shí)，backlog 是否合理等，都可以通過(guò)數(shù)據(jù)得到相應(yīng)結(jié)論。

Chaos-engineering

Chaos-engineering 混沌工程鼓勵(lì)和利用可觀測(cè)性，試圖幫助用戶先發(fā)制人地發(fā)現(xiàn)和克服系統(tǒng)弱點(diǎn)。2020 年 6 月，CNCF 針對(duì)可觀測(cè)性提出了特別興趣小組。除了三大支柱外，CNCF 還提出了混沌工程和持續(xù)優(yōu)化。

對(duì)于混沌工程是否能劃分在可觀測(cè)性里，當(dāng)前社區(qū)依然存在疑議，而 CNCF 的可觀測(cè)性特別興趣小組里已包含了 chaos-engineering 和持續(xù)優(yōu)化。我們認(rèn)為，CNCF 的做法有一定道理，混沌工程可以被認(rèn)為是一種可觀測(cè)性的分析工具，但其重要前提是可觀測(cè)性。試想，如果在實(shí)施混沌工程過(guò)程中發(fā)生故障，我們甚至都無(wú)法確定它是否由混沌工程引起，這也將帶來(lái)極大麻煩。

因此，可以利用可觀測(cè)性盡可能縮小爆炸半徑、定位問(wèn)題，通過(guò) chaos-engineering 持續(xù)優(yōu)化系統(tǒng)，提前發(fā)現(xiàn)系統(tǒng)薄弱點(diǎn)，更好地為系統(tǒng)穩(wěn)定性保駕護(hù)航。

OpenTelemetry

OpenTelemetry 是一個(gè)通過(guò)多個(gè)項(xiàng)目合并而來(lái)的開(kāi)源框架。我們需要更加面向終端研發(fā)統(tǒng)一的可觀測(cè)性視圖，比如期望將 logging、metrics 和 tracing 數(shù)據(jù)進(jìn)行互相關(guān)聯(lián)打標(biāo)，盡可能減少數(shù)據(jù)孤島，通過(guò)多數(shù)據(jù)源的關(guān)聯(lián)提升整體可觀測(cè)性。并利用可觀測(cè)性盡可能縮短線上故障排查時(shí)間，為業(yè)務(wù)服務(wù)恢復(fù)爭(zhēng)取時(shí)間。