[[435884]]

一 、前言

可觀測性這個(gè)概念最早出現(xiàn)于20世紀(jì)70年代的電氣工程，核心的定義是：

A system is said to be observable if, for any possible evolution of state and control vectors, the current state can be estimated using only the information from outputs.

相比傳統(tǒng)的告警、監(jiān)控，可觀測性能夠以更加“白盒”的方式看透整個(gè)復(fù)雜的系統(tǒng)，幫助我們更好的觀察系統(tǒng)的運(yùn)行狀況，快速定位和解決問題。就像發(fā)動(dòng)機(jī)而言，告警只是告訴你發(fā)動(dòng)機(jī)是否有問題，而一些包含轉(zhuǎn)速、溫度、壓力的儀表盤能夠幫我們大致確定是哪個(gè)部分可能有問題，而真正定位細(xì)節(jié)問題還需要觀察每個(gè)部件的傳感器數(shù)據(jù)才行。

二 、IT系統(tǒng)的可觀測性

電氣化時(shí)代起源于第二次工業(yè)革命(Second Industrial Revolution）起于19世紀(jì)七十年代，主要標(biāo)志是：電力、內(nèi)燃機(jī)的廣泛應(yīng)用。而可觀測性這一概念為何在近100年后才會被提出？難道在此之前就不需要依賴各類傳感器的輸出定位和排查故障和問題？顯然不是，排查故障的方式一直都在，只是整個(gè)系統(tǒng)和情況更加復(fù)雜，所以才需要更加體系化、系統(tǒng)化的方式來支持這一過程，因此演化出來可觀測性這個(gè)概念。所以核心點(diǎn)在于：

• 系統(tǒng)更加的復(fù)雜：以前的汽車只需要一個(gè)發(fā)動(dòng)機(jī)、傳送帶、車輛、剎車就可以跑起來，現(xiàn)在隨便一個(gè)汽車上至少有上百個(gè)部件和系統(tǒng)，故障的定位難度變的更大。
• 開發(fā)涉及更多的人：隨著全球化時(shí)代的到來，公司、部分的分工也越來越細(xì)，也就意味著系統(tǒng)的開發(fā)和維護(hù)需要更多的部門和人來共同完成，協(xié)調(diào)的代價(jià)也越來越大。
• 運(yùn)行環(huán)境多種多樣：不同的運(yùn)行環(huán)境下，每個(gè)系統(tǒng)的工作情況是變化的，我們需要在任何階段都能有效記錄好系統(tǒng)的狀態(tài)，便于我們分析問題、優(yōu)化產(chǎn)品。

而IT系統(tǒng)經(jīng)過幾十年的飛速發(fā)展，整個(gè)開發(fā)模式、系統(tǒng)架構(gòu)、部署模式、基礎(chǔ)設(shè)施等也都經(jīng)過了好幾輪的優(yōu)化，優(yōu)化帶來了更快的開發(fā)、部署效率，但隨之而來整個(gè)的系統(tǒng)也更加的復(fù)雜、開發(fā)依賴更多的人和部門、部署模式和運(yùn)行環(huán)境也更加動(dòng)態(tài)和不確定，因此IT行業(yè)也已經(jīng)到了需要更加系統(tǒng)化、體系化進(jìn)行觀測的這一過程。

IT系統(tǒng)的可觀測性實(shí)施起來其實(shí)和電氣工程還是比較類似，核心還是觀察我們各個(gè)系統(tǒng)、應(yīng)用的輸出，通過數(shù)據(jù)來判斷整體的工作狀態(tài)。通常我們會把這些輸出進(jìn)行分類，總結(jié)為Traces、Metrics、Logs。關(guān)于這三種數(shù)據(jù)的特點(diǎn)、應(yīng)用場景以及關(guān)系等，我們會在后面進(jìn)行詳細(xì)展開。

三、IT可觀測性的演進(jìn)

IT的可觀測性技術(shù)一直在不斷的發(fā)展中，從廣義的角度上講，可觀測性相關(guān)的技術(shù)除了應(yīng)用在IT運(yùn)維的場景外，還可以應(yīng)用在和公司相關(guān)的通用場景以及特殊場景中。

• IT運(yùn)維場景：IT運(yùn)維場景從橫向、縱向來看，觀察的目標(biāo)從最基礎(chǔ)的機(jī)房、網(wǎng)絡(luò)等開始向用戶的端上發(fā)展；觀察的場景也從純粹的錯(cuò)誤、慢請求等發(fā)展為用戶的實(shí)際產(chǎn)品體驗(yàn)。
• 通用場景：觀測本質(zhì)上是一個(gè)通用的行為，除了運(yùn)維場景外，對于公司的安全、用戶行為、運(yùn)營增長、交易等都適用，我們可以針對這些場景構(gòu)建例如攻擊檢測、攻擊溯源、ABTest、廣告效果分析等應(yīng)用形式。
• 特殊場景：除了場景的公司內(nèi)通用場景外，針對不同的行業(yè)屬性，也可以衍生出特定行業(yè)的觀測場景與應(yīng)用，例如阿里云的城市大腦，就是通過觀測道路擁堵、信號燈、交通事故等信息，通過控制不同紅綠燈時(shí)間、出行規(guī)劃等手段降低城市整體擁堵率。

四 、Pragmatic可觀測性如何落地

回到可觀測性方案落地上，我們現(xiàn)階段可能無法做出一個(gè)適用于各個(gè)行業(yè)屬性的可觀測引擎，更多的還是專注于DevOps和通用的公司商業(yè)方面。這里面的兩個(gè)核心工作是：

• 數(shù)據(jù)的覆蓋面足夠的全：能夠包括各類不同場景的不同類型的數(shù)據(jù)，除了狹義的日志、監(jiān)控、Trace外，還需要包括我們的CMDB、變更數(shù)據(jù)、客戶信息、訂單/交易信息、網(wǎng)絡(luò)流、API調(diào)用等
• 數(shù)據(jù)關(guān)聯(lián)與統(tǒng)一分析：數(shù)據(jù)價(jià)值的發(fā)掘不是簡單的通過一種數(shù)據(jù)來實(shí)現(xiàn)，更多的時(shí)候我們需要利用多種數(shù)據(jù)關(guān)聯(lián)來達(dá)到目的，例如結(jié)合用戶的信息表以及訪問日志，我們可以分析不同年齡段、性別的用戶的行為特點(diǎn)，針對性的進(jìn)行推薦；通過登錄日志、CMDB等，結(jié)合規(guī)則引擎，來實(shí)現(xiàn)安全類的攻擊檢測。

從整個(gè)流程來看，我們可以將可觀測性的工作劃分為4個(gè)組成部分：

• 傳感器：獲取數(shù)據(jù)的前提是要有足夠傳感器來產(chǎn)生數(shù)據(jù)，這些傳感器在IT領(lǐng)域的形態(tài)有：SDK、埋點(diǎn)、外部探針等。
• 數(shù)據(jù)：傳感器產(chǎn)生數(shù)據(jù)后，我們需要有足夠的能力去獲取、收集各種類型的數(shù)據(jù)，并把這些數(shù)據(jù)歸類分析。
• 算力：可觀測場景的核心是需要覆蓋足夠多的數(shù)據(jù)，數(shù)據(jù)一定是海量的，因此系統(tǒng)需要有足夠的算力來計(jì)算和分析這些數(shù)據(jù)。
• 算法：可觀測場景的終極應(yīng)用是數(shù)據(jù)的價(jià)值發(fā)掘，因此需要使用到各類算法，包括一些基礎(chǔ)的數(shù)值類算法、各種AIOps相關(guān)的算法以及這些算法的組合。

五 、再論可觀測性數(shù)據(jù)分類

Logs、Traces、Metrics作為IT可觀測性數(shù)據(jù)的三劍客，基本可以滿足各類監(jiān)控、告警、分析、問題排查等需求，然而實(shí)際場景中，我們經(jīng)常會搞混每種數(shù)據(jù)的適用形態(tài)，這里再大致羅列一下這三類數(shù)據(jù)的特點(diǎn)、轉(zhuǎn)化方式以及適用場景：

• Logs：我們對于Logs是更加寬泛的定義：記錄事/物變化的載體，對于常見的訪問日志、交易日志、內(nèi)核日志等文本型以及包括GPS、音視頻等泛型數(shù)據(jù)也包含在其中。日志在調(diào)用鏈場景結(jié)構(gòu)化后其實(shí)可以轉(zhuǎn)變?yōu)門race，在進(jìn)行聚合、降采樣操作后會變成Metrics。
• Metrics：是聚合后的數(shù)值，相對比較離散，一般有name、labels、time、values組成，Metrics數(shù)據(jù)量一般很小，相對成本更低，查詢的速度比較快。
• Traces：是最標(biāo)準(zhǔn)的調(diào)用日志，除了定義了調(diào)用的父子關(guān)系外（一般通過TraceID、SpanID、ParentSpanID），一般還會定義操作的服務(wù)、方法、屬性、狀態(tài)、耗時(shí)等詳細(xì)信息，通過Trace能夠代替一部分Logs的功能，通過Trace的聚合也能得到每個(gè)服務(wù)、方法的Metrics指標(biāo)。

六 、“割裂”的可觀測性方案

業(yè)界也針對這種情況推出了各類可觀察性相關(guān)的產(chǎn)品，包括開源、商業(yè)化的眾多項(xiàng)目。例如：

1. Metrics：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
2. Traces：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
3. Logs：ELK、Splunk、SumoLogic、Loki、Loggly

利用這些項(xiàng)目的組合或多或少可以解決針對性的一類或者幾類問題，但真正應(yīng)用起來你會發(fā)現(xiàn)各種問題：

1. 多套方案交織：可能要使用至少M(fèi)etrics、Logging、Tracing3種方案，維護(hù)代價(jià)巨大
2. 數(shù)據(jù)不互通：雖然是同一個(gè)業(yè)務(wù)組件，同一個(gè)系統(tǒng)，產(chǎn)生的數(shù)據(jù)由于在不同的方案中，數(shù)據(jù)難以互通，無法充分發(fā)揮數(shù)據(jù)價(jià)值

在這種多套方案組合的場景下，問題排查需要和多套系統(tǒng)打交道，若這些系統(tǒng)歸屬不同的團(tuán)隊(duì)，還需要和多個(gè)團(tuán)隊(duì)進(jìn)行交互才能解決問題，整體的維護(hù)和使用代價(jià)非常巨大。因此我們希望能夠使用一套系統(tǒng)去解決所有類型可觀測性數(shù)據(jù)的采集、存儲、分析的功能。

七 、可觀測性數(shù)據(jù)引擎架構(gòu)

基于上述我們的一些思考，回歸到可觀測這個(gè)問題的本質(zhì)，我們目標(biāo)的可觀測性方案需要能夠滿足以下幾點(diǎn)：

1. 數(shù)據(jù)全面覆蓋：包括各類的可觀測數(shù)據(jù)以及支持從各個(gè)端、系統(tǒng)中采集數(shù)據(jù)
2. 統(tǒng)一的系統(tǒng)：拒絕割裂，能夠在一個(gè)系統(tǒng)中支持Traces、Metrics、Logs的統(tǒng)一存儲與分析
3. 數(shù)據(jù)可關(guān)聯(lián)：每種數(shù)據(jù)內(nèi)部可以互相關(guān)聯(lián)，也支持跨數(shù)據(jù)類型的關(guān)聯(lián)，能夠用一套分析語言把各類數(shù)據(jù)進(jìn)行融合分析
4. 足夠的算力：分布式、可擴(kuò)展，面對PB級的數(shù)據(jù)，也能有足夠的算力去分析
5. 靈活智能的算法：除了基礎(chǔ)的算法外，還應(yīng)包括AIOps相關(guān)的異常檢測、預(yù)測類的算法，并且支持對這些算法進(jìn)行編排

可觀測數(shù)據(jù)引擎的整體架構(gòu)如下圖所示，從底到上的四層也基本符合方案落地的指導(dǎo)思想：傳感器+數(shù)據(jù)+算力+算法。

• 傳感器：數(shù)據(jù)源以O(shè)penTelemetry為核心，并且支持各類數(shù)據(jù)形態(tài)、設(shè)備/端、數(shù)據(jù)格式的 采集 ，覆蓋面足夠的“廣”。
• 數(shù)據(jù)+算力：采集上來的數(shù)據(jù)，首先會進(jìn)入到我們的 管道系統(tǒng) （類似于Kafka），根據(jù)不同的數(shù)據(jù)類型構(gòu)建不同的索引，目前每天我們的平臺會有幾十PB的新數(shù)據(jù)寫入并存儲下。除了常見的 查詢 和 分析 能力外，我們還內(nèi)置了 ETL 的功能，負(fù)責(zé)對數(shù)據(jù)進(jìn)行清洗和格式化，同時(shí)支持對接外部的流計(jì)算和離線計(jì)算系統(tǒng)。
• 算法：除了基礎(chǔ)的數(shù)值算法外，目前我們支持了十多種的 異常檢測/預(yù)測算法 ，并且還支持 流式異常檢測 ；同時(shí)也支持使用 Scheduled SQL 進(jìn)行數(shù)據(jù)的編排，幫助我們產(chǎn)生更多新的數(shù)據(jù)。
• 價(jià)值發(fā)掘：價(jià)值發(fā)掘過程主要通過 可視化 、 告警 、 交互式分析 等人機(jī)交互來實(shí)現(xiàn)，同時(shí)也提供了 OpenAPI 來對接外部系統(tǒng)或者供用戶來實(shí)現(xiàn)一些自定義的功能。

八 、數(shù)據(jù)源與協(xié)議兼容

隨著阿里全面擁抱云原生后，我們也開始逐漸去兼容開源以及云原生的可觀測領(lǐng)域的協(xié)議和方案。相比自有協(xié)議的封閉模式，兼容開源、標(biāo)準(zhǔn)協(xié)議大大擴(kuò)充了我們平臺能夠支持的數(shù)據(jù)采集范圍，而且減少了不必要的造輪子環(huán)節(jié)。上圖展示了我們兼容外部協(xié)議、Agent的整體進(jìn)度：

• Traces：除了內(nèi)部的飛天Trace、鷹眼Trace外，開源的包括Jaeger、OpenTracing、Zipkin、SkyWalking、OpenTelemetry、OpenCensus等。
• Logs：Logs的協(xié)議較少，但是設(shè)計(jì)比較多的日志采集Agent，我們平臺除了自研的Logtail外，還兼容包括Logstash、Beats（FileBeat、AuditBeat）、Fluentd、Fluent bits，同時(shí)還提供syslog協(xié)議，路由器交換機(jī)等可以直接用syslog協(xié)議上報(bào)數(shù)據(jù)到服務(wù)端。
• Metrics：時(shí)序引擎我們在新版本設(shè)計(jì)之初就兼容了Prometheus，并且支持Telegraf、OpenFalcon、OpenTelemetry Metrics、Zabbix等數(shù)據(jù)接入。

九 、統(tǒng)一存儲引擎

對于存儲引擎，我們的設(shè)計(jì)目標(biāo)的第一要素是統(tǒng)一，能夠用一套引擎存儲各類可觀測的數(shù)據(jù)；第二要素是快，包括寫入、查詢，能夠適用于阿里內(nèi)外部超大規(guī)模的場景（日寫入幾十PB）。

對于Logs、Traces、Metrics，其中Logs和Traces的格式和查詢特點(diǎn)非常相似，我們放到一起來分析，推導(dǎo)的過程如下：

Logs/Traces：

• 查詢的方式主要是通過關(guān)鍵詞/TraceID進(jìn)行查詢，另外會根據(jù)某些Tag進(jìn)行過濾，例如hostname、region、app等
• 每次查詢的命中數(shù)相對較少，尤其是TraceID的查詢方式，而且命中的數(shù)據(jù)極有可能是離散的
• 通常這類數(shù)據(jù)最適合存儲在搜索引擎中，其中最核心的技術(shù)是倒排索引

Metrics：

• 通常都是range查詢，每次查詢某一個(gè)單一的指標(biāo)/時(shí)間線，或者一組時(shí)間線進(jìn)行聚合，例如統(tǒng)一某個(gè)應(yīng)用所有機(jī)器的平均CPU
• 時(shí)序類的查詢一般QPS都較高（主要有很多告警規(guī)則），為了適應(yīng)高QPS查詢，需要把數(shù)據(jù)的聚合性做好
• 對于這類數(shù)據(jù)都會有專門的時(shí)序引擎來支撐，目前主流的時(shí)序引擎基本上都是用類似于LSM Tree的思想來實(shí)現(xiàn)，以適應(yīng)高吞吐的寫入和查詢（Update、Delete操作很少）

同時(shí)可觀測性數(shù)據(jù)還有一些共性的特點(diǎn)，例如高吞吐寫入（高流量、QPS，而且會有Burst）、超大規(guī)模查詢特點(diǎn)、時(shí)間訪問特性（冷熱特性、訪問局部性等）。

針對上述的特性分析，我們設(shè)計(jì)了一套統(tǒng)一的可觀測數(shù)據(jù)存儲引擎，整體架構(gòu)如下：

1. 接入層支持各類協(xié)議寫入，寫入的數(shù)據(jù)首先會進(jìn)入到一個(gè)FIFO的管道中，類似于Kafka的MQ模型，并且支持?jǐn)?shù)據(jù)消費(fèi)，用來對接各類下游
2. 在管道之上有兩套索引結(jié)構(gòu)，分別是倒排索引以及SortedTable，分別為Traces/Logs和Metrics提供快速的查詢能力
3. 兩套索引除了結(jié)構(gòu)不同外，其他各類機(jī)制都是共用的，例如存儲引擎、FailOver邏輯、緩存策略、冷熱數(shù)據(jù)分層策略等
4. 上述這些數(shù)據(jù)都在同一個(gè)進(jìn)程內(nèi)實(shí)現(xiàn)，大大降低運(yùn)維、部署代價(jià)
5. 整個(gè)存儲引擎基于純分布式框架實(shí)現(xiàn)，支持橫向擴(kuò)展，單個(gè)Store最多支持日PB級的數(shù)據(jù)寫入

十 、統(tǒng)一分析引擎

如果把存儲引擎比喻成新鮮的食材，那分析引擎就是處理這些食材的刀具，針對不同類型的食材，用不同種類的刀來處理才能得到最好的效果，例如蔬菜用切片刀、排骨用斬骨刀、水果用削皮刀等。同樣針對不同類型的可觀測數(shù)據(jù)和場景，也有對應(yīng)的適合的分析方式：

1. Metrics：通常用于告警和圖形化展示，一般直接獲取或者輔以簡單的計(jì)算，例如PromQL、TSQL等
2. Traces/Logs：最簡單直接的方式是關(guān)鍵詞的查詢，包括TraceID查詢也只是關(guān)鍵詞查詢的特例
3. 數(shù)據(jù)分析（一般針對Traces、Logs）：通常Traces、Logs還會用于數(shù)據(jù)分析和挖掘，所以要使用圖靈完備的語言，一般程序員接受最廣的是SQL

上述的分析方式都有對應(yīng)的適用場景，我們很難用一種語法/語言去實(shí)現(xiàn)所有的功能并且具有非常好的便捷性（雖然通過擴(kuò)展SQL可以實(shí)現(xiàn)類似PromQL、關(guān)鍵詞查詢的能力，但是寫起來一個(gè)簡單的PromQL算子可能要用一大串SQL才能實(shí)現(xiàn)），因此我們的分析引擎選擇去兼容關(guān)鍵詞查詢、PromQL的語法。同時(shí)為了便于將各類可觀測數(shù)據(jù)進(jìn)行關(guān)聯(lián)起來，我們在SQL的基礎(chǔ)上，實(shí)現(xiàn)了可以連接關(guān)鍵詞查詢、PromQL、外部的DB、ML模型的能力，讓SQL成為頂層分析語言，實(shí)現(xiàn)可觀測數(shù)據(jù)的融合分析能力。

下面舉幾個(gè)我們的查詢/分析的應(yīng)用示例，前面3個(gè)相對比較簡單，可以用純粹的關(guān)鍵詞查詢、PromQL，也可以結(jié)合SQL一起使用。最后一個(gè)展示了實(shí)際場景中進(jìn)行融合分析的例子：

• 背景：線上發(fā)現(xiàn)有支付失敗的錯(cuò)誤，需要分析這些出現(xiàn)支付失敗的錯(cuò)誤的機(jī)器CPU指標(biāo)有沒有問題
• 實(shí)現(xiàn)：首先查詢機(jī)器的CPU指標(biāo)；關(guān)聯(lián)機(jī)器的Region信息（需要排查是否某個(gè)Region出現(xiàn)問題）；和日志中出現(xiàn)支付失敗的機(jī)器進(jìn)行Join，只關(guān)心這些機(jī)器；最后應(yīng)用時(shí)序異常檢測算法來快速的分析這些機(jī)器的CPU指標(biāo)；最后的結(jié)果使用線圖進(jìn)行可視化，結(jié)果展示更加直觀。

上述的例子同時(shí)查詢了LogStore、MetricStore，而且關(guān)聯(lián)CMDB以及ML模型，一個(gè)語句實(shí)現(xiàn)了非常復(fù)雜的分析效果，在實(shí)際的場景中還是經(jīng)常出現(xiàn)的，尤其是分析一些比較復(fù)雜的應(yīng)用和異常。

十一、數(shù)據(jù)編排

可觀測性相比傳統(tǒng)監(jiān)控，更多的還是在于數(shù)據(jù)價(jià)值的發(fā)掘能力更強(qiáng)，能夠僅通過輸出來推斷系統(tǒng)的運(yùn)行狀態(tài)，因此和數(shù)據(jù)挖掘這個(gè)工作比較像，收集各類繁雜的數(shù)據(jù)、格式化、預(yù)處理、分析、檢驗(yàn)，最后根據(jù)得到的結(jié)論去“講故事”。因此在可觀測性引擎的建設(shè)上，我們非常關(guān)注數(shù)據(jù)編排的能力，能夠讓數(shù)據(jù)流轉(zhuǎn)起來，從茫茫的原始日志中不斷的去提取出價(jià)值更高的數(shù)據(jù)，最終告訴我們系統(tǒng)是否在工作以及為什么不工作。為了讓數(shù)據(jù)能夠“流轉(zhuǎn)”起來，我們開發(fā)了幾個(gè)功能：

1. 數(shù)據(jù)加工：也就是大數(shù)據(jù)ETL（extract, transform, and load）中T的功能，能夠幫我們把非結(jié)構(gòu)化、半結(jié)構(gòu)化的數(shù)據(jù)處理成結(jié)構(gòu)化的數(shù)據(jù)，更加容易分析。
2. Scheduled SQL：顧名思義，就是定期運(yùn)行的SQL，核心思想是把龐大的數(shù)據(jù)精簡化，更加利于查詢，例如通過AccessLog每分鐘定期計(jì)算網(wǎng)站的訪問請求、按APP、Region粒度聚合CPU、內(nèi)存指標(biāo)、定期計(jì)算Trace拓?fù)涞取?/li>
3. AIOps巡檢：針對時(shí)序數(shù)據(jù)特別開發(fā)的基于時(shí)序異常算法的巡檢能力，用機(jī)器和算力幫我們?nèi)z查到底是哪個(gè)指標(biāo)的哪個(gè)維度出現(xiàn)問題。

十二、可觀測性引擎應(yīng)用實(shí)踐

目前我們這套平臺上已經(jīng)積累了10萬級的內(nèi)外部用戶，每天寫入的數(shù)據(jù)40PB+，非常多的團(tuán)隊(duì)在基于我們的引擎在構(gòu)建自己公司/部門的可觀測平臺，進(jìn)行全棧的可觀測和業(yè)務(wù)創(chuàng)新。下面將介紹一些常見的使用我們引擎的場景：

1 全鏈路可觀測

全鏈路的可觀測性一直都是DevOps環(huán)節(jié)中的重要步驟，除了通常的監(jiān)控、告警、問題排查外，還承擔(dān)用戶行為回放/分析、版本發(fā)布驗(yàn)證、A/B Test等功能，下圖展示的是阿里內(nèi)部某個(gè)產(chǎn)品內(nèi)部的全鏈路可觀測架構(gòu)圖：

• 數(shù)據(jù)源包括移動(dòng)端、Web端、后端的各類數(shù)據(jù)，同時(shí)還包括一些監(jiān)控系統(tǒng)的數(shù)據(jù)、第三方的數(shù)據(jù)等
• 采集通過SLS的Logtail和TLog實(shí)現(xiàn)
• 基于離在線混合的數(shù)據(jù)處理方式，對數(shù)據(jù)進(jìn)行打標(biāo)、過濾、關(guān)聯(lián)、分發(fā)等預(yù)處理
• 各類數(shù)據(jù)全部存儲在SLS可觀測數(shù)據(jù)引擎中，主要利用SLS提供的索引、查詢和聚合分析能力
• 上層基于SLS的接口構(gòu)建全鏈路的數(shù)據(jù)展示和監(jiān)控系統(tǒng)

2 成本可觀測

商業(yè)公司的第一要?jiǎng)?wù)永遠(yuǎn)是營收、盈利，我們都知道盈利=營收-成本，IT部門的成本通常也會占據(jù)很大一個(gè)部分，尤其是互聯(lián)網(wǎng)類型的公司?，F(xiàn)在阿里全面云化后，包括阿里內(nèi)部的團(tuán)隊(duì)也會在乎自己的IT支出，盡可能的壓縮成本。下面的示例是我們阿里云上一家客戶的監(jiān)控系統(tǒng)架構(gòu)，系統(tǒng)除了負(fù)責(zé)IT基礎(chǔ)設(shè)施和業(yè)務(wù)的監(jiān)控外，還會負(fù)責(zé)分析和優(yōu)化整個(gè)公司的IT成本，主要收集的數(shù)據(jù)有：

1. 收集云上每個(gè)產(chǎn)品（虛擬機(jī)、網(wǎng)絡(luò)、存儲、數(shù)據(jù)庫、SaaS類等）的費(fèi)用，包括詳細(xì)的計(jì)費(fèi)信息
2. 收集每個(gè)產(chǎn)品的監(jiān)控信息，包括用量、利用率等
3. 建立起Catalog/CMDB，包括每個(gè)資源/實(shí)例所屬的業(yè)務(wù)部門、團(tuán)隊(duì)、用途等

利用Catalog + 產(chǎn)品計(jì)費(fèi)信息，就可以計(jì)算出每個(gè)部門的IT支出費(fèi)用；再結(jié)合每個(gè)實(shí)例的用量、利用率信息，就可以計(jì)算出每個(gè)部門的IT資源利用率，例如每臺ECS的CPU、內(nèi)存使用率。最終計(jì)算出每個(gè)部門/團(tuán)隊(duì)整體上使用IT資源的合理度，將這些信息總結(jié)成運(yùn)營報(bào)表，推動(dòng)資源使用合理度低的部門/團(tuán)隊(duì)去優(yōu)化。

3 Trace可觀測

隨著云原生、微服務(wù)逐漸在各個(gè)行業(yè)落地，分布式鏈路追蹤（Trace）也開始被越來越多的公司采用。對于Trace而言，最基礎(chǔ)的能力是能夠記錄請求在多個(gè)服務(wù)之間調(diào)用的傳播、依賴關(guān)系并進(jìn)行可視化。而從Trace本身的數(shù)據(jù)特點(diǎn)而言，它是規(guī)則化、標(biāo)準(zhǔn)化且?guī)в幸蕾囮P(guān)系的訪問日志，因此可以基于Trace去計(jì)算并挖掘更多的價(jià)值。

下面是SLS OpenTelemetry Trace的實(shí)現(xiàn)架構(gòu)，核心是通過數(shù)據(jù)編排計(jì)算Trace原始數(shù)據(jù)并得到聚合數(shù)據(jù)，并基于SLS提供的接口實(shí)現(xiàn)各類Trace的附加功能。例如：

• 依賴關(guān)系：這是絕大部分的Trace系統(tǒng)都會附帶的功能，基于Trace中的父子關(guān)系進(jìn)行聚合計(jì)算，得到Trace Dependency
• 服務(wù)/接口黃金指標(biāo)：Trace中記錄了服務(wù)/接口的調(diào)用延遲、狀態(tài)碼等信息，基于這些數(shù)據(jù)可以計(jì)算出QPS、延遲、錯(cuò)誤率等黃金指標(biāo)。
• 上下游分析：基于計(jì)算的Dependency信息，按照某個(gè)Service進(jìn)行聚合，統(tǒng)一Service依賴的上下游的指標(biāo)
• 中間件分析：Trace中對于中間件（數(shù)據(jù)庫/MQ等）的調(diào)用一般都會記錄成一個(gè)個(gè)Span，基于這些Span的統(tǒng)計(jì)可以得到中間件的QPS、延遲、錯(cuò)誤率。
• 告警相關(guān)：通?；诜?wù)/接口的黃金指標(biāo)設(shè)置監(jiān)控和告警，也可以只關(guān)心整體服務(wù)入口的告警（一般對父Span為空的Span認(rèn)為是服務(wù)入口調(diào)用）。

4 基于編排的根因分析

可觀測性的前期階段，很多工作都是需要人工來完成，我們最希望的還是能有一套自動(dòng)化的系統(tǒng)，在出現(xiàn)問題的時(shí)候能夠基于這些觀測的數(shù)據(jù)自動(dòng)進(jìn)行異常的診斷、得到一個(gè)可靠的根因并能夠根據(jù)診斷的根因進(jìn)行自動(dòng)的Fix?，F(xiàn)階段，自動(dòng)異?；謴?fù)很難做到，但根因的定位通過一定的算法和編排手段還是可以實(shí)施的。

下圖是一個(gè)典型的IT系統(tǒng)架構(gòu)的觀測抽象，每個(gè)APP都會有自己的黃金指標(biāo)、業(yè)務(wù)的訪問日志/錯(cuò)誤日志、基礎(chǔ)監(jiān)控指標(biāo)、調(diào)用中間件的指標(biāo)、關(guān)聯(lián)的中間件自身指標(biāo)/日志，同時(shí)通過Trace還可以得到上下游APP/服務(wù)的依賴關(guān)系。通過這些數(shù)據(jù)再結(jié)合一些算法和編排手段就可以進(jìn)行一定程度的自動(dòng)化根因分析了。這里核心依賴的幾點(diǎn)如下：

1. 關(guān)聯(lián)關(guān)系：通過Trace可以計(jì)算出APP/服務(wù)之間的依賴關(guān)系；通過CMDB信息可以得到APP和PaaS、IaaS之間的依賴關(guān)系。通過關(guān)聯(lián)關(guān)系就可以“順藤摸瓜”，找到出現(xiàn)問題的原因。
2. 時(shí)序異常檢測算法：自動(dòng)檢測某一條、某組曲線是否有異常，包括ARMA、KSigma、Time2Graph等，詳細(xì)的算法可以參考： 異常檢測算法 、 流式異常檢測 。
3. 日志聚類分析： 將相似度高的日志聚合，提取共同的日志模式（Pattern），快速掌握日志全貌，同時(shí) 利用Pattern的對比功能，對比正常/異常時(shí)間段的Pattern，快速找到日志中的異常。

時(shí)序、日志的異常分析能夠幫我們確定某個(gè)組件是否存在問題，而關(guān)聯(lián)關(guān)系能夠讓我們進(jìn)行“順藤摸瓜”。通過這三個(gè)核心功能的組合就可以編排出一個(gè)異常的根因分析系統(tǒng)。下圖就是一個(gè)簡單的示例：首先從告警開始分析入口的黃金指標(biāo)，隨后分析服務(wù)本身的數(shù)據(jù)、依賴的中間件指標(biāo)、應(yīng)用Pod/虛擬機(jī)指標(biāo)，通過Trace Dependency可以遞歸分析下游依賴是否出現(xiàn)問題，其中還可以關(guān)聯(lián)一些變更信息，以便快速定位是否由于變更引起的異常。最終發(fā)現(xiàn)的異常事件集中到時(shí)間軸上進(jìn)行推導(dǎo)，也可以由運(yùn)維/開發(fā)來最終確定根因。

十三、寫在最后

可觀測性這一概念并不是直接發(fā)明的“黑科技”，而是我們從監(jiān)控、問題排查、預(yù)防等工作中逐漸“演化”出來的詞。同樣我們一開始只是做日志引擎（阿里云上的產(chǎn)品： 日志服務(wù) ），在隨后才逐漸優(yōu)化、升級為可觀測性的引擎。對于“可觀測性”我們要拋開概念/名詞本身來發(fā)現(xiàn)它的本質(zhì)，而這個(gè)本質(zhì)往往是和商業(yè)（Business）相關(guān)，例如：

1. 讓系統(tǒng)更加穩(wěn)定，用戶體驗(yàn)更好
2. 觀察IT支出，消除不合理的使用，節(jié)省更多的成本
3. 觀察交易行為，找到刷單/作弊，即時(shí)止損
4. 利用AIOps等自動(dòng)化手段發(fā)現(xiàn)問題，節(jié)省更多的人力，運(yùn)維提效

而我們對于可觀測性引擎的研發(fā)，主要關(guān)注的也是如何服務(wù)更多的部門/公司進(jìn)行可觀測性方案的快速、有效實(shí)施。包括引擎中的傳感器、數(shù)據(jù)、計(jì)算、算法等工作一直在不斷進(jìn)行演進(jìn)和迭代，例如更加便捷的eBPF采集、更高壓縮率的數(shù)據(jù)壓縮算法、性能更高的并行計(jì)算、召回率更低的根因分析算法等。