Prometheus在B端门店回收系统中的应用-51CTO.COM

1 为什么要使用Prometheus

1.1 背景

回收系统本质做的是服务平台。对外交互多，例如与渠道商、回收商的接口交互。因此与回收商接口的交互情况需要记录。
回收系统的内部是通过大量MQ异步驱动运行的，复杂性很高。某一个MQ执行异常很容易引起流程中断。因此记录MQ的消费情况也很重要。

1.2 当前系统存在的问题

主动发现问题的能力不足。历史接入了一些企微通知，但数量不足，场景少，覆盖面窄。针对一些发生率不是很高的场景，很容易漏掉。系统需要实时掌握运行状态，减少问题响应时间。
单纯使用企微通知报警，虽然也可以对关键场景进行提示，但维度单一，缺少图形不直观。报警之前不成体系，没有联系，不能直观的展示业务的执行情况。并且报警数量稍微一多，容易引起消息轰炸，丢失关键信息。
排查问题时缺少辅助工具，耗时长。

2 Prometheus简介

图片

2.1 核心组成部分

2.1.1 Prometheus server

核心组件，负责抓取、存储和查询指标数据，提供API以供访问。
Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。
内置的UI界面，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。

2.1.2 Exporter

Prometheus插件或独立组件，负责抓取指定服务或系统的性能指标数据。
Prometheus原理是通过 HTTP 协议周期性抓取被监控组件的状态，输出这些被监控的组件的 Http 接口为 Exporter。
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，将其公开为HTTP端点或指定的格式。
Prometheus server通过轮询或指定的抓取器从Exporter提供的Endpoint端点中提取数据。

2.1.3 Alertmanager

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，就会产生一条告警。
Prometheus告警管理器组件，负责管理告警规则、通知和报警策略的设置，提供第一类和第二类警报的分类管理服务PushGateway。
Prometheus数据采集基于Pull模型进行设计，在网络环境必须要让Prometheus Server能够直接与Exporter进行通信。
当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。
通过PushGateway将内部网络的监控数据主动Push到Gateway当中。
Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据

2.1.4 Service Discovery

服务发现功能，动态发现待监控的Target，完成监控配置的重要组件。

2.2 四种上报类型

2.2.1 Counter

递增的整数型指标，用于表示累计数量。只能增加，不能减少，一般用于统计请求次数、错误次数等场景。

2.2.2 Gauge

是一个可变的数值指标，用于表示某个瞬时值。可变大变小，一般用于表示当前连接数、温度等持续变化指标。

2.2.3 Histogram

可以将事件按照不同的桶进行分组，用来观察指标在各个不同区间范围的分布情况，一般用于分析请求延迟，操作响应时间。

2.2.4 Summary

与Histogram类似，区别在于Histogram存储的是数据，Summary直接存储的就是百分位，本质上并没有什么区别，通过Histogram也可以计算出百分位。

3 Prometheus如何保障业务系统的稳定运行

3.1 监控核心业务数据保证系统稳定性

3.1.1 监控回收订单的数量

图片

通过统计监控某段时间的回收单的创建数量，可以做以下几个方面的数据分析和预警：

分析需求的有效性与重要性。以接入 9906001 渠道为例，投入人力与时间资源多，订单却极少，未体现价值，若长期如此，该需求低效或无效。而 9902001 渠道订单量很多，说明渠道很重要，进行相关业务开发时需确保升级可靠性。
进行数据对比，9902001 渠道持续拥有高订单量，与订单量极低的渠道形成鲜明对比，为业务和产品指明不同运营策略方向。
设立订单突增或掉零预警机制。如在双 11、618 大促时提前介入监控系统稳定性。但是对于渠道商回收业务，因外部活动或新机型发售不可预知，订单突增时预警，技术介入查看系统状态确保稳定；渠道长时间无订单也预警排查系统问题。

3.1.2 监控回收订单创建失败

图片

通过监控关键业务流程失败：

可快速发现线上问题并及时排查解决，避免影响用户体验与业务运行，不再像以往等业务反馈才行动。
业务需求上线时观察对核心业务的影响，若回收单创建大量失败，可能上线有问题，需排查是否回滚。

3.2 提高故障响应和处理效率，保证系统稳定性

3.2.1 监控调用回收商接口异常

图片

业务系统与外部系统交互的过程中，失败的原因是多种多样的。有可能是网络问题，外部接口的问题或者业务系统代码逻辑的问题。

监控回收商接口异常及其原因，可快速定位问题根源。若因外部系统所致，及时反馈给外部系统；若为业务系统代码问题，可依据简要问题信息在日志中搜索报错，借助详细日志定位解决问题。

注：在进行指标监控时，防止监控的指标的tag过多，转转这边限制为500。

例如在监控调用回收商接口异常原因指标时，将异常进行归类，从而保证了tag不会过多。

//调用外部系统方法
public <T, R> R execute(String priceSource, String actionCode, T bodyParam, Class<R> respsonseDataClazz) {
        try {
            //.....读取配置，组装请求url等逻辑
            try {
              //......发起请求
            } catch (ResourceAccessException e) {
                //捕获超时异常，抛出重试异常
                log.error("报价方接口请求超时或异常，将重试,exception:{}", ExceptionUtils.getStackTrace(e));
                throw new RetryException("报价方接口请求超时或异常", e);
            }

            if (HttpStatus.OK.value() != responseEntity.getStatusCode().value()) {
                log.info("priceSourceApi接口httpCode非200,httpCode:{}", responseEntity.getStatusCode().value());
                throw new RetryException("priceSourceApi调用失败: " + responseEntity.getStatusCode().value());
            }

            BaseResp baseResp = responseEntity.getBody();
            if (Objects.isNull(baseResp)) {
                throw new PriceSourceApiException("priceSourceApi返回值为空");
            }
           //....
            String respCode = baseResp.getCode();
            //根据code判断是否重试
            if (!priceSourceApiAction.getSuccessCode().equals(respCode)) {
                throw new RetryException("priceSourceApi调用失败: " + baseResp.getMsg());
            }
            //.......
            return o;
        } catch (Exception e) {
            log.error("execute Api PriceSource fail for priceSource: {}, action: {}", priceSource, actionCode, 
            throw new HunterErrorException("调用回收商接口失败",e);
        } finally {
            // 记录全部请求数
            long usingTime = System.currentTimeMillis() - startTime;
            String metricsName = PrometheusMetricsEnum.OUTER_RECYCLER_HANDLE_INTER2_TOTAL.getName() + priceSource;
            MetricsMonitor.recordOne(metricsName, actionCode, usingTime);
        }
    }

3.3 不同监控指标，监控力度不同

当我们监控不同指标时，需要根据指标的重要性，设置不同的报警规则。

例如创建回收单失败和调用回收商接口报错的指标的重要性不同。对于创建回收单业务来说，影响的是外部渠道调用接口可靠性的，不能有过多报错，且接口是否重试也是由外部渠道控制的，因此我们要保证接口的可靠性，有问题要及时处理解决。但是对于调用回收商的接口，业务系统有重试机制，调用失败会自行重试，且对于外部渠道是无感知的，不影响外部渠道调用业务接口的可靠性。所以对于创建回收单失败指标来说，我们报警监控配置是一分钟内有一个失败就会发送报警通知。但是对于调用回收商接口报错的指标，我们报警配置是十分钟内有五次错误才会发送报警通知。

3.4 监控远程调用QPS和耗时保证系统稳定性

3.4.1 监控远程调用耗时为技术方案提供依据

图片

SCF框架是转转自己开发的远程调用框架，类似于Dubbo。

设计需求实现时需调用不同业务系统接口，可串行或并行调用。比如在做创建回收单业务时，需要读取用户信息，读取渠道信息，还有相关的配置信息。我们通过提前查看调用具体接口的大概耗时，预估到了串行调用这些接口会有超时的风险，因此在读取这些配置信息时，我们采用异步调用，减少创建回收单业务接口的耗时，保证接口不会超时。

3.4.2 监控远程调用QPS

图片

在远程调用中通常用限流防业务系统因过多调用崩溃。但是若都是正常流量，则应考虑增机、调整限流规则确保其他业务系统稳定。所以这时监控的作用就体现出来了，当QPS达到了限流的百分之八十，发送一个告警，及时通知技术去观察判断是不是有别的业务系统，因为业务突增，导致调用增加，进而及时调整限流规则，来满足别的业务系统的调用。

3.5 监控其它基础依赖指标保证系统的稳定性

3.5.1 监控FGC次数

图片

通过监控FGC次数，如果频繁发生FGC，说明系统现在处于不正常的状态：1.有可能存在内存泄露。2.有可能JVM内存配置的过小，不满足业务系统需要。通过这方面的监控及时排查FGC频繁发生的原因，减少FGC发生的次数也可以提升系统的稳定性。

3.5.2 监控数据库连接池

图片

通过监控数据库连接池相关的指标：

通过观察事务提交耗时指标，可以清晰的观察到是否存在大量打大事务，影响数据库连接池的连接和释放。
通过观察事务回滚次数指标，可以判断系统中是否存在大量的业务异常，导致事务回滚。
通过观察事务提交次数，可以为连接池配置连接数量提供一定的依赖数据。

3.5.3 监控容器指标

图片

通过监控容器相关指标可以防止业务系统因为基础系统原因导致不稳定。

例如监控宿主机磁盘容量指标可以防止因磁盘不足，导致业务系统无法读写磁盘，比如日志无法写入等问题。

4 总结

图片

转转除了上面的一些举例还有很多方向的监控：虚拟机指标监控、线程池监控、MQ监控、Codis连接池监控等等。

因为业务系统最终稳定性就是靠异常监控与及时预警来保证的，所以建立完善的监控系统和及时预警是非常重要的。

提前预知和识别问题

监控和告警系统可以帮助我们实时获取系统的运行数据和指标。
通过对关键指标的监控和分析，可以提前预知系统可能出现的问题，如性能下降、异常错误、服务不可用等。
通过告警及时发现问题，可以提高问题识别的速度和准确性，便于及时采取相应的措施来修复问题。

提高故障响应和处理效率

及时发现和处理故障可以减少系统的停机时间，避免影响用户体验和业务运行。
配置监控和告警系统可以帮助运维团队更快速地响应和解决问题，减少故障的恢复时间，减少业务损失。

优化系统性能和资源利用

监控和告警系统可以实时监测系统的性能和资源利用情况，如CPU、内存、磁盘、网络等。
通过对系统的性能指标进行监控和分析，可以帮助我们了解系统的负载情况和瓶颈。
及时进行性能优化和资源扩展，以提高系统的稳定性和可扩展性。

安全风险的监测和应对

监控和告警系统还可以对系统的安全风险进行实时监测和预警。通过对异常访问、漏洞攻击、异常登录等进行监控和分析
可以帮助及时发现和应对潜在的安全风险，并保护系统和数据的安全。

关于作者

黄敬乾侠客汇JAVA开发工程师