基于大數(shù)據(jù)的APM平臺

1、 基于大數(shù)據(jù)的APM平臺APM其全稱是 Application Performance Management，翻譯過來就是應(yīng)用性能管理系統(tǒng)。根據(jù)Gartener2016年的定義，APM主要分為三個核心領(lǐng)域即 Digital Experience Monitoring(DEM)。主要是量化監(jiān)控人機交互的一些體驗。比如線上 APP 的崩潰率以及其所在網(wǎng)絡(luò)環(huán)境的速度，這些都可以量化為性能指標進行監(jiān)控，并且這些指標與人機交互的體驗關(guān)聯(lián)性很大。二，應(yīng)用程序發(fā)現(xiàn)、跟蹤和診斷。主要是針對服務(wù)端各個應(yīng)用組件之間的關(guān)系，檢測一些節(jié)點資源的占用情況，鉆取組件之間的拓撲并進行可視化。比如常見的對服務(wù)集群各個節(jié)點的

2、CPU /內(nèi)存占用情況的檢測及可視化監(jiān)控。三，應(yīng)用程序分析。這個更為高層，是利用機器學(xué)習(xí)、統(tǒng)計推斷等一些方法，發(fā)現(xiàn)服務(wù)端一些性能異常的來源，然后對一些服務(wù)器的性能指標進行監(jiān)控或者預(yù)測，實現(xiàn)智能化的。我們做的 APM更專注于基于第一個領(lǐng)域（DEM）。主要是面向移動設(shè)備做交互。那么，我們做這款產(chǎn)品的動機是什么？從公司層面上講，我們是做云存儲產(chǎn)品起家，其后逐層推出了富媒體（直播、點播云）服務(wù)、微服務(wù)化的容器云平臺、大數(shù)據(jù)平臺、人工智能平臺。所有產(chǎn)品之間都是遞進關(guān)系。而我們的 APM 產(chǎn)品其實是構(gòu)建在大數(shù)據(jù)平臺之上的 SaaS 產(chǎn)品。所以這個產(chǎn)品的衍生過程是合情合理的。從功能角度講，我們團隊做 APM

3、 的初衷是什么？主要有四個方面：第一，提高直播推流以及播放 SDK 的性能。第二，優(yōu)化直播節(jié)點質(zhì)量。第三，一些簡單的統(tǒng)計需求，比如日活等。第四，日志查詢的需求。我們在最初接到這幾個需求時，其實把它歸結(jié)分為兩類：一個是時序數(shù)據(jù)，即剛才前面提到的三個方面，最終都是可以歸結(jié)為幾張時序的折線圖；二是日志的檢索。什么是時序數(shù)據(jù)？簡單而言就是基于時間序列的數(shù)據(jù)點，并且在同一個數(shù)據(jù)序列中的各個數(shù)據(jù)必須有可比性。比如日常生活中的金融股票，可以看到每日的 K 線圖、月線圖，以及如圖 1 所示都是時序的數(shù)據(jù)以及CPU 內(nèi)存的使用量。圖 1為了應(yīng)對一開始的需求，我們做了一個如圖 2 所示的萌芽版，自己寫了一套程序，

4、在內(nèi)存里以及 Redis 中做一些數(shù)據(jù)的聚合及緩存，然后打點到時序數(shù)據(jù)庫和持久化到 MySQL，再通過 Grafana 進行展示，同時也將全量的日志導(dǎo)入到對象存儲。圖 2從圖 2 可以看到，由移動端的 APP 打點到網(wǎng)端，再依次通過 Flume、 Kafka，然后做一些聚合，將聚合出來的數(shù)據(jù)投放到一些數(shù)據(jù)庫中。另外將一些全量的數(shù)據(jù)導(dǎo)入到對象存儲，以供今后做一些離線分析，展示層最開始是用 Grafana 進行展示的。這樣一個版本基本上滿足了最初提出的業(yè)務(wù)需求。但在完成這些需求之后，我們團隊內(nèi)進行了一些思路的拓展，即能不能利用這些數(shù)據(jù)做對七牛直播云用戶有幫助的事情，更進一步地，能否做對非七牛直播云

5、用戶有益的事情，我們認真地進行了思考。之前我在直播業(yè)務(wù)部門的時候，其實經(jīng)常在一些用戶技術(shù)支持群里面收到客戶們的抱怨，歸結(jié)起來主要有以下幾個問題：第一是視頻打開的速度很慢，即首開時間時間較長；第二是視頻經(jīng)常緩沖，播放時很卡頓。第三是用戶出錯排障很慢，不知道是誰的問題，以及問題的出現(xiàn)時間。比如到底是主播網(wǎng)絡(luò)的問題，或者同一個房間里訪客本身WIFI 的問題導(dǎo)致的卡頓等。當(dāng)用戶碰到以上一些問題時，經(jīng)常一頭霧水地跑來咨詢我們的技術(shù)支持，排障的效率較低。圖 3于是我們提出了如圖 3 所示的視頻APM 目標，主要是針對直播領(lǐng)域，我們提出了四個主要功能：第一，多維度的數(shù)據(jù)聯(lián)合分析，比如 CDN、省份、服務(wù)器

6、IP、ISP 等，對服務(wù)器的性能指標進行分析第二，實時監(jiān)控數(shù)據(jù)第三，提供快速查詢定位，針對每個用戶的問題進行一些回溯第四，簡單的運營統(tǒng)計此外，我們橫向地進行了拓展，提出對移動 APM的設(shè)想功能：第一，APP線上崩潰報告，期望實現(xiàn)類似 Crashlytics 這類崩潰收集服務(wù)的初步功能。第二，網(wǎng)絡(luò)性能的監(jiān)測，App在某個時刻訪問自己的API很慢，想判定是自己的服務(wù)有問題還是所處的網(wǎng)絡(luò)存在故障，這個時候可以做一個網(wǎng)絡(luò)性能的測試。第三， APP頁面視圖響應(yīng)時間監(jiān)測。第四，對性能指標的多維度聯(lián)合分析。第五，自定義統(tǒng)計數(shù)據(jù)的分析。這個主要是偏向于運營的數(shù)據(jù)?；谖覀兊拿妊堪婕軜?gòu)我們遇到了什么問題？第一，

7、因為基本上所有的統(tǒng)計功能都是自己寫的，所以功能拓展上就遇到了麻煩。比如，每增加一個統(tǒng)計維度就需要修改很多代碼；常見的聚合函數(shù)，必須自己去實現(xiàn)，比如百分位這樣的函數(shù)；新增一個統(tǒng)計點可能造成代碼復(fù)用率降低。第二，水平拓展很困難，遇到計算資源瓶頸時難以拆分統(tǒng)計邏輯。圖 4于是我們做了一個如圖 3 所示的規(guī)劃版。首先也是移動 APP 打點到一個網(wǎng)關(guān)，然后分發(fā)到 Kafka ，一個是實時，一個是非實時，然后進行計算，同時會把全量的日志導(dǎo)出到ES中。我們自己會在展示層做一個 Portal，也可通過 SparkSQL 進行離線分析以及使用 Kibana 做日志檢索。這個規(guī)劃版有什么問題呢？我們APM 團隊剛

8、成立時，人員很少，并且大部分都是從端開發(fā)轉(zhuǎn)過來，只有一個全棧的老司機在帶路，這個版本基本上是要把整套大數(shù)據(jù)框架重新搭建一遍。此外，我們自己有對象存儲服務(wù)，但是如果要用到原生的 Spark進行數(shù)據(jù)導(dǎo)入，則要再搭一個HDFS 集群，成本很大。如果還要做一些基于時序數(shù)據(jù)庫的監(jiān)控，還需要搭 Grafana 套件。當(dāng)時我們的心情很糾結(jié)，如果自己去搭這樣一套集群，首先業(yè)務(wù)層面的功能開發(fā)會受到影響，其次可以預(yù)見今后我們對這一整個集群的調(diào)試、排障和初步運維工作是無比艱巨的。但是需求來了還是得繼續(xù)做下去，正在我們著手開始搭建一整個集群時，公司內(nèi)部推出了一個大數(shù)據(jù)平臺，代號Pandora。這是一套從存儲到數(shù)據(jù)化、

9、可視化、全棧的大數(shù)據(jù)的分析產(chǎn)品，它的核心其實是一個 workflow，用戶可以使用 Workflow 管理自己的數(shù)據(jù)流，無須有大數(shù)據(jù)背景，實現(xiàn)可視化數(shù)據(jù)流監(jiān)控，降低運維成本；并且集成諸多優(yōu)秀的社區(qū)組件，優(yōu)化并做到更好。我們評估了一下 Pandora 的架構(gòu)及功能點之后，發(fā)現(xiàn)無比契合我們的需求，于是立即終止了之前的一些集群架設(shè)工作，成為了 Pandora 的第一批用戶。圖 5如圖 5 所示是七牛大數(shù)據(jù)平臺Pandora 的架構(gòu)圖，其數(shù)據(jù)流的方向是自上而下的。上游是數(shù)據(jù)源的輸入，中游是一個實時或者離線計算工作流的引擎，下游是各類的數(shù)據(jù)導(dǎo)出服務(wù)。上游數(shù)據(jù)來源可分為多種，一個是RESTAPI，可以方便

10、地進行自定義打點；其次有一個功能強大的日志搜集工具LogKit，可以快速收集各類日志；然后還有一系列不同語言版本的SDK，比如GO/Python/PHP 甚至是 Android/iOS 等移動版，可快速用不同的姿勢接入推送數(shù)據(jù)。此外，Pandora還支持從七牛的對象存儲，以及如 CDN 日志存儲這樣一些離線數(shù)據(jù)源進行數(shù)據(jù)拉取。總而言之，所有數(shù)據(jù)來源就分為實時和離線兩部分，這兩部分數(shù)據(jù)都會被打入到各自的消息隊列中，而后用戶可在工作流引擎中分別創(chuàng)建兩種任務(wù)，即實時計算任務(wù)或離線計算任務(wù)。這種計算任務(wù)創(chuàng)建動作可以往復(fù)進行，如一個消息隊列中的數(shù)據(jù)可以經(jīng)過三四次甚至更多的清洗、轉(zhuǎn)換過程，直到最終在下游被

11、導(dǎo)出。Pandora 提供了幾種導(dǎo)出服務(wù)，一個是 Pandora 自研的時序數(shù)據(jù)庫TSDB，另外是日志檢索服務(wù)LogDB，還可以導(dǎo)出到七牛對象存儲進行永久化保存，另外還有其他一些 RDS以及HTTP 的回調(diào)導(dǎo)出方式。導(dǎo)出至對象存儲的離線數(shù)據(jù)還可以通過Pandora提供的另外一個單獨的組件叫做XSpark直接拉取，以進行離線分析。最外層還有一個 Report Studio 報表系統(tǒng)可從各類下游節(jié)點中導(dǎo)出數(shù)據(jù)進行報表展示。圖 7于是我們就根據(jù) Pandora 的架構(gòu)重新設(shè)計了如圖 7 所示的實施版架構(gòu)圖。首先也是由移動 App 通過 SDK 或 REST API打點到我們自己的網(wǎng)關(guān)，在進行初步的數(shù)

12、據(jù)清洗之后打點到 Pandora 的Pipeline，全量的原始數(shù)據(jù)可以直接導(dǎo)出到對象存儲和 LogDB，供持久化及快速檢索使用。各個統(tǒng)計功能點會經(jīng)過實時工作流的 Transform 計算任務(wù)之后，導(dǎo)出到LogDB或TSDB，然后通過 APM Portal 進行展示。此外我們在 TSDB 之上，建立了一個監(jiān)控告警系統(tǒng)。最后，我們通過 XSpark 定時分析導(dǎo)出到對象存儲的原始數(shù)據(jù)，做更多維度的關(guān)聯(lián)系分析及實現(xiàn)更高層次的數(shù)據(jù)分析邏輯。至此，我們團隊可以將主要精力集中在紅框的組件上，第一是移動 SDK的開發(fā)，第二是 Pandora 工作流一些核心計算邏輯的編寫，第三是數(shù)據(jù)展示的前端及監(jiān)控告警系統(tǒng)，

13、此外還有數(shù)據(jù)網(wǎng)關(guān)等的開發(fā)部署。最初的一系列大數(shù)據(jù)集群相關(guān)煩惱不復(fù)相伴。圖 8基于 Pandora ，我們核心邏輯變成什么樣子？由于Pandora 提供了可視化的任務(wù)編輯界面，所有的計算邏輯都可以呈現(xiàn)為樹狀的拓撲。先是上游的數(shù)據(jù)打點都會在工作流的數(shù)據(jù)源匯集，然后在數(shù)據(jù)源之上新建若干個計算任務(wù)，計算出實時的結(jié)果會自動被導(dǎo)出到單獨的消息隊列，最后再導(dǎo)出到時序數(shù)據(jù)庫。如圖 8（APM實時計算工作流）所示，各個消息隊列里面的數(shù)據(jù)想額外導(dǎo)出到對象存儲、日志檢索這些下游的節(jié)點都是可行的。圖中每個分支代表了一個APM 的統(tǒng)計計算功能。我們以直播的卡頓率這個性能指標為例，分享一下在 Workflow中的計算創(chuàng)建

14、過程。首先要定義卡頓率的測量方法。比如以一分鐘為頻率，我們觀察某段視頻在一分鐘之內(nèi)是否存在緩沖？有的話填 1，無緩沖填 0，上報之后，將這一列數(shù)據(jù)的值進行求和，然后除以該時間段內(nèi)的總上報數(shù)量，即為這段時間內(nèi)的卡頓率。我們可以通過運營商、服務(wù)器 IP、上報平臺等各種不同維度對卡頓率進行聚合。圖 9這個卡頓率反映在 workflow 是什么樣子？就是如圖 9 右側(cè)所示的一個 SQL 語句。SQL 中d的字段在數(shù)據(jù)源里都存在，如果沒有的話可以通過一些預(yù)計算先得出。比如V4 是代表一個卡頓率的列，sum 操作可得到緩沖總次數(shù)，count 則得到上報數(shù)據(jù)的總條數(shù)。sum(v4)/count(v4) 則可

15、得到平均卡頓率。在 workflow 的 pipeline 中進行如上聚合計算之后，將最終結(jié)果導(dǎo)出到時序數(shù)據(jù)庫中，就形成了一個實時的卡頓率變化情況的序列。圖 10最終卡頓率這個指標導(dǎo)出的結(jié)果是什么樣子？即如圖10所示的一張表。首先它是以時間作為基準，然后分為CDN 、國家、分辨率、運營商、實時觀看的總?cè)藬?shù)、移動平臺、省份等維度。我們最后可以通過這張表指定查詢到如 “福建電信 iPhone 用戶在某半小時之內(nèi)”的卡頓率情況。圖 11隨著產(chǎn)品的逐步完善，發(fā)展至今，整個 APM 的組件如圖 11 所示。一個是端的打點 SDK，現(xiàn)在已經(jīng)有iOS 和安卓版，一個接收打點的網(wǎng)關(guān)，一個展示系統(tǒng)展示頁面，以及

16、一個告警系統(tǒng)。底下深藍色四個方塊其實都是 Pandora 提供的組件，我們所有的運算邏輯目前都是放在實時數(shù)據(jù)流的處理引擎中，之后會根據(jù)需求建立一些離線數(shù)據(jù)的處理任務(wù)?，F(xiàn)階段在離線數(shù)據(jù)分析這塊，主要是利用 XSpark 對原始數(shù)據(jù)做定時統(tǒng)計，算出諸如應(yīng)用日活、地域分布等數(shù)據(jù)。這套系統(tǒng)的吞吐量取決于 Pandora 吞吐量的上限，現(xiàn)在 Pandora 每分鐘實時寫入的數(shù)據(jù)增量是數(shù)百個GB、數(shù)據(jù)條數(shù)達到數(shù)十億條；每天的數(shù)據(jù)增量是數(shù)百 TB，已經(jīng)經(jīng)受住了海量數(shù)據(jù)的驗證。因此依托 Pandora 這個平臺，我們不擔(dān)心吞吐量受到限制。我們自己的程序做一個水平拓展，比如網(wǎng)關(guān)在數(shù)據(jù)峰值過來時做什么樣的應(yīng)對，我

17、們在上面進行了一個容器化的處理，就是把這些組件都做成一個微服務(wù)，然后可以方便的對他們進行水平拓展。這樣一個服務(wù)高可用性以及數(shù)據(jù)吞吐能力等問題基本都解決了?；仡欁畛跆岢龅?APM 的目標（圖 3），這些目標我們是否都能夠通過 Pandora 這套大數(shù)據(jù)平臺，然后構(gòu)建出來并一一實現(xiàn)了？答案是肯定的。剛才講了，比如卡頓率的計算，我們放到時序數(shù)據(jù)庫里面，然后再通過前端拉取出來進行展示。圖 12大家看到如圖 12 所示的兩個圖，上圖是卡頓率，下圖是首開時間，然后根據(jù)它的移動設(shè)備平臺、運營商以及省份這三個維度進行聯(lián)合展示。它可以快速拉取，根據(jù)省份、運營商、平臺進行分析，得到圖 12。底下的首開時間也是一樣

18、的。圖 13如圖 13 所示是更多緯度的質(zhì)量的對比。比如通過移動端的上報，我們可以獲取到各個 CDN 廠商的數(shù)據(jù)。據(jù)此監(jiān)控各個廠商在某個時刻，或者在某些運營商、某些省份、某些設(shè)備平臺之下的表現(xiàn)。對于大規(guī)模直播服務(wù)提供廠商，他們可能會有多條備線，那么就可以根據(jù)我們所反饋的質(zhì)量指標來切換所要選擇的主線或者備線。比如福建一個廠商在某個時間段內(nèi)，他的主要流量都放在A廠商，如果卡頓率、請求錯誤率等大幅提高，就可以根據(jù)監(jiān)控數(shù)據(jù)進行實時的切換，比如切換到該時刻另外一個性能比較好的B廠商。圖 14圖 14 是從LogDB日志檢索出的一些數(shù)據(jù)。直播過程中，用戶經(jīng)常會和平臺提供方抱怨，說什么時候很卡，或者某個房間

19、的某些用戶說無法觀看。整個問題處理的流程中，用戶是先反饋到直播服務(wù)的提供商，然后再由直播服務(wù)的提供商向我們的技術(shù)支持進行反饋。由于中間多了這樣的一個流程，整個處理的速度就會降低。如今，使用用戶日志進行檢索，直播服務(wù)的提供商可以根據(jù)用戶的設(shè)備 ID或者用戶 IP 直接在日志檢索系統(tǒng)里進行查詢，然后回溯觀察當(dāng)時用戶所處的網(wǎng)絡(luò)情況以及同一時段該房間內(nèi)其他用戶的情況，可以先自行定位問題所在，提速排障過程。圖 15對于移動 APM，現(xiàn)在我們做了 APP 崩潰日志的收集。我們將App 端上報的日志存放到 LogDB以及對象存儲進行檢索及展示。另外我們支持自定義事件上報，這個對于簡單的運營統(tǒng)計需求，其實很有

20、幫助。它可以自己定義一些數(shù)據(jù)格式，通過 APM創(chuàng)建這樣一個數(shù)據(jù)Repo后，會在 Pandora 自動生成一個Pipeline 和Export。通過將上報的數(shù)據(jù)存放到LogDB 或?qū)ο蟠鎯?，以便后期報表展示或者進行二次數(shù)據(jù)分析。之前說到離線的日志分析，可以把全量的數(shù)據(jù)都存放到對象存儲，然后通過XSpark分析后通過 Zeppelin展示，用戶要自己使用的話，可能會有一點的使用門檻，自己可能需要熟悉一些 spark 的編程范式，可以對離線的日志進行統(tǒng)計。比如我們統(tǒng)計出了一個網(wǎng)絡(luò)的正常響應(yīng)的正常代碼的比重，還有用戶設(shè)備以及省份的分布圖。比如一天跑一次生成一個數(shù)據(jù)表，可以直接把報表導(dǎo)出，用來做一些運營

21、的分析，或者把這些數(shù)據(jù)二次導(dǎo)出到下游的存儲中。另外我們還做了一個 APM 的功能監(jiān)控告警，最開始是基于TSDB，即時序數(shù)據(jù)庫來構(gòu)建的。并且使用Kapacitor，一個實時聚合計算和告警引擎。但是我們遇到一個問題，時序數(shù)據(jù)庫更適用于做查詢，因為它是對查詢有做優(yōu)化，基本寫入一次，多次讀取，而高頻的聚合計算，是極耗 TSDB 所在節(jié)點的 CPU和內(nèi)存的。比如以IP 做GroupBy 的聚合運算，會造成查詢的超時。Kapacitor 是用程序員思維做出來的一款產(chǎn)品，它提供了自定義的 DSL 叫TICKScript，但學(xué)習(xí)成本高，普通終端用戶基本沒辦法自行創(chuàng)建一個告警任務(wù)。我們是如何處理這兩個問題的呢？

22、第一是可以利用 Grafana 為做告警，第二是基于 TSDB，利用 Kapacitor 進行實時聚合計算和告警，通過定制一個前端降低告警任務(wù)創(chuàng)建門檻。第三是基于七牛云這 Pipeline 為利用實時計算做復(fù)雜運算的告警。如果說計算任務(wù)非常大，或者運算邏輯復(fù)雜，其實可以做一個容器上的垂直擴容。然后通過 Pipeline 進行聚合計算之后再把這部分數(shù)據(jù)導(dǎo)出到 TSDB，最后再進行告警。圖 17左邊是我們做的定制化的告警界面，可以在一個時序數(shù)據(jù)庫的倉庫，選擇一個表，選擇要監(jiān)控的字段，中間可以設(shè)置一個閾值，比如五分鐘內(nèi)總體的卡頓率 20% 的情況下，底下是一個下游的告警分發(fā)，可以通過郵件等方式分發(fā)告警信息。右邊是基于 Workflow 做的實時流計算工作，我們把之前能放在 TSDB 中做的聚合計算任務(wù)放到 Pipeline