雲原生時代可觀察性的挑戰
在單體應用時代，應用部署在單機上，如需要高可靠性多以HA的方式部署，出現問題時可以直接登陸機器用指令檢視機器的名額，日志等資料就比較容易能夠定位。
但随着應用從單體架構演進到微服務架構，如今雲上的應用分布式部署已經是預設選項，而微服務架構下帶來了許多新的元件如Service Discovery，Service Router，使得整個架構比傳統架構要複雜的多：
k8s的出現，更是帶來了更簡單可靠的應用部署管理能力，使得服務更容易被拆分，微服務化更加徹底，進一步使系統變得複雜而難以掌控。
CNCF的一個調查也顯示，53%的受訪者認為使用容器時最大的挑戰是複雜性，同時有35%的受訪者将可靠性和監控作為部署挑戰
目前Serverless的應用也越來越廣泛，在傳統模式下，如果線上出現問題，我們可以登陸伺服器，搜尋日志，分析程序，甚至 dump 記憶體來進行問題分析。到了 Serverless 模式下，使用者看不到伺服器了，這個時候如果系統出現異常怎麼辦呢？使用者還是需要有豐富的排查診斷工具，能夠觀測到包括流量、系統名額、依賴服務等各方面綜合的狀态，以實作快速準确的問題診斷。當圍繞 Serverless 模式的全面可觀測能力不足的時候，使用者必然不會對此感到放心。
新技術新架構的出現使得系統越來越複雜，越是複雜越需要對系統的狀态有全面的了解，才能保持線上系統的穩定，是以可觀察性(Observability)被越來頻繁的提及，那麼我們到底需要一個什麼樣的可觀察性工具呢？
可觀察性工具的需求
可觀察性有三大支柱: Metric、Trace、Log，其中Metric主要用來發現問題，Trace用來定位問題所在的服務，Log可以用來定位導緻問題的根因，三者相輔相成，是以要成為一個統一的可觀察性平台，對三大支柱的支援缺一不可。
SLS本身擁有強大的日志集中收集處理分析能力，日志模型實際上是一種随機 + 全局模型可以相容Trace、Event，但時序場景是連續+局部分析模型，使用日志模型在性能和并發上不能滿足需求，因需要一個專門用來存儲時序資料的存儲。
市面上有OpenTSDB，InfluxDB，Prometheus等開源的時序存儲具，為什麼SLS還需要開發MetricStore呢？實際上目前的時序存儲或多或少存在一些問題：
<li data-lake-id="9cac5cfd6e4866696e81882166588eda">規模與彈性：InfluxDB開源版本是不支援叢集的，Prometheus自身也隻有單機模式以及聯邦模式，拓展成分布式需要借助Thanos等工具，在資料規模到一定程度後，開源軟體常常就力不從心了</li>
<li data-lake-id="407939242b3ab93a9fdcfdfd9f828440">靈活性：開源軟體在各自的領域内都提供了很大的靈活性，但互相之間的配合并不緊密，例如使用Prometheus采集的資料對應的Grafana dashboard并不能直接用在用Telegraf采集的資料上</li>
<li data-lake-id="e04a6e8806aeb7a640affc323ab12df8">統一的分析能力：由于模型的差異，傳統上時序資料經常使用特定的query文法，即使是InfluxQL也是SQL方言，并不能很好的和Log，Trace打通</li>
<li data-lake-id="0e2c9b260133b889423ae440fafb0c53">開放開源：對于商業産品，大家常常會擔心是否足夠開放，能否和原有的開源技術棧進行融合，是否可以在盡可能對不影響原有部署的情況下利用商業産品提供的額外能力</li> 是以，SLS開發了MetricStore，并結合SLS原有的采集、資料加工、分析、可視化、告警等能力，形成統一的解決方案。
MetricStore解決方案
規模與彈性
支撐大規模資料量以及可彈性拓展是SLS原本在日志上擁有的優勢，在底層引擎上，SLS是一套純分布式的存儲計算分離架構，設計之初就是面向大規模、多租戶的場景，一個時序庫由多個Shard組成，資料會均勻存儲在多個Shard中，并且Shard可以動态的擴縮容，不影響任何寫入/查詢。而業界衆多開源時序引擎都是采用聯邦或計算存儲綁定的架構，在大規模場景下經常捉襟見肘。同時我們也做了大量性能優化，使MetricStore的查詢性能最優。
架構改進
在PromQL查詢引擎上，開源方案通常使用Prometheus的Remote Read API，這有一個緻命缺陷: 資料一定要先傳輸到讀取節點再做計算，在對大量資料做查詢時，這部分網絡開銷可能超過計算開銷成為瓶頸，而MetricStore因為内置了PromQL引擎，可以下推部分算子，并且可以在内網萬兆網絡中完成資料的拉取整合，傳回聚合後結果，極大的加速了查詢效率。
高性能存儲模型
MetricStore底層由C/C++編寫，充分利用各類硬體/指令優勢，存儲上使用了多種高效壓縮算法（RLE、DeltaOfDelta、Gorilla、Prefix、ZSTD、LZ4等）組合，資料壓縮率可達到10到100+倍，單核壓縮性能可達30-100M/s。在時序場景，對于MetricName、Labels的查詢支援壓縮讀取，大大提升資料查詢性能。
多級緩存
時序場景的查詢特點比較強：例如近期資料、查詢局部性、持續性等。是以可以使用緩存來提升整體的查詢性能。為了盡可能提升緩存的命中率，SLS提供了多層的緩存政策：
<li data-lake-id="9b5bf0bb39b79f1561c6f60145184338">查詢結果：直接緩存PromQL的查詢結果，相同請求可以直接傳回結果，非常适用于多人同時刷屏的場景</li>
<li data-lake-id="9de70c925c25b8d8b66d401ae9b6aaeb">緩存時間線：在Prometheus層把擷取到的時間線緩存下來，對于定期運作的Query隻需額外擷取增量資料即可</li>
<li data-lake-id="03eef76786ff4dcb2ed81d04b0b1d311">緩存Meta資料：SLS的MetricStore總共存在4級Meta，每個不同級别的Meta分别使用不同的緩存政策，盡可能避免Meta加載</li>
<li data-lake-id="0083721f34b07e8394ea14befe54cf21">Segment資料：實際存儲的資料會按照分片存儲在記憶體中，避免熱點資料頻繁讀取磁盤</li>
<li data-lake-id="9b2592ee43ab45200c979076df66d6d9">近期資料：近期資料（5min以内）存儲在記憶體中，使用無鎖的多線程安全SkipList管理，支援高QPS讀寫</li>
<li data-lake-id="c0a4f341d729071b6827d68a84e064f0">SSD Cache：SLS采用的混合存儲方式，檔案都是先寫SSD，然後定期搬到HDD，是以近期刷盤的資料都在SSD上</li> PromQL引擎性能優化
我們在原生PromQL執行引擎上做了多項優化，包括路由、并行讀取、部分算子下推、排序優化等，充分利用SLS的硬體資源優勢，在大資料量查詢時性能可提升近10倍。
經過重重優化後的MetricStore在各項性能名額以及穩定性上面都超越了開源軟體，且對使用者來說使用更簡單，全托管免運維的方式也讓使用者更加省心。
統一分析能力
可觀察性的本質就是對資料做分析，而長久以來Log、Trace和Metrics都使用不同的分析文法，Log、Trace因為更接近于資料庫的表結構，是以适用SQL，Metrics資料因為有大量的時序處理，通常使用不同的文法，這使得三者難以進行統一的分析，而MetricStore在完全相容PromQL的基礎上還拓展了PromQL的分析能力，支援SQL+PromQL的混合調用，使得複雜的資料分析成為可能。：
<div class="lake-codeblock-content" style="border: 1px solid rgb(232, 232, 232); max-width: 750px; color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: rgb(249, 249, 249);">
<div class="CodeMirror-sizer" style="color: rgb(89, 89, 89); margin: 0px; padding: 16px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><pre class="cm-s-default" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line-number lake-lm-pad-level-0" style="color: rgb(191, 191, 191); margin: 0px 8px 0px 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"></span><span class="lake-preview-codeblock-content" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="cm-keyword" style="color: rgb(215, 58, 73); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">SELECT</span> promql_query_range<span class="cm-bracket" style="color: rgb(153, 153, 119); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">(</span><span class="cm-string" style="color: rgb(102, 153, 0); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">'some_metric'</span><span class="cm-bracket" style="color: rgb(153, 153, 119); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">)</span> <span class="cm-keyword" style="color: rgb(215, 58, 73); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">FROM</span> metrics SELECT ip_to_country(labels['ip']) as country FROM (SELECT promql_query_range('some_metric_with_ip_label') FROM metrics)
</div>
</div> 當使用PromQL拿到查詢結果後，在SQL中可以做進一步加工: 例如join維表，ip轉換，例如:
<li data-lake-id="d3c529a4250fd76a3abf6e8cca6aa656">場景1: 資料label中帶有ip，希望join cmdb中的資料做富化，得到機器的管理者，狀态，所在機房等資訊，以便做進一步判斷</li>
<li data-lake-id="e0a65809ed5e5ccfa253ee0aa9086149">場景2: 資料label中帶有使用者通路ip，希望利用ip庫将ip解析為省份，營運商</li>
<li data-lake-id="f5b7dcccd22eadecaf91a64bf69d50f7">場景3: 獲得時間線後希望對資料做機器學習，例如時序分解，預測，異常檢測等</li>
<li data-lake-id="ffb0d0830864a86104b5af2ca0a54994">場景4: 監控資料通過機器ip join日志資料，擷取關聯的日志</li> 這些場景通過PromQL本身都無法實作，但SLS借助和SQL的融合使其成為可能。同時使用者也可以通過JDBC協定和已有的BI平台對接，無縫使用時序資料，而這些開源方案包括絕大多數商業方案均沒有提供此類能力。
開放開源
SLS一貫有擁抱開源的良好傳統，在MetricStore上也是一樣，開源的資料都可以很容易的接入，且SLS原有的接入管道例如Logtail，SDK寫入等也得以保留，資料寫入後可選擇使用SLS的dashboard，也可以選擇第三方可視化方案如Grafana。
豐富且開放的采集
<li data-lake-id="d2124474506a5aaf6df1a6b3b3619040"><a href="https://help.aliyun.com/document_detail/171781.html" target="_blank">Prometheus Remote Write</a><br>作為一個相容PromQL的時序存儲服務，SLS支援作為Prometheus Remote Write的目标，該方案可使使用者無縫切換資料到SLS上，隻需配置Remote Write，并且修改Grafana的資料源連結指向MetricStore即可完成Prometheus遷移。</li>
<li data-lake-id="bfb51d80c714503d7f3ba2724ae8e22f"><a href="https://help.aliyun.com/document_detail/188041.html" target="_blank">Telegraf接入</a><br>Telegraf也是一個很流行的資料采集器，logtail相容了InfluxDB協定，是以可作為Telegraf的Output接收資料，此外我們還開發了全托管的Telegraf模闆配置，使用者無需自行維護Telegraf，隻需要在sls頁面上通過Wizard配置即可接入，Logtail将自動管理Telegraf的生命周期，配置下發等，同時還配備了相應的最佳實踐Dashboard，開箱即用。<strong><br></strong></li>
<li data-lake-id="1720812338d56a1395e2e301e158b728"><a href="https://github.com/open-telemetry/opentelemetry-collector-contrib" target="_blank">OpenTelemetry接入</a></li> 作為未來雲原生可觀察性的标準方案，OpenTelemetry目前是CNCF下第二活躍的Project（僅次于Kubernetes，高于Prometheus），未來包括Log、Trace、Metric都會采用OpenTelemetry定義的标準，使這三者可以更好的結合。目前SLS已經提供了OpenTelemetry的接入方式，可以使用官方的Collector把Log、Trace、Metric資料寫入到SLS中。
<li data-lake-id="1ec7338b1f2b1fe7bf21d91a03e83a13"><a href="https://help.aliyun.com/document_detail/29063.html" target="_blank">SDK寫入</a><br>Prometheus的采集模式比較單一，始終是從一個Exporter Pull資料，對于大部分服務端程式來說這不是問題，但對于一些用戶端程式想要寫入自定義埋點資料，或者一些邊緣計算節點希望上傳資料時，因為Prometheus沒有寫接口，類似的需求難以實作，這時候SDK寫入就派上用場了，使用者可以使用SLS的各種語言的SDK來寫入資料</li>
<li data-lake-id="94d92a995d3bb8b214afe8444c5d5e40"><a href="https://help.aliyun.com/document_detail/171780.html" target="_blank">雲監控資料導入</a><br>通過導入雲監控資料，使用者得以将雲資源的監控資料和自定義的監控資料存放到一起，對于混合雲的使用者尤為實用，不需要再在雲上雲下維護兩套監控系統</li>
<li data-lake-id="b46e7b04d50d3b0c9dc6ae136f4f2373"><a href="https://help.aliyun.com/document_detail/28981.html" target="_blank">原有的各種輸入途徑</a></li> 如Logtail檔案采集、移動端、Flink/Blink寫入、BinLog、資料加工、OSS導入等。
豐富的資料接入管道使得SLS可以化身為DevOps資料中台，對接各類資料進行一站式的分析。
開放可視化
SLS本身有着不錯的可視化能力，Dashboard可滿足大部分需求。在雲原生下衆多監控方案都是基于Grafana進行可視化，而近年來Grafana發展速度極快，基本上已經成為雲原生中的監控資料可視化标準。是以我們也支援對接
Grafana，使用者不必改變原有的使用習慣，直接使用Prometheus資料源即可，或者也可以使用Grafana上的SLS資料源，SLS資料源可以使用SQL進行更複雜的處理。此外我們也給Grafana貢獻了實用的Dashboard，在grafana.com搜尋SLS即可下載下傳。
因為MetricStore相容Prometheus Query API，是以原先能用于Prometheus的可視化方案均能用于MetricStore。
落地場景
基于以上的能力，MetricStore在阿裡巴巴集團内部以及公有雲上都服務了大量使用者的監控場景落地
場景1：阿裡自用雲原生監控究極方案
在阿裡集團内部，我們服務了最大的基礎設施: ASI（Alibaba Serverless infrastructure），是阿裡巴巴針對雲原生應用設計的統一基礎設施。ASI可以認為是一組巨大的K8s叢集，單個叢集的Node數超過7000台實體機。ASI是面向雲原生的，監控自然也使用了目前雲原生下的标準監控方案：Prometheus。
最初ASI使用的是單機版Prometheus，随着規模的增大，單一的Prometheus已經無法承載，于是切換到了Thanos方案，并設計了一套多Thanos聯合使用的方案 。然而當規模上到數萬台實體機、上百萬Pod後，Thanos開始逐漸暴露出一系列的問題：
• 寫: 由于存儲量大，本地磁盤無法存儲足夠的資料，存儲周期短
• 查: 查詢時常常需要聚合上百萬條時間線，超過千萬級的資料點，原生Prometheus的查詢非常慢，常常超過分鐘級響應，并且負載高，容易hang或者當機
• 管：為了提高Thanos性能，使用了裸實體機的部署方案，機器申請、上下線、擴容、FailOver恢複等運維代價巨大
Thanos的架構非常複雜，如下圖所示：
為了支援雙十一業務，ASI需要擴容大量容器，這也意味着會增加大量的監控資料，此時尋找替代的Prometheus存儲方案已經迫在眉睫。
MetricStore提供的方案相比要簡潔的多，使用者并不需要改變原有的Prometheus部署，隻需要Remote Write寫入就可以了：
ASI團隊開始在7月份雙寫資料到Metric Store進行測試，并在雙十一前将75%的叢集監控資料的查詢切換到Metric Store上，目前每日新增資料200+TB，穩定寫入無資料丢失，存儲時間從原來的15天增加到30天，報警查詢的延遲更是下降了近3倍(18:28為切換時間點):
場景2：從分鐘級到秒級
在外部使用者中，同樣有很多重度依賴MetricStore的客戶，某頭部網際網路公司之前基于OpenTSDB建構了一套分鐘級的監控系統，然而在業務量膨脹數倍後開始出現各類性能問題，經常會有幾個大Query打爆整個叢集的情況出現。
最終客戶在調研了衆多方案後選擇使用SLS的MetricStore功能，實作數十倍的性能提升。
在此性能的基礎上，客戶開始追求更實時的告警方式，将資料采集、告警間隔從分鐘級提升到秒級（5秒），資料量和查詢QPS都會上升一個數量級。面對這種情況，使用者僅僅是在SLS中分裂了一些Shard即可完成擴容。目前在每天寫入超過500億條資料，查詢QPS上千的情況下一直穩定運作（客戶壓測中可達上萬QPS）。
場景3：Log Metric結合
SLS上存儲着大量的原始通路日志，很多使用者直接基于通路日志來進行分析和監控，由于每次都要全量計算所有的日志，是以監控會浪費巨大的資源而且還達不到很低的延遲。MetricStore上線後，我們利用ScheduledSQL定期計算日志中的名額并寫入MetricStore，所有的監控、告警、可視化都可以基于MetricStore中預聚和的名額進行，性能大大提升。同時SLS提供的智能巡檢服務可直接基于MetricStore進行巡檢，自動發現其中的異常名額并産生告警。接收到告警後，通過預置的可視化報表檢視各類名額，在确定一些可疑點後，再跳轉到原始通路日志的Logstore去檢視詳細的報錯資訊并确定根因。
目前Log Metric這套結合的方案已經應用于SLB通路日志分析、Kubernetes Ingress日志分析中，未來還會推廣到更多的AccessLog型場景中，讓基于AccessLog的分析、監控、問題排查更加便捷。
總結
SLS時序庫的工作離不開集團和社群同學們的幫助，還要感謝集團内外客戶們對SLS的信任，在MetricStore上線之初就開始接入各類的資料：因為信任、是以簡單。
今年是MetricStore上線第一年，随着使用者的增多，資料量的迅速增大，也面臨着更大的挑戰，我們也将持續優化MetricStore引擎，不斷拓展在可觀察性領域的想象力。
關鍵點來了：SLS團隊長期招聘人才，歡迎對大資料、監控、可觀察性、前端可視化、移動端開發、機器學習等有興趣的同學前來聯系我~~