前端异常监控解决方案研究

日志的最终目的是要使用，由于一般日志的体量都非常大，因此，要在庞大的数据中找到需要的日志记录，需要依赖比较好的搜索引擎。Splunk是一套成熟的日志存储系统，但它是付费使用的。按照Splunk的框架，Elk是Splunk的开源实现，Elk是ElasticSearch、Logstash、Kibana的结合，ES基于Lucene的存储、索引的搜索引擎；logstash是提供输入输出及转化处理插件的日志标准化管道；Kibana提供可视化和查询统计的用户界面。

一个完善的日志统计分析工具需要提供各方面方便的面板，以可视化的方式给日志管理员和开发者反馈信息。

5.1 用户纬度

同一个用户的不同请求实际上会形成不同的story线，因此，针对用户的一系列操作设计唯一的request id是有必要的。同一个用户在不同终端进行操作时，也能进行区分。用户在进行某个操作时的状态、权限等信息，也需要在日志系统中予以反应。

5.2 时间维度

一个异常是怎么发生的，需要将异常操作的前后story线串联起来观察。它不单单涉及一个用户的一次操作，甚至不限于某一个页面，而是一连串事件的最终结果。

5.3 性能维度

应用运行过程中的性能情况，例如，界面加载时间，api请求时长统计，单元计算的消耗，用户呆滞时间。

5.4 运行环境维度

应用及服务所运行的环境情况，例如应用所在的网络环境，操作系统，设备硬件信息等，服务器cpu、内存状况，网络、宽带使用情况等。

5.4 细粒度代码追踪

异常的代码stack信息，定位到发生异常的代码位置和异常堆栈。

5.6 场景回溯

通过将异常相关的用户日志连接起来，以动态的效果输出发生异常的过程。

对异常进行统计和分析只是基础，而在发现异常时可以推送和告警，甚至做到自动处理，才是一个异常监控系统应该具备的能力。

6.1 自定义触发条件的告警

a. 监控实现

当日志信息进入接入层时，就可以触发监控逻辑。当日志信息中存在较为高级别的异常时，也可以立即出发告警。告警消息队列和日志入库队列可以分开来管理，实现并行。

对入库日志信息进行统计，对异常信息进行告警。对监控异常进行响应。所谓监控异常，是指：有规律的异常一般而言都比较让人放心，比较麻烦的是突然之间的异常。例如在某一时段突然频繁接收到D级异常，虽然D级异常是不紧急一般重要，但是当监控本身发生异常时，就要提高警惕。

b. 自定义触发条件

除了系统开发时配置的默认告警条件，还应该提供给日志管理员可配置的自定义触发条件。

• 日志内含有什么内容时
• 日志统计达到什么度、量时
• 向符合什么条件的用户告警

6.2 推送渠道

可选择的途径有很多，例如邮件、短信、微信、电话。

6.3 推送频率

针对不同级别的告警，推送的频率也可以进行设定。低风险告警可以以报告的形式一天推送一次，高风险告警10分钟循环推送，直到处理人手动关闭告警开关。

6.4 自动报表

对于日志统计信息的推送，可以做到自动生成日报、周报、月报、年报并邮件发送给相关群组。

6.5 自动产生bug工单

当异常发生时，系统可以调用工单系统API实现自动生成bug单，工单关闭后反馈给监控系统，形成对异常处理的追踪信息进行记录，在报告中予以展示。

7.1 sourcemap

前端代码大部分情况都是经过压缩后发布的，上报的stack信息需要还原为源码信息，才能快速定位源码进行修改。

发布时，只部署js脚本到服务器上，将sourcemap文件上传到监控系统，在监控系统中展示stack信息时，利用sourcemap文件对stack信息进行解码，得到源码中的具体信息。

但是这里有一个问题，就是sourcemap必须和正式环境的版本对应，还必须和git中的某个commit节点对应，这样才能保证在查异常的时候可以正确利用stack信息，找到出问题所在版本的代码。这些可以通过建立CI任务，在集成化部署中增加一个部署流程，以实现这一环节。

7.2 从告警到预警

预警的本质是，预设可能出现异常的条件，当触发该条件时异常并没有真实发生，因此，可以赶在异常发生之前对用户行为进行检查，及时修复，避免异常或异常扩大。

怎么做呢？其实就是一个统计聚类的过程。将历史中发生异常的情况进行统计，从时间、地域、用户等不同维度加以统计，找出规律，并将这些规律通过算法自动加入到预警条件中，当下次触发时，及时预警。

7.3 智能修复

自动修复错误。例如，前端要求接口返回数值，但接口返回了数值型的字符串，那么可以有一种机制，监控系统发送正确数据类型模型给后端，后端在返回数据时，根据该模型控制每个字段的类型。

8.1 主动异常测试

撰写异常用例，在自动化测试系统中，加入异常测试用户。在测试或运行过程中，每发现一个异常，就将它加入到原有的异常用例列表中。

8.2 随机异常测试

模拟真实环境，在模拟器中模拟真实用户的随机操作，利用自动化脚本产生随机操作动作代码，并执行。

定义异常，例如弹出某个弹出框，包含特定内容时，就是异常。将这些测试结果记录下来，再聚类统计分析，对防御异常也很有帮助。

9.1 多客户端

一个用户在不同终端上登录，或者一个用户在登录前和登录后的状态。通过特定算法生成requestID，通过该requestId可以确定某个用户在独立客户端上的一系列操作，根据日志时序，可以梳理出用户产生异常的具体路径。

9.2 集成便捷性

前端写成包，全局引用即可完成大部分日志记录、存储和上报。在特殊逻辑里面，可以调用特定方法记录日志。

后端与应用本身的业务代码解耦，可以做成独立的服务，通过接口和第三方应用交互。利用集成部署，可以将系统随时进行扩容、移植等操作。

9.3 管理系统的可扩展

整套系统可扩展，不仅服务单应用，可支持多个应用同时运行。同一个团队下的所有应用都可以利用同一个平台进行管理。

9.4 日志系统权限

不同的人在访问日志系统时权限不同，一个访问者只能查看自己相关的应用，有些统计数据如果比较敏感，可以单独设置权限，敏感数据可脱敏。

10.1 性能监控

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!