2022年阿里云可觀測技術峰會演講資料PPT合集（298頁）.pdf

1、可觀測性技術發展趨勢栗蔚中國信通院云大所 副所長可觀測性技術發展趨勢需求系統穩定性保障軟件全生命周期質量保障02發展可觀測性從硬件到軟件云時代的可觀測性01痛點缺乏統一認知與建設方式造成多種工具與數據間的割裂03趨勢觀測標準化數據統一化數據類型持續豐富04發展可觀測性從硬件到軟件云時代的可觀測性01可觀測性技術發展：從硬件到軟件從硬件領域誕生最早的可觀測性概念早期軟件可觀測性助力系統故障排查可觀測性的概念最早誕生于電氣工程領域，為了了解黑盒系統的辡行情況，通辟對應的儀表 觀察輸出信號來判斷系統辡行狀態。軟件普及以后，軟件從業者也需要對軟件系統的辡行情況進行檢測。從而誕生了日志和監控兩種早期的軟

2、件系統觀測手段，用于故障發現及故障排查?？捎^測性技術發展：云時代的可觀測性可觀測性技術棧 CNCF 隨著微服務、解耦合的架構成為主流，在多級服務依賴場景下，傳統監控手段很難有效進行故障定位鏈路追蹤(tracing)作為新型觀測數據應辡而生。傳統觀測數據的治理方式也在持續進步Kafka、ELK、Prometheus等工具的誕生，使得日志、監控等傳統觀測數據被更有效的采集和利用。觀測方式持續進化 eBPF技術的誕生及其在可觀測性領域的應用，使我們可以采集到更多樣的系統辡行數據。用戶對觀測數據進行靈活定義的需求，催生了多種觀測數據編排工具，允許用戶低門檻地拓展及自定義更多樣的采集數據觀測數據更加多樣

3、為適應云時代的軟件架構，可觀測性技術進一步演進需求系統穩定性保障軟件全生命周期質量保障02可觀測性是系統穩定性保障的必要手段數據來源：中國混沌工程調查報告（2021）2021年12月7日與16日，亞馬遜AWS在一周內連續發生兩次大規模宕機宕機事故。2021年7月14日，B站服務器故障3小時造成服務無法訪問。2020年12月14日，Google Cloud服務器由于內部存儲配額問題造成身份驗證系統中斷，引發全球宕機45分鐘，影響波及全球用戶。故障平均發現時長（MTTD）故障平均修復時長（MTTR）云時代下，復雜業務系統難以洞察，為穩定性保障帶來挑戰中國混沌工程調查報告（2021）數據顯示，僅不到

4、一半的受訪企業故障平均發現時長（MTTD）小于1小時；故障平均修復時長普遍超過1小時，超辟6成故障修復時間（MTTR）高于1小時，甚至有約20%的服務故障修復時間超過12小時。系統運行情況的觀測水平不足，面臨故障時的反應速度差強人意通辟建設可觀測性平臺，高效全面的收集系統辡行狀態數據，在此基礎上制定完善的告警策略，可大大提高系統故障時的響應速率，降低辡維人員排查成本，增強系統穩定性。系統狀態可觀測是系統穩定性保障的基礎軟件全生命周期的可觀測極大提升交付質量 將可觀測性應用到軟件開發全生命周期，使得軟件開發、測試、部署、辡營白盒化，避免“暗疾”?？捎^測性為業務對比及調優提供數據支撐，如A/B測試

5、等多版本功能對比時，通辟觀測數據對比版本業務效果優劣，助力服務質量提升。需求 需求提出 需求分析 需求評審 開發 代碼開發 代碼評審 代碼合并 測試 功能測試 性能測試 故障演練 部署 制品管理 部署發布 運營 AB測試 性能監控 服務質量目標 全生命周期可觀測，避免開發過程中“暗疾”隨著敏捷開放與CI/CD的推廣，服務功能的更新迭代速度也大大加快，更需要觀測工具實時監控業務質量，確保每個版本更新都能滿足服務質量目標。目前業界也在推廣敏捷開發流水線與觀測工具的結合，打破“先發布，后觀測”的現有格局：流水線實時讀取觀測數據，確保部署前的測試辟程無問題、部署之后版本辡行狀況良好。在提升迭代效率的同

6、時，保障版本質量?？捎^測性滲透軟件開發全生命周期，提升軟件交付質量結合CI/CD，敏捷開發的同時保障軟件質量痛點缺乏統一認知與建設方式造成多種工具與數據間的割裂03可觀測性當前缺乏統一認知、缺乏統一建設方式云原生時代的可觀測性概念發展迅速，可觀測性概念未能被及時廣泛更新可觀測性技術落地的最佳實踐方面，企業缺乏可觀測性的建設指南當前國內對于可觀測性技術落地的最佳實踐方面仍有較大空白。雖然市面上具有琳瑯滿目的觀測工具，但缺乏可觀測性相關的規范標準及建設指南。對于剛接觸的企業來說，有時即使接觸到了這些觀測工具，也未能最大化發揮其價值?？捎^測性的理念經辟多年發展，隨著軟件技術及架構的演進，可觀測性的內

7、涵也經歷了多輪的迭代更新。我們在行業研究辟程中發現，仍有不少企業對可觀測性的理解還偏向于傳統的監控手段。業界仍然缺少對可觀測性最新內涵的普及認知。多種可觀測性工具隔離造成數據間的割裂數據內容割裂不同工具的數據格式定義各有不同，無法進行跨工具間的數據流通各工具間缺乏協調，數據內容涵蓋不全面，要么重復采集、要么采集不全多種觀測數據間的內容無法互相印證數據處理割裂不同工具的數據采集方式不同，造成采集時的資源冗余和浪費不同工具的數據儲存策略及載體不同難以跨工具對多種觀測數據進行統一分析數據展示割裂難以跨工具對多種數據進行統一展示難以跨工具對多種數據進行統一搜索查詢難以跨工具在多種數據間建立聯系、挖掘并

8、展示數據間的關聯面對多樣化的觀測手段，如果沒有“統一觀測”的認知、且缺乏建設參考，則可能發生“同時使用多套觀測工具卻無法做出整合，造成各觀測工具間互相獨立、互相割裂“的現象，無法對數據進行組合分析、無法達成數據利用最大化趨勢觀測標準化數據統一化數據類型持續豐富04可觀測性技術發展趨勢可觀測性技術的未來發展，總體將呈現以下趨勢，解決現有痛點觀測標準化為推進產業內對可觀測性辛成共識解決建設方式不統一 以及使用多種觀測工具造成割裂等問題發展可觀測性標準化及建設指南數據統一化在可觀測性認知統一的基礎上規范數據格式，統一存儲與處理促進多種觀測數據整合統一數據類型持續豐富以eBPF為例的新技術持續發展推動

9、可觀測性數據類型持續豐富可觀測性技術發展趨勢觀測標準化2021年，中國信通院牽頭業內企業可觀測性資深實踐企業編寫可觀測性平臺技術能力要求行業標準，并納入中國信通院“系統穩定性保障”標準體系中針對當前業界對可觀測性缺乏統一認知及建設指南的現象，已有不少專家學者投身可觀測性的普及與推廣工作中，可觀測性技術持續向標準化與普及化方向發展中國信通院聯合了業內多位可觀測性資深實踐專家，啟動了可觀測性技術發展白皮書編寫，旨在向業內輸出一份可觀測性的最佳實踐及建設指南 中中國國信信息息通通信信研研究究院院云云計算算與與大大數數據據研研究究所所 混混沌沌工工程程實驗室室 2 20 02 22 2 年年 5 5

10、月月 2022 當前已經有來自阿里云、騰訊、觀測云、日志易、PerfMa等企業的多位可觀測性技術專家參與內容編寫白皮書內容扔在持續迭代中，預計于7月底信通院可信云大會上正式發布混沌工程平臺全鏈路壓測可觀測性容量管理應用多活系統穩定性度量穩穩定定性性保保障障標標準準體體系系混沌工程成熟度根因分析平臺數據調用數據調用分析指導穩定保障安全生產應急管理輔助支撐可觀測性技術發展趨勢數據統一化在對可觀測性認知普及的同時，軟件社區及觀測產品建設者正在持續推動觀測數據的整合，多種觀測數據向格式及處理方式統一化的方向發展軟件社區致力于推動多種觀測數據的規范整合2019年，CNCF對其原有獨立的可觀測性項目Ope

11、nTracing及OpenCensus進行合并，形成整合版的數據規范及工具：OpenTelemetry，涵蓋日志、監控、及鏈路追蹤。觀測產品也在向多種觀測數據統一化的方向建設對可觀測性數據進行統一采集、統一處理、統一儲存，將原本割裂的多種觀測數據進行整合、關聯分析，辛成數據利用最大化統一儲存跨數據種類展示、跳轉多種數據統一查詢統一采集降低多數據采集冗余統一處理數據可跨種類關聯可觀測性技術發展趨勢數據類型持續豐富多種新型數據采集和分析技術的出現，使我們可以更靈活的采集系統辡行數據、分析系統辡行情況，觀測數據的類型和內容持續豐富以eBPF為例，eBPF技術在可觀測性領域的應用，使得原本難以觸辛的系

12、統底層辡行數據也可以被觀測和采集。后續新技術的出現，還將推動系統可觀測范圍進一步擴大。同時，支持用戶自定義數據采集等相關功能也成為主流，推動可觀測性數據內容進一步豐滿日志鏈路追蹤監控CrashdumpProfile在原有的日志、監控、鏈路追蹤三大支柱基礎上，衍生出了如profile,crash dump等特化的數據展示手段，促進可觀測數據類型持續豐富可觀測驅動高效決策云原生架構追逐Day0&Day1效率，使得Day2復雜度大幅上升?？捎^測性是微服務架構下降低復雜架構下無序熵增的唯一手段?？捎^測引領協同創新SRE/DevSecOps/BizOps/FinOps等新角色、新范式出現，可觀測能力成為

13、多重角色的共同關注點與溝通橋梁?？捎^測無處不在企業數字化轉型凸顯體驗價值，IT系統全棧上云技術棧日趨收斂。新一代可觀測性產品向下覆蓋云邊端，向上連接業務與最終用戶體驗。云原生時代，可觀測成為主角基礎設施不斷下沉，應用仍然是最佳觀測視角阿里云上的每一個應用，都天生可觀測-阿里云應用托管產品家族容器服務（ACK）、企業分布式應用服務（EDAS）、Serverless應用引擎（SAE）、函數計算（FC）全系默認集成應用實時監控（ARMS）。-基于eBPF的應用可觀測技術去年開始被容器服務默認集成，低功耗、無侵入實現應用黃金指標檢測和應用全局拓撲可視化，已于生產場景大規模使用。觀測、防護、治理一體化-

14、阿里云應用治理類產品應用性能測試（PTS）、微服務引擎（MSE）、應用高可用服務（AHAS）全系默認集成ARMS應用監控。-ARMS應用安全服務（RASP）將應用安全“注入”到應用內，并于6月正式商業化。越標準，越智能，AI 輔助運維已經成為可能-ARMS應用監控指標+超過50個云產品監控指標全面打通托管版Prometheus，鏈路全面支持OpenTelemetry SDK。-ARMS Insight支持超過20類微服務場景高頻問題的自動發現與診斷，并打通告警系統。應用管控應用觀測用戶體驗性能分析風險分析安全防護微服務治理應用生命周期管理阿里云十年可觀測能力沉淀微服務化DevOps/運維自動化

15、業務中臺化全面容器化/云化云原生20102013201720152021微服務架構下的可觀測基礎設施技術中臺下的穩定性運營中心云原生時代的標準化觀測服務信通院先進級認證Forrester容器可觀測能力滿分Gartner國內唯一入選iLogtailArthasJaegerElastic LabsGrafana Labs袋鼠云博睿諧云OpenTelemetryPrometheusSkywalking可觀測開源與合作伙伴生態自主開源擁抱開源行業生態行業生態擁抱開源自主開源可觀測左移數字化運營全?？捎^測萬物皆云時代，觀測力將成為每一個參與者的核心競爭力將可觀測性融合至研發運維環節中，使得問題獲得更快反

16、饋閉環；持續使用應用性能（APM）管理工具發現未知性能問題；使用用戶體驗管理工具模擬真實用戶訪問行為。通過可觀測數據洞察IT成本，提升ROI；可觀測技術和安全技術（如RASP和Cloud SIEM）的融合使用，降低IT風險；基于可觀測數據協同各部門間合作，使用 ChatOps 方式與云交互。使用開源標準（如PrometheusExporter/OpenTelemetry SDK)暴露服務運行指標；審計、事件信息匯總至云事件總線（EventBrdige）便于統一管理與分析；擁抱分布式云架構，提供云、邊、端一體化的可觀測視圖。運維工程師/研發人員項目管理者/架構師/團隊負責人基礎云服務提供者Mor

17、e than Tracing Logging and Metrics吳晟SkyWalking v9 Full-stack APMMetricsTracingLoggingThe hottest topic in ObservabilityTracinghttps:/skywalking.apache.org/docs/main/latest/en/papers/stam/Dapper 10 years ago Google ResearchTrace ConceptSpan ConceptContext-enhanced LogsLow sampling rateSTAM:Enhancing

18、Topology Auto Detection For A Highly Distributed and Large-Scale Application SystemMetricsMetrics Native format&EcosystemPrometheus FetcherZabbix FormatOpenCensusEnvoy Metrics ServiceSkyWalking MeterTelegraf(WIP)Monitoring Kubernetes through kube-state-metrics(KSM),cAdvisor and OpenTelemetryStreamin

19、g log processLoggingFluentdFluent-bitElastic FileBeatEnvoy Access LogOpenTelemetry CollectorMultiple AgentsService Logging CollectingProfilingAgent/SDK based profilingNative Java and Python agentseBFP profilingFor all C,C+,Golang,Rust serviceshttps:/ Demand LoggingOn-DemandLoggingZero cost行業 SaaS 的微

20、服務穩定性保障實戰祁曉波自我介紹祁曉波 南京愛福路汽車科技有限公司穩定性負責人經歷 13年本科畢業 16年加入南京愛福路汽車科技有限公司(f6)負責f6后端的架構設計 實施了微服務的拆分 主導了k8s 在f6的落地和實踐 全程參與f6內部DevOps的設計建設和演進 f6云原生理念布道者 f6內部穩定性倡導者 可觀測性倡導者 SRE探索者專注 Java/SpringBoot/Dubbo架構 微服務架構 云原生領域 DevOps實踐/CICD SRE領域Twitter工程師在2017年發表的Monitoring and Observability，首次將Observability一詞帶入開發者的

21、視野。通過半玩笑的方式調侃了關于可觀測性和監控的區別在軟件產品和服務領域，可觀測性則是指從應用系統中收集盡可能多的遙測數據，以便可以調查和解決新出現的復雜問題，確保企業能夠主動觀察系統，在影響客戶體驗之前解決故障及問題，安全地進行測試并實施優化，更好地管理和控制業務風險。由此，可觀測性可以被視為系統的一個屬性，與功能性、安全性相似。引言可觀測發展趨勢數字表示相對于圖表上給定區域和時間的最高點的搜索興趣。值 100 是該術語的峰值流行度。值為 50 表示該詞的受歡迎程度是前者的一半。得分為 0 表示該術語沒有足夠的數據?？捎^測性定義控制理論中的可觀測性（observability）是指系統可以由

22、其外部輸出推斷其其內部狀態的程度。系統的可觀察性和可控制性是數學上對偶的概念?？捎^測性最早是匈牙利裔工程師魯道夫卡爾曼針對線性動態系統提出的概念12。若以信號流圖來看，若所有的內部狀態都可以輸出到輸出信號，此系統即有可觀測性。-wikipedia目錄難點與挑戰業務蓬勃發展康威定律的作用穩定性訴求01可觀測演進傳統監控+微應用日志收集架構升級+可觀測性引入云原生改造可觀測理念02未來暢想ebpfchaos-engineering融合 OpenTelemetry03難點與挑戰：業務蓬勃發展 穩定性訴求激增F6汽車科技，一家專注于汽車后市場信息化建設的互聯網平臺公司為維修企業開發智慧管理平臺，為行業

23、提供維修應用大數據難點與挑戰：康威定律的作用Any organization that designs a system(defined broadly)will produce a design whose structure is a copy of the organizations communication structure.Melvin E.Conway當業務膨脹時，從組織上來看，由于康威定律的作用導致我們設計微服務將趨同于組織架構。此時相對來說溝通效率是趨近極大值。但是也帶來了分布式系統的一些問題，沒有人可以對服務有整體的全局性的了解。作為研發，其最直接的期望是“分布式的系統，

24、單機系統的排查效率”。促使我們需要將傳統的以服務器為中心的思路轉變為以調用鏈為中心的思路。難點與挑戰：穩定性訴求激增煙囪應用B煙囪應用A目錄難點與挑戰業務蓬勃發展康威定律的作用穩定性訴求01可觀測演進傳統監控+微應用日志收集架構升級+可觀測性引入云原生改造可觀測理念02未來暢想ebpfchaos-engineering融合 OpenTelemetry03傳統監控+微應用日志收集ELKStack獲取日志和查詢 ElastAlert完成日志告警圖片圖片“ELK”是三個開源項目的首字母縮寫，這三個項目分別是：Elasticsearch、Logstash 和 Kibana。Elasticsearch

25、是一個搜索和分析引擎。Logstash 是服務器端數據處理管道，能夠同時從多個來源采集數據，轉換數據，然后將數據發送到諸如 Elasticsearch 等“存儲庫”中。Kibana 則可以讓用戶在Elasticsearch 中使用圖形和圖表對數據進行可視化ElastAlert 它通過將 Elasticsearch 與兩種類型的組件、規則類型和警報相結合來工作。Elasticsearch 會定期查詢并將數據傳遞給規則類型，該類型確定何時找到匹配項。發生匹配時，會收到一個或多個警報，這些警報會根據匹配采取行動。ELKElastAlert架構升級+可觀測性引入Grafana看板+Zorka支持jvm

26、監控圖片圖片Grafana是一個跨平臺、開源的數據可視化網絡應用程序平臺。用戶配置連接的數據源之后，Grafana可以在網絡瀏覽器里顯示數據圖表和警告。該軟件的企業版本提供更多的擴展功能。擴展功能通過插件的形式提供，終端用戶可以自定義自己的數據面板界面以及數據請求方式。Grafana被廣泛使用。Zorka 是個復雜的可編程的分析和監控 Java 運行應用程序的代理工具，無縫集成了流行的監控系統和協議（Zabbix,Nagios,syslog,SNMP），并且提供額外的跟蹤，分析功能，以及數據收集器，這些能幫助發現性能問題和一般的系統問題。來添加其他功能。GrafanaZorkaJMX tech

27、nology is present in the Java SE platform since J2SE 5.0 version and provides ways to monitor any application or device present in the JVM.云原生改造k8s的編排能力和微服務相輔相成 迫切需要trace組件的支持應用實時監控服務ARMS（Application Real-Time Monitoring Service）是一款阿里云應用性能管理（APM）類監控產品。借助本產品，您可以基于前端、應用、業務自定義等維度，迅速便捷地為企業構建秒級響應的應用監控能力。

28、Prometheus是CNCF的一個開源項目，Google BorgMon監控系統的開源版本，是一個系統和服務的監控系統。周期性采集metrics指標，匹配規則和展示結果，以及觸發某些條件的告警發送。Prometheus應用實時監控服務ARMS云原生改造JmxExporter快速支持云原生Java組件的jvm信息展示JMX Exporter 通過JavaAgent直接利用Java 的JMX 機制來讀取JVM 運行時的監控數據，然后將其轉換為Prometheus 可轆識的metrics 栺式，讓Prometheus 對其進行監控采集。通過PrometheusOperator注冊對應Service

29、Monitor即可。云原生改造利用配置中心完成應用到owner的精準告警配置中心帶來了較好的解耦能力 將應用和owner分開 出現告警時通過此方式可以通過webhook進行at具體的人利用apollo的多語言SDK 我們自研了精準告警轉發 結合apollo體驗完善云原生改造ARMS:無侵入支持Trace可觀測升級Log Trace Metrics 理念升級業界廣泛推行的可觀測性包含三大支柱：日志事件(Logging)，分布式鏈路追蹤(Tracing)和 指標監控(Metrics）。Logging：不能單純的理解就是日志，泛指的是應用運行而產生的可以詳細解釋系統運行狀態的各種事件，日志記錄是其中

30、最常用一種手段。Tracing：全鏈路追蹤，面向的是請求，通過對請求打標、透傳、串聯，最終可以還原出一次完整的請求，可幫助工程師分析出請求中的各種異常點。Metrics：是對Logging事件的聚合，泛指各種指標監控和大盤，通過多維度聚合、分析和可視化展示，幫助工程師快速理解系統的運行狀態?？捎^測升級簡版根因分析上線通過簡單的歸類算法 將當前服務報錯日志進行聚類分析 完成可能服務報錯原因分析可觀測升級ARMS支持traceId透出responseHeader2022-06-04 22:01:13,479 INFO DubboServerHandler-x.x.x.x:20880-thread-

31、176 c.f.m.r.c.PlatformRoutingHintKeyLocator:?ea1acd43a616543512734582027d0006 getHintKey=NCZ,group=xxx39.148.116.191-04/Jun/2022:22:01:57+0800 GET/portal/operating/guide/queryAll 200 900 https:/ 200 x.x.x.x:x 0.004 0.004 -on ea1acd5b9416543513172963061d0007小方欒解決大問題 無需修改代碼點擊arms開關支持在接入層日志支持相關展示即可 發生異

32、?？梢钥焖俾搫油瑫r僅需要修改日志pattern 即可以支持日志展示traceId可觀測升級prometheus exporterhttps:/ blackbox exporter allows blackbox probing of endpoints over HTTP,HTTPS,DNS,TCP and ICMP.https:/ metrics for certificates collected from various sources:TCP probesHTTPS probesPEM filesKubernetes secretsKubeconfig filesThe metrics

33、 are labelled with fields from the certificate,which allows for informational dashboards and flexible alert routing.BlackBoxExporter SSLExporter等各種Exporter生態 支持更大的可觀測范圍可觀測升級ARMS支持運維告警平臺 將自建Prometheus、ARMS、日志服務、云監控或自定義事件集成到ARMS告警管理中。ARMS告警管理將集成的所有事件匯總并去重。ARMS告警管理通過靜默過濾，過濾掉不重要的、不需要發送告警通知的事件。ARMS告警管理通過

34、通知策略和升級策略對所有告警事件進行分派，并通過電話、短信、郵件、釘釘等方式發送告警通知，其中，通過釘群發送的告警通知可以在釘釘群中管理告警?？捎^測升級ARMS支持運維告警平臺。、可觀測升級成本觀測通過成本可觀測的方式利用kubecost的相關特性優化成本可觀測升級Java生態免修改注入agent方式-JAVA_TOOL_OPTIONS通過InitContainer的方式注入JAVA_TOOL_OPTIONS 免修改支持到宿主pod通過共享volume的方式完成javaagent的共享我們可以通過開源組件（如opekruise）workspread通過patch的方式支持目錄難點與挑戰業務蓬勃

35、發展康威定律的作用穩定性訴求01可觀測演進傳統監控+微應用日志收集架構升級+可觀測性引入云原生改造可觀測理念02未來暢想ebpfchaos-engineering融合 OpenTelemetry03ebpf基于 eBPF 的 Kubernetes 一站式可觀測性云原生組件愈發進入深水區 排查問題不僅僅是應用層 需要關注系統層面比如DNS導致的抖動或者網絡重傳等均需要更加底層的數據進行追蹤排障利用ebpf能夠更好的回答Google SRE提出來的 延遲 流量 錯誤率 飽和度等等黃金指標chaos-engineering混沌工程鼓勵和利用可觀察性，試圖幫助您先發制人地發現和克服系統弱點2020年6

36、月 cncf針對可觀測性提出了特別興趣小組。TAG Observability 主要關注與觀察云本地工作負載有關的主題。此外，它還為最終用戶提供輔助材料和最佳做法，并為技術咨詢小組范圍內的 CNCF 項目提供指導和協調。除了三大支柱之外,還提出了混沌工程和持續優化。當然混沌工程是否能夠劃分在可觀測性確實有些疑義，混沌工程與其說是可觀察性或分析工具，不如說是一種可靠性。但是混沌工程的很重要的前提確實也是可觀測性。OpenTelemetryOpenTelemetry，這是一個由OpenTracing和OpenCensus合并創建的開源可觀察性栽架。今天實施應用程序跟蹤解決方欒，無論它是商業的還是開

37、源的，實際跟蹤很可能是通過向事務添加特定的 HTTP 標頭來完成的，這樣您就可以跨層獲得端到端視圖應用。問題是，添加到事務中的標頭是特定于供應商的，并且可能被不了解它們的中介（例如防火墻、負載平衡器等）丟棄，從而導致“損壞”的跟蹤。W3C Trace Context 的創建是為了解決這個問題，方法是制定一個實際標準，指定將使用哪些 HTTP 標頭來傳播跟蹤上下文，減少并有望消除丟失上下文的問題。我們需要更加面向終端研發的統一的可觀測視圖 融合了log metrics trace的全流程數據的方式。阿里云可觀測峰會Observability Conference萬節點規模云服務的SRE能力建設阿

38、里云可觀測峰會Observability Conference 宋傲（凡星），2021年加入阿里巴巴 阿里云-云原生應用平臺 研發工程師 目前主要參與阿里云產品的穩定性及SRE工作自我介紹阿里云可觀測峰會Observability Conference目錄背景及現狀系統架構簡介系統現狀工作內容01實踐經驗分享可觀測數據的收集和接入數據可視化和問題排查告警分級響應機制白屏化運維工具鏈建設02總結和未來工作告警準確度&接手率優化多類型數據聯動埋點成本控制03阿里云可觀測峰會Observability ConferencePart.01 背景及現狀：系統架構簡介 系統用途：實時數據流計算&存儲 底座

39、：阿里云 容器服務ACK 流量入口：Gateway Service（LoadBalancer）存儲介質：阿里云塊存儲ESSD&文件存儲NAS 中間件：Kafka服務（流量緩沖及通信）元數據管理：ACM 流式計算及查詢：Consumer服務、Center服務阿里云可觀測峰會Observability ConferencePart.01 背景及現狀：系統現狀 部署地域多：部署Region數量接近20個 讀寫鏈路長：數據讀寫會依次經過多個組件的處理，組件之間依賴關系較為復雜 監控對象復雜：基礎設施（調度、存儲、網絡etc.），中間件（Kafka），業務組件（Gateway，Center，Consum

40、er）阿里云可觀測峰會Observability ConferencePart.01 背景及現狀：工作內容可觀測數據的收集數據可視化及問題排查告警&應急處理阿里云可觀測峰會Observability ConferencePart.01 背景及現狀：工作內容可觀測數據的收集衡量應用狀態，信息少，可通過增加維度來增加額外信息，通過指標告警快速發現異常。請求從接收到處理完成的全周期跟蹤路徑。相較于指標，增加了請求相關信息。通過排查鏈路快速定位異常。應用運行產生的事件的日志數據。通過日志分析快速排除故障。指標Metrice日志Log鏈路Trace阿里云可觀測峰會Observability Confer

41、encePart.01 背景及現狀：工作內容數據可視化&問題排查阿里云可觀測峰會Observability ConferencePart.01 背景及現狀：工作內容告警&應急處理告警分級通知&升級策略運維處理工具化，白屏化事后統計及復盤問題的認領和處理流程標準化流程+工具阿里云可觀測峰會Observability ConferencePart.01 背景及現狀：工作內容告警&應急處理流程工具阿里云可觀測峰會Observability Conference目錄背景及現狀系統架構簡介系統現狀工作內容01實踐經驗分享可觀測數據的收集和接入數據可視化和問題排查告警分級響應機制白屏化運維工具鏈建設02總

42、結和未來工作告警準確度&接手率優化多類型數據聯動埋點成本控制03阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享可觀測數據的收集數據可視化及問題排查告警&應急處理阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入

43、指標（Metrics）數據阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據 接入難度？可靠性&運維成本？易用性？采集能力？存儲能力？Metrics協議選型：Prometheus（毋庸置疑）開源自建 or 云托管Prometheus？阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）

44、數據一鍵接入阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據K8s基礎監控&節點狀態的接入（ACK組件管理中心）阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據Kafka的接入（Prometheus云服務實例）阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據云盤ESSD監控的接入（CSI存儲插件監控）阿里云可觀測峰會Obs

45、ervability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據應用埋點+服務發現阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據Java組件的接入（MicroMeter/Spring BootActuator+ServiceMonitor）阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據Java組件的接入（MicroMeter/Spring Boot Act

46、uator+ServiceMonitor）阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據Go組件的接入（Prometheus Go SDK+ServiceMonitor）阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據R：Rate，接口調用頻率E：Error，接口錯誤數D：Duration，接口RT無侵入監控接口RED（基于eBPF）阿里云可觀測峰會Observability ConferencePart.02

47、 實踐經驗分享：可觀測數據收集&接入指標（Metrics）數據應用層接口RED狀態的接入（基于eBPF）ACK組件管理中心安裝cmonitor即可阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入鏈路（Trace）和日志（Log）數據鏈路及日志讀寫鏈路監控：基于ARMS Cmonitor&鏈路追蹤系統組件日志：基于arms-Promtail&LokiK8s系統事件日志：基于ARMS事件中心阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入讀寫鏈路監控和問題定位阿里云可

48、觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入組件運行日志收集和存儲阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：可觀測數據收集&接入K8s運行事件收集和監控阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐大盤配置Tips 控制查詢時間線個數，避免TimeSeries Panel渲染壓力大 善用Variable，包括數據源類型變量，值類型變量等 可使用Transform讓Table Panel靈活

49、顯示統計信息 分清Range&Instant查詢，避免無用的范圍查詢拖慢大盤顯示速度阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐：內部大盤分享K8s集群總覽阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐：內部大盤分享節點水位阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐：內部大盤分享全局SLO阿里云可觀測峰會Obs

50、ervability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐：內部大盤分享 Kafka客戶端及服務端監控阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐：內部大盤分享Java應用運行情況監控阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：數據可視化及問題排查Grafana大盤配置實踐：內部大盤分享 Table格式的錯誤類型復盤統計表阿里云可觀測峰會Observability ConferencePar

51、t.02 實踐經驗分享：數據可視化及問題排查問題排查案例分享：基于Histogram指標和Loki日志的服務慢查詢問題排查阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制應急響應流程告警配置排班告警觸發應急處理事后復盤和機制優化阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制原有告警系統中存在的問題告警配置排班告警觸發應急處理事后復盤和機制優化難以跨Region同步生效告警，配置工作效率低且易出錯告警依賴自建定時任務檢查，穩定性難以保證原有系統的問題阿里云可觀測峰會O

52、bservability ConferencePart.02 實踐經驗分享：告警和分級響應機制原有告警系統中存在的問題告警配置排班告警觸發應急處理事后復盤和機制優化排班依靠手工，易出現漏排班或backup缺失原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制原有告警系統中存在的問題告警配置排班告警觸發應急處理事后復盤和機制優化告警觸發條件單一，難以在告警觸發鏈路上增加額外業務邏輯（如動態閾值，動態打標等）原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分

53、級響應機制原有告警系統中存在的問題告警配置排班告警觸發應急處理事后復盤和機制優化告警無法主動認領，易出現無人處理的告警告警無法主動屏蔽，問題發生時易出現告警風暴原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制原有告警系統中存在的問題告警配置排班告警觸發應急處理事后復盤和機制優化告警體系沒有事后復盤和優化，易出現大量的低價值告警告警處理情況難以進行事后統計，缺乏數據支撐原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制基于ARMS告警運維中心的

54、告警系統建設實戰ARMS支持的解決方案：告警模板全球生效功能難以跨Region同步生效告警，配置工作效率低且易出錯告警依賴自建定時任務檢查，穩定性難以保證原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制基于ARMS告警運維中心的告警系統建設實戰ARMS支持的解決方案：告警排班表和動態通知排班依靠手工，易出現漏排班或backup缺失原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制基于ARMS告警運維中心的告警系統建設實戰ARMS支持的解決方案

55、：事件處理流和告警富化Demo：基于ACM配置中心+Serverless云函數+ARMSITSM的告警動態優先級告警觸發條件單一，難以在告警觸發鏈路上增加額外業務邏輯（如動態閾值，動態打標等）原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制基于ARMS告警運維中心的告警系統建設實戰ARMS支持的解決方案：告警的認領、關閉和屏告警無法主動認領，易出現無人處理的告警告警無法主動屏蔽，問題發生時易出現告警風暴原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分

56、級響應機制基于ARMS告警運維中心的告警系統建設實戰ARMS支持的解決方案：告警的認領接手率統計大盤告警體系沒有事后復盤和優化，易出現大量的低價值告警告警處理情況難以進行事后統計，缺乏數據支撐原有系統的問題阿里云可觀測峰會Observability ConferencePart.02 實踐經驗分享：告警和分級響應機制基于Grafana的白屏化運維工具鏈阿里云可觀測峰會Observability Conference目錄背景及現狀系統架構簡介系統現狀工作內容01實踐經驗分享可觀測數據的收集和接入數據可視化和問題排查告警分級響應機制白屏化運維工具鏈建設02總結和未來工作告警準確度&接手率優化多類型

57、數據聯動埋點成本控制03阿里云可觀測峰會Observability ConferencePart.03 總結&未來工作告警準確度和接手率的優化及時調整不合理的告警閾值，嘗試多閾值告警埋點成本控制自監控指標的維度治理和無用數據清理多類型數據聯動嘗試將三類可觀測數據與Profiler進行聯動，提升問題排查效率阿里云可觀測峰會Observability Conference加入釘群，了解更多可觀測實踐阿里云可觀測峰會Observability Conference友邦人壽可觀測體系設計與落地沈斌客戶背景部分友邦保險友邦人壽 卓越的營銷員隊伍 6W健康長久好生活2021最佳保險科技平臺 友邦友享APP

58、沈斌CloudSolution-云應甠架構負責人業務特點和架構 業務復雜性高 安全性要求高 穩定性要求高 性能要求高保險行業的特點 歷史包袱重 技術架構復雜 調甠鏈路復雜 網絡鏈路復雜保險行業架構特點Kubernetes生態IaaS：VM、存儲、網絡、安全服務領域A微服務A1微服務A2服務領域B微服務B1微服務B2PaaS：數據庫、中間件應甠系統1數據庫中間件操作系統物理服務器+存儲+網絡設備+安全設備VM虛擬機AS400OLAS應甠系統2IDCAli Cloud可觀測性建設痛點和挑戰微服務化程度高業務監控指標分散全局視角1.觀測復雜度提升Servlet Structs WebServiceS

59、pringCloud SpringBoot技術棧不統一 版本差異大2.技術選型困難角色分工數據隔離3.統一觀測困難觀測指標繁多業務指標多指標沉淀4.指標治理復雜的應甠部署架構調甠鏈不完整故障定位困難5.快速故障定位可觀測性建設流程和規劃 業務目標調研 技術架構調研應甠架構系統架構部署架構 運維體系調研 痛點、差距分析 統一監控目標制定 服務資源追蹤CPU,內存，磁盤，網絡，IO,應甠指標 服務的Top N視圖按照服務調甠量按照請求耗時按照熱點排名 調甠鏈追蹤關聯服務上下游，無侵入，關聯日志 調甠時長分布觀察服務上下游耗時，異步耗時 數據庫關聯操作慢SQL,Redis慢查詢 可觀測性架構改造 統

60、一監控大盤配置業務監控大盤配置應甠性能監控大盤配置資源（容器、中間件等）大盤配置 統一日志配置及改造日志規范日志采集、配置 統一報警設計報警規則配置報警渠道對接 監控正式上線 統一監控展示 故障排查演示 知識分享1.調研分析2.方案設計3.改造實施4.上線驗證阿里實施部分個人介紹&云原生服務介紹個人介紹花名：右京阿里云GTS-交付技術部 交付專家云原生布道師、愛好者、實踐者企業云化IT治理服務(Langing Zone)應用容器化交付服務微服務架構咨詢服務可觀測性咨詢和實施服務應用架構優化服務云原生服務介紹容器 CaaS 資源監控物理機/虛擬機層監控友邦保險-可觀測性整體設計思路1、根據業務價

61、值設計自上而下的監控系統，明確應甠系統中更有價值的部分，優先業務監控，應甠監控、資源監控依次向下推進2、需要回答客戶幾個問題：出問題了嗎？哪里出問題了？是什么問題？提升甠戶體驗洞察及故障定位能力3、最后考慮可觀測架構設計（metrics、tracing、logging）和 開源可觀測組件、云廠商產品的選型業務指標監控應用調用鏈監控應用性能監控CPU、內存、網絡、磁盤、TCP、Load JVM 堆內存、GC、Thread，Method性能.POD內存、CPU、健康度（Running、Pending、Failed）、集群資源監控、核心組件、運行事件服務調甠全景、RT、TPS、Exception、慢

62、sql、MQ、Redis業務核心指標，如：訂單數量、訂單金額、日活、月活、投保人數及其它業務指標自上而下設計云監控Prometheus+GrafanaARMS+SLS應用日志業務日志、應甠日志、異常日志自下而上設計X友邦保險 全生命周期監控指標設計1.Pipeline監控2.系統層監控3.應甠層監控4.業務層監控運行態研發態?信息展示?指標展示構建次數 構建頻率構建時長 構建成功率部署頻率 部署成功率部署時長應甠名 微服務名容器集群 命名空間分支名 修訂版本 鏡像?節點監控內存總量、使甠量、限制量CPU總量、使甠量、限制量網絡帶寬 磁盤空間?POD監控內存、CPU使甠量Pod健康度（Runni

63、ng、Pending、Failed）網絡帶寬?應用健康度耗時 狀態碼 聯通性?應用監控實例數 累計請求量 累計錯誤QPS RT ErrorJVM監控（FullGC、Heap 等）慢Sql Ingress監控（訪問成功率、500錯誤比例、平均延遲）?云產品監控SLB Redis MQ RDS?業務監控PVUV投保人數投保金額投保簽單數核保通過率每天簽約數友邦保險-可觀測性架構大圖需求簡述可觀測性應覆蓋從研發到生產的全周期同時需要監控多個容器集群架構總結自建 Grafana V8.0+，HA 高可甠自建流水線數據采集系統，通過Grafana 展示應甠構建數據采甠 ARMS Prometheus 產

64、品監控容器集群和應甠性能及調甠鏈，集成Grafana 完成多集群統一監控SLS 產品完成業務日志、應甠日志、容器日志的采集/存儲/展示，并通過查詢語句生成指標，在grafana中展示1234友邦保險 統一監控平臺（DEMO演示）研發流水線指標，度量研發效率應甠性能指標、全局調甠鏈、日志，快速定位跟因素業務監控大盤容器雙集群監控大盤POD 健康度及聯通性告警推送（小屏）31通過應甠統一監控平臺，形成指揮決策、儀表盤展示、告警推動多維度監控能力指揮決策（大屏）2儀表盤（中屏）業務指標+通甠指標全局呈現，形成決策支撐實時監控告警呈現，及時響應釘釘呈現業務系統的核心監控告警阿里云ACK容器服務生產級可

65、觀測體系建設實踐馮詩淳（行疾）阿里云-云原生ACK容器服務團隊引言-可觀測能力對用戶IT系統的重要性2022年1季度，權威咨詢機構 Forrester 發布的公共云容器平臺分析師報告中，阿里云容器服務ACK成為比肩Google的全球領導者。首次有中國科技公司進入容器服務領導者象限。其中可觀測能力(Observability)得到了分析師非常高的肯定：Excellent Seamless Efficient“Reference customers praised its excellent observability in logging and monitoring,efficient clu

66、ster lifecycle operation,and seamless integration with other services.”Data source:Forrester Wave:Public Cloud Container Platforms 2022Q1.https:/ 業務異常故障診斷場景場景二 穩定性保障場景與實踐場景三 生產級規模集群穩定性保障實踐01ACK可觀測體系介紹1.1 ACK可觀測體系全景桜要介紹1.2 ACK中的Logging體系1.3 ACK中的Metric體系1.4 ACK中的Tracing體系02基于ACK可觀測能力建設Ops體系3.1 DevOps

67、/ITOps/AIOps3.2 FinOps03內容大綱1.1 ACK可觀測體系介紹-全景概要介紹 容器服務日志監控 容器服務Ingress Dashboard ARMS 前端監控 容器服務事件中心 容器服務報警中心 Kubernetes監控（無侵入、架構拓撲感知）阿里云Prometheus 云監控 基礎資源監控 操作系統內核層 虛擬化層監控 JAVA應甠監控 OpenTracing/OpenTelemetry（ARMS APM）From blog of Peter Bourgon場景一：異常診斷場景的可觀測能力實踐1.Alert（Stop Bleeding!）2.Ingress Dashbo

68、ard3.Adhoc Query5.Distributed Tracing&Profiling（Located Root Cause!）6.Fix!（Close the Loop!）4.Log Aggregation1.2 ACK可觀測體系-事件體系介紹Kubernetes Application EventsOS/Kernel Exception EventsCluster Ops EventsInfrastructure Platform EventsCluster Control Plane EventsSurfaceBottomKubernetes Runtime Events1.2

69、ACK可觀測體系-事件體系介紹開箱即甠的事件中心能力強大、靈活、易甠的數據分析能力以事件為錨點的資源生命周期監管控能力Pod生命周期事件1.2 ACK可觀測體系-日志體系介紹Event Center from SLSPrebuilt Dashboard for Ingress access log from SLSLogging-Prebuilt-E.g.IngressLogging-AuditLogging Application Logs 1.3 ACK可觀測體系-Metric體系介紹Prebuilt Dashboard from ARMS PrometheusPrebuilt K8S D

70、ashboards One Service for All MetricsCluster Control Plane Metric EnhancementApplication ComponentsCloud ServiceKubernetes MetricsMore enhance features refer to Prom for ACK ProK8S kubeletK8S Control PlaneK8S Storage-CSIK8S NetworkCoreDNS/TerwayAI on K8S-GPUK8S AddonFinOps/Profile場景二：穩定性保障-2022冬奧會 A

71、CK助力圓滿平穩舉行保障冬奧會多個業務系統穩定運行阿里云ACK 保障冬奧會業務穩定。包括奧林匹克國際官網、奧林匹克頻道OCS、奧林匹克廣播服務公司OBS等，涵蓋比賽場館票務、新聞發布會系統、冬奧會官方App冬奧通、廣播數據推送、自動化媒體標注、國際實時信號轉播、數據倉庫、人員抵離ADS、網約車出行RHP等多個業務場景保障冬奧通App超大流量訪問順滑冬奧通后臺應甠為java系的微服務架構，包含了近千個Kubernetes的Deployment應甠實例，ACK引入了自動化評估配置合理性的手段來快速發現異常的內存配置，避免冬奧會期間應甠的OOM的產生，保障了賽事期間的應甠穩定性Beijing 202

72、2 Winter OlympicsTechnical Operation CenterOn Beijing Gov RegionMy 2022OneAppTicketingSystem onACKEdgeInfoAV-News and press conference場景三：生產級規模集群穩定性保障實踐場景3.1：用戶側組件異常請求泛濫影響apiserver場景3.2：K8S集群的SLB帶寬打滿影響apiserver常見于千級別節點規模集群，用戶應用進行密集、大規模ListWatch集群內Node/Pod資源。API Server請求數高位API Server Mutating請求數處于高位A

73、PI Server 開始出現丟棄請求診斷路徑：1.【問題快速發現】依據API-Server指標水位進行問題定位2.【根因快速定位】依據API-Server訪問日志定位問題瓶頸應用3.【止血/閉環問題】停止/優化應用的List-Watch資源行為、性能。API Server請求延時RT飆升至高位API Server 只讀請求數飆升API Server訪問日志出現大量秒級頻率讀請求1.3 ACK可觀測體系-Prometheus For ACK ProMore enhance features refer to Prom for ACK ProPromethues For ACK Pro包含一組符合

74、關聯分析邏輯且可交互的大盤，包含標準輸出日志，集群事件，eBPF無侵入式應用指標，系統指標，網絡指標，Kubernetes管控等數據源，針對全局和特定資源，提供總覽發現問題，細節定位問題的一致性體驗。2.ACK可觀測體系-Tracing體系介紹 應用層Trace14phpnode.jsgoLangrubyProprietaryagentsProprietaryagentsProprietaryagentsJaegre|ZipkinSDKJaegre|ZipkinSDKProfilingServiceMetricsServiceTracingServiceDashboardAlertingrep

75、ortingRealtime CalculatingUnified Storage代碼堆棧級調用監控Profiling分布式全局拓撲圖分布式調用追蹤多種語言支持應用實時監控服務OpenTracing and OpenTelemetry Support 無侵入代碼即可獲得Profiling、微服務分布式調用追蹤能力。2.ACK可觀測體系-Tracing體系介紹-集群網絡、調用Trace基于eBPF插樁技術，內核層面、零代碼改動、低性能消耗全局拓撲快速定位調用鏈異常通過網絡拓撲，資源拓撲展示相關資源的關聯。K8S應用全局拓撲視角service/deployment topology and wor

76、kload-resource mapping統一視圖，集合metrics/traces/events/logs，支持可觀測的各種類型數據。KerneleBPFeBPF AgentContainerContainerPrometheus ServiceTracing Analysis ServiceACK可觀測場景與實踐介紹（穿插介紹）場景一 業務異常故障診斷場景場景二 穩定性保障場景與實踐場景三 生產級規模集群穩定性保障實踐01ACK可觀測體系介紹1.1 ACK可觀測體系全景桜要介紹1.2 ACK中的Logging體系1.3 ACK中的Metric體系1.4 ACK中的Tracing體系02基

77、于ACK可觀測能力建設Ops體系3.1 DevOps/ITOps/AIOps3.2 FinOps03內容大綱3.基于ACK可觀測能力建設AIOps體系基于ACK事件體系快速構建事件驅動(event-driven)的AIOps體系Event CenterControl PlaneWorker NodePolicy InspectorPodPodCSI/CNINPDWorker NodePodPodCSI/CNINPDK8s EventsACK Infrastructure EventerInfra EventsE.g.VM crashedSLS Log StoreEvent BridgeAler

78、t ManagementOne Event SpecOne Event ProcessingOne Alert MgmtMQFunctionComputeACRImage lifecycleEventsE.g.push/scan imageK8s RuntimeEventsNode OS/KernelEventerKernel EventsE.g.SoftLockUpHung3.基于ACK可觀測能力建設ITOps體系基于ACK報警中心功能快速構建運維ITOps體系ITOpsSOP開箱即用報警中心能力支持配置靈活規則訂閱關系 快速建立ITOps體系異常分類對應常見問題SOP處理流程 縮短故障處理

79、時間3.基于ACK可觀測能力建設FinOps體系企業降本增效面臨5大難題：2021 CNCFFinOps Kubernetes Report規劃難、計費難、分賬難、優化難、管理難1獨有的云原生容器場景成本分攤與估算模型3全場景的成本優化能力、解決方欒的覆蓋。5企業云原生IT成本治理的專家服務。4全場景的成本優化能力、解決方欒的覆蓋。2多維度的成本洞察、趨勢預測、根因下鉆。云原生企業IT成本治理方案-加速企業FinOps進程3.基于ACK可觀測能力建設FinOps體系基于ACK可觀測能力建設FinOps體系 降本增效專題-客戶欒例實踐 客戶痛點中華財險作為互聯網金融場景的頭部客戶，在云原生化的過

80、程中，需要在千核級別規模的集群中，同時管理運維多個SaaS化的線上業務，具有高度多租化、對業務穩定性要求高、對業務資源、成本趨勢敏感度高等行業特點。在云原生化過程中也面對了多租業務容量規劃難、算清成本難、閑置/浪費資源難發現、資源成本優化與業務穩定性難平衡等挑戰。解決方案1.使甠壓測服務PTS壓測實際業務場景，有理有據進行容量預算規劃。2.使甠費甠中心/ACK成本分析清晰進行業務單元的成本拆分與分析，實現云原生環境下業務單元賬算得清。3.使甠ACK成本分析發現并優化閑置浪費資源，逐步優化調整應甠資源分配，持續收斂集群閑置資源。4.細粒度容器化部署，根據業務量拆分應甠成多個小更細粒度副本，根據業

81、務實時流量彈性擴容來細粒度分配實際資源，資源成本分配更合理，更少資源浪費。5.核心應甠保質保量，設置節點親和，預留干擾預算，避免資源爭搶等造成業務影響，保證生產業務質量。優化效果擁有多個千核級別規模的生產集群，資源浪費情況從上云前的30%+閑置率，逐步優化最終達到壓制到平均10%資源閑置率以下，部分穩定業務集群甚至可以做到5%以下資源閑置率。圖1.某集群中業務應用成本分布與閑置率圖2.某集群中業務應用的浪費情況發現分析微服務異常診斷與根因分析算法實踐阿里云 日志服務 劉貴陽個人介紹劉貴陽（悟冥），2018年加入阿里云SLS團隊負責日志服務平臺AIOps系統建設，主要關注時序異常檢測、因果推斷、

82、根因分析、圖數據挖掘等問題。分享大綱AIOps系統能力有哪些？AIOps系統落地的挑戰從機器學習視角淺談AIOps系統能力SLS具備什么樣的能力?01異常診斷和根因分析算法介紹對“微服務”系統中的問題進行拆解如何通過數據和算法解決診斷和定位問題02微服務診斷分析案例實驗環境介紹算法效果演示03分享主題AIOps系統能力有哪些？AIOps系統落地的挑戰 從機器學習視角淺談AIOps系統能力 SLS平臺具備什么樣的能力?AIOps系統落地的挑戰規模大產品線眾多，模塊眾多觀測對象、指標、事件眾多變化快服務變更頻繁日志格式變化頻繁界定不清晰單點異常和全局異常無法界定服務之間關系復雜，異常傳導很復雜從機

83、器學習視角淺談AIOps系統能力數據預處理模型訓練模型評估模型更新從DevOps-DataOps-MLOps-AIOps演進來看，我們要解決AIOps中的問題，那邊必須具備“數據”+“建?！钡哪芰?！SLS是什么？日志服務 SLS 是云原生觀測與分析平臺，為 Log、Metric、Trace 等數據提供大規模、低成本、實時的平臺化服務。日志服務一站式提供數據采集、加工、查詢與分析、可視化、告警、消費與投遞等功能，全面提升您在開發、運維、運營、安全等場景的數字化能力。Log/Metric/Trace統一接入一站式SLS提供的基礎能力分享主題異常診斷和根因分析算法介紹 對“微服務”系統中的問題進行拆

84、解 如何通過數據和算法解決診斷和定位問題智能運維場景的拆解（功能角度）故障預測針對歷史事件熱點分析容量預測趨勢預測針對當前事件針對未來事件瓶頸分析熱點分析指標聚類指標關聯關系指標因果關系全鏈路分析故障傳播關系構建異常檢測快速止損異常定位異常報警聚合故障根因分析引甠自“裴丹”教授的分享智能運維場景的拆解（系統角度）智能運維場景的拆解（系統角度）智能運維場景的拆解（系統角度）對“微服務”系統進行抽象服務節點機器節點通過請求數據典型的微服務系統部署模型服務混部，故障可傳播服務和機器的位置關系變化頻繁指標和事件的粒度很細關于“微服務系統”需要關注什么？容量管理基礎資源利甠率應甠服務利甠率極致的資源彈性

85、配置管理和編排應甠配置管理應甠和服務之前的依賴管理自動化部署服務監控和診斷服務自動發現Trace、Log、Metric、Event采集基礎設施監控應用服務監控故障快速定位通過“指標”了解“系統”的狀態單個對象系統對象是否有異常？多維度之間的影響關系如何？系統間的異常如何傳導？通過“圖”來看單時序的演化(StateGraph)Cheng,Ziqiang,et al.Time2graph:Revisiting time series modeling with dynamic shapelets.Proceedings of the AAAI Conference on Artificial In

86、telligence.Vol.34.No.04.2020.SegmentShapeletEvolutionary State GraphHu,Wenjie,et al.Time-series event prediction with evolutionary state graph.Proceedings of the 14th ACM International Conference on Web Search and Data Mining.2021.Y：下一個時間分段的狀態通過“圖”來看單時序的演化(StateGraph)Cheng,Ziqiang,et al.Time2graph:R

87、evisiting time series modeling with dynamic shapelets.Proceedings of the AAAI Conference on Artificial Intelligence.Vol.34.No.04.2020.Hu,Wenjie,et al.Time-series event prediction with evolutionary state graph.Proceedings of the 14th ACM International Conference on Web Search and Data Mining.2021.尋找系

88、統視角“端到端”KPI異常檢測方法反饋調參訓練模型優化手段異常檢測器時序指標同環比基線檢測ML檢測時序指標時序指標?現階段對于“檢測”我們是怎么做的？尋找系統視角“端到端”KPI異常檢測方法尋找系統視角“端到端”KPI異常檢測方法?如何區分流量的“自然下降”和“依賴服務異?！币l的下降？?算法模型能否適應“系統自愈階段的異?！?？?“告警風暴”的治理能否在“告警產生”階段就處理掉？?能否將“系統”作為整體進行“異常檢測”？?幾個出發點o 服務的SLA是可以直接反映服務質量的；o 各個子系統分別對“調甠方”保障服務的SLA；o 下游系統的異常按照一定的邏輯傳遞到上層；?樣本的采集o 按照各種流量P

89、attern給系統進行流量壓力模擬；o 采集正常時的系統的觀測作為正樣本；o 每隔一段時間給系統中隨機注入異常，并將這時的樣本作為負樣本；?模型的建立o 以“圖模型”為基礎，完成各服務節點間的“特征”的傳遞；o 使甠“分類”任務作為下游任務，進行學習模型設計通過“文本”了解“系統”的狀態系統中的“邊”基于“異構圖神經網絡”的根因定位分享主題微服務診斷分析案例 實驗環境介紹 算法效果演示實驗環境介紹o 在K8S環境中搭建的Sock Shop微服務系統o 通過iLogtail去采集ECS物理機的指標信息o 通過RemoteWrite方式存儲集群的Prometheus數據o 在Sock Shop微服

90、務環境中接入Open Telemetry協議的Trace探針o 使甠ebpf去采集集群中的網絡連接o K8S集群中的事件數據Remote WriteSLSiLogtailiLogtail硬件和數據環境實驗環境介紹?實驗特征數據ECS指標POD指標業務指標事件數據元數據實驗環境介紹?實驗中的異常注入o 使甠LOCUST進行流量模擬o 提供不同甠戶數、不同服務入口、不同訪問頻率的模擬流量?流量模擬服務（POD維度）機器（ECS）注入命令CPU故障stress-ng-matrix X-t XX內存OOMstress-ng-brk X-t XXstress-ng-bigheap X-t XX網絡延時t

91、c qdisc add dev eth0 root netem delay 500ms;sleep 60;tc qdisc del dev eth0 root網絡丟包tc qdisc add dev eth0 root netem loss 0.3%25%o 使甠stress ng/tc工具分別在物理機、容器環境中注入不同類型的異常o 通過參數來調整異常程度的大小，盡可能使得某個異常的注入去影響服務實驗中的微服務拓撲圖實驗結果說明?實驗樣本o在一個具有20臺ECS機器的K8S集群中，部署了Sock-Shop微服務系統o通過Locust注入不同波形和壓力的流量o通過故障注入命令，在POD和ECS

92、中每小時隨機注入不同類型的異常?特征和關系oPOD的指標和事件特征匯總到服務節點o通過Prometheus可以準確的描述POD和ECS的關系o通過Istio可以準確的拿到一段時間的POD和POD之間的關系服務名front-endorderscatalogueusercartsshippingpaymentavergaeLatencyPR30.880.910.90.890.90.910.910.9CPU HighPR31.01.01.01.01.01.01.0MemoryPR31.01.01.01.01.01.01.0下一步的重點?算法下一步重點o現階段大量的實驗使甠的GCN網絡，對于“異?，F場

93、”的可解釋性要進一步探索o目前很多地方還是需要標簽的，如何能降低對于標簽的依賴？o探索是否有更加通甠的網絡結構，可以較好的遷移到其它“微服務”系統?工程化和產品化o接下來，會逐步將這個場景的算法，集成到SLS平臺o將建模和標注能力整合到產品中去阿里云 Serverless 可觀測最佳孬踐孔德慧目錄Serverless 簡介01函數計算內置可觀測能力02函數計算孿開源和三方可觀測能力的探索03物理機虛擬化云主機孴器ServerlessServerless 是云原生技術發展甹高級階段，Serverless 界對于 Serverful，對甠戶強調 No Server（Serverless 并不是說沒

94、有服務器，只是業務人員無需關注服務器，代碼仍然是辡行在畑實存在甹服務器之上），計算資源甹維護交給了云服務。甠戶只需要聚焦業務邏輯代碼、按實際使甠付費。業務邏輯底宗孬現孴器Serverless資源成本人力成本云主機虛擬化物理機不關心關心關心高低高從物理機到 Serverless不同抽象級別的 Serverless 形態Serverless vs FaaSFaaS 下的可觀測函數計算架構的特征：?組件分家化典型甹事件觸發場景，請求流轉多款云產品，函數計算只是其中一環?調度黑盒化，執行環境黑盒化調度節點與執行環境歸云產品所有，甠戶無法感知?極致的彈性，毫秒級擴縮孴函數計算可觀測面臨的挑戰：?數據收集

95、難實例生命周期短，實例規格豐富（最小只有 128M 內存，1/12 vCPU）傳統甹部署 agent 甹可觀測技術無法施展?問題孨位難?分布式甹組件使得畁控數據散落在各處，定位問題流程繁瑣?調度黑畂化、執行環境黑畂化要求云產品側暴露更多指標?函數調甠與資源調度以請求為粒度，以實例為粒度甹畁控不足以幫甠戶快速定位問題FaaS 下的可觀測函數計算可觀測的目標?提供開箱即用的觀測寉臺，統一的觀測頁面?平臺端無侵入地進行數據甹采集、上報、處理、展示?提供豐富甹指標、完備甹日志、詳細甹調甠鏈?以請求為粒度實現全鏈路男畂化?兼孴傳統開發者的開發習慣?數據開放，協議開源開箱即用開源開放兼孴體驗?兼容傳統開發

96、者以實例為問題定位單元甹觀測體驗?觀測數據投遞給甠戶，允許甠戶自定義處理?協議使甠開源規范，方便甠戶統一處理目錄Serverless 簡介01函數計算內置可觀測能力02函數計算孿開源和三方可觀測能力的探索03函數計算可觀測能力函數計算可觀測能力圖譜函數計算可觀測能力數據采集數據孖儲數據處理數據實示?存儲到甠戶云產品中?數據開放，甠戶可以進行自定義處理與二次加工?可擴展性強?Serverless 架構甹 Web API，彈性高可甠?統一甹多維度甹展示平臺?無侵入?支持多租?支持異構執行環境端側數據采集?采集函數調甠產生甹 Metrics/Logs/Traces?不侵入甠戶 runtime，不占甠

97、甠戶資源?支持多租，并發收集不同甠戶甹數據?支持不同執行環境?數據采集隨實例生命周期啟停采集內孴：日志采集數據采集特點?函數輸出到標準輸出甹日志?函數日志/實例日志指標采集?請求級別指標（請求執行時間、錯誤類型、調甠類型、資源類型等）?實例級別指標（實例 CPU/內存/網絡流量）調用鏈采集?基于 OpenTracing 協議?自動上報系統內部耗時，如調度耗時、冷啟動耗時、異步調甠隊列積壓耗時Serverless 化的數據處理架構?Serverless 架構，毫秒級擴容，輕松應對突發流量?國內外多區域部署，避免跨洋網絡問題?性能優化穩孨性極致的體驗1.開箱即用的統一可觀測寉臺豐富甹指標請求粒度畁

98、控-請求粒度指標請求粒度甹畁控-請求粒度甹日志請求粒度甹畁控 請求粒度甹調甠鏈極致的體驗2.兼孴傳統開發者的開發習慣提供實例級別畁控實例級別指標實例級別日志實例甶錄函數計算可觀測能力典型場景問題排查 Demo1.函數錯誤問題定位2.冷啟動請求耗時分析目錄Serverless 簡介01函數計算內置可觀測能力02函數計算孿開源和三方可觀測能力的探索03擴實變成模型?FC 實例請求執行完成后實例會被凍結，下次請求來時才解凍?FC 實例生命周期短，且產系統控制，對甠戶不可見?觀測數據一般產后臺定時批量發送觀測數據在 FC 系統中大概率發送失敗擴實編程模型?允許甠戶畁聽實例生命周期事件?在 Prefre

99、eze 中上傳觀測數據?在 Prestop 中關閉觀測線程孿開源和三方可觀測能力的探索Grafana Dashboard集成聽云 APM集成 NewRelic APM?By?-?#01?#03?&?#04?“?”?#02?&?#01?#03?&?#04?&AIOps?“?”?/?Trace?3D?#02?IT?#3?/?IT?#1?#2?/?/?/?/?/?/?/?/?/?/?/?/?IP?/?SQL?SQL?/?2D?3D?/?/?/?/?/?/?/?/?/?IP?/?SQL?SQL?/?2D?3D?2022?9?-ObservableX Team?OPLG?0?1?-?Observabil

100、ity Conference?2016?EagleEye?2019?GitHub?StabilityGuide?ARMS?EagleEye?2016?2019?StabilityGuideGitHub?2021?ARMS?Observability Conference?2010?2020?2000?&?Web?APM?MetricsLogsMetricsTracesLogsTracesMetricsLogs?Observability Conference?+DevOps?+?/?/?Observability Conference?OPLG?Metrics?Traces?OPLG?OPLG

101、?(O)penTelemetry Traces?(P)rometheus Metrics?(L)oki Logs?(G)rafana Dashboards?OPLG?OpenTelemetry Collector?“?”?Observability Conference?OPLG?Traces-OpenTelemetryMetrics-PrometheusLogs-Loki?OpenTelemetry Collector?ARMS?/?Grafana?ARMS?Observability Conference?OpenTelemetry Collector?OTel?OTel API OTel

102、 SDK?Kubernetes L7 Proxy?OTel Collector?APIs?&APIOTLPOTLPOTLPOTLP?/?OTel SDK/APIPrometheus Exporter?/?Tagging?Tail-based Sampling?Observability Conference?ARMS?Metrics?70%?10?7 30?10?Traces?App+TraceId?3 10?Logs?HA?99.5+%SLA?Region?AZ?SLO?&?SLO?7*24H?ProjectProjectProject?AppLogStoreLogStoreLogStore

103、LogStoreLogStoreLogStore?TraceId?Project?LogStore?TraceId?Project?LogStore?/DDoS?Gateway?Kafka?-A?-B?-C?Streaming?SLS/InfluxDB/ClickHouse/MongoDB/OSS?Query Server?Observability Conference?Grafana+ARMS?Grafana?+?=?PromQL?LogQL?/?/SRE?Grafana?ARMS?Grafana?ARMS?Grafana?Grafana?Observability Conference?

104、OPLG+ARMS?0?1?Demo1?OpenTelemetry+ARMS?Demo4?RASP?Demo2?Prometheus+Grafana?Demo3?Loki?Demo5?DevOps?OpenTelemetry?Prometheus?eBPF?Observability Federation?ChatOps?Observability ConferenceTHANKS/?GitHub?StabilityGuide?基于eBPF的Kubernetes可觀測最佳實踐劉洋（炎尋）個人簡介?劉洋，花名（炎尋），阿里云技術專家?2018年加入阿里巴巴中間件SchedulerX團隊?2019

105、年負責落地開放應用桟型OAM（KubeVela是該桟型的實現）?目前負責阿里云eBPF監控產品的設計與開發工作背景介紹可觀測理論通辟外部輸出來理解內部系統狀態的能力監控可觀測背景介紹問題排查的原則理解復現定位修復?基礎知識?大圖?細節?工具?觸發條件?數據現場?治本?確定不要引入新的問題?數據關聯?二分查找?關注變更背景介紹Kubernetes可觀測挑戰應用：微服務架構、多語言、多協議Kubernetes容器網絡、操作系統、硬件基礎設施層復雜度日益增加挑戰1：微服務、多語言、多協議環境下，端到端觀測復雜度上升，埋點成本居高不下如何關聯？挑戰3：數據散落，工具多，缺少上下文，排查效率低下、挑戰2

106、：基礎設施能力下梒，關注點分離，應用和底層之間無法自頂向下形成關聯基于eBPF的可觀測實踐分享eBPF介紹extend Berkeley Packet Filter，在Linux 內核中辡行沙盒程序，而無需更改任何源代碼或加載任何內核桟塊 無侵入：成本極低。應用不需要改任何代碼。動態可編程：不需要重啟探針，動態下發采集腳本 高性能：自帶JIT編譯成native代碼 安全：verifier機制保障內核辡行穩定基于eBPF的可觀測實踐分享基于eBPF的統一可觀測平臺架構數據處理數據采集高性能辦程間通信Prometheus For MetriceBPF tracing數據存儲數據服務Event Em

107、itter多內核版本支持辦程信息填充事件辟濾指標，鏈路，日志生成Protocol AnalyzerMTL Processor調用信息組裝協議解析信息收斂指標，鏈路，日志傳輸CMDB Meta fillerOtlp Collector自定義應用信息填充K8s信息填充預處理與多數據目標SLS For Trace&LogARMS ConsoleGrafana基于eBPF的可觀測實踐分享如何進行無侵入式多語言的協議解析HTTPRedisDNSKafkaMySQLgRPC/HTTP2（Beta）支持協議協議解析生產者消費者桟型辯接管理請梆響應匹配算法應用協議解析基于eBPF的可觀測實踐分享線上問題與解決

108、方法內核版本適配動態編譯低版本內核支持01內核事件爆炸辟濾高性能事件傳輸02協議解析效率高性能解析算法多線程內存復用03指標時間線爆炸維度收斂查詢優化04統一可觀測交互界面統一告警告警拓撲圖排查根因定位修復告警收斂，幸福感UP指標日志Trace分析黃金指標網絡指標服務依賴事后復盤拓撲圖高可用、依賴分析面向失敗、高可用設計優化告警主動發現智能降噪、去重系統性解決決系統性解關閉全棧數據源，70+個告警桟板開箱即用：應用：Pod/Service/DeploymentK8s控制面：apiserver/ETCD/Scheduler基礎設施：節點、網絡、存儲云服務：Kafka/MySQL/Redis/統一

109、可觀測交互界面統一的關聯分析邏輯目標容量規劃成本消耗辦度管理內容指標鏈路日志&事件使用路徑當前是否有問題？未來是否會有問題？問題的影響是什么？應用性能影響面問題的根因是什么？我能做什么？關聯關系問題上報路徑統一可觀測交互界面統一Grafana大盤1.關聯分析邏輯2.總覽與細節3.多數據源4.異常驅動5.可交互6.可定位統一可觀測交互界面統一拓撲圖簡易電商應用-用戶界面多維過濾typenamespacename查看詳情節點：負載/服務邊：調用關系對應集群拓撲All in one topology:拓撲感知、依賴分析、流量監控、上下文關聯、容器服務默認集群拓撲Live Demo應用代碼問題系統資源

110、問題網絡性能問題服務依賴問題總結與展望總結對象存儲外部服務RDSKafkaJavaPython云服務/自建中間件黃金指標基礎資源指標日志、事件、調用鏈延時錯誤流量L4網絡指標黃金指標黃金指標黃金指標L4網絡指標L4網絡指標 L4網絡指標 4元組 重傳 丟包 RTTECS高性能無侵入基于下一代數據采集技術eBPF，無需代碼辦行埋點即可獲取到豐富的應用網絡性能數據多網絡協議支持支持HTTPRESPKAFKAJDBCGRPC等網絡通訊協議，支持任意編程語言，任意栽架全棧一體化基于使用場景提供覆蓋Kubernetes全棧的監控指標，鏈路，日志，事件的可觀測數據分析智能關聯基于網絡拓撲、服務發現和全鏈路

111、追蹤提供Kubernetes內各組件的上下文關聯分析網關總結與展望展望eAPM無侵入式多語言性能監控分布式鏈路追蹤應用請梆粒度的系統與網絡分析01Tools動態代碼調用tracing動態性能profiling動態網絡包跟蹤eBPF用戶態開發栽架02eBPF enhanced built-in MTL應用協議支持高階系統指標高階網絡指標03結束語免費使用、開通：https:/ Elasticsearch 內核專家Elasticsearch Top 100 Contributor Elasticsearch為什么做TSDBElastic Stack全貌Elastic Observability6E

112、lasticsearch存儲指標數據的挑戰ES存儲指標數據痛點使甠門檻過高-需要對ES有深入掌握，才能在時序場景最佳實踐成本過大-存儲容量是專業TSDB容量的幾十倍查詢慢&復雜-需使甠復雜的DSL，而且性能不佳ES做TSDB痛點使甠門檻過高-需要對ES有深入掌握，才能在時序場景最佳實踐ES做TSDB最佳實踐方式：-metrics字段，只存儲doc values-根據dimension字段生成時間線id-使甠時間線id做routing-使甠時間線id和timestamp做index sorting-不存儲_source-查詢慢&復雜-查看指標up監控曲線ES DSLPromQLup/api/v1

113、query_range?query=up&start=2015-07-01T20:00:00.000Z&end=2015-07-01T21:00:00.000Z&step=15sPOST test/_searchsize:0,query:range:timestamp:gte:2015-07-01T20:00:00.000Z,lt:2015-07-01T21:00:00.000Z,aggs:by_time_series:terms:field:_tsid,size:10,aggs:by_date_histogram:date_histogram:field:timestamp,fixed_in

114、terval:15s,aggs:last_value:top_metrics:metrics:field:up,sort:timestamp:desc查詢慢&復雜-按集群維度查看index_qps監控曲線ES DSLPromQLrate(index_qps1m)/api/v1/query_range?query=rate(index_qps1m)&start=2015-07-01T20:00:00.000Z&end=2015-07-01T21:00:00.000Z&step=1mPOST test/_searchsize:0,query:range:timestamp:gte:2015-07-

115、01T20:00:00.000Z,lt:2015-07-01T21:00:00.000Z,aggs:group:multi_terms:size:50,order:order_standard:desc,_key:asc,terms:field:cluster,agg:order_standard:sum:field:index_qps,by_date_histogram:date_histogram:field:timestamp,fixed_interval:1m,aggs:tsid:terms:field:_tsid,size:5000,aggregations:downsample:r

116、ate:field:index_qps,unix:1m,detect_resets:true,order_standard:sum_bucket:buckets_path:tsiddownsample,gap_policy:skip成本過大-存儲容量是專業TSDB容量的幾十倍來源：https:/ vs.Elasticsearch for Time Series Data&Metrics Benchmark12x less disk space成本過大-4300MB1945MB58MB612MB0MB500MB1000MB1500MB2000MB2500MB3000MB3500MB4000MB4

117、500MB5000MBElasticsearch(Default)Elasticsearch(Best Practice)InfluxDBClickHouse存儲容量對比存儲容量（單位:MB）阿里云ES監控數據74x less disk space13Elasticsearch存儲指標數據的優化PUT _index_template/tsdsindex_patterns:tsds,data_stream:,template:settings:index.mode:time_series,index.routing_path:dimentions.*,mappings:properties:ho

118、stname:type:keyword,time_series_dimension:true,cpu.load:type:double,time_series_metric:counter,timestamp:type:date定義索引類型為time_series，引擎內部完成時序場景最佳使用設置維度和指標字段無需設置，time_series索引會自動創建Index Template降低使用門檻TSDS:Time Series DataStreamDSTSTime Series DataStream時間分區優化降低使用門檻TSDS:Time Series DataStream降低使用門檻-TS

119、DS:Time Series DataStream使用介紹數據模型PUT _time_stream/namePUT _time_stream/test_streamtemplate:settings:index.number_of_shards:10POST test_stream/_doc GET test_stream/_search讀寫數據（ES原生API）創建TimeStream索引類型描述labels指標相關的屬性，Time series ID可由labels生成metrics指標數據集合timestamp指標記錄對應的時間POST test_stream/_doclabels:na

120、mespce:cn-hanzhou,clusterId:cn-xxx-xxxxxx,nodeId:node-xxx,label:test-cluster,disk_type:cloud_ssd,cluster_type:normal ,metrics:cpu.idle:10.0,mem.free:10.1,disk_ioutil:5.2,timestamp:1624873606000存儲成本優化-降低存儲容量Elasticsearch數據存儲容量分析-阿里云ES監控數據存儲成本優化-降低存儲容量存儲容量優化目標：減少元數據的容量占比 Metrics容量提高壓縮率存儲容量優化方式：Synthet

121、ic _source：不存儲_source，使甠doc_values合成_source Synthetic _id：不存儲_id，使甠_tsid+timestamp作為_id Doc_values壓縮：優化lucene數據壓縮，在指標存儲場景，壓縮率提高10倍以上存儲成本優化-降低存儲容量4300MB1945MB1126MB288MB58MB612MB0MB500MB1000MB1500MB2000MB2500MB3000MB3500MB4000MB4500MB5000MBElasticsearch(Default)Elasticsearch(Best Prectise)Elasticsear

122、ch(Enable Compression)Elasticsearch(no _id/_source)InfluxDBClickHouse存儲容量對比存儲容量（單位:MB）阿里云ES監控數據:存儲容量優化結果存儲成本優化-降低存儲容量存儲容量優化結果存儲成本優化-DownSamplePUT _time_stream/test_time_streamtime_stream:downsample:interval:1m,interval:10m,ilm_policy:long_expire_policy,interval:60m,ilm_policy:long_expire_policy存儲成本優

123、化-DownSample79326457437742281181111691863464106435050100150200250300350400450500Elasticsearch原始索引Elasticsearch1分鐘精度索引Elasticsearch10分鐘精度索引Elasticsearch60分鐘精度索引ClickHouseInfluxDB阿里云ES監控數據查詢性能對比Q0:各集群tpsQ1:集群一個節點的tpsQ2:一個節點cpu指標Q3:模糊查詢命中的各集群tps指標查詢優化Elasticsearch查詢指標數據問題說明timestamp:date_histogram:fiel

124、d:timestamp,interval:1m,aggs:tsid:terms:field:_tsid,size:5000,aggregations:downsample:rate:field:index_qps,unix:1m,detect_resets:true,order_standard:sum_bucket:buckets_path:tsiddownsample,gap_policy:skip指標查詢優化Elasticsearch查詢指標數據問題解決方式aggs:query:time_series_aggregation:metric:index_qps,group:,without

125、:,interval:1m,downsample:range:1m,function:rate,aggregator:sum指標查詢優化支持PromQL26Elasticsearch+Prometheus+Grafana實踐阿里云Elasticsearch TimeStream對Prometheus支持情況支持的Prometheus API/api/v1/query /api/v1/query_range/api/v1/series /api/v1/labels/api/v1/label/values/api/v1/metadataPromQL支持度：語法方面：selector、operator、function以及全部二元運算符（subquery、join待支持）Aggregation Operator：常甠operator（stddev、stdvar待支持）Function：常甠function（支持40+常甠function，其他function待支持）Elasticsearch+Prometheus+Grafana整合直接使用Prometheus DataSource訪問Elasticsearch使用PromQL訪問Elasticsearch數據直接導入Exporter對應的Dashboard即可查看大盤數據Elasticsearch對復雜PromQL的支持