很多研發(fā)人員在日常工作中經(jīng)常回遇到以下兩個問題：竟然不可以運行，為什么？竟然可以運行，為什么？

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

引言

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

(資料圖片)

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

可觀測發(fā)展趨勢

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

上圖左下角為可觀測性的全球搜索趨勢，其中中國的搜索熱度頗高。

可觀測性定義

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

難點與挑戰(zhàn)業(yè)務(wù)蓬勃發(fā)展 穩(wěn)定性訴求激增

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

康威定律的作用

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

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

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

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

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

可觀測演進傳統(tǒng)監(jiān)控+微應(yīng)用日志收集ELKStack 獲取日志和查詢 ElastAlert 完成日志告警

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

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

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

架構(gòu)升級+可觀測性引入Grafana 看板+Zorka 支持 jvm 監(jiān)控

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ARMS：無侵入支持 Trace

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

可觀測升級Log Trace Metrics 理念升級

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

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

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

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

簡版根因分析上線

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

ARMS 支持 traceId 透出 responseHeader

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

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

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

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

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

ARMS 支持運維告警平臺

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

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

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

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

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

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

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

Prometheus Exporter

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

成本觀測

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

未來暢想基于 eBPF 的 Kuberneters 一站式可觀測性

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

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

Chaos-engineering

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

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

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

OpenTelemetry

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

關(guān)鍵詞： 可觀測性 組織架構(gòu) 是否正常 我們需要 蓬勃發(fā)展