云上的可观察性数据中台，如何构建？
筆者是飛天最早的研發人員之一，曾經參與從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?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的云上的可观察性数据中台，如何构建？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里云邀您参加2020年数据湖高峰会议
- 下一篇： 微服务治理实践：服务契约