对服务进行指标监控是帮助提升服务质量、提高排查问题开发效率、降低错误耗费损失的手段。
从近两天对服务进行监控的设计与实现中，我发现这是一件有价值且有技巧的事情，如何攫取出合适且有利的监控指标，设计直观的可视化监控图表以及有助于问题排查的上报数据结构都是重要的。
本文将围绕案例，分析如何综合考量服务的监控指标，并给出实践建议。
技术上基于ELK生态，Grafana可视化。下文中的Panel指的是Grafana的图表单位。
为什么要监控服务？
一个线上服务要能恒久地对外服务，其稳定性是一个重要的因素。服务被调用次数的震荡、调用耗时的变化都能反应出服务当前的状况如何。通过监控和告警，使开发者能查看到其异变，以及时对服务进行扩容、改进等措施。
可视化的监控能直观地反应出服务在某时某刻的反常现象，通过对反常现象的时间定位，能更好地帮助开发者排查问题，找到问题所在的日志，减轻解决bug所耗费的时间，提高维护服务的效率。
对服务进行业务指标监控，可以反应现实场景下的用户行为，能带来一定的数据分析价值，给优化特定场景下的服务质量带来可能。
服务往往不是独立的，其上下游的情况也能从一定的程度上反应服务的质量，故监控其对上下游的通信情况(调用耗时、调用结果)也是可考虑的。而此间，有可能会涉及到消息队列、缓存中间件等通信指标，这些都有可能成为性能的瓶颈，所以有必要监控包括队列积压、队列消息延迟、缓存命中等指标。
如何分析监控指标并实现？
摒弃无用的，攫取有观察价值的指标。
总的方向就是要尽量让每一个可视化的监控都能反映出某种问题发生的可能性。
简单的说，监控服务接口的QPS是最为常见的，这可能可以发现接口被刷的问题。而监控耗时变化可能发现IO的异常。
要列举出所有可能的指标，可以从一些角度上出发：比如可以从全盘到部分（如果服务是对接多个上游提供统一服务），也可以分别从接口层面、上下游层面、质量层面、业务层面等来分析。
从全盘到部分
示例服务介绍
榜单输出服务是一个统一的服务，输出多个榜单的数据，调用方给定榜单名称即可得到该榜单的数据。其为多个调用方服务。由于只有一个接口，所以只能对该接口的情况进行监控。代码中打点一个上报日志，服务所在机器的IP、请求的榜单名称、接口调用耗时。
设计监控
按照从全盘到部分的思路，首先我们可以监控：
- 获取榜单接口的QPS
- 获取榜单接口的耗时
这两个指标反映服务的整体表现。但是由于有多个榜单要输出，所以有几个监控：
- 各个榜单数据的被请求次数
- 各个榜单被请求所花费的时间
第二个的耗时监控使用三分位：50\85\95 ，以体现整体和局部水平。
其中第一个监控，在一个Panel中多条曲线表示多个榜单的被请求次数。这能看出榜单的差别，但是，无法形象地看出各个榜单在总请求调用次数的占比。所以可以添加一个监控：
- 各个榜单在一段时间范围内被调次数的占比
这个监控需要使用饼图来表示，也是整体到部分的体现。
除了上述的监控以外，对于各个提供服务的主机，也是可以进行监控的，可以对不同的主机的QPS、耗时进行监控，以了解每台机器的状况。
从被监控服务的多个维度
服务介绍
UniteCashOut是一个统一的提现服务，为各个平台提供积分兑换成现金并提现到用户个人的服务，其中积分兑换是多档位的，不同量的积分可以兑换不同数量的现金。
服务暴露出若干接口，诸如查询各个档位的信息、发起提现订单、确认提现订单并进行提现、查询提现订单。
服务拥有若干上游，拥有一个下游，用于将指定金额提现到用户的微信或者QQ钱包账户中。
服务不仅需要从下游获取消息来确定提现是否成功，还要通过给上游发送消息来告知提现成功。
思路
从结果到实现
不同于上一个示例，这个服务是一个多接口的、有完整流程的、有上下游且多接入方的服务，那么在编码中就会有不止一处的上报数据。
我们循“从结果到实现”的思路来设计并实现监控。这如同设计产品，要所见即所得，从结果入手（监控可视化Panel），然后再逐步实现。
步骤
完成一次可视化监控开发的步骤可以是：
- 综合考察服务的上下游、接口、技术、性能。
- 初步拟定每一个Panel所应该展示的信息，从各个维度来思考。
- 同其他团队成员评审拟定的Panel预案，对其进行修订。
- 确定好有哪些Panel，并针对其考虑有哪些上报数据。
- 考虑上报数据的点位（在何中处境下进行数据上报）。
- 设计上报数据结构，进行编码实现上报。
- 在Grafana中配置Panel。
上述步骤中，第三项是重要的，这有助你设计出有价值的可视化服务监控，能帮助你理解项目的多维度。
而第四、五项中需要考虑的上报数据包含哪些上下文信息，值得注意的是：
不要惧怕上报的数据可能不会在可视化图表中展现，丰富的上下文信息能帮助你解决未来潜在的问题。
上下文信息的意义更在于日志记录，避免出现问题时查询繁多的日志。
第六步中，你需要综合考虑所有的Panel需求，设计出精简的上报数据点位，避免无意义的多次上报。
多维度设计Panel
这一小节主要是讲述第三步和第四步。
监控的维度可以是多样的，接口、上下游、质量、业务都是可选的维度。
接口维度
对每一个必要的接口进行监控，这样的接口尽量是可能产生浮动的接口，如果有些接口是不常用的，那可能是没有什么监控价值的。
从QPS、耗时来监控接口，其中耗时可以用多个分位来展示。
上下游维度
由于服务由多个上游，你可以分别对不同的上游进行Panel定制，以了解到服务为多个接入方提供服务的质量。
而服务对下游的调用，可能直接会影响到服务质量，那么调用返回的结果将会是改进服务的一个切入点，你可以监控调用下游的时间、次数，及调用是否是成功的。通过一个饼图即可反应出返回结果的错误分布。
除此之外，在这个示例服务中，还存在上下游的消息传递，消息队列的延时也会是可考虑的监控指标。
质量
一个流程（本例中是从下订单到提现完成）的完成，是有一定的时间的，如果这个时间超出了预期，那么服务的质量是不佳的，必须进行调整，所以，这个整体流程时间是可考量的监控指标。
业务
业务指标当然是视情况而定的。
在本例中，提现金额是一个指标，如果Panel能反应处某时某刻的提现金额超出预期，那么可能产生了重大的Bug，如果说今日的提现金额和昨日对比有巨大差异，那么需要分析产生这种现象的原因。
所以可以用一个Panel对表示金额同期对比，也可以用Panel来表达不同接入方的提现金额分布。
分析上报点位与数据结构
在足够了解代码的逻辑之后，你才应该去插入上报数据的代码。
而在此之前，有两点尤为重要的考虑：
- 数据的采集应当准确。
- 数据包含足够有价值的上下文信息。
要让数据采集正确，譬如能采集到所有的耗时信息，你需要包裹住你要测量的代码，并防止其中产生的异常妨碍到耗时的采集。
有价值的上下文信息，在本示例中，譬如用户的订单信息、提现金额信息、用户的IP都是值得包含的，通过Kibana的索引功能，你可以通过这些上下文信息来定位问题。（这是取代打印日志的好办法）
在Grafana中配置Panel
前面所有的准备都是为了这一步的配置。
这一小节中，将对Grafana的基本功能作阐述，这将帮助你快速了解它的能力，以及快速上手。
Grafana监控的基本单位是Panel，可以简单理解为一个可视化的图表。
若干个Panel组成一个Dashboard，也就是一整个监控版面。
每一个Panel你都可以配置来自同一个数据源的多个查询，但是DashBoard不要求你的所有Panel都查询自同一个数据源。
