分布式链路监控报警机制的实现方案

刘林

（北京大学，北京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 中消费数据，根据系统的配置项对接口数据进行分析，在单位时间内符合报警阈值的，把接口相关信息发送给相关人的微信公众号上，相关人员能及时了解接口的信息，第一时间处理有异常的接口，大大提高了解决问题的效率，减少不必要的业务损失。