企業(yè)可觀測(cè)性架構(gòu)分析（聚焦架構(gòu)優(yōu)化、業(yè)務(wù)有效應(yīng)用與效率提升）

當(dāng)前文檔為博主分析當(dāng)前公司可觀測(cè)性相關(guān)能力過(guò)程中痛點(diǎn)與架構(gòu)的思考，希望能為廣大博友帶來(lái)一些架構(gòu)幫助與借鑒

注：為避免企業(yè)信息泄漏相關(guān)信息會(huì)進(jìn)行脫敏，如后續(xù)公司均以fsdm來(lái)代替，相關(guān)平臺(tái)與技術(shù)細(xì)節(jié)做模糊與省略處理等。如有細(xì)節(jié)探討可聯(lián)系博主

一、背景與目標(biāo)

分析fsdm當(dāng)前可觀測(cè)性建設(shè)現(xiàn)狀，識(shí)別核心痛點(diǎn)，并提出系統(tǒng)性的解決方案，使可觀測(cè)性能力更有效地在業(yè)務(wù)中應(yīng)用與落地，最終實(shí)現(xiàn)：

提升故障排查效率：縮短報(bào)警問(wèn)題定位時(shí)間
優(yōu)化排查體驗(yàn)：構(gòu)建統(tǒng)一的可觀測(cè)性平臺(tái)，提升研發(fā)和運(yùn)維團(tuán)隊(duì)的工作效率
增強(qiáng)業(yè)務(wù)保障能力：通過(guò)預(yù)測(cè)性監(jiān)控進(jìn)行提前預(yù)警
為企業(yè)長(zhǎng)期架構(gòu)演進(jìn)提供技術(shù)基座：設(shè)計(jì)可觀測(cè)性平臺(tái)架構(gòu)，通過(guò)逐步演進(jìn)以達(dá)到最終理想架構(gòu)

二、現(xiàn)狀分析

2.1、已具備能力

fsdm在可觀測(cè)性建設(shè)方面已具備三大核心能力：

? 日志串聯(lián)（Logging）

- 完成了分布式日志收集與聚合

- 支持鏈路trace的日志查詢與分析

? 鏈路追蹤（Tracing）

- 利用Tracing相關(guān)平臺(tái)

- 實(shí)現(xiàn)了分布式調(diào)用鏈跟蹤

? 監(jiān)控告警（Metrics）

- 建立了基礎(chǔ)監(jiān)控指標(biāo)體系

- 配置了關(guān)鍵業(yè)務(wù)告警規(guī)則

2.2、核心問(wèn)題識(shí)別

基礎(chǔ)設(shè)施相對(duì)完善，但存在以下關(guān)鍵問(wèn)題：

?? 業(yè)務(wù)利用率不足

研發(fā)團(tuán)隊(duì)仍主要依賴傳統(tǒng)日志查看方式
可觀測(cè)性工具在故障排查中的使用率不高
直接影響問(wèn)題排查效率，平均定位時(shí)間較長(zhǎng)

?? 數(shù)據(jù)孤島嚴(yán)重

Metrics/Tracing/Logging三大能力相互分離
缺乏統(tǒng)一的關(guān)聯(lián)分析能力
無(wú)法形成完整的問(wèn)題排查閉環(huán)

?? 平臺(tái)體驗(yàn)割裂

告警通知與分析平臺(tái)未打通
如：超時(shí)告警無(wú)法在Tracing平臺(tái)直接關(guān)聯(lián)分析
用戶需要在多個(gè)平臺(tái)間切換，操作復(fù)雜度高

以下為具體case抽樣：

case	問(wèn)題	關(guān)鍵問(wèn)題	排查路徑現(xiàn)狀	期望排查路徑
群內(nèi)接口超時(shí)告警	無(wú)法準(zhǔn)確定位當(dāng)時(shí)鏈路，只能靠日志或人為分析	技術(shù)類告警未與trace關(guān)聯(lián)	接到告警(1) -> 查詢sls日志(2) -> 從日志中人為篩選出n條(3) -> 通過(guò)每條的traceid進(jìn)行關(guān)聯(lián)查詢來(lái)源與參數(shù)(4) -> 打開(kāi)Tracing平臺(tái)查詢鏈路，此時(shí)可能會(huì)沒(méi)有(5) -> 打開(kāi)監(jiān)控平臺(tái)查看當(dāng)時(shí)請(qǐng)求波動(dòng)(6) -> 通過(guò)sls或Tracing平臺(tái)分析服務(wù)內(nèi)部是否存在問(wèn)題(7) -> 人為綜合分析(8)	接到告警(1) -> 一鍵跳轉(zhuǎn)Tracing平臺(tái)可直觀看到來(lái)源、內(nèi)部服務(wù)情況與請(qǐng)求波動(dòng)(2) -> 可通過(guò)篩選某條日志的traceid進(jìn)行日志查詢(3) -> 人工分析 (長(zhǎng)期可通過(guò)智能化手段進(jìn)行“根因建議”) (4)
錯(cuò)誤日志異常報(bào)警	僅靠日志排查或人為分析調(diào)用來(lái)源	errlog未與trace關(guān)聯(lián)（目前僅有Exception代入，但其實(shí)大多數(shù)Exception沒(méi)有業(yè)務(wù)或參數(shù)關(guān)鍵信息，基本無(wú)效）
業(yè)務(wù)告警	如某階段業(yè)務(wù)指標(biāo)徒增。需排查來(lái)源	業(yè)務(wù)指標(biāo)與trace割裂
查詢消息鏈路	單個(gè)traceid關(guān)聯(lián)出全天數(shù)據(jù)	對(duì)于長(zhǎng)鏈接等異步場(chǎng)景可能只存在問(wèn)題（trace生命周期管理？）	通過(guò)消息sid或消息內(nèi)容排查，純靠日志中準(zhǔn)確打印內(nèi)容，如某個(gè)節(jié)點(diǎn)未打印關(guān)鍵信息，需人工分析時(shí)間區(qū)間日志，推斷當(dāng)時(shí)節(jié)點(diǎn)情況	通過(guò)traceid一鍵關(guān)聯(lián)
查詢mq消息來(lái)源	能查出好多無(wú)關(guān)緊要的日志。需人為過(guò)濾無(wú)效信息	對(duì)于長(zhǎng)鏈接等異步場(chǎng)景可能只存在問(wèn)題（trace生命周期管理？）	通過(guò)traceid關(guān)聯(lián)日志。人為過(guò)濾無(wú)關(guān)信息，需保證日志內(nèi)容準(zhǔn)確打印，不然可能存在過(guò)濾失誤加大分析難度	通過(guò)traceid一鍵關(guān)聯(lián)

三、根因分析

對(duì)當(dāng)前情況調(diào)研與分析，可觀測(cè)性利用率不高的根本原因可歸納為以下三個(gè)層面：

3.1、體驗(yàn)層面：不好用

工具鏈割裂：三大可觀測(cè)性能力未深度集成，數(shù)據(jù)割裂并且缺乏統(tǒng)一入口
操作路徑冗長(zhǎng)：從告警到根因定位需要跨多個(gè)平臺(tái)，操作復(fù)雜

3.2、能力層面：有問(wèn)題

Trace能力缺陷：對(duì)長(zhǎng)鏈路、輪訓(xùn)線程、MQ等場(chǎng)景支持不友好
采樣策略問(wèn)題：動(dòng)態(tài)采樣機(jī)制存在缺陷，導(dǎo)致關(guān)鍵告警數(shù)據(jù)無(wú)法查到（可能，需排查）
數(shù)據(jù)準(zhǔn)確性問(wèn)題：如單個(gè)TraceID可能關(guān)聯(lián)到全天數(shù)據(jù)，影響分析準(zhǔn)確性

四、解決與演進(jìn)方案

目前fsdm可觀測(cè)性建設(shè)已具備良好基礎(chǔ)，但需要系統(tǒng)性地解決當(dāng)前的核心痛點(diǎn)。基于問(wèn)題的緊急程度和影響范圍采用分階段解決策略，優(yōu)先解決核心痛點(diǎn)，然后探索構(gòu)建智能化體系，最終進(jìn)行整體架構(gòu)升級(jí)構(gòu)建可觀測(cè)性平臺(tái)。

4.1、第一階段：解決核心痛點(diǎn)，整合三大能力

4.1.1、修復(fù)關(guān)鍵技術(shù)問(wèn)題

采樣策略優(yōu)化
- 排查并修復(fù)為何存在報(bào)警在Tracing平臺(tái)無(wú)法查到問(wèn)題
- 關(guān)鍵業(yè)務(wù)路徑：強(qiáng)制采樣？
數(shù)據(jù)準(zhǔn)確性保障
- 異步場(chǎng)景支持優(yōu)化
- TraceID生命周期管理？
服務(wù)流程自動(dòng)化
- 服務(wù)自動(dòng)錄入，減少申請(qǐng)流程

4.1.2、完成三大能力深度集成

深度集成MTL三大套件以Tracing為核心，實(shí)現(xiàn)三大數(shù)據(jù)源關(guān)聯(lián)，提供關(guān)聯(lián)分析能力
Logging升級(jí)（原Logging僅支持到Trace Id埋入關(guān)聯(lián)升級(jí)為）
- Trace Id埋入關(guān)聯(lián)
- Tracing異常日志收集（使errlog具備一鍵鏈路追蹤能力）
- 業(yè)務(wù)日志與Tracing深度結(jié)合
  - Log -> span
Metrics升級(jí)（原Metrics獨(dú)立服務(wù)升級(jí)為）
- 技術(shù)監(jiān)控與告警指標(biāo) ，依托Tracing進(jìn)行處理（不再獨(dú)立服務(wù)）
  - 理論目前已有能力支撐
- 業(yè)務(wù)指標(biāo)Tracing收集，支持關(guān)聯(lián)鏈路（原Tracing收集百分比不變）
  - 統(tǒng)一規(guī)范、統(tǒng)一數(shù)據(jù)（如轉(zhuǎn)換為span）

4.2、第二階段：智能化升級(jí)與探索

4.2.1、短期智能化能力

接口/鏈路安全智能分析與預(yù)警
告警降噪
1. 基于歷史數(shù)據(jù)訓(xùn)練降噪模型
2. 支持告警聚合和根因分析
智能排查建議
1. API錯(cuò)誤率上升 → 推薦查看網(wǎng)關(guān)日志+依賴服務(wù)狀態(tài)
2. 響應(yīng)時(shí)間異常 → 自動(dòng)分析數(shù)據(jù)庫(kù)慢查詢+緩存命中率
3. 服務(wù)不可用 → 檢查上下游服務(wù)拓?fù)?資源使用情況

4.2.2、長(zhǎng)期AIOps構(gòu)建

構(gòu)建AIOps引擎（降低人為分析成本）降低人為分析成本：預(yù)測(cè)容量瓶頸、自動(dòng)定位根因，異常傳播分析

基于歷史流量與資源指標(biāo)，預(yù)警容量瓶頸
- 基于歷史流量預(yù)測(cè)資源需求，提前1-2周預(yù)警容量瓶頸
整合拓?fù)潢P(guān)系+指標(biāo)波動(dòng)+日志異常，生成根因概率評(píng)分（如：MySQL慢查詢導(dǎo)致API超時(shí)：置信度92%）
基于服務(wù)拓?fù)涞漠惓鞑ヂ窂阶R(shí)別，預(yù)測(cè)故障影響范圍，自動(dòng)生成應(yīng)急響應(yīng)建議

4.3、第三階段：構(gòu)建可觀測(cè)性平臺(tái)理想架構(gòu)體系

采用存儲(chǔ)與計(jì)算分離架構(gòu)
1. 通過(guò)存儲(chǔ)與計(jì)算分離的架構(gòu)體系，降低系統(tǒng)各模塊之間的耦合度，從而顯著提高服務(wù)的可用性和穩(wěn)定性。
2. 增強(qiáng)架構(gòu)的擴(kuò)展能力，能夠靈活應(yīng)對(duì)業(yè)務(wù)增長(zhǎng)和數(shù)據(jù)量擴(kuò)大的需求。
3. 保證架構(gòu)設(shè)計(jì)清晰，易于理解和維護(hù)，降低開(kāi)發(fā)和運(yùn)維成本。
數(shù)據(jù)采集與處理
1. 數(shù)據(jù)采集與同步
  1. 利用OB Client對(duì)業(yè)務(wù)服務(wù)進(jìn)行高效的數(shù)據(jù)采集，并將采集到的數(shù)據(jù)同步至OB數(shù)據(jù)中心。
  2. 數(shù)據(jù)同步模式可靈活選擇為推送（Push）或拉取（Pull），具體實(shí)現(xiàn)細(xì)節(jié)待進(jìn)一步確定。
  3. OB Client的能力提供方式可采用SDK或Agent的形式，具體實(shí)現(xiàn)方案需根據(jù)業(yè)務(wù)需求和技術(shù)可行性進(jìn)行評(píng)估和選擇。
2. 數(shù)據(jù)清洗與存儲(chǔ)
  1. 在OB數(shù)據(jù)中心對(duì)采集到的原始數(shù)據(jù)進(jìn)行深度清洗，去除噪聲數(shù)據(jù)和無(wú)效信息，確保數(shù)據(jù)質(zhì)量。
  2. 將清洗后的數(shù)據(jù)按照統(tǒng)一的模型進(jìn)行存儲(chǔ)落地，為后續(xù)的數(shù)據(jù)分析和應(yīng)用提供基礎(chǔ)。
平臺(tái)能力
1. MTL可視化平臺(tái)
  1. 依托OB數(shù)據(jù)中心強(qiáng)大的數(shù)據(jù)處理和存儲(chǔ)能力，針對(duì)不同業(yè)務(wù)場(chǎng)景進(jìn)行針對(duì)性的計(jì)算和分析。
  2. 僅是一種ui表現(xiàn)形式，可以是阿里云相關(guān)平臺(tái)、開(kāi)源系統(tǒng)自行部署等等
2. AIOPS智能化插件
  1. 提供AIOPS智能化插件，增強(qiáng)平臺(tái)的分析能力，提高運(yùn)維效率和系統(tǒng)的穩(wěn)定性。
  2. 如智能化分析、自動(dòng)化故障檢測(cè)、診斷和預(yù)測(cè)、接口/鏈路安全智能分析與預(yù)警
平臺(tái)賦能與集成
1. 發(fā)布平臺(tái)集成
  1. 發(fā)布平臺(tái)可進(jìn)行能力集成，通過(guò)識(shí)別發(fā)布節(jié)點(diǎn)的鏈路情況，實(shí)現(xiàn)問(wèn)題的快速識(shí)別和定位。
  2. 在發(fā)布過(guò)程中實(shí)時(shí)監(jiān)控業(yè)務(wù)指標(biāo)，及時(shí)發(fā)現(xiàn)潛在問(wèn)題，保障發(fā)布過(guò)程的順利。
2. 自動(dòng)化測(cè)試結(jié)果分析
  1. 自動(dòng)化測(cè)試平臺(tái)可進(jìn)行能力集成，支持對(duì)自動(dòng)化測(cè)試結(jié)果的鏈路分析，加快問(wèn)題定位時(shí)間、降低人工分析成本
3. 用戶行為分析賦能
  1. 可為用戶行為分析提供一定的數(shù)據(jù)基礎(chǔ)
4. 安全風(fēng)控賦能
  1. 可為安全風(fēng)控提供數(shù)據(jù)支持和決策依據(jù)。

5. 更深一步

- 可與db中間件等相關(guān)做MTL集成，打造業(yè)務(wù)+技術(shù) 可觀測(cè)性一體化平臺(tái)

五、可觀測(cè)性成熟度模型

六、總結(jié)與思考

可觀測(cè)性建設(shè)過(guò)程中的數(shù)據(jù)孤島問(wèn)題，其實(shí)在業(yè)界也是一個(gè)普遍性問(wèn)題。從該案例中可以發(fā)現(xiàn)，數(shù)據(jù)孤島的形成往往是歷史演進(jìn)的結(jié)果，不同可觀測(cè)性能力在不同階段各自發(fā)展，后續(xù)數(shù)據(jù)未進(jìn)行互聯(lián)互通。

更進(jìn)一步，從可觀測(cè)性延伸看，當(dāng)前的基礎(chǔ)設(shè)施能力已相對(duì)完善，關(guān)鍵挑戰(zhàn)在于能力的整合與打通。后續(xù)架構(gòu)分析與設(shè)計(jì)中，應(yīng)著重考慮并解決這一問(wèn)題。