分布式鏈路監控報警機制的實現方案

劉林

（北京大學，北京100871）

0 引言

近些年，微服務架構[1]一詞在軟件領域廣泛傳播，它是一種新的軟件架構風格，越來越多的項目采用了這種軟件風格。它提倡將單一應用程序劃分成一組小的服務，服務之間相互協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務和服務之間采用輕量級的通信機制相互溝通（通常是基于HTTP 的Restful API）。每個服務都圍繞著具體的業務進行構建，并且能夠被獨立的部署到生產環境中。

微服務架構將整個應用拆分成多個分散的服務，一次API 請求往往需要涉及多個服務，服務之間的調用關系越來越復雜，發生故障時定位問題越來越困難。此時，亟需一款合適的分布式鏈路監控系統來解決這些問題。通過對目前各個APM（Application Performance Management）[2]功能對比[3]，確定采用適合Java語言的Pinpoint[4]分布式鏈路監控系統。

在對Pinpoint 深入了解中，發現它的報警機制偏弱，在應用出現異常時不能及時的通知相關人員。在本文中，對Pinpoint 報警機制進行重新設計，采用微信公眾號報警通知。

1 Pinpoint監控系統

1.1 Pinpoint組件

Pinpoint 分布式鏈路監控系統由三個主要組件構成。

（1）Pinpoint Agent 端，依附在Java 應用程序上，負責從應用上采集各種指標數據并傳輸給Collector 端。它利用Java Agent 機制，采用修改應用字節碼的方式將邏輯植入到相關的類中，對原有的代碼無任何侵入。

（2）Pinpoint Collector 端，接受agent 端傳輸過來的采集數據，將這些數據分析、整理和加工，把處理好的數據存儲到HBase 數據庫中，通過Web 界面來查看各種監控數據。

（3）Pinpoint Web，部署在Web 容器中，屬于展示端，在Web 頁面上顯示各種統計數據，方便相關人員進行查看和排查問題。

1.2 現狀分析

目前Pinpoint 監控系統中報警通知機制比較簡單，以應用為基本單位，統計該應用下接口的各種監控指標，如接口超時數量、接口報錯數量等。定時程序按固定時間段去統計這些指標，觸發閾值后發送郵件給指定人。以應用為統計維度，范圍太大，粒度不夠細。定時統計時效性也不夠，延遲厲害。

2 優化方案

通常，應用程序對外提供統一的API 接口來為其他應用服務。本文中采用以API 接口為維度來統計該接口的異常數量、超時數量等指標，實時地把異常信息發送到相關人員的微信上，該優化方案涉及三個部分。

（1）在Collector 端，對各個應用整理完成的接口指標數據以JSON 數據格式存入RabbitMQ[5]中，各個字段意義和格式如下：

（2）由于監控系統接入的應用數量眾多，接口調用的請求量很高，需要分析的接口數據量非常巨大，所以這里采用RabbitMQ 消息隊列來傳遞數據，主要起到異步、解耦的作用。

（3）日志分析平臺，從系統中讀取配置文件，配置文件里定義了各個接口的超時時間，異常數量，發送微信聯系人等項，子配置項覆蓋默認配置項，如接口沒有定義配置項的按默認配置計算，系統配置和說明如下：

日志分析平臺從RabbitMQ 中消費數據，以接口為維度進行分組，結合配置文件分析在單位時間內是否接口觸發報警閾值，如符合條件發送報警信息。整體架構如圖1 所示。

圖1

3 結語

在開源分布式鏈路追蹤Pinpoint 的基礎上，Collector端把處理完成的接口數據發送到RabbitMQ 中，日志報警平臺從RabbitMQ 中消費數據，根據系統的配置項對接口數據進行分析，在單位時間內符合報警閾值的，把接口相關信息發送給相關人的微信公眾號上，相關人員能及時了解接口的信息，第一時間處理有異常的接口，大大提高了解決問題的效率，減少不必要的業務損失。