雲上的可觀察性數據中臺，如何構建？

簡介： 做爲阿里經濟體基礎設施的阿里雲日誌服務（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向下對接各類開源的協議與數據源，向上對各類場景提供支撐能力。核心能力在於圍繞可觀察性的各類監控數據，提供統一的存儲與計算能力，平臺能夠用 「一、二、三、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要落地，咱們必須尊重專家系統的經驗沉澱，例如經過模板化、知識表示與推理、或在一些場景中使用遷移學習等。