实战 | 总有刁民想害朕——Payments打造360°监控体系的实践

供稿 | Payments 邓明&张杨编辑 | 顾欣怡本文3916字，预计阅读时间12分钟更多干货请关注“eBay技术荟”公众号

 导读 

还在为众多的BUG而愁眉苦脸，惴惴不安？

还在为应用的稳定性苦思忧虑，寝食难安？来！朕带你瞧瞧eBay帝国的皇家监控保卫团：六扇门CAL，司礼监DW，锦衣卫Pulsar以及东厂ELK！本期由Payments团队倾情呈现，360°完美监控系统，你值得拥有！

概述

近来我司SRE团队发了一个叫做《SRE重案调查组》的系列文章，里面记录了他们非常牛逼怪诞诡谲的DEBUG过程，读上去颇有一种风起云涌惊心动魄的感觉。

只不过，这一系列的文章，聚焦在特定问题上。除此之外，还有一个关键问题——即对于一个应用，尤其是业务系统来说，如何构建一个经得起考验的监控体系呢？

一个应用，从上线开始，开发者就要陷入一种焦虑：担心系统会不会崩掉，有没有什么情况没被考虑到，用户体验好不好…...

这种焦虑就像是老母亲好不容怀胎十月生下一个孩子，心里还没有松口气，又陷入另外一种忧虑，担心他吃不吃得好，睡不睡得着，会不会生病……

即便系统稳定运行一段时间之后，依旧无法遏制地觉得它会出问题。再想到半夜接到on-call电话爬起来修BUG，这种心情，大抵是，总有刁民想害朕。

这刁民，自然就是各种BUG了。常言道，我不是在修BUG，就是在写BUG；又有言道，我不是BUG的搬运工，我是BUG的生产者；我其实没BUG，BUG都是别人的……为了减轻这种“总有刁民想害朕”的焦虑，今天朕就以最近上线的系统S（某处理商家退款操作的系统）为例子，给大家科普一下如何布下天罗地网，做到全方位无死角360°旋转跳跃闭着眼的监控。

俗话说，兵马未动，狗腿先行。这第一步，当然是把朕的“六扇门”CAL放出来了……

六扇门CAL

普天之下莫非王土

CAL是什么呢？CAL是一个基于结构化日志的分布式监控系统，其全称是“Central Application Log”。点评美团CAT大家多少有所耳闻，但是很多人并不知道， CAL实际上是CAT的先驱和基石。

CAL是历史最悠久，也是最基础的监控手段，一个项目启动之际，就要考虑接入CAL。因此我喜欢把它比作“六扇门”——江湖人对衙门捕快的俗称。CAL提供了一家公司所需要的最基本的监控手段：

第一种是基于request的详细的日志数据：

图1（点击可查看大图）

这种主要用于排查问题，即DEBUG。

另一种则是应用层面上的监控。在该层次上，最主要的就是关注错误数量的统计，指标有绝对数量，同比增长，罕见错误和未期望异常等。

图2（点击可查看大图）

利用它的错误统计，我们曾经发现一个很有意思的问题。在某一次的发布中，流量逐步放开，最开始每次放开1%的流量。

在观察Error数量的时候，我们就发现有点不太对劲。按道理来说，错误数量和流量是同比例增长的关系，即如果流量增加N倍，那么错误数量也应该增加N倍。例如在10%流量的情况下，平均每分钟的错误数量是100个，那么在100%流量的情况下，平均每分钟的错误数就应该是在1000个左右，波动不会特别大。

而我们实际观察到的是：每增加1%的流量，错误数量不是同等增加1%，而是呈现出了增加5%的趋势。

很显然，此次发布必然存在有问题。而后我们找到对应Error的CAL，发现下游返回的一个响应有问题。该响应在系统中被多次用到，每一次使用，都会出现一个Error。这样就造成了Error“暴涨”的现象——这种错误和分布式环境下的“异常雪崩”倒是有几分相似。

此外，在应用层面上，CAL还监控性能相关的指标，如TPS，响应时间等。

图3（点击可查看大图）

俗话说，没有告警的监控系统是没有灵魂的，所以我们还有一个基于CAL的告警系统。该系统允许用户配置各种规则，当系统匹配触发到某条规则的时候，用户就能收到各种告警信息了。

所谓规则，就是规则之间的逻辑运算组成的复合规则以及监控指标的数学运算组成的基本规则。

图4（点击可查看大图）

在应用上线之后，都要设置好这些告警规则。常见的告警在机器层面上有：JVM full GC, GC pause time，CPU负载；在业务层面，则是依据具体的业务场景来设置，一般而言都会设置错误数量相关的告警。

CAL的告警尚且不够智能。因为这种规则设置是比较死板的，所以当收到告警的时候，并不一定就是真的出问题了。具体还要结合业务信息，或者其他监控工具的观测结果，才能断定是否真的出现了问题。

而且记录太详细也是要付出代价的。CAL的数据保存期限比较短，查询也较慢。很多情况下，当我们心急火燎地去找某个CAL记录的时候，总是“等到花儿都谢了”才找着，甚至晚一点就根本找不到了。

毋庸讳言，CAL不负其“国之柱石”的地位，每个应用接入之后，最起码的监控信息就都有了。但老话说“闻道有先后，术业有专攻”，CAL也并非全能型选手。由于其较为基础且全面，所以在一些特定的场景之下，就会显得比较无力，需要别的工具作为补充。

司礼监DW

天下文书皆汇于此

有时候，系统会发生那么一些事，这些事情单个看起来非常正常，混在一起看似乎就不那么正常了。正好比，单个刁民买一桶汽油是正常的，但是每个刁民都买一桶汽油就不正常了——买那么多汽油，除了想要烧死朕，还能是要干什么？

所以，我们需要一个全局的机构，汇总数据，进行分析和筛选。为此我们接入了数据仓库——被我比喻为司礼监，毕竟司礼监“掌天下机要”。当然也是因为要硬凑一个比喻。

DW这个东西，主要依赖于定时来产生一些报表，通过这些报表来分析一些蛛丝马迹。和CAL比起来，DW的目的性更强并且分析也更细致。

比如说，我们接入DW之后就迅速利用DW来记录S系统的错误码，以及一些错误信息。

早期我们发现，单纯看CAL的总体数量统计是不够的。有些时候，错误数量总体平稳，你去看一时半会也发现不了问题。但是如果对这些错误进行分类分析，就会发现问题。

举个“栗子”，假如我们的系统只有两种错误：A和B，那么总体数量就是A+B，这个和可以很稳定，但是某次发布之后，A下降了而B上升了，但是总和大体不变。如果不分类分析的话，是无法发现这种变化的。

我们有一份报表就是对这些错误码进行分析，将错误码进行分类，如图5所示。

图5（点击可查看大图）

曾经，我们就通过这个报表发现了一个很奇怪的错误码，是下游返回来的。后来询问了下游之后才知道，原来这个错误码和另外一个错误码，都表示退款的时候商家账号里面没有足够的钱能够退还给买家。而这个新的错误码，在当初商定接口的时候根本没有提及！

要使用DW，唯二要做的事情就是自己设计DW里面的数据表和编写数据分析脚本。

可惜的是，DW可谓是成也离线，败也离线——这个东西时效性有点差，毕竟数据汇总是一个离线的过程，是需要时间的。有时候等数据汇总起来，才发现刁民们早已买好了两卡车汽油，朕的骨头都已经被烧成灰了。

锦衣卫Pulsar

水银泻地无孔不入

按道理来说，前面两步搞完之后，似乎就可以“二世三世至于万世，传之无穷”了。然而前面这两位，都还有一个先天不足，就是它们更倾向于“事后诸葛”，即只有当我出了什么问题，它才能派上用场。

那能不能防患于未然呢？这当然是可以的，最简单的莫过于将可能出问题的地方纳入严密的监管之下。就像古时候帝王为了防止将军做大，又或者王爷靖难而在他们身边布下暗子密探。这个东西在明朝有一个显赫的名字——锦衣卫。在传说中，锦衣卫可是在全国各个角落都埋了无数的暗桩间谍密探的。

这个锦衣卫，就是Pulsar了。Pulsar是什么东西呢？简单来说，就是用来埋点的。

埋点是为了获得结果指标或者过程指标。当一个新功能上线之后，用户从进入首页到下单，这一过程的转化率是否有提高，就是结果指标。而像用户行为分析，分析用户页面访问行为，包括用户驻留时间，跳转URL等等，就是过程指标。图6则是我们的一个页面访问路径：

图6（点击可查看大图）

东厂ELK

缇骑四出缉拿天下

可是，经过一番思考之后，朕总觉得前面那几位还是不够让人放心。

比如某天，我们想要搞个比较复杂的搜索，像是某个时间段内因某两个原因退款失败的订单号，又或者是根据某些关键字来搜索日志，那么前面的所有工具都要懵逼了。

因此，我们需要一个更加狗腿的机构，这个机构就是以朕的喜好为目的，让偷狗就绝不辇鸡。这就只能是ELK了！ELK全称是“Elasticsearch-Logstash-Kibana”，俗称“日志三宝”。一个目的性更强，实时性更好，搜索更强大的监控工具。

首先，它支持更加细粒度的统计数据。例如针对URL请求，它可以细化到具体URL请求的数量：

图7（点击可查看大图）

其次，它有强大的搜索功能。CAL虽然也支持文本搜索，但是实在难用而且性能太糟糕。而对于ELK，ES能够做到多强大的搜索，它就能够展示多丰富多复杂的数据，如图8所示：

图8（点击可查看大图）

我们之前借助ELK发现一个很有意思的现象，可以看作是一个监控数据改进业务的案例。

接入了ELK之后，有一个柱形图引起了我们的兴趣：

图9（点击可查看大图）

为什么说有趣呢？因为我们看到之所以退款失败，很大程度上是因为CONFLICT_CASE_EXIST。

图9中的错误信息表示的是，如果这个订单已经有一个“售后流程”（如退款、订单取消、退货等）在处理中，那么就不允许再一次发起退款。比如说该订单已经发起了一个退款，那么再次尝试发起退款就会失败。

又或者说这个订单有多个商品，之前买家退货了其中一部分，那么也不允许退款。

这实际上是一种过于严苛的业务逻辑了。因为在前面举例的两种情况下，禁止是毫无道理的，反而应该放开这种限制，这样能带来更好的用户体验。如今，这种改进已经提上议程，就等发布上线了。

ELK并不是无侵入式的。我们需要根据自身的监控目标来设计ES索引，而后在业务代码里面嵌入日志采集代码。

总结

现在我们需要全方面讨论一下这些工具了。毕竟有对比才有伤害。

一般会从四个角度来衡量一个监控的功效（如图10所示）：

1. 系统故障：如机器自身的状态，网络的状态；
2. 业务指标：如业务出错量，订单量，成交金额等；
3. 应用性能：如各个服务的响应时间；
4. 用户行为：如用户的输入输出特征，页面驻留特征。

图10（点击可查看大图）

而判断一个工具好不好用则是从四个角度来衡量（如图11所示）：

1. 数据详细程度，是否含有统计数据；
2. 时效性；
3. 数据保存期限；
4. 查询速度。

图11（点击可查看大图）

如果用排兵布阵来形容我们Payments的监控体系，那么应该：

1）以CAL为中军——最为基础的监控；

2）DW和Pulsar为两翼——能够提供各有特色的监控内容；

3）ELK为前锋——逢山开路遇水搭桥，也是最为精锐的部分。

最后有一个十分有趣的问题。这个问题要从本文的核心思想所代表的矛盾心理开始说起：即我们研发团队这种“总有刁民想害朕”的心理，十分贴近有罪推定——反正看谁都不像是好人。然而使用监控工具却又是一种无罪推定的手法——从监控数据里面收集证据构造一条“证据链”，最终证明系统真的出了问题。

“证据链”是一种法学上的说法，强调的是证据之间互为印证。比如口供可能是屈打成招，人证可能被买通，物证可能是伪造的。但是三者合在一起，互相印证之下，真相就无所遁形。

在监控里面则是，单个监控工具很可能错报、漏报、误报。但是多个监控工具组合之后，就不太可能出错了。就我们引入的这些工具而言，一般来说，任何一个都可能发现“潜在问题”。这时，要做的就是去其它工具收集更多信息，进行多方验证。最终断定系统究竟是健康还是不健康。

那么，在你的监控体系里，是如何构造一条稳固证据链的呢？

作者介绍

邓明 (Ming)：Payments产品开发工程师

一位上能撸码，下能撰文的小萌新

张杨 (Frank)：Payments产品开发工程师

能搞定从遗留系统改造到使用最新技术栈产品开发的“攻城狮”一枚 ，在payments内部的技术问题，stack overflow解决不了的，可以问Frank :-)

您可能还感兴趣：

干货 | eBay Kubernetes集群的存储实践实战 | eBay PB级日志系统的存储方案实践SRE重案调查组 第一集 | 高延迟问题的罪魁祸首System.gc()SRE重案调查组 第二集 | 挖掘应用处理变慢的“真相”SRE重案调查组 第三集 | 探秘HTTP异步请求的“潘多拉魔盒”SRE重案调查组 第四集 | JVM元数据区的内存泄漏之谜SRE重案调查组 第六集 | 剖析Java的非常规线程死锁问题

eBay2020校招现已正式启动！详情点击下方链接：2020校招 | eBay空中宣讲会倒计时3天！2020校招 | 拿好这份笔试攻略，你就是过儿2020校招 | 你想要的eBay全都有！eBay校园招聘正式启动！2020校招 | eBay内推集结号就等你来！

你还可以：

↓点击阅读原文，直接开启网申之旅~