// log 方法调用后由报错检测是否达到设置阀值，最终确认是否报错

（3）后端页面抓取服务

由于京东很多页面内容是异步加载的，像首页、单品等系统有许多第三方异步接口调用，使用后端程序抓取到的页面数据是同步的，并不能取到动态的 JavaScript 渲染的数据，所以就必须使用像 PhantomJS 这种能模拟浏览器的工具。

常规监控我们使用 PhantomJS 模拟浏览器打开页面进行抓取，然后将监控规则解析成 JavaScript 代码片段执行收集结果。

高级监控我们使用 PhantomJS 打开页面后向页面注入像 jasmine, Mocha 等类似的前端 JavaScript 测试框架，然后在页面执行对应的录入测试用例并返回结果。

规则队列生成器会将规则系统采集的规则转化类成消息队列，然后交由长时持续处理器依次处理。

为什么采用类消息队列的处理方式？

这和 PhantomJS 的性能是密不可分的，由多次实践发现，PhantomJS 并不能很好地进行并发处理，当并发过多，会导致 CPU 过载，从而导致机器宕机
在本机环境下的虚拟机中进行并发测试，数据并不理想，极限基本在 ab -n 100 -c 50 左右。 所以为了防止并发导致的问题，就选择了使用类消息队列来避免因为并发过高导致的服务不可用。

我们这里通过调用内部的分布式缓存系统生成类消息队列，队列的生成其实可以参考数据接口–队列。最基本的模型就是在缓存中创建一个 KEY ，然后根据队列数据结构的模式进行数据的插入和提取。

当然，类消息队列的中间介质可根据你实际的条件来选择，当然你也可以使用本机内存实现。这可能会导致应用和类消息队列竞争内存。

长时持续处理器是要功能就是消费规则队列生成器生成的类消息队列。

在长时持续处理器的具体实现中，我们充分利用了 JavaScript 的 setInterval 方法来持续获取累消息队列的内容下发给规则转化器，然后转发给负载均衡调度器。之后再对返回的结果进行统一处理，比如邮件或者短信报警。

PhantomJS 服务可以做为公共 API 提供给客户端进行测试需求的处理， API 通过 HTTP 方式调用。在 API 的处理上需要提供 HTTP 数据到规则和 PhantomJS 的转换。从而又演化出了 HTTP 数据到规则转换器。

首先、启动 HTTP 服务，然后将长时处理器下发的规则进行进一步转化，转化后启动子进程，HTTP 服务会监听子进程的处理结果，并在处理完毕之后返回。

报警系统我们目前使用的是京东内部自的统一监控平台 UMP，通过调用平台提供的一些 API 来实现报警邮件与短信通知。

如何根据报警到具体页面？

在用户通过监控管理系统录入规则后，监控系统会根据 UMP 规则针对用户录入的页面生成 UMP 使用的 key。当长时持续处理器发现 PhantomJS 服务返回的结果标示为异常后，就会使用 key 来进行日志记录。

报警主要分为了短信和邮件报警。邮件报警是在每条异常之后就会发给指定系统用户。短信则是根据异常次数来进行处理的，当异常次数过大，就会下发短信通知。

对于此系统部署是分为两大块进行的。因为机器资源数量有限，没有将所有部分都单独部署。

规则管理系统以及规则队列生成器和持续处理器整合部署在一台机器上，PhantomJS服务部署在了其他的机器上。进程管理使用了著名的PM2。这样就可以避免自己在开发类似的部署功能。PM2 是一个带有负载均衡功能的NodeJS应用的进程管理器。可充分利用CPU，并保证进程永远都存活。

• 内建负载均衡（使用 Node cluster 集群模块）。

不过在此次部署中，并没有使用内建负载均衡的特性，没用通过集群的方式部署代理。仅仅使用了后台运行和 0 秒停机重载的特性

其实我们现在开发的这套监控系统并不复杂，只是合理的运用了一些现有的技术框架。抽象出来我们自己需要的一些功能。但却有效的达到了我们的预期功能，并且节省了很多之前需要人肉测试的时间成本。系统本身还有很多问题在待解决状态，比如报警系统的规则处理与阀值设定，JavaScript报错的准确过滤机制等，这些问题我们都会一一解决，并且未来的前端监控系统会成为一个平台，核心服务在后端爬取页面服务，应用端可以有多种形式，比如监控、测试工具等。

• 监控系统虽然在应用层面进行了垂直划分，但是由于机器资源等限制，并没有进行单独功能的部署。这点可能会在后期的使用中进行优化。因为现在仅仅提供给本部门使用。
• PhantomJS服务还需要进一步优化，以承载大并发，大处理量。提供成稳定的服务。协同开发业务线和测试业务线制定统一的规范，以达到优化的监控。
• 报警由于依赖于公司内部的UMP系统，所以并不是特别灵活，每次系统接入都需要用户去UMP系统接入。

本规则适用于京东开放平台所有使用京东在线自主售后系统（以下简称“售后系统”）的商家。

）购物链接或未经京东许可的第三方非京东（JD.COM）链接、银行账号、第三方支付账号、二维码、非京东平台咚咚/或400电话及时通讯账号、电子邮箱、实体店地址及未经京东备案许可的联系方式、广告商品信息等；如商家有上述违规行为，京东有权按照《京东开放平台商家积分管理规则》中的一般违规”发布或推送第三方信息”对商家进行相应处理。

5.5.商家以及商家所配备的客服团队（或人员）不得在提供售后服务过程中使用任何形式的带有人身攻击、侮辱性等不文明的语言，包括但不限于诽谤、骚扰、跟踪、诋毁、谩骂消费者以及使用任何引起消费者不满的字句或以其他方式侵犯消费者的合法权益的行为。如商家有上述违规行为，京东有权按照《京东开放平台商家积分管理规则》中的严重违规”恶意骚扰客户”对商家进行相应处理。

5.6.商家以及商家所配备的客服团队（或人员）在回复消费者售后服务问题时要做到以下要求：

5.6.1.不得违反国家法律法规的规定、商家与京东合同的约定以及京东开放平台对商家的管理规定。

5.6.2.不得诋毁京东品牌形象或者京东平台上其它任何商家、品牌、产品的形象。

5.6.3.不得泄露京东的任何商业机密，包括但不仅限于商家与京东签订合同以及合作过程中所获知的与京东相关的决策、计划、技术、数据、操作流程等。

5.6.4.与京东消费者沟通时应当使用规范的用语，不得出现反动、色情和暴力等内容字句。

如商家存在第5.6项违规行为，京东有权按照《京东开放平台商家积分管理规则》中的严重违规，”扰乱平台秩序”对商家进行相应处理。

5.7.商家以及商家所配备的客服团队（或人员）违反本协议规定的任何条款，给京东、京东消费者以及其他方造成损失的，商家必须承担全部的赔偿责任，同时，如发现商家违反本规定，或有消费者对该商家发起投诉且查证属实的，京东有权不经通知而立即终止该商家继续使用售后系统。

5.8.商家应对发生在售后系统中的所有行为负完全责任，应妥善保管系统的帐号、个人信息及相关密码。对于因未经授权的人员使用商家的售后系统而可能造成的任何损失，均将由商家自行承担，如果京东为此先行承担了相关责任，则商家同意赔偿京东因此而支出的所有费用及损失。

5.9.由于商家原因或商品质量等原因，商家与消费者达成赔偿或补偿方案的，商家应承担赔偿/补偿中产生的全部费用。如商家与消费者达成的赔偿金或补偿金由京东先行垫付的，商家应自京东通知之日起5日内向京东支付相应款项，逾期未支付的京东有权自应结算的货款或保证金中扣除。

6.1.京东开放平台商家的行为，发生在本管理规则生效之日以前的，适用当时的规则。发生在本管理规则生效之日以后的，适用本规则。

6.2.京东可根据平台运营情况随时调整本管理规则并向商家公示。

6.3.商家应遵守国家法律、行政法规、部门规章等规范性文件。对任何涉嫌违反国家法律、行政法规、部门规章等规范性文件的行为，本规则已有规定的，适用于本规则。本规则尚无规定的，京东有权酌情处理。但京东对商家的处理不免除其应承担的法律责任。商家在京东的任何行为，应同时遵守与京东及其关联公司签订的各项协议。