云闪付指标监控实践

云闪付从2018年开始进行微服务改造，服务越拆越细，调用关系越来越复杂，涉及节点也越来越多，公司内部的监控手段已经无法便捷地支撑云闪付多样的监控需求，我们必须要寻找一种适用场景丰富、易上手、展现效果好的监控手段。

我们有基于ELK的日志监控，虽然能够方便的查询不同节点的日志排查问题，但是云闪付每日产生的日志量非常庞大，导致查询较慢，使用体验不佳；我们有Netparse网络流量监控工具，但是只能监控http入口流量情况，对微服务之间的调用情况无能为力；我们有DBAAS 平台，可以监控如：MYSQL、Redis等中间件的运行情况，但是组件类型的覆盖面不够；对于一些业务数据的展示，我们采用脚本查库的方式，虽然易上手，但是不够优雅，且脚本的维护也有不小的成本。

为了解决上述的诸多问题，我们基于Prometheus构建了云闪付的指标监控平台，提供统一的监控数据采集、存储、展示、分析、告警功能，便于开发和运维查看各种维度的监控数据，主要包括：业务监控（自埋点）、组件监控、日志监控、接口监控和组件访问监控五个维度。

— 1 —

平台架构 

Prometheus是一套开源的系统监控和告警框架，灵感来自Google的Borgmon监控系统。2016年，Prometheus加入云原生计算基金会，以其强大的功能和易上手的特性，迅速成为云原生指标监控领域的事实标准。

Prometheus具有如下特点：

1、存储时序数据

2、开箱即用，自带时序数据库，同时也支持其他数据库，比如：influxdb等等

3、提供PromSQL，支持多维数据的复杂查询

4、基于HTTP的拉模式采集时间序列数据，也支持通过Pushgateway变成推模式

5、展现形式丰富，支持对接Grafana

根据云闪付的特点，我们对Prometheus进行了本地化改造，架构如下图所示：

分为指标来源、指标存储、指标可视化和指标告警四个部分。

1.1指标来源

我们将采集的指标分为五个维度，分别是：业务监控数据、接口监控数据、组件监控数据、日志监控数据和组件访问监控数据。

1.1.1业务监控数据

业务监控数据指面向业务的监控数据，比如：交易数量、活动剩余名额、交易量同比/环比等等，针对此类数据，我们仅规范监控指标的名称，如：累积量类型的监控指标名称必须以”_total”结尾，开发使用Prometheus SDK完成埋点。

1.1.2. 接口监控数据

接口监控数据指HTTP接口和RPC服务接口的监控数据，包括：成功率、响应时间和TPS。开发仅需引入二次封装的SDK包，即可实现所有服务接口的监控，无任何代码改动。

1.1.3. 组件监控数据

除了社区提供的各类组件的Exporter，如：kafka_exporter、zookeeper_exporter等等，公司自研的组件，如：数据同步组件Moray，我们也会开发Exporter获取运行数据。

1.1.4. 日志监控数据

由于我们是指标监控平台，针对日志仅提供日志量的监控，包括：

1、不同日志级别日志量监控，包括：TRACE、DEBUG、INFO、WARN、ERROR、FATA

2、指定关键字日志量监控

3、不同异常类日志量监控

开发仅需引入二次封装的SDK包，即可日志量监控，无任何代码改动。

1.1.5. 组件访问监控数据

同一条SQL在不同数据量、不同系统压力条件下，执行的耗时不同，通过日志记录耗时，开销大，依靠数据库慢日志又不能反映不同场景的执行情况，因此我们实现了Mybatis插件来记录不同类型SQL的执行耗时，方便开发进行性能评估。此外，我们还自定义注解实现了内部方法耗时的监控。

1.2指标存储

我们按系统维度申请部署Prometheus，当前采用本地存储的方案。后续资源无法扩展，可利用Prometheus的远程读写功能写入第三方时序数据库，如：M3DB、TDEngines等。

1.3指标可视化

我们结合Grafana使用，通过编写PromQL实现各类数据的展示。对于PromQL无法满足的情况，比如：按天生成监控日报，我们利用Prometheus提供的HTTP API编写Python脚本实现。

1.4指标告警

我们利用Alertmanager的Webhook功能对接公司内部告警平台，实现通过内部通讯软件U聊通知开发和运维同事。如下图所示：

— 2 —

平台用途 

2.1各类监控日报

➤  技术类日报：接口成功率、响应时间和昨日最大TPS

➤  业务类日报

➤  重大活动类日报

2.2监控大盘

搭建云闪付指标监控平台带来的最大收益是让我们能够时刻掌握系统运行的情况，并给系统性能指标制定提供了参考依据。

— 3 —

展望 

完整的监控体系包括基础设施监控，服务监控，业务监控等维度，不同的维度间应该相互联动互换信息形成真正的一体化监控。

更进一步，监控体系按照来源可以分为：Metrics、Logging和Tracing。银联在这三方面都有所涉及，比如：Metrics监控有Prometheus，AIM，Logging监控有ULSP，Tracing监控有UPTrace。这三种类型都各有优势，如下图所示：

基于上述的比较，可以预期将来会以Metrics作为告警来源，再去关联Tracing和Logging。当Metrics出现告警时，通过查找Logging和Tracing去定位问题，分析问题，这样既能保证告警的有效性，又能降低资源使用。