运维千问——浅谈如何做后端服务的业务监控？

我们都知道服务器层面的基础监控已经是玲琅满目，可以说是层出不穷，比如各大云厂商自带的基础设施的监控，基本能满足我们的需求。即使你是使用了多云的业务部署架构，那也可以轻易办到，比如使用open-falcon或者夜莺等开源监控系统，再比如比较流行的grafana prometheus，Zabbix等国外监控系统，使用分布式架构采用默认指标就可以满足我们的需求，但是针对于业务监控，可能有些公司有自己的想法，也可能捉襟见肘。这篇文章我们可以一起从运维的角度探讨，如何做后端业务指标的监控，当然本文仅仅是一种参考思路，不作为上线依据。

一什么是业务监控

个人理解的业务监控，是指针对业务层的异常指标开展的搜集/汇聚/存储/分析/告警/可视化等一系列流程系统化的过程。当然，业务监控具备实时性，数据量大等特点。通过业务监控可以帮助公司提升业务质量和服务质量，细节一点可以说是帮住业务开发者及时的发现/跟踪/预测问题，帮助业务完善业务逻辑，用户数据分析等。所以做业务监控要明确要监控什么，哪些指标是有意义的，以及如何去实现。

二如何做业务监控

因为是涉及到搜集/汇聚/存储/分析/告警/可视化等一系列流程系的系统化，我们也不防拆开看。

2.1 搜集业务数据

这个很好说，就是通过日志打点搜集，或者服务埋点推送的方式搜集数据。一般而言通过日志埋点，需要要求研发人员将业务日志按照一定的规则打印，这个实现方法也很简单，公司总体出一份统一格式的日志SDK，按照格式打印。然后使用filebeat等工具格式化采集，或者自研工具采集。再将数据推送到kafka等消息通道缓存，kafka上游自然也存在消费者去消费托送的日志格式化数据。

还有一种方法是业务服务自己推送数据到kafka等，一般是不推荐这样处理，因为其对服务性能有一定的消耗，尤其是业务量比较大的服务。

2.2 汇聚与存储

汇聚一词一般我们可以想象是从溪流汇聚成江河，江河汇聚成大海，数据的汇聚也是一个意思。因为我们可能有成百上千个服务，分布在不同的主机或者容器，然后还有可能存在多节点，多云的场景；那么我们怎么汇聚所有的数据到中心节点呢？从服务侧搜集过来的数据我们其实多称为元数据，这个数据是未经过加工处理的，当推送到当前节点的kafka集群之后，其上游消费者来消费，上游消费者一般是在元数据节点之外，可以在中心节点，也可以在中心节点与元数据节点之间，这个要看具体的业务架构情况而定。因为消费来的数据一般是用来存储和分析使用，所以个人建议可以给上游消费服务下发汇聚策略，比如计算一分钟内的流量，求和，最大值，最小值，方差等，用于消减数据体量，分担计算压力。当然如果你的需求是保留元数据也是可以不做策略处理。

由于监控数据都是实时的，所以少不了使用时序数据库存储，一般业界比较流行的有 TencentDB

/influxDB/TDengine/OpenTSDB等，各有千秋，可以根据需要选用。

2.3 可视化和告警

数据有了，那么接下来可以对数据做一些展示和告警处理。当然前提条件是分析数据。当然这里也是基础的分析，比如环比数据，同比数据，增幅，降幅等等。这些常用的数据分析一般都有固定的算法支撑，我们需要做的是明确你的指标符合那种场景，即那种场景经过分析后能够快速帮你达到目的。这些分析后的数据可以是基于预先制定的分析策略实施，也可以裸奔的。最后将分析后的数据展示于面板，并适用于告警策略。

数据的可视化，一般公司都会有基础业务指标的展示，按照年月日时等，还可以查看环比同比等。另外公司也会有一些炫酷的dashbord，这些投放于大屏公领导观测，以制定有效决策。最重要的是告警，告警策略最好具有普适性和自动化性，普适性是指针对所有指标都可以使用于某个规则，自动化性是指，在添加告警规则时能够根据服务的特性自动化实施一系列指标，而非人为的一个个操作。另外建议告警链接到工单系统，推送给责任人，谁制造麻烦谁解决，解决方案等也可以记录在工单系统。