案例｜服务化架构系统监控难题解决方案

原文网址连接：http://url.cn/kVjUVO

众所周知，系统监控一直是拥有复杂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能够收集的信息包括：

• CPU信息，包括基本信息（vendor、model、mhz、cacheSize）和统计信息（user、sys、idle、nice、wait）；

• 文件系统信息，包括Filesystem、Size、Used、Avail、Use%、Type；

• 事件信息，相似Service Control Manager；

• 内存信息，物理内存和交换内存的总数、使用数、剩余数；RAM的大小；

• 网络信息，包括网络接口信息和网络路由信息；

• 进程信息，包括每一个进程的内存、CPU占用数、状态、参数、句柄；

• IO信息，包括IO的状态，读写大小等；

• 服务状态信息；

• 系统信息，包括操做系统版本，系统资源限制状况，系统运行时间以及负载，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耗时、微服务调用耗时、缓存访问耗时、数据库访问耗时、消息队列处理耗时等，以及各环节的错误信息，便于跟踪性能瓶颈及错误。

因为服务调用量巨大，同时便于管理员查看，监控系统不能存储全部请求的调用链，主要存储如下几种请求：

• 周期内最慢Top 1000请求：经过分析最慢的top 1000请求，能够判断主要的性能瓶颈环节，好比数据库访问，或者调用第三方公司接口耗时过多。

• 采样请求：根据设置采样比例，随机选取部分请求，存储请求的调用链。

• 关键字：知足关键字规则，存储请求的调用链。
  

接口性能指标监控，主要监控接口的可用性和响应时间，由内部监控和外部监控两部分组成：

• 外部监控：外部监控由第三方公司负责，分为两种，一是App中埋点，采集真实的业务请求性能指标。二是经过第三方公司部署在各地的采集点，主动监控接口在各地区的可用性和性能指标。外部监控只能监控负载均衡器对外的最终接口服务地址的可用性和性能指标，若是要监控机房内部接口服务器，则须要机房内部部署第三方公司的Agent，这样会带来很是大安全风险，因此机房内部节点监控由内部监控完成。

• 内部监控：内部监控采用OMP，监控负载均衡层后面的接口服务器的可用性和性能指标，及时发现异常节点，同时OMP根据异常缘由，回调业务系统提供的恢复URL，尝试恢复系统。

应用产生的日志分散在各应用服务器当中，因为安全管理很是严格，开发人员查看线上系统的日志很是不方便，同时日志内容匹配关键字须要发送告警通知相关人员。OMP将日志统一采集存储到Elastic Search集群，实现日志检索。OMP日志实时监控主要包括以下功能：

• 日志实时在线查看：监控平台能够实时查看日志文件的内容，效果相似tail –f 命令，同时屏蔽内容中的敏感信息（如密码等）；

• 日志全文检索：全文检索日志内容及高亮显示；

• 关联日志查看：查看日志产生时刻，日志所属应用关联组件和应用的日志；

• 关键字告警：用户本身定义告警规则，符合匹配规则发送邮件和短信通知。
  

最后一项监控内容，是业务指标实时监控。除了监控系统主动采集的信息，还有业务层指标须要进行监控，如周期内订单数量、第三方数据同步结果等。这些业务层的指标数据，由各业务系统负责采集，而后上报到监控系统，监控系统完成图表展示及告警通知。

四大方面详解OPM系统设计

首先来了解一下OPM的系统体系架构，以下图所示：

• 中间件采集器：独立部署多台中间件性能指标采集器，经过Zookeeper实现故障转移和任务分配。中间件采集器经过中间件的Java客户端执行状态查询命令，解析命令结果获得性能指标，因为状态查询获得的是最新累计值，采集器还负责计算周期内的均值、最大值、最小值等周期数据。中间件采集将采集到的数据实时上报到接收器集群。

• Agent监控代理：Agent监控代理部署在各服务器上，实时采集服务器的日志文件内容、CPU负载、内存使用率、网卡上下行流量、磁盘读写速率、磁盘读写次数(IOPS)等。Agent采集到的数据实时上报到接收器集群，对于日志文件，为防止阻塞，上传过程还须要作流控和丢弃策略。

• 代码埋点：代码埋点主要采集服务调用链数据，经过封装的缓存访问层、数据库访问层、消息队列访问层，以及分布式服务框架(RPC)，得到服务调用链耗时和错误信息。代码埋点采集数据本机暂存，一分钟合并上报一次到接收器集群。

• 业务指标上报：业务指标由各业务系统负责采集，上报到接收器集群，上报周期和策略由各业务决定。

• 接收器集群：OPPO自研的Data Flow组件，架构参考Flume，内部包括输入、通道、输出三部分，将接收到的数据输出到Kafka队列，后文将做详细介绍。

• Kafka消息队列：因为监控数据容许丢失和重复消费，因此选择高性能的Kafka作为消息队列，缓冲消息处理。

• 消息处理集群：消息处理集群订阅Kafka主题，并行处理消息，处理告警规则、发送通知、存储到HBase和ES。

• Hbase：HBase存储指标类数据，管理控制台经过查询HBase生成实时图表。

• Elastic Search：存储日志内容，实现日志全文检索。

OPPO Data Flow实现了数据流配置和管理，设计参考Flume，内部包括Source(输入)、通道(Channel)、输出(Sink)三部分，通道是一个队列，具有缓冲数据的功能。之因此不采用Flume，主要考虑以下几个缘由：

• Flume提供了良好的SourceàchannelàSink框架，但具体的Source、Sink须要本身去实现，以兼容oppo线上使用软件版本，以及优化的参数配置。

• Flume资源占用较大，不适合做为Agent部署在业务服务器

• Flume配置文件采用properties方式，不如xml配置直观，更不能管理界面来配置。

• 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）分布式服务框架，并对缓存、数据库、消息队列操做进行封装埋点，目的是透明的实现服务调用跟踪。实现方式以下：

• 在App请求的入口生成惟一requestID，放入ThreadLocal

• 缓存访问层代码埋点，从ThradLocal取出requestID，记录缓存操做耗时

• 数据库访问层代码埋点，从ThradLocal取出requestID，记录数据库操做耗时

• 调用其它微服务 (RPC)，将requestID传递到下一个微服务，微服务将接收到的requestID存入ThreadLocal，微服务内部的缓存、数据库操做一样记录requestID操做耗时及错误信息。

• 消息队列写入、消费代码埋点，传递requestID，记录消息消费耗时。

调用链数据庞大，没法全量存储，监控系统将周期内最慢Top1000请求，采样的部分请求以及符合关键字规则请求的服务调用链存储在HBase中，管理控制台能够快速分析查看。

分布式服务框架是打通服务调用链的关键。开源的Dubbo应用普遍，考虑到Dubbo版本较长时间没有更新（有些Dubbo依赖库已经跟开发生态的其余开源组件版本冲突）、代码量较大，并且服务治理能力较弱，很难彻底掌控Dubbo的全部细节，而前文提到的OPPO自行开发的分布式服务框架OSF，代码精简知足核心需求，与监控系统深度集成。

OSF实现微服务RPC调用requestID的传递，记录每一个服务的调用耗时及错误信息，框架每分钟汇总上报微服务调用耗时及错误信息到监控平台。

OSF主要特性以下：

• 支持RESTFul协议，容器支持Tomcat、Netty、JDK Http Server；

• 支持TCP二进制协议，容器支持Netty；

• 支持HTTP/2协议，测试中；

• 支持Protobuf、JProtobuf、Kryo、FST、MessagePack、Jackson、GSON、Hessian序列化实现。

由消费方决定序列化方式：

• 注册中心基于MySQL，同时提供推送、client拉取两种方式，保证服务发现可靠性；

• 注册中心提供HTTP API，支持多语言、移动设备；

• 支持多数据中心部署；

• I/O线程与工做线程池分离，提供方忙时当即响应client重试其它节点。

从可靠性及伸缩性角度来看，主要包括如下内容：

• 接收器：接收器的输入采用OSF RESTFul协议开发，经过注册中心，client可以自动发现接收器节点的变化，经过client实现负载均衡及故障转移，从而保证接收器的可靠性、伸缩性。

• 中间件采集器：中间件采集器经过zookeeper选举Master，由Mater来分配采集任务，采集器节点变化，选举的Master从新分配采集任务，这样任意增减采集器节点，都能从新平衡采集任务，保证采集任务的持续可靠运行。

• 消息处理：因为多个节点均分同一个kafka topic的消息而且实现高可用比较困难，OMP预先定义了若干个kafka topic，消息处理节点经过zookeeper选举Master，由Master来分配Topic数量，当某个消息处理节点宕机，该节点负责的topic转移到其余节点继续处理。

• Agent监控代理：服务器上shell脚本按期检查Agent状态，不可用时自动重启Agent，同时OMP维持与Agent之间的心跳消息，超过3个周期没有收到Agent的心跳消息，OMP发送告警通知相关人员处理。

从OPPO的自主研发监控系统的实践案例来看，一切应当从业务需求出发，目的是解决业务遇到的问题。面对开源软件的选择，要有所“为”，有所“不为”。业界有不少成熟的开源软件，也有一些比较大胆的设计思想可供借鉴，但开源软件并非拿过来就能用好这么简单的，选择的原则可“管”可“控”。一个开源软件，若是不能“掌控”，不够简单，那就不如不用，本身用土办法也许反而会更好，出了问题至少还能想一想应急的办法。一样要具有“管理”性，否则黑盒子般运行，内心没底，那做为IT管理人员来讲就睡不安心了。

本文做者罗代均 ，现就任于OPPO基础技术团队，从事监控平台、服务框架等基础技术开发工做。2005年毕业后，前后主导过通讯、移动金融、应用商店、PaaS平台等领域多个产品系统设计开发、项目管理工做。本文由做者受权由InfoQ公众平台独家首发。