OPPO Monitor Platform：從應用請求到后端處理，自研解決服務化架構系統監控難題

眾所周知，系統監控一直是擁有復雜IT架構的企業所面臨的一個重要問題，而這也并不是每家企業都能夠輕松解決的技術挑戰。OPPO作為一家國際智 能終端設備及移動互聯網服務供應商，推出過多款外觀精細、功能可靠的智能手機產品，其品牌知名度也一直名列前茅。但實際上OPPO公司與其他快速發展的現 代企業一樣面臨著自己的IT挑戰，而更加鮮為人知的，則是其品牌背后同樣出色的IT團隊與信息化支持能力。

OPPO后端系統規模近幾年快速發展，系統重構以后采用了服務化的架構，各系統之間耦合降低，開發效率得到了很大的提升。然而在服務化帶來了好處 的同時，難于監控的問題也一并出現。由于服務之間調用關系錯綜復雜，接口出現問題，多個系統報錯，因此很難定位真正的故障源頭。整個請求調用鏈就像一個黑 盒子，無法跟蹤請求的整個調用路徑，發現性能瓶頸點。

為了解決這些問題，OPPO公司自行開發了一套監控系統，并結合第三方監控系統，形成了從App請求開始到后端處理過程的完整監控體系。OPPO 監控系統的簡稱為OMP(OPPO Monitor Platform)，歷時半年開發，分為兩期上線，現在已全面接入OPPO線上項目。

三大理由決定自主研發

之所以選擇自主研發監控系統，主要是考慮到三方面的原因：定制化需求、易用性、以及開發成本低。

首先，在對比之后發現現有的開源監控軟件無法滿足OPPO 的需求。對于監控系統來說最核心的一條需求，就是要能夠監控每個App請求的完整調用鏈，從App發起請求，到后端的負載均衡接入、API Server、微服務調用、緩存、消息隊列、數據庫訪問時間等。系統架構微服務化以后，服務跟蹤和服務調用鏈監控尤為重要，否則系統故障及性能瓶頸就很難 排查了。

為了打通用戶請求的完整調用鏈，需要在API框架、RPC框架、緩存操作、數據庫操作、隊列消費等代碼埋點，以及高性能處理和存儲系統，而目前的 開源軟件無法滿足需求，各大公司也因此才開發了自己的監控平臺。由于服務調用跟蹤功能跟開發框架深度關聯，各公司選用的框架并不相同，所以業界鮮有類似開 源的產品。

第二個原因是考慮到權限及一體化管理界面的需求。監控平臺不僅僅面向運維人員，開發人員、運營人員、測試人員也需要經常使用。例如根據監控平臺采 集到JVM Young GC/Full GC次數及時間、耗時Top 10線程堆棧等信息，經常查看監控平臺，開發、測試人員便可以評估代碼質量，排除隱患。

監控平臺面向用戶眾多，安全性及權限管理要求較高，同時需要一體化的管理界面，簡潔易用，而組合多個開源軟件，權限和管理便捷性很難滿足需求。

第三，監控系統的開發難度比較低。自行研發的監控平臺雖有千般好處，但是如果開發的難度太大，以至于無法持續的投入，那也是沒有意義的。基于 Sigar、kafka、Flume、HBase、Netty等技術，開發高性能、可伸縮的系統難度實際上并不大，需要投入的資源不需要很多。

六項目標內容實現線上應用全面監控

OMP的最終目標是提供一體化的監控系統，在同一套管理界面及權限體系之下，對線上應用系統進行多維度的監控。OMP現階段主要監控內容包括：主機性能指標監控、中間件性能指標監控、服務調用鏈實時監控、接口性能指標監控、日志實時監控、業務指標實時監控。

主機性能指標監控 方面的開源軟件非常多，比如Zabbix、Cacti等。主要采集主機的CPU負載、內存使用率、各網卡的上下行流量、各磁盤讀寫速率、各磁盤讀寫次數(IOPS)、各磁盤空間使用率等。

借助開源的Sigar庫，可以輕松采集主機信息，為了保證整個監控系統體驗的一致性，以及系統擴展性、穩定性的要求，我們沒有直接采用Zabbix等開源監控系統，而是自己開發Agent程序，部署在主機上采集信息。

Sigar（System Information Gatherer And Reporter），是一個開源的工具，提供了跨平臺的系統信息收集的API。核心由C語言實現的，可以被以下語言調用： C/C++、Java 、Perl 、NET C# 、Ruby 、Python 、PHP 、Erlang 。

Sigar可以收集的信息包括：

1) CPU信息，包括基本信息（vendor、model、mhz、cacheSize）和統計信息（user、sys、idle、nice、wait）

2)文件系統信息，包括Filesystem、Size、Used、Avail、Use%、Type

3)事件信息，類似Service Control Manager

4)內存信息，物理內存和交換內存的總數、使用數、剩余數；RAM的大小

5)網絡信息，包括網絡接口信息和網絡路由信息

6)進程信息，包括每個進程的內存、CPU占用數、狀態、參數、句柄

7)IO信息，包括IO的狀態，讀寫大小等

8)服務狀態信息

9)系統信息，包括操作系統版本，系統資源限制情況，系統運行時間以及負載，JAVA的版本信息等.

對于 中間件性能指標監控 ，目前根據業務使用中間件的情況來看，主要采集的中間件包括Nginx、MySQL、MongoDB、Redis、Memcached、JVM、 Kafka等。實現方式為部署獨立的采集服務器，通過中間件的java客戶端執行狀態查詢命令，解析出相應的性能指標，采集的部分指標如下表所示：

JVM	堆內存、永久代內存、老年代內存、線程CPU時間、線程堆棧、Yong GC、Full GC
MySQL	慢查詢、QPS、TPS、連接數、空間大小、表鎖、行鎖…
Redis	QPS、命中率、連接數、條目數、占用內存…
Memcached	QPS、命中率、占用內存、條目數、連接數…
Nginx	每秒請求數、連接數、keepalive連接數、持久連接利用率…

系統架構微服務化以后，服務調用錯綜復雜，出了問題或性能瓶頸，往往很難定位。所以 服務調用鏈實時監控 極為重要。

服務調用鏈監控是從一個App發起請求開始，分析各環節耗時及錯誤情況，包括負載均衡接入、API Server耗時、微服務調用耗時、緩存訪問耗時、數據庫訪問耗時、消息隊列處理耗時等，以及各環節的錯誤信息，便于跟蹤性能瓶頸及錯誤。

由于服務調用量巨大，同時便于管理員查看，監控系統不能存儲所有請求的調用鏈，主要存儲以下幾種請求：

1) 周期內最慢Top 1000請求：通過分析最慢的top 1000請求，可以判斷主要的性能瓶頸環節，比如數據庫訪問，或者調用第三方公司接口耗時過多。

2) 采樣請求：根據設置采樣比例，隨機選取部分請求，存儲請求的調用鏈。

3) 關鍵字：滿足關鍵字規則，存儲請求的調用鏈。

接口性能指標監控 ，主要監控接口的可用性和響應時間，由內部監控和外部監控兩部分組成。

1) 外部監控：外部監控由第三方公司負責，分為兩種，一是App中埋點，采集真實的業務請求性能指標。二是通過第三方公司部署在各地的采集點，主動監控接口在各地區的可用性和性能指標。

外部監控只能監控負載均衡器對外的最終接口服務地址的可用性和性能指標，如果要監控機房內部接口服務器，則需要機房內部部署第三方公司的Agent，這樣會帶來非常大安全風險，所以機房內部節點監控由內部監控完成。

2) 內部監控：內部監控采用OMP，監控負載均衡層后面的接口服務器的可用性和性能指標，及時發現異常節點，同時OMP根據異常原因，回調業務系統提供的恢復URL，嘗試恢復系統。

應用產生的日志分散在各應用服務器當中，由于安全管理非常嚴格，開發人員查看線上系統的日志非常不方便，同時日志內容匹配關鍵字需要發送告警通知相關人員。OMP將日志統一采集存儲到Elastic Search集群，實現日志檢索。OMP 日志實時監控 主要包括如下功能：

1) 日志實時在線查看：監控平臺可以實時查看日志文件的內容，效果類似tail –f 命令，同時屏蔽內容中的敏感信息（如密碼等）。

2) 日志全文檢索：全文檢索日志內容及高亮顯示

3) 關聯日志查看：查看日志產生時刻，日志所屬應用關聯組件和應用的日志

4) 關鍵字告警：用戶自己定義告警規則，符合匹配規則發送郵件和短信通知。

最后一項監控內容，是 業務指標實時監控 。除了監控系統主動采集的信息，還有業務層指標需要進行監控，如周期內訂單數量、第三方數據同步結果等。這些業務層的指標數據，由各業務系統負責采集，然后上報到監控系統，監控系統完成圖表展現及告警通知。

四大方面詳解OPM系統設計

首先來了解一下OPM的系統體系架構，如下圖所示：

(點擊放大圖像)

1) 中間件采集器：獨立部署多臺中間件性能指標采集器，通過Zookeeper實現故障轉移和任務分配。中間件采集器通過中間件的Java客戶端執行狀態查詢 命令，解析命令結果得到性能指標，由于狀態查詢得到的是最新累計值，采集器還負責計算周期內的均值、最大值、最小值等周期數據。中間件采集將采集到的數據 實時上報到接收器集群。

2) Agent監控代理：Agent監控代理部署在各服務器上，實時采集服務器的日志文件內容、CPU負載、內存使用率、網卡上下行流量、磁盤讀寫速率、磁盤 讀寫次數(IOPS)等。Agent采集到的數據實時上報到接收器集群，對于日志文件，為防止阻塞，上傳過程還需要做流控和丟棄策略。

3) 代碼埋點：代碼埋點主要采集服務調用鏈數據，通過封裝的緩存訪問層、數據庫訪問層、消息隊列訪問層，以及分布式服務框架(RPC)，獲得服務調用鏈耗時和錯誤信息。代碼埋點采集數據本機暫存，一分鐘合并上報一次到接收器集群。

4) 業務指標上報：業務指標由各業務系統負責采集，上報到接收器集群，上報周期和策略由各業務決定。

5) 接收器集群：OPPO自研的Data Flow組件，架構參考Flume，內部包括輸入、通道、輸出三部分，將接收到的數據輸出到Kafka隊列，后文將作詳細介紹。

6) Kafka消息隊列：由于監控數據允許丟失和重復消費，所以選擇高性能的Kafka做為消息隊列，緩沖消息處理。

7) 消息處理集群：消息處理集群訂閱Kafka主題，并行處理消息，處理告警規則、發送通知、存儲到HBase和ES。

8) Hbase：HBase存儲指標類數據，管理控制臺通過查詢HBase生成實時圖表。

9) Elastic Search：存儲日志內容，實現日志全文檢索。

(點擊放大圖像)

OPPO Data Flow 實現了數據流配置和管理，設計參考Flume，內部包括Source(輸入)、通道(Channel)、輸出(Sink)三部分，通道是一個隊列，具備緩沖數據的功能。之所以不采用Flume，主要考慮如下幾個原因：

1) Flume提供了良好的SourceàchannelàSink框架，但具體的Source、Sink需要自己去實現，以兼容oppo線上使用軟件版本，以及優化的參數配置。

2) Flume資源占用較大，不適合作為Agent部署在業務服務器上

3) Flume配置文件采用properties方式，不如xml配置直觀，更不能管理界面來配置

4) Flume管理界面不友好，不能查看輸入、輸出的實時流量圖表以及錯誤數量。

參考Flume 的設計思想，OPPO Data Flow是更易管理、配置更便捷的數據流工具。使用開源軟件，并不只是拿來就用這一種方式，學習其設計精華，從而進一步改進也是一種方式。

實際上，Agent監控代理、中間件采集器、接收器集群都是OPPO Data Flow組件，組合不同的Source和Sink。Source、Sink采用OSF服務框架開發，實現Agentà接收器的自動發現、負載均衡及故障轉移功能。

	輸入(Source)	通道(Channel)	輸出(Sink)
Agent監控代理	TailFileSource CPUSource MemorySource NetworkSource DiskSource	MemoryChannel	HttpSink
中間件采集器	NginxSource MySqlSource MongoDBSource RedisSource JvmSource MemcachedSource	MemoryChannel	HttpSink
接收器	HttpSource	FileChannel	KafkaSink

下圖為Data Flow內嵌管理界面，可以查看數據流量和錯誤信息，點擊名稱可以查看歷史流量。

(點擊放大圖像)

服務調用鏈 是監控的重點，核心的核心，為了打通服務調用鏈，OPPO開發了OSF（OPPO Service Framework）分布式服務框架，并對緩存、數據庫、消息隊列操作進行封裝埋點，目的是透明的實現服務調用跟蹤。實現方式如下：

1) 在App請求的入口生成唯一requestID，放入ThreadLocal

2) 緩存訪問層代碼埋點，從ThradLocal取出requestID，記錄緩存操作耗時

3) 數據庫訪問層代碼埋點，從ThradLocal取出requestID，記錄數據庫操作耗時

4) 調用其它微服務 (RPC)，將requestID傳遞到下一個微服務，微服務將接收到的requestID存入ThreadLocal，微服務內部的緩存、數據庫操作同樣記錄requestID操作耗時及錯誤信息。

5) 消息隊列寫入、消費代碼埋點，傳遞requestID，記錄消息消費耗時。

調用鏈數據龐大，無法全量存儲，監控系統將周期內最慢Top1000請求，采樣的部分請求以及符合關鍵字規則請求的服務調用鏈存儲在HBase中，管理控制臺可以快速分析查看。

分布式服務框架 是打通服務調用鏈的關鍵。開源的Dubbo應用廣泛，考慮到Dubbo版本較長時間沒有更新（有些Dubbo依賴庫已經跟開發生態的其他開源組件版本沖 突）、代碼量較大，而且服務治理能力較弱，很難完全掌控Dubbo的所有細節，而前文提到的OPPO自行開發的分布式服務框架OSF，代碼精簡滿足核心需 求，與監控系統深度集成。

OSF實現微服務RPC調用requestID的傳遞，記錄每個服務的調用耗時及錯誤信息，框架每分鐘匯總上報微服務調用耗時及錯誤信息到監控平臺。

OSF主要特性如下：

1) 支持RESTFul協議，容器支持Tomcat、Netty、JDK Http Server

2) 支持TCP二進制協議，容器支持Netty

3) 支持HTTP/2協議，測試中

4) 支持Protobuf、JProtobuf、Kryo、FST、MessagePack、Jackson、GSON、Hessian序列化實現

由消費方決定序列化方式

5) 注冊中心基于MySQL，同時提供推送、client拉取兩種方式，保證服務發現可靠性。

6) 注冊中心提供HTTP API，支持多語言、移動設備

7) 支持多數據中心部署

8) I/O線程與工作線程池分離，提供方忙時立即響應client重試其它節點

(點擊放大圖像)

從 可靠性及伸縮性 角度來看，主要包括以下內容：

1) 接收器：接收器的輸入采用OSF RESTFul協議開發，通過注冊中心，client能夠自動發現接收器節點的變化，通過client實現負載均衡及故障轉移，從而保證接收器的可靠性、伸縮性。

2) 中間件采集器：中間件采集器通過zookeeper選舉Master，由Mater來分配采集任務，采集器節點變化，選舉的Master重新分配采集任務，這樣任意增減采集器節點，都能重新平衡采集任務，保證采集任務的持續可靠運行。

3) 消息處理：由于多個節點均分同一個kafka topic的消息并且實現高可用比較困難，OMP預先定義了若干個kafka topic，消息處理節點通過zookeeper選舉Master，由Master來分配Topic數量，當某個消息處理節點宕機，該節點負責的 topic轉移到其他節點繼續處理。

4) Agent監控代理：服務器上shell腳本定期檢查Agent狀態，不可用時自動重啟Agent，同時OMP維持與Agent之間的心跳消息，超過3個周期沒有收到Agent的心跳消息，OMP發送告警通知相關人員處理。

從OPPO的自主研發監控系統的實踐案例來看，一切應當從業務需求出發，目的是解決業務遇到的問題。面對開源軟件的選擇，要有所“為”，有所“不 為”。業界有很多成熟的開源軟件，也有一些比較大膽的設計思想可供借鑒，但開源軟件并不是拿過來就能用好這么簡單的，選擇的原則可“管”可“控”。一個開 源軟件，如果不能“掌控”，不夠簡單，那就不如不用，自己用土辦法也許反而會更好，出了問題至少還能想想應急的辦法。同樣要具備“管理”性，不然黑盒子般 運行，心里沒底，那作為IT管理人員來說就睡不安心了。

作者簡介

羅代均 ，現就職于OPPO基礎技術團隊，從事監控平臺、服務框架等基礎技術開發工作。2005年畢業后，先后主導過通信、移動金融、應用商店、PaaS平臺等領域多個產品系統設計開發、項目管理工作。