孔羅星-字節跳動觀測智能化之路.pdf

《孔羅星-字節跳動觀測智能化之路.pdf》由會員分享，可在線閱讀，更多相關《孔羅星-字節跳動觀測智能化之路.pdf（29頁珍藏版）》請在三個皮匠報告上搜索。

1、字節跳動觀測智能化之路服務端觀測平臺負責人/孔羅星Dev Infra-APM/服務端觀測平臺負責人個人&團隊介紹13年APM領域經驗，21年加入字節后開始負責服務端觀測平臺團隊面向整個字節內部開發者提供觀測平臺，與多個團隊協同構建Metrics/Traces/Logs/Events等數據埋點&加工鏈路&存儲，并基于此提供一站式的監控、報警、日志、鏈路追蹤、根因分析等產品化能力What、Why服務端一站式智能觀測平臺業務和架構配合團隊KitexHertzJet RPCMesh日常排障、性能分析架構治理優化穩定性、容災、大促成本優化服務場景APM as a Service微服務/基礎設施/SLO監

2、控數據探索內置應用生態集成LLM AgentCase管理開放平臺：觀測數據、元數據、算法、workflow報警報警引擎Trace平臺功能元數據服務元數據拓撲關系組件元數據觀測數據MetricsLogsTracesProfilingsEvents報警統計Duty引擎采樣策略高級分析查詢檢索TCE(容器)FaaSSYS-STE(物理層)語言團隊組件(Redis/MySQL)聚類分析日志日志加工標準指標Measurement查詢檢索現狀和挑戰業務多樣性業務多樣性服務整個字節所有業務，包括抖音、懂車帝、飛書、火山引擎、電商等語言x框架：Java/Go/C+/Python x 10+框架超大數據量超大數

3、據量微服務數量：數十萬Metrics：數十億點/sTraces：近億Span/s日志：數百PB存儲量報警：上千萬報警規則狂奔的業務狂奔的業務用戶規模用戶規模內部用戶規模最大的產品之一數萬UV、數十萬PV研發、SRE、QA日常高頻使用業務希望保姆式服務平臺要最大限度降低使用成本穩定性要求日益提高精益求精的產品設計平臺工程整合大量數據&平臺多角色需求不同，導致產品較為復雜數據需要長期治理微服務拓撲復雜度高分析難度大多個業務仍處于快速發展期技術棧復雜度越來越高：例如AI Infra業務研發對可觀測理解程度不高觀測數據標準化程度不一產品體系龐大且復雜覆蓋率提升有瓶頸解決思路抄近路-AIOps智能化內置

4、RCA各處集成自動化產品演進覆蓋度平臺能力場景化應用數據標準雙線并行、相輔相成保持產品演進長期方向，建設好基礎能力，同時為AI鋪路提高AI投入，通過AI應用降低使用成本，同時輔助用戶理解產品設計AI排障-引入前手工逐層分析異常指標、Trace、日志，遞歸查找下游問題AI排障-引入后報警即觸發全自動分析，自動尋找上下游關聯，智能聚合相同根因報警，給出影響面評估智能化的前置依賴海量觀測數據標準化Service AService BService CMySQL ARedis AService AContainerRuntimeRpc clientRpc serverProcessHost 1磁盤IO

5、網絡內核CPU內存MySQL AProxyData ServerContainerContainercontainer.cpu.usagejvm.heap.usagerpc.client.latencygo.runtime.coroutine_cnt機房_dcdcidcipv4地址hostipv4hostv4服務集群clusterpaas_clustercluster_namepod namepodname_pod_namepod_name人能很容易使用數據嗎？代碼或算法容易分析數據嗎？平臺內各處容易聯動跳轉嗎?不規范的Metrics tag舉例日志不同對象/組件指標不一致指標/trace/l

6、og不一致服務/SDK版本不同指標不一致同類SDK語言不同指標不一致用戶go.psm.heap.bytego.psm.gcPause.usruntime.go.memory.allocated_bytespsm=xyzruntime.go.gcpsm=xyzgo.psm.numGosruntime.go.goroutine.numpsm=xyzgogo runtimeruntime v1v1 metricsmetricsgogo runtimeruntime v3v3 metricsmetricslanguage=goruntime_sdk_version=1.3.1framework=kit

7、exmetadatametadatametadatametadatalanguage=goruntime_sdk_version=3.1.1framework=kitexserviceservice A Aserviceservice B Bservice.runtime.go.total_bytesservice.runtime.go.gc_pauseservice.runtime.go.goroutine_num指標描述tag映射路由規則指標來源于 runtime.MemStats.HeapAlloc,表示當前程序已經申請但尚未被釋放的堆內存的總量_dc=dc_pod_name=pod_n

8、amecluster_name=clusterif runtime_sdk_version=3.0.0use runtime v3 metricselseuse runtime v1 metrics觀測數據標準化：Measurement全面且準確的元數據Service AService BService CMySQL ARedis AService AContainerRuntimeRpc clientRpc serverProcessHost 1磁盤IO網絡內核CPU內存MySQL AProxyData ServerContainerContainercontainer.cpu.usagej

9、vm.heap.usagerpc.client.latencygo.runtime.coroutine_cnt如何得到容器的宿主機？B是A的強依賴還是弱依賴？A是什么語言的服務版本是多少？只知道宿主機IP，它在哪個機房？是什么規格？MySQL是什么版本？是否分片？微服務元數據 組件元數據 拓撲元數據 易分析的數據=觀測數據 join 元數據自動化和智能化的結合工程架構智能歸因整體架構內置應用RCAProblem觀測數據、元數據、算法SDK元數據服務技術棧拓撲關系組件元數據觀測數據MetricsLogsTracesProfilingsChange Events框架基建編排框架FaaS集成Case

10、管理用戶反饋、根因標注準確率回溯數據持久化Alert Events平臺集成監控圖表報警卡片飛書機器人業務自定義RCA業務指標分析風險巡檢LLMAgent分析套件自動化分析Low-Level數據訪問Mid-Level過載分析原子算法流量來源分析單實例分析Panic分析High-Level可用性下降分析MySQL異常分析延遲上漲分析分層API遞歸分析上游分析錯誤類型維度下鉆關聯分析獲取因果關系靜態表分析動態因果關系篩選最終根因遞歸分析下游是否上游問題是否下游問題排列組合局部性問題剪枝根因選擇專家經驗數據算法智能化排障報警觸發飛書卡片根因分析ProblemProblem相同根因對用戶而言所謂智能就是

11、原本需要依靠人得出結論的現在能夠自動得出了，至于采用的是專家經驗還是算法還是大模型用戶并不關心，而為了能 自動 得出結論，我們需要智能算法的幫助有用 準確結論+過程用戶反饋有用率 90%診斷不出來沒關系，別誤導我！結果感覺不符合預期，是怎么得出的結論？原來還可以這么排查，漲姿勢了 結果不對，但我看其中的某個圖猜到原因了 有的指標從來沒關注過，原來這么有用 極好的可解釋性 幫助用戶理解如何使用系統 用戶亦可貢獻經驗 用戶可抽取部分能力二開用戶心聲好處準確率 70%輔助配套Case反饋收集數據持久化準確性回溯機器人助手權限"a管理人工標注數據重放觸發現場保存生態集成監控大盤監控大盤報警卡片

12、報警卡片實例遷移實例遷移webhookwebhook飛書飛書未來展望交易極致報警信噪比宿主機直播中臺本地生活電商SREB服務開發開發A服務開發開發開發SRE中臺服務開發0101常常多個服務由一個團隊維護，相應的負責人要響應多個報警，且報警有各種類型，但背后可能是一個原因每個服務的報警都需要發給對應的接收人每個服務的報警都需要發給對應的接收人0202是我的問題還是別人的問題？浪費多個團隊人力同時都去排查，且根據團隊經驗不同有可能得出不同結論多個業務之間互相不知道是同一個問題多個業務之間互相不知道是同一個問題0303需要詳細分析各種指標得出結論，實際情況中由于問題常常疊加，排查難上加難根因服務不知

13、道自己的問題影響有多大根因服務不知道自己的問題影響有多大圍繞圍繞ProblemProblem構建報警構建報警 聚合相同根因的報警，根據接收人的關注點發送通知 根因是什么，是不是我導致的，故障傳播鏈是什么樣的 我受到了什么影響、我給別人造成了什么影響交易宿主機直播中臺本地生活電商SREA團隊B團隊SRE中臺服務開發B團隊LLM&Bot StudioLLM&Bot StudioBot Studio能做什么？插件：對接外部數據，例如自己開發的API知識庫：沉淀知識，通過各類數據源抓取工作流：自定義開發，編排插件、代碼處理等發布：發布成飛書、微信等bot，同時也可以發布API自動化編排：根據用戶輸入自

14、動調用插件、知識庫、工作流可觀測性&運維場景Case插件：對接RCA分析API知識庫：錄入指標規則、報警規則等工作流：對API做包裝，例如轉換時間格式、默認值填充發布：飛書bot、API提供產品調用運維診斷非常定制化，需要有編排能力通過Bot Studio使開發過程極大簡化，可充分利用大模型能力插件+工作流提供了足夠的拓展空間，讓各種可觀測和運維能力tools可以輕松集成Low/Mid/High Level API都可以被整合，按需調用自由編排AI Everywhere報警規則解讀報警規則解讀服務巡檢服務巡檢MoreMore您的服務在過去一周運行整體正常，但存在部分穩定性風險：1.CPU使用率在每日10:00 11：00較高，有過載風險查看詳情，請考慮擴容。擴容N臺可將CPU使用率降低至60%以下2.有2個下游調用錯誤率持續較高，但沒有影響服務可用性(是弱依賴)，查看詳情3.調用下游A的延遲偏高，且與服務自身延遲趨勢相符，如果想優化性能可關注該服務我的服務有什么需要關注的地方嗎統計服務過去一天的SLO達標情況大盤圖表太多找不到關注點？報警噪音過大該如何優化？服務性能熱點在哪里，該如何優化？我的日志是否有隱私泄露風險？自動化排障學習產品功能解讀日志內容各類數據分析生成圖表大盤通用知識問答自動化運維某個指標是啥含義？任何需要自動化、智能化的地方