雲上的可觀察性資料中臺，如何構建？

簡介：作為阿里經濟體基礎設施的阿里雲日誌服務（SLS），服務了上萬級的使用者，每天處理20PB日誌/Metric/Trace資料，為AIOps、大資料分析、運營服務、大資料安全等場景提供支撐，解決工程師可觀察性的問題。經過幾年的錘鍊和演進，正在向統一的可觀察性中臺發展。本文分享阿里雲端儲存團隊構建SLS中臺的背景和設計中的Trade Off，並通過兩個最佳實踐介紹如何通過中臺構建智慧的應用程式。

筆者是飛天最早的研發人員之一，曾經參與從0到5000臺飛天叢集和作業系統的構建。飛天是一個龐大的軟體系統，既有非常多的模組，也要跑在幾萬臺物理機上，如何讓分散式軟體高效地執行離不開監控、效能分析等環節，因此在飛天研發的第一天我們就同時開始研發飛天監控系統“神農”。神農通過採集大量的系統資料，幫助我們更好地理解系統、軟體協作複雜性背後的關係。同時神農也在伴隨著越來越大、越來越多海內外叢集的飛天作業系統成長，支撐阿里巴巴集團和阿里雲的業務。在2015年，經歷過一番思考，我們決定把神農抽象成一個更底層的服務——SLS（日誌服務，第一天主要focus在日誌場景中），希望通過SLS能夠服務支撐更多的Ops場景，包括AIOps（智慧分析引擎）。

一 構建可觀察性中臺的背景

先說說從一個工程師的角度看到的變化：對一個工程師而言，5年前的工作是非常細分的，研發的工作就是把程式碼開發好。但隨著網際網路的發展，業務系統Scope越來越大，需要在質量、可用性和可運維性上有更高的要求。並且為了保障我們的業務是持續改進的，必須在工作中涉及到更多運營的因素，例如統計系統訪問、留存和體驗等情況。

從個人視角轉化到行業視角也能發現一個趨勢：在十幾年前，研發的時間會花在三個部分：創新（編碼），部署+上線，觀察+分析，並且部署+上線會花費大量的時間。近幾年雲端計算和雲原生的興起解放了開發運維在部署、上線和環境標準化上的精力。但業務的高要求需要在各個環節中承擔更大的Scope，從多個視角來看待問題。背後就會有大量、碎片化的資料分析工作。

如果我們把具體的資料分析工作進行拆分，可以拆解成一個簡單的黑盒。黑盒的左邊是資料來源，右邊是我們對資料來源觀測判斷後的行動。例如：

• 在安全場景中，安全運營工程師會採集防火牆、主機、系統等日誌、根據經驗對日誌進行建模，識別其中的高危操作，生成關鍵性事件，系統根據多個事件進行告警。
• 在監控和運營場景中，這個過程是類似的。無非是把資料來源和建模的方法做了替換。

所以我們可以看到，雖然各個場景角色不同，資料來源不同，但在機制上我們是可以建立一套系統性分析框架來承載這類可觀察性的需求的。

二 中臺的技術挑戰

構建中臺的思路看起來很直接，要做這件事情有哪些挑戰呢？

我們可以從資料來源、分析和判別這三個過程來分析：

• 第一大挑戰來自於資料來源接入。以監控場景為例，業界有不同的視覺化、採集、分析工具針對不同的資料來源。為了能建立監控可觀察性體系，需要引入大量的垂直系統。這些系統之間有不同的儲存格式，介面不統一，有不同的軟體體驗，往往難以形成合力。
• 第二大挑戰來自於效能與速度。資料分析的過程實際上是把專家經驗（Domain Knowledge）沉澱的過程，而Ops場景一般都是Mission Critical過程，因此需要非常快地分析速度和所見即所得能力。
• 第三大挑戰來自於分析能力。在接入足夠多的資料後，往往會面臨監控項太多，資料量太多，線索太多等問題，我們需要有成套的方法幫助我們去降維、去發現、去關聯、去推理。AIOps演算法目前聚焦在這一層上。

前兩個問題本質上是一個系統問題，而後面兩個問題和演算法與算力相關。中臺的推出可以解決第1和第2個問題。

三 阿里雲SLS，自研自用可觀察性中臺

2015年我們研發了SLS，經過幾年的錘鍊和演進，正在向統一的可觀察性中臺發展。SLS向下對接各種開源的協議與資料來源，向上對各種場景提供支撐能力。核心能力在於圍繞可觀察性的各種監控資料，提供統一的儲存與計算能力，平臺可以用 “1、2、3、4” 四個詞來概括。

• “1” 代表一箇中臺。
• “2” 代表提供兩種基本的儲存模型：Logstore與MetricStore，分別面向適合Trace/Log型別的日誌儲存（Logstore），適合監控資料Metric型別的時序儲存（MetricStore）。這兩種儲存並不是孤立的，建立在統一的儲存概念上，並且可以非常靈活的相互轉化。
• “3” 代表三類分析引擎：資料加工引擎（DSL）、SQL查詢分析引擎（SQL）、智慧分析引擎（AIOps）。DSL主要面向資料加工和與預處理場景，解決格式多樣化的問題；SQL查詢分析引擎面向儲存資料提供清洗、計算能力；而內嵌的AIOps可以給特定問題提供智慧演算法。

• “4” 代表四類典型場景：例如ITOps、DevOps、SecOps、BusinessOps等。涉及到運維、研發、運營和黑客增長等領域。阿里集團80%以上類似場景都基於SLS來構建。

平臺始終向使用者提供支撐能力，相容各種資料來源與協議，支撐業務但不做業務產品。

1 儲存設計

為了構建可觀察性的中臺，我們先看看目前儲存系統的現狀。在運維領域AIOps系統的構建過程中，長期並存四種型別的儲存系統，分別是：

• Hadoop/Hive：存放歷史日誌，Metric等資料，儲存成本便宜，分析能力較強，但延時較高。
• ElasticSearch：存放需要實時訪問的Trace，Log資訊，檢索速度快，但成本較高，適合近線的熱資料，分析能力中等。
• NoSQL：用來儲存經過聚合的指標類資料，TSDB類是NoSQL儲存擴充套件，檢索聚合後的指標速度快，成本較便宜，缺點是分析能力較弱。
• Kafka：用來匯入匯出路由各種資料，主要儲存臨時資料，上下游介面豐富，沒有分析能力。

這四類獨立的儲存系統較好地解決了四種不同型別的需求，但存在兩大挑戰：

資料流動性

資料儲存後能夠支撐某個場景的服務能力，但隨之而來的問題就是流動性。資料存在於多個系統中，做資料關聯、對比、整合時就需要去搬資料，這往往需要花費非常多的時間。

介面易用性

面對不同的儲存物件的介面不統一，例如Log一般使用ES的API來包裝，而Metric一般會用Prometheus協議或通過NoSQL介面直接呼叫等等。為了整合資料往往需要涉及到不同的API與互動方式，增加了系統的整體複雜性。

目前四種儲存系統的現狀導致資料使用需要較長的週期及一定的開發量，限制了AIOps，DataOps等場景發揮更大的作用。

2 如何抽象儲存

如果我們把監控資料的生成過程做一個抽象，可以發現一般會由兩個過程組成：變化+狀態。所有的事物都是一個待續變化的過程，例如資料庫的一張表在某一個時刻（例如2點）的狀態實際上是由歷史上所有變化累計的結果。在監控領域中也是一樣，我們可以通過Log、Trace等方式把系統狀態的變化儘可能儲存（或取樣）下來。例如使用者在1小時內做了5次操作，我們可以把這5次操作的日誌或Trace捕捉下來。當我們需要一個狀態值時（比如2點的系統狀態是什麼），我們可以對這些所有的操作日誌做一個回放，形成某一個時間點的一個彙總值，例如在視窗大小為1小時的區間內，操作QPS為5。這裡就是一個簡單的Log轉為Metric的關係，我們可以使用其他邏輯，例如對Log中的Latency欄位做一個Avg來獲得該視窗的Latency。

在SLS儲存設計的過程中，我們也遵循了這樣的客觀規律：

• 底層提供了一個FIFO Binlog佇列，資料寫入和讀取都是順序的，以嚴格的寫入時間（Arrival Time）作為排序。
• 在Binlog之上，我們可以挑選某些欄位生成一個Logstore，Logstore可以認為是資料庫的一個表：是帶Schema的，至少有EventTime這個欄位（事件發生的原始時間），可以指定列的型別和名字。這樣我們就可以通過關鍵詞和SQL檢索Logstore中的內容。
• 除此之外，我們可以根據需求對Logstore中的某些列生成多個Metric儲存，例如根據Host+Method+Time構建一個以Host+Method作為Instance的監控資料儲存表，從而可以根據時間段把資料撈出。

讓我們來看一個例子：以下是一個站點的訪問記錄，在1秒內經歷了4次訪問。

time, host, method, latency, uid, status
[2020-08-10 17:00:00, Site1, UserLogin, 45ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserBuy, 25ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserBuy, 1ms, 1001, OK]
[2020-08-10 17:00:01, Site1, UserLogout, 45ms, 1001, OK]
[2020-08-10 17:00:01, Site2, UserLogin, 45ms,1002, Fail]

當這些資料寫入Logstore後，相當於寫入了一張存放日誌的資料庫，可以通過SQL對其中任意欄位進行查詢與分析。例如“ select count(1) as qps”，獲得當前彙總的QPS。

也可以通過預定義好一些維度，例如希望通過host+method組合來構建最小監控粒度，每隔1秒鐘獲得QPS，Latency等資料，那我們可以定義如下的MetricStore，當資料寫入後，能夠自動根據規則生成如下結果：

[host, method, time], [qps, latency]
[site1, userLogin, 2020-08-10 17:00:00], [1, 45]
[site1, userBuy, 2020-08-10 17:00:01], [2, 15]
[site1, userLogout, 2020-08-10 17:00:01], [1, 25]

通過這種方式，我們就可以在一種儲存中通過原始資料的儲存、聚合形成日誌與Metric轉移。

3 計算設計

根據平時遇到的場景，我們把監控資料的計算抽象成三類問題：

• 非結構化資料如何變為結構化資料
• 面對複雜系統，能否設計一套所見即所得低門檻語言進行資料分析
• 面對海量資訊，是否有降維演算法來降低問題複雜度

我們構建了三類計算方法分別來處理以上問題：

第一個問題實際上一個業務複雜度的問題，根源來自產生資料的人和使用資料的人之間的GAP。在大部分開發流程中打日誌的往往是開發者，但分析日誌的往往是運維和運營，在寫日誌過程中沒有足夠預見性導致資料無法直接被使用。這裡需要有一套低程式碼開發的語言來做各種各樣的資料轉化、分派、富化，把多個業務系統不同格式的資料進行簡化。為此我們設計了一套面向資料加工（ETL）場景的語言（DSL)，該語言提供了300多個常用運算元，專制日誌格式的各種疑難雜症。

例如在原始日誌中，只有一個project_id欄位在訪問url引數裡，ip這個欄位對應的設計我們無法拿到。在SLS的DSL語言中，我們只需要寫3行程式碼，從url中提取引數，與資料庫中欄位進行富化。原來看起來無用的訪問日誌就立即盤活，可以分析出主機和使用者之間的訪問關係了。

第二個問題是一個多語言融合的問題，我們的選擇是以SQL作為查詢和分析框架，在框架中融入PromQL及各種機器學習函式。這樣就可以通過子查詢+主查詢進行巢狀，對結果進行計算並預測。

SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ...

以下就是一個複雜分析的例子：

• 先通過呼叫promql運算元拿到主機每分鐘的監控值
• 通過視窗函式對原始資料進行降取樣，例如變為每秒的數值
• 通過外層的預測函式對查詢結果進行預測

第三個問題是演算法的問題，我們內建了大量基於AI的巡檢、預測、聚類、根因分析等演算法，可以在人工分析和自動巡檢告警中直接使用到。這些演算法通過SQL/DSL函式向使用者提供，可以在各種場景中用到。

四 中臺支撐案例

SLS在阿里集團內外有萬級的使用者，大量運用到AIOps各種資料分析場景中，這裡列舉兩個比較有意思的案例。

案例1：流量解決方案

流量日誌是最常見的訪問日誌型別，無論是Ingress，Nginx還是CDN Access Log都可以抽象成訪問日誌型別，在SLS解決方案中：

• 採集一份原始日誌保留7天時間（LogStore）進行查詢，更長時間備份到物件儲存（OSS）。
• 通過SLS原生的SQL對日誌進行資料加工+各維度聚合，例如根據微服務介面進行Group By。
• 對聚合後的資料進行時序型別儲存（MetricStore）。
• 通過AIOps巡檢函式對數以千計的介面進行智慧巡檢，生成告警事件。

整個過程從採集到配置到執行只需要花5分鐘，滿足多樣性需求。

案例2：雲成本監控與分析

阿里雲的使用者每天會面臨大量的賬單資料，雲成本中心就利用SLS採集、分析、視覺化與AIOps功能開發了一款成本管家應用，智慧幫助使用者分析雲產品成本，預測成本的趨勢，找到賬單中異常的原因。

五 寫在最後

雖然過去幾年我們沒有直接做AIOps應用，但通過把資料能力、AI能力中臺化，反而支撐了更多的使用者與場景。最後簡單總結下過去兩年做可觀察性中臺的心得體會：

AIOps = AI + DevOps/ITOps/SecOps/BusinessOps…

目前大部分人覺得AIOps解決的是運維的問題，實際上該套方法可以無縫地切換到各種OPs場景中，例如DevOps，SecOps（Bigdata Security），以及通過AI來進行運維與使用者增長，方法都是通用的。和AI所在的任何一個領域一樣，資料是根本、算力是基礎、演算法是核心，缺一不可。

Domain Knowledge是AIOps落地關鍵

一個有經驗的運維或分析師，對系統有深刻的見解和建模經驗。因此AIOps要落地，我們必須尊重專家系統的經驗沉澱，例如通過模板化、知識表示與推理、或在一些場景中使用遷移學習等。

原文連結：https://developer.aliyun.com/article/775468?

版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。